> It seems that Alexander left out a link. Strange,
> usually he doesn't do that. :)

Yeah. Note that the link to the declaration can be found in the article that I've referenced in my posting. ;-)

> It's
> > eCheckedLocking.html" target="_blank" title="http://www.cs.umd.edu/~pugh/java/memoryModel/Doub
> eCheckedLocking.html">The "Double-Checked Locking is
> Broken" Declaration. It's a pretty good
> discussion of the pitfalls of trying to use/implement
> DCL correctly. Also, if you search the Google groups
> on this topic, you will see that 90% of the
> participants don't understand the issues, even after
> it's repeatedly pointed out to them. That alone
> should tell you how tricky DCL is.

Forget stupid "DCL" term. Please use DCSI (and DCCI).

>
> The main problem with DCL is that there is no
> abstraction layer or api that programmers can use to
> do a correct implementation. You are pretty much at
> the mercy of the memory model on your particular
> platform. And even if you know what to do at some
> point, the memory models are always changing.

I don't see how they are "always changing". You either have a "fully" relaxed model or something close to SC. atomic<> with hoist/sink barriers (in addition to conventional acquire/release stuff) would surely work in ten years from now with no problems whatsoever. Oder?

regards,
alexander.

> > Forget stupid "DCL" term. Please use DCSI (and
> > DCCI).
>
> excuse my ignorance but are these acronyms a creation
> of your own ?

Yeah, sort of "my own". ;-)

> or do you have a pointer to some formal
> definition of these "DCSI" and "DCCI" thingies ?

Sure.

http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austi...

http://groups.google.com/groups?selm=3ECA3A27.C06CBB62%40web.de

http://groups.google.com/groups?selm=3ecb989d%40usenet01.boi.hp.com

regards,
alexander.

[... pedigree of "DCSI" and "DCCI" terms ...]

> so at least two peoples on earth (you included)

Nah, and my kids...

> use them already ;-)

Yeah, to tell the truth, my wife doesn't like for some reason (as usual, she said: "bad taste"). ;-)

regards,
alexander.

ClayB wrote:
>
> Alexander, now that we've cleared up the FLAs (four
> letter acronyms :-), can you give us a rundown on how
> the DCSI and DCCI codes work and what an improvement
> they are over the DCL (DCI)? I've poked around the
> URLs you gave and looked through the code, but all
> the dots and more dots make my eyes cross. I'm sure
> others would appreciate a few words of explanation,
> too.

DCSI/DCCI is "kinda useful" for thread-safe lazy inits
of immutable stuff (with a few exceptions... like Joe's
condvars with DCCI ;-) ). Mutable stuff that needs
locking can simply "eagerly" initialize a mutex (or a
read-write lock) and use it not only for access, but
also for thread-safe lazy init of associated stuff
(you'd need locking anyway for mutable stuff, "lock-
free" aside for a moment). Well, again, there are
exceptions here as well, like lazy init of things ala
TSD keys (or read-write locks that simply lack static
initializers) in libraries or components that don't
have "init/fini" calls, for example.

DCSI-TLS is this:

/* ... */ mutex stuff_mtx; stuff * stuff_shared_ptr; thread_specific_ptr stuff_thread_ptr; /* ... */ }; const stuff & thing::stuff_instance() { // "lazy" one stuff * ptr; if (0 == (ptr = stuff_thread_ptr.get())) { { mutex::guard guard(stuff_mtx); if (0 == (ptr = stuff_shared_ptr)) ptr = stuff_shared_ptr = new stuff(/*...*/); } stuff_thread_ptr.set(ptr); } return *ptr; }

The idea is that each thread should perform
synchronization on first access of shared data which
guarantees proper memory sync./visibility. A possible
implementation of thread_specific_ptr<> can be found
here: (Subject: Re: OO
design: Is "errno" Exception?). Note that there's
a "defect" in POSIX with respect to "no_cleanup" TSD
keys. Please also note that Microsoft TLS is so
braindamaged that I was unsure whether it's worth to
even mention it. ;-)

Now, DCSI-MBR is this:

/* ... */ mutex stuff_mtx; atomic stuff_ptr; /* ... */ }; const stuff & thing::stuff_instance() { // "lazy" one stuff * ptr; // hoist load barrier (with data dependency "hint") if (0 == (ptr = stuff_ptr.load_ddhlb())) { mutex::guard guard(stuff_mtx); if (0 == (ptr = stuff_ptr.load())) { ptr = new stuff(/*...*/); // sink store barrier stuff_ptr.store_ssb(ptr); } } return *ptr; }

Here, the idea is that atomic<> should provide required
atomicity and memory sync./visibility via injecting
necessary memory access reordering constraints (for
both compiler and hardware). More info on this can be
found here: (Subject: Re:
Is this thread-safe on multi-processor Win32?). Also,
please note that Microsoft interlocked stuff (kinda
revised "Server-2003-and-above" including) is also
braindamaged beyond the limits, so to speak. No wink,
this time.

Now, DCCI doesn't serialize init. Multiple inits are
done concurrently but there's a single "winner". Here
it is:

/* ... */ atomic stuff_ptr; /* ... */ }; const stuff & thi ng::stuff_instance() { // "lazy" one stuff * ptr; // hoist load barrier (with data dependency "hint") if (0 == (ptr = stuff_ptr.load_ddhlb())) { ptr = new stuff(/*...*/); // sink store barrier if (!stuff_ptr.attempt_update_ssb(ptr, 0)) { delete ptr; // hoist load barrier (with data dependency "hint") if (0 == (ptr = stuff_ptr.load_ddhlb())) abort(); } } return *ptr; }

Questions?

regards,
alexander.

P.S. C/C++ volatiles wont help you here (portably).
Revised Java volatiles WILL work... but they'll inject
kinda "way too much" constraints/barriers (to my taste);
I don't like them. I like atomic<> template that,
hopefully, will be standardized by the C++ standards
committee and/or "hypothetical" POSIX.1++ folks).