Does pthread_cond_wait put the calling thread to wait state to be waken up by pthread_cond_signal/pthread_cond_broadcast, so that it does not poll and churn the CPU?
Also, does sem_wait put the thread in wait state? If I understand correctly the mutex acquire/release methods make the threads poll continuously on the mutex and do not put the thread in waiting state.
Yes, pthread_cond_wait, when successful, causes the thread to wait until notified. That is the purpose of the call.
sem_wait will put the thread in the wait state if the semaphore cannot be decremented. In it's in a high state, then the call will return immediately.
In most situations, you needn't concern yourself with whether the locks are implemented via busy-waiting or scheduler yielding. Either way, you get the guaranteed behavior, and generally the library implementer will choose the most efficient method available on the platform on which you are running. In some cases (where you have more than one core and the expected wait time is small) that's busy-waiting.
Yes, the task which calls pthread_cond_wait() will be put into wait state:
pthread_cond_wait atomically releases mutex and cause the
calling thread to block on the condition variable cond
In the internal of current linux, it uses futex to do the stuffs.
sem_wait will block the task until either it becomes possible to perform the decrement for the semaphore if the semaphore currently has the value zero when call.
