Date: Wed, 13 Aug 2014 17:23:58 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: My current understanding of cond var access restrictions Since this has all gotten really confusing, I've written up a summary of my current understanding of access- and destruction-related issues with cond vars. Jens, I'd appreciate it if you could comment on whether the below text seems to match your understanding. Hopefully this will help us work out a design that solves the current flaws (of which I suspect there are many). 1. When can a cv be destroyed? After a return from pthread_cond_broadcast when the program has ensured that there will be no new waiters or signalers. After a return from pthread_cond_signal when there is only one waiter and the program has ensured that there will be no new waiters or signalers. After a return from pthread_cond_[timed]wait when there are no other waiters or sufficiently many wakes (possibly via a broadcast) have been performed to unblock all waiters, and the program has ensured that there will be no new waiters or signalers. In the case where the program is relying on the wake being the result of a signal in order to ensure that no further signals happen, it is MANDATORY that the signal be performed while holding the mutex (or that some other form of synchronization with the signaling thread be used). Otherwise there is no way for the woken thread to establish that its wake was a result of the signal operation and not a spurious wake just before the signal operation (in which case the subsequent signal operation would be an illegal use of the cv after destruction). 2. When can a shared cv be unmapped? This is unclear pending the resolution of Austin Group issue #864: http://austingroupbugs.net/view.php?id=864 For the time being I think we should operate with the assumption that it's valid to unmap (without destroying) at any time that destroying would be valid. 3. When can the mutex associated with a cv be destroyed? After a return from pthread_cond_[timed]wait when there are no other waiters, and the program has ensured that there will be no new waiters or other attempts to use the mutex. 4. When can signal and broadcast safely use the mutex? Not at all, unless it can block waiters from exiting the wait. Any waiter could spontaneously exit the wait as a result of cancellation, timeout, or a cv signal from another thread, and by the above, it may be entitled to destroy the mutex. 5. When can [timed]wait safely access the cv? Only before unlocking the mutex, unless the implementation synchronizes with possible signaling threads, or with destruction (and possibly unmapping). Otherwise, per the above, it's possible that a signaling thread destroys the cv. (The reason the mutex unlocking is significant is that becoming a waiter is specified to be atomic with unlocking the mutex; before the mutex is unlocked, the thread is formally "about to become a waiter" rather than "already a waiter" and thus not subject to signals but instead is a "future waiter" that would make it illegal to destroy after signaling.) Since it seems impossible to implement a cv without accessing the cv object after the mutex unlock (even in the minimal implementation, it's necessary to have at least one read access for the futex wait), I think this means an internal synchronization mechanism is necessary. 6. When can signal/broadcast safely access the cv? Since it's impossible for a woken waiter to determine whether it woke spuriously or as a result of signal/broadcast, and it's impossible to know whether the signal/broadcast was actually called yet without further synchronization after signal/broadcast returns (either by unlocking the mutex, if the signal was performed with the mutex held, or via some other mechanism), signal/broadcast has unlimited access to the cv object for the entire duration of the call.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.