[Xenomai] The task calling pthread_cond_signal() has to own the lock
rpm at xenomai.org
Mon Oct 2 16:18:15 CEST 2017
On 10/02/2017 04:08 PM, Giulio Moro wrote:
> I am using condition variables with the Posix skin on Xenomai 3.0.5
> I find that if the thread calling pthread_cond_signal() has not acquired the lock associated with the condition variable, the waiting thread is not resumed. Is this expected behaviour? As
> According to the Posix specifications (referenced by the Xenomai docs):
> "The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() "
> therefore, I think that what I observe is unexpected behaviour.
> Note: I am happy for my use case to accept the non-deterministic behaviour caused by the signalling thread not acquiring the lock.
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.
More information about the Xenomai