Re: [boost] Regressions in your Boost libraries as of 2005-07-19

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-07-23 13:00:57

John Maddock wrote:
>>The problem only shows up on my dual-processor G5, and never seemed to
>>happen on single-processor systems, so we have some kind of race
>>condition. Looking more carefully at the Spirit source, I see this:
>>
>>#ifdef BOOST_SPIRIT_THREADSAFE
>>                static boost::mutex mutex;
>>                boost::mutex::scoped_lock lock(mutex);
>>#endif
>>
>>I don't think that's valid, because two threads could try to initialize
>>the static at the same time. We'd need to do some other kind of locking
>>in here, then create the mutex on the heap.
> 
> 
> Right that code absolutely will create a race condition in the mutex 
> initialisation.
> 
> If it helps any regex has a static_mutex class that is initialised with a 
> static initialiser list (so no race condition), I've been meaning to polish 
> this off as a formal submission, but in the mean time the code is here: 
> boost/regex/pending/static_mutex.hpp.

Yey! No more spirit regressions. Thanks to Doug, Stefan and the
tip from John. Alas, we were not able to use the regex code
because it is not header only. So, thanks to Martin Wille who
did the fix based on Peter Dimov's suggestion a few months ago.

Quoting Martin:

A similar problem was lurking in the phoenix closure implementation.

I hope both are fixed now. I used the technique Peter Dimov suggested 
some time ago:

X & instance()
{
    static X x;
    return x;
}

void f()
{
    call_once( instance );
    X /*const*/ & x = instance();
    // use x
}

(My code uses a function-local static boost::call_once instance that 
gets initialized with a static initializer to guard the construction of 
the offending mutex.)

Of course, the MT code now is even uglier than it used to be before.

The tests pass *here*. However, that doesn't imply anything but 
syntactical correctness, since this is a single-CPU box. Let's await the 
other results.

Affected files: object_with_id.ipp and phoenix/closures.hpp

....

Again, thanks to everyone! I learn a lot from you guys!

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net