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. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
