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