[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
