RE: [boost] Enhanced call_once()

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-06 10:50:01

> From: Pete Becker [mailto:petebecker_at_[hidden]]
> Sent: 06 August 2002 15:51
> At 03:33 PM 8/6/2002 +0100, Anthony Williams wrote:
> 
> >So with Boost.Threads, you only have dynamic mutex 
> initialization (with 
> >init order problems), despite the fact that two of the three 
> (I don't know 
> >anything about MacOS) supported platforms have a mechanism 
> for avoiding 
> >init order problems with Mutexes?
> 
> Put it the other way around: with Boost.Threads you only have 
> dynamic mutex 
> initialization (with potential init order problems) because 
> one of the 
> three supported platforms doesn't have a mechanism for statically 
> initializing mutexes. It's a legitimate limitation.

If you're saying that MacOS doesn't provide a mechanism for avoiding init
order problems with mutexes, fair point; I'm surprised there isn't one,
though.

> But: the major compilers for Win32 all have an 
> implementation-specific 
> mechanism for getting particular functions run before user-defined 
> constructors. 

Now I'm thinking you mean Win32 doesn't have the required support to avoid
init order problems. What is wrong with using named Mutexes?

> So this issue can be avoided in the implementation of a 
> lazy_initialization class. Further, it's not necessary to use a mutex 
> object here; a once function is sufficient.

True, but Win32 doesn't provide once functions; you have to write your own
(like boost.Threads.call_once)

Anthony