bachlipp@[EMAIL PROTECTED]
wrote:
>
> 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?
>
> 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?
>
> 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).
It doesn't conform to the current POSIX (which doesn't allow thread
races on any thread-shared "memory location"). I read Burrow's solution
as a non-conforming optimization of the classic DCSI-TLS aiming at
reduction of number of thread-specific (thread-local) variables to a
single one instead of having one thread-specific flag per pthread_once_t
instance (solution which is conforming under the current XBD 4.10...
modulo POSIX-undefined term "memory location" :-) ). BTW, regarding
"_fast_pthread_once_per_thread_epoch" (line 2), I don't think that there
a need for that "if" (including fetch to x) given the precondition for
entering slow path.
regards,
alexander.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
