Consider if you used pthread_cond_broadcast instead of pthread_cond_signal. All threads that are in a pthread_cond_wait on the conditions are signaled to wake up. Only one of them can because in order to exit pthread_cond_wait they each must reacquire the mutex. The one that gets the mutex finishes and unlocks the mutex, and then the next one gets the mutex. Despite being a performance hit from waking more threads than needed, this should not change the correct function of code that is using of pthread_cond_wait properly.
From the manpage for pthread_cond_wait:
"Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur."
When a thread returns from a pthread_cond_wait it should check that there is data (that was protected by the mutex) that indicates it can actually proceed. Typicaly this involves the thread that performed the pthread_cond_signal incrementing a count or setting a flag (protected by the mutex), and the thread that received the pthread_cond_wait looping on the the wait call while the flag value is zero, and if its not zero decrementing the flag before it leaves its mutex protected section.
I don't see the expected loop, nor the signaling value addressed in the snippit you provided.