Boost logo

Threads-Devel :

From: Anthony Williams (anthony_at_[hidden])
Date: 2006-03-06 11:32:08

David Abrahams <dave_at_[hidden]> writes:

> Anthony Williams <anthony_at_[hidden]> writes:
>>> Okay, two different types. But why is static_mutex needed? I still
>>> haven't seen a good argument, given that you need once routines to
>>> initialize the shared data anyway.
>> My primary concern is this:
>> There is lots of code that has mutex objects at global scope, or as static
>> objects at function scope. This code, particularly the latter, is open to race
>> conditions, if more than one thread can exist before the object has been
>> initialized. If we can provide mutexes that "just work" in such scenarios,
>> this is a step forward.
> You completely miss (or at least fail to address) my point. Mutex
> objects at global scope generally protect data at global scope.
> Unless that data has a trivial ctor, its initialization needs to be
> protected by a once routine anyway. Why not just use the same once
> routine for the mutex too? I'm not sure it's worth making a whole
> separate, usually-unsafe, mutex category just so we can handle the
> case where global protected data has a trivial ctor.

I understand your point here. I was just trying to explain, and show that this
isn't the only use case.

>> See
>> <>
>> for the POSIX rationale for static initializers for mutexes.
> The POSIX rationale was written for a 'C' world; it may not be as
> valid in a world where objects require construction.

Fair point. The alternative they show is to use call_once, pretty much as you
described --- this works better in the presence of objects.

>> The need for static mutexes might be reduced in C++, but there are still use
>> cases,
> Yes. The question is whether they are general enough to warrant
> supporting them. I contend that they are not, at least not in the
> next few revisions of the library.

You're probably right. I started down this line of thought when rewriting
boost::call_once, and noticed that mutexes at global scope are used
everywhere, and yet they are not thread-safe for initialization. Maybe I could
do with some perspective.


Anthony Williams
Software Developer
Just Software Solutions Ltd

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at