Douglas Gregor 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.

[...] Very likely! I noticed similar problems with intel 9 on a hyperthreading machine: http://tinyurl.com/cmq5r Stefan

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

This looks very nice. However, using static_mutex would create a dependency on Boost.Regex for all Spirit MT code. I hope static_mutex will eventually become a part of Boost.Thread.

Good point, I've been meaning to make it header only, but haven't had cause to really up until now.

I changed the offending code to use boost::call_once() for mutex initialization (following a suggestion Peter Dimov made in another thread related to a similar problem). The test passes on OSL2 (darwin-gcc-3.3 toolset) now.

That call_once idea is really cunning. Embarrissingly I only invented static_mutex because I couldn't think of a way of getting call_once to do what I wanted! Just thinking off the top of my head, I wonder if the technique could be boilerplated: template <class Mutex, class id> Mutex& get_static_mutex(); // returns an instance of Mutex that is unique to "id". Extreme Usage Example: ~~~~~~~~~~~~~~~~~ template <class T1, class T2> struct mytag; template <class T1, class T2> void myproceedure(T1 t1, T2 t2) { // get a mutex instance that is unique to this function, *and* the types T1 and T2: boost::mutex m& = get_static_mutex<boost::mutex, mytag<T1,T2> >(); boost::mutex::lock l(m); // thread safe code goes here: // etc.... } Implementation: ~~~~~~~~~~~ All untried: template <class Mut, class Tag> Mut& do_get_mutex() { static Mut m; return m; } template <class Mut, class Tag> void call_once_proc() { do_get_mutex(); } template <class Mutex, class id> Mutex& get_static_mutex() { boost::once_flag once = BOOST_ONCE_INIT; boost::call_once(&call_once_proc<Mutex, id>, once); return do_get_mutex<Mutex, id>(); } How does this look as an extension to Boost.Threads? Unless I've missed something (!) it should work for any mutex type. Actually shouldn't this work for any global variable that you want initialised in a thread safe manner? You know the more I think about this, the more I worry about what I've missed, it can't be this simple can it? Regards, John.