Re: Boost.Threads - once functions

From: williamkempf_at_[hidden]
Date: 2001-08-01 17:31:00

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > > consider the following example (just an illustration;
> > > no error checking, etc):
> > >
> > > int                    process_private_once_status = 0;
> > > int __declspec(thread) thread_local_once_status    = 0;
> > >
> > > void dcl_once()
> > > {
> > >
> > >   // 1st check
> > >   if ( 0 == thread_local_once_status ) {
> > >
> > >     // Create/Open named mutex
> > >     HANDLE hndlMutex = CreateMutex( NULL,
> > >                                     FALSE,
> > >                                     ONCE_MUTEX_NAME(
> > > process_private_once_status ) );
> >
> > I never thought of using a named mutex approach.  Not overly
> > efficient, but a very nice idea non-the-less.  I've been thinking 
too
> > much about portable threads to see this one.  This makes me wonder
> > why you use TLS at all here.  There seems to be no reason for it.
> >
> > typedef void (*once_routine)();
> > typedef bool once_t;
> > #define BOOST_ONCE_INIT false
> >
> > void run_once(once_t& once, once_routine func)
> > {
> >    if (!once)
> >    {
> >       HANDLE mutex = CreateMutex(NULL, FALSE, "boost_once");
> >       WaitForSingleObject(mutex, INFINITE);
> >       if (!once)
> >       {
> >          func();
> >          once = true;
> >       }
> >       CloseHandle(mutex);
> >    }
> > }
> 
> how about "ReleaseMutex(mutex)".

Accidently left out of the code.  That's what you get when you code 
in e-mails ;).

> also, named mutex
> need to be associated with &once (once control variable).

No, it doesn't "need" to be.  With it not being associated with &once 
it's just a "global" mutex.  Every call to run_once() will use the 
same conceptual mutex (I say conceptual since the named mutex may or 
may not still actually exist in a call, so may or may not be 
created).  The Kernel will handle all synch issues of the creation 
here.

Bill Kempf