Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk