Re: Boost.Threads - once functions

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-01 15:49:10

> > 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)". also, named mutex
need to be associated with &once (once control variable).
that is why i was using macro/function ONCE_MUTEX_NAME().
the idea is to build the name at runtime which would
include process id and address of once control variable.

> Or is the TLS used solely to insure the DCL doesn't suffer from
> memory barrier problems?

yes; to insure the program does not break memory synchronization
rules (defined in posix and java; no word in windows SDK)

> On Win32 this won't be an issue

rather, on IA32 this won't be an issue
(due to its archaic in-order memory model).

> (I honestly
> don't know if it will be on IA64 and at this point don't care, since
> this is a platform implementation issue and not a concern for
> portability).  To be honest, I don't understand the issue any way...
> shouldn't the mutex lock (WaitForSingleObject() here) invoke a memory
> barrier here any way?  (Maybe responses to that question should go to
> e-mail... I'm not sure others care about this.)

http://groups.google.com/groups?as_umsgid=3B53E398.8A8C5979%40web.de
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://www.cs.umd.edu/~pugh/java/memoryModel/

regards,
alexander.