> From: Pete Becker [mailto:petebecker@acm.org]
> 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