[Xenomai] The task calling pthread_cond_signal() has to own the lock
rpm at xenomai.org
Mon Oct 2 16:45:42 CEST 2017
On 10/02/2017 04:25 PM, Giulio Moro wrote:
>> 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.
I don't think so. Success here means nobody owns the mutex, including
the caller; you could have another thread owning that mutex, preventing
libcobalt to take the fast path (by returning 0 immediately).
At any rate, if the application does not care for serializing accesses
to condvars, accepting a fundamentally racy behavior, the kernel is
entitled to tell such app that everything was fine.
> 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?
I don't see any deadlock situation in that case, but yes, libcobalt only
resumes a convar waiter when the lock covering it is released, to
prevent a double context switch, would the waiter had a higher priority
than the thread signaling the condvar.
More information about the Xenomai