what would cause go to spend so much time in runtime.pthread_cond_signal

Question

I have written a multi-goroutine benchmark test in go. And I use the go tool pprof to analyze how to optimize my code. When I use top10 to show some information, I got the following outputs:

Showing top 10 nodes out of 167
      flat  flat%   sum%        cum   cum%
    4700ms 17.86% 17.86%     4700ms 17.86%  runtime.pthread_cond_signal
    1790ms  6.80% 24.66%     1790ms  6.80%  cmpbody
    1470ms  5.59% 30.24%     1620ms  6.16%  syscall.syscall
    1360ms  5.17% 35.41%     3280ms 12.46%  runtime.scanobject
    1170ms  4.45% 39.86%     1410ms  5.36%  runtime.findObject
     960ms  3.65% 43.50%      960ms  3.65%  runtime.pthread_cond_wait
     950ms  3.61% 47.11%      950ms  3.61%  runtime.memmove
     650ms  2.47% 49.58%      650ms  2.47%  runtime.usleep
     650ms  2.47% 52.05%     2490ms  9.46%  talent.TopN.func1
     630ms  2.39% 54.45%     2890ms 10.98%  runtime.mallocgc

It's obviously that the runtime.pthread_cond_signal spend so much time in my code. I try to google to search some usable information about runtime.pthread_cond_signal. But failed to got them. Though Some posts have mentioned it, they just provide few tips, and keep me still confused about it.

I guess that this situation is relative about the channel's usage in Go, but I am not sure about my opinion, and I also don't know some details about that.

What I want to know is the following:

1. What would cause go to spend so much time in runtime.pthread_cond_signal usually?

2. In normal conditions，how to optimize your go code when this situation happens？

Feel free to provide any information and advice. I would appreciate to receive any help from you.

Answer 1

This likely means your code is doing a lot of locking/unlocking. pthread_cond_signal is used to notify condition variables, and is only used by Go on OSX, it seems. It's used in the implementation of semawakeup which itself is used in the unlock primitive, which is used everywhere locking/unlocking is done.

As the comments suggested, try the (web) command in go tool pprof to see where these calls are made from.

It's hard to provide more details without seeing your specific benchmark.