|
|
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
>> <http://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_init.html#tag_03_537_08_04>
>> 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
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk