bachlipp@[EMAIL PROTECTED]
writes:
> Dear C++ memory model experts,
>
> yesterday I skimmed through the sources of the latest Boost.Thread
> library, especially the POSIX Threads implementation of
> boost::call_once(). It fundamentally changed in the past. The current
> implementation quotes the ISO/IEC JTC1 SC22 WG21 N2444 do***ent
> (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2444.html>)
> and uses an algorithm by Mike Burrow published there.
>
> After reading especially Meyers / Alexandrescu: "C++ and the Perils of
> Double-Checked Locking" (<http://www.aristeia.com/Papers/
> DDJ_Jul_Aug_2004_revised.pdf>) (and for Java: Bacon et al.: "The
> 'Double-Checked Locking is Broken' Declaration" (<http://
> www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html>)) I
> want to ask the following:
>
> 1. Following several threads on the atomicity with regard to signals
> and non-atomicity with regard to threads of sig_atomic_t (or another
> integral type in the Boost implementation) my question is as follows:
> Can the [atomicity] and [atomicity2] requirements really be ****tably
> fulfilled on POSIX Threads systems? But do we really need this
> requirement at all for the proof?
They are not guaranteed by POSIX, however every architecture I am aware of
has
some data type that can be read as a single unit without risk of tearing.
On
some systems that's only a byte, but on the platforms sup****ted by boost,
a
suitably-aligned int satisfies that condition.
> 2. I miss one argument in the correctness reasoning layed out by
> Burrow: "_fast_pthread_once_per_thread_epoch" (line 2) implies a
> memory barrier. He mentions that the second
> "pthread_mutex_lock()" (line 8) is assumed to provide release
> consistency. So in total we end up with the two barriers declared
> necessary on Page 12 (the multiprocessor Section) of the Meyers /
> Alexandrescu paper. Or do I miss something here?
Line 2 doesn't imply a barrier. In fact, that's the whole point of the
algorithm: the "fast path" has no barriers. If a thread has seen this
once_flag be initialized already, or has seen a once_flag that was
initialized
after this one, no locking is required. Since all the once_flags are
protected
with the same mutex, this is acceptable.
> So, I believe the code is correct, but as the correctness of such a
> central piece of software is vital, someone - including me - should
> take the time to contribute to such a "mental exercise" (Burrow).
I believe the proof in N2444 is sufficient.
Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
