[Xenomai] The task calling pthread_cond_signal() has to own the lock

Giulio Moro g.moro at qmul.ac.uk
Mon Oct 2 16:25:28 CEST 2017

> libcobalt enforces the requirement to hold the lock so that optimizing
> the wake up process is possible - under the assumption that the caller
> owns the lock. There is no hack around this.

Then I would suggest that pthread_cond_signal() should return an error code if the caller does not own the mutex. Currently it returns 0 (success), which is pretty confusing. I am happy to help bringing the documentation up to date once this is done.

Am I right to say that the waiting thread will only be unblocked after the lock has been released from the calling thread, thus avoiding a potential deadlock situation?


More information about the Xenomai mailing list