Re: [boost] [thread] A simply static initializeable mutex

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-30 07:33:45

"Martin Bonner" <martin.bonner_at_[hidden]> writes:

> From: Felipe Magno de Almeida
>
>> On 10/30/06, Anthony Williams <anthony_w.geo_at_[hidden]> wrote:
>>> Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>>> [snipped]
>> 
>>>> Do you mean: the object might be already zero initialized before
>>>> the ctor runs? If yes: this is very dangerous to rely on!
>>> 
>>> No. This is required. The memory for an object with
>>> static-storage-duration MUST be zero initialized prior to the
>>> constructor running. 
>> 
>> It dont even matter, it *must* not have a constructor. Or else
>> there'll be a race condition on the compiler's flag and multiple
>> constructor calls.
>
> Does this matter if all the constructor does is repeat the zero
> initialization?  (Serious question.  The answer is not obvious to me).
>
> Roland suggested a mutex which relied on the zero initialization of
> static PODs.  He then listed a number of issues that maintaining POD
> status introduces (like we can't eliminate copy constructors).  I
> pointed out that actually ALL static objects are zero initialized, so we
> could have a default constructor that does nothing or repeats the zero
> initialization (which means we could create the mutex other than as a
> object with other than static storage duration).

There are two race conditions in effect on MSVC. One is the race to START the
construction, and the other is the race between COMPLETING construction and
USING the object.

If the constructor does nothing or initializes the members to zero, then the
consequence of the first race is irrelevant, except that if multiple threads
run the constructor, then multiple destructor calls will be scheduled.

The second race is more serious --- if using the object sets the members to
anything other than their initial values, and then requires that they retain
these values, then it is essential that the constructor is complete before any
thread tries to use the object. Otherwise, the still-running constructor may
overwrite the data structure, and reset it back to zero, and thus mess up the
thread that tried to use the object.

I posted some MSVC-specific code a short time ago that overcame these problems
(see the thread on once init stuff).

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk