[ace-users] <no subject>
Alexander Terekhov
"Douglas C. Schmidt" <sch...@cs.wustl.edu> wrote:
"Charlie Duke" <cd...@cuseeme.com> wrote:
[...]
> >> I came across this article the other day which argues
> >> that Double-checked Lock is not safe. The article is
> >> about the use of the pattern in Java, however I'm
> >> wondering if the arguments apply to C++ also.
yes.
> >> Any insight ?
>
> This topic is described at length on page 361-362 in POSA2
> <www.cs.wustl.edu/~schmidt/POSA/>.
you might also have a look at:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
for more insights and for correct/full version with explicit
memory barriers from Doug. (there is an error [one statement
is missing] in the first printing of POSA2 which I have:
Page | ś | Line | Wrong Text | Correct Text
Page: 362
ś: 4/5
Line:
Wrong Text:
Guard<Thread_Mutex> guard (singleton_lock_);
// Double check.
if (tmp == 0) {
Correct Text:
Guard<Thread_Mutex> guard (singleton_lock_);
// Double check.
tmp = instance_;
if (tmp == 0) {
)
note that pthread_once does already provide correct and
portable solution for lazy initialization in MT environment.
however, IMHO it would be nice to have a language feature:
Newsgroups: comp.std.c++
Subject: Re: C++0x
From: Alexander Terekhov <tere...@web.de>
Nick Thurn wrote:
[...]
> No barrier construct for multi-threading:
> - no way to make double checked locking work portably
there is a way to make it work portably; using thread
locals (tsd). here is a compact example in Java (in C++
you would need to have a "portable" class similar to
ThreadLocal or just stick to C/POSIX pthreads for tsd):
class Singleton {
private static Singleton theInstance;
private static final ThreadLocal perThreadInstance =
new ThreadLocal() {
public Object initialValue() { return createInstance(); }
};
public static Singleton getInstance() {
return (Singleton)perThreadInstance.get();
}
private static synchronized Singleton createInstance() {
if (theInstance == null)
theInstance = new Singleton();
return theInstance;
}
}
however, I would really prefer to write:
Singleton& Singleton::getInstance()
{
static synch Singleton theSingleton; // synchronized local static
return theSingleton;
}
so that via "static synch" the language implementation
would provide the correct and most effective solution
for lazy initialization in MT environment on each
particular platform; e.g. DCL with memory barriers or
tsd (who knows which is faster) for multiprocessors
with weak memory models, "classic" DCL for all
uniprocessors and multiprocessors with strong memory
model or something completely different; platform
specific.
that would also ensure zero overhead ("synch" should be
just ignored by compiler) if my code/lib would be
compiled for running in ST environment only (without
-pthread option or similar). btw, that is the only
reason why "static synch" locals would do better than
already portable pthread_once - I just do not like to
maintain two versions; one with pthread_once for MT
programs and another with static locals for ST programs.
regards,
alexander.
_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ihr...@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de