BTW, looking at the spec for pthread_cond_wait, there's actually no
mention about a limitation regarding using pthread_cond_signal invoked
from within a signal handler to unblock a pthread_cond_wait. However,
this does not work
either for me. If you follow the signal operation, I can see that when
it reaches the nxsem_get_value() on the cond->sem, the semaphore value
is zero and the sem_give is not done.
Should this work?
Yes, calling pthread_cond_signal() should work, however, no signal
should be delivered. The word "signal" is overloaded: Here the
condition is signaled but no signal should be sent so I am not quite
sure what I am looking at. Apparently some other logic is signaling the
task group asynchronously?
I am thinking that there must be some race condition: When the
condition variable is created the cond->sem value will be set to zero.
While waiting for cond->sem, it will be set to -1. If you see cond->sem
equal to zero, my guess would be that the signal was received and
cond->sem was incremented asychronously by the signal delivery logic.
But that is only a guess.
It would be good to check the behavior without the signal interfering.
