[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Aug 2014 01:20:25 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: My current understanding of cond var access restrictions
Hi,
Am Mittwoch, den 13.08.2014, 17:23 -0400 schrieb Rich Felker:
> 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.
I think so.
But have in mind that all what you say, strongly relies on
implementing each of the control structures as one monolithic
object. As soon as you split conditions into two parts (one the user
space interface, one an internal synchronization structure that is
allocated separately) part of the trouble disappears.
I know that you don't like that "split" approach for the disadvantages
that dynamic allocation has. But I think that the standard(s) clearly
have such an implementation in mind when they speak of init functions
allocating the necessary resources for a control structure.
> 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).
I think this can be summarized in that the thread that does the
destruction must be able to establish a happens-before relation
between all pthread_cond_[timed]wait operations and the final wake
operation. In current POSIX this relation can only be established by
mutexes or similar synchronization mechanisms. Once C11 will be
integrated to POSIX, atomic operations will be added to that.
> 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.
I don't have thought enough about the shared case, yet, since it
doesn't appear for C threads. But my first view is to agree with what
you write in #864.
> 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.
ok
> 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.
Are you suggesting that all waiters when coming back should first
regain an internal lock on the cv?
> 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.
so again this suggests an internal lock on the cv that would be used
to synchronize between waiters and wakers?
> (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.)
an important distinction, I agree
> Since it seems impossible to implement a cv without accessing the cv
> object after the mutex unlock (even in the minimal implementation,
This supposing that the mutex unlock operation and the wait operation
are done with two different system calls.
> it's necessary to have at least one read access for the futex wait), I
> think this means an internal synchronization mechanism is necessary.
If by internal synchronization you mean that the transition from the
unlock to the wait only has to appear to be atomic (the ``as-if''
rule), yes.
> 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.
yes
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
