By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 882 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

Double-checked locking: is this alternative OK?

P: n/a
SomeObject* instance() // flawed way
{
static SomeObject* instance = NULL;
LockThing(); // locking even when not required
if(instance == NULL) // instance may still be NULL when another thread
checks
instance = new SomeObject();
UnlockThing(); // oh dang, more unnecessary function calls after first
pass
return instance;
}

SomeObject* instance() // OK?
{
static bool been_there_done_that = LockThing();
static volatile instance = new SomeObject(); // no problemo (on X86
hardware)
static bool been_there_done_that_B = UnlockThing();
return instance; // fast is nice! No overhead after first pass through
function
}

John
Mar 17 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
JohnQ wrote:
SomeObject* instance() // flawed way
{
static SomeObject* instance = NULL;
LockThing(); // locking even when not required
if(instance == NULL) // instance may still be NULL when another
thread checks
instance = new SomeObject();
UnlockThing(); // oh dang, more unnecessary function calls after
first pass
return instance;
}
Could you explain why you don't do it this way:

if (instance == NULL) {
LockThing();
instance = new SomeObject();
UnlockThing();
}
return instance;

? That should avoid the unnecessary locking you mention, no?
>
SomeObject* instance() // OK?
{
static bool been_there_done_that = LockThing();
static volatile instance = new SomeObject(); // no problemo (on X86
hardware)
static bool been_there_done_that_B = UnlockThing();
return instance; // fast is nice! No overhead after first pass
through function
}

John

The problem with having to double-check is not solved by your static
initialisation, however. The language at this point makes no attempt
to resolve the problem of calling the function "for the first time"
from two different threads. And AIUI the sequence of events in that
case can be

Thread 1 Thread 2
LockThing() - succeeds
LockThing() - fails, waits
new SomeObject() . // waiting
UnlockThing() . // waiting
return instance
new SomeObject() // overrides instance
UnlockThing()
return instance // different instance

The Committee is working on thread support, however. Static
initialisations would have to be resolved before the thread support
can be claimed, that's for sure.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Mar 17 '07 #2

P: n/a
On Mar 17, 8:31 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
if (instance == NULL) {
LockThing();
instance = new SomeObject();
UnlockThing();
}
return instance;
I think this can be improved to:

if (instance == NULL) {
LockThing();
if (instance == NULL) {
instance = new SomeObject();
}
UnlockThing();
}
return instance;

This is mentioned in [1] as "The Double-Checked Locking Pattern."
Thread 1 Thread 2
LockThing() - succeeds
LockThing() - fails, waits
new SomeObject() . // waiting
UnlockThing() . // waiting
return instance
new SomeObject() // overrides instance
The above code fixes this, instead of calling "new SomeObject()":
Thread 1 Thread 2
Checks if instance is NULL
(Since instance is not NULL,
do *not* call "new SomeObject()")
UnlockThing()
return instance // different instance
[1] "Modern C++ Design" Andrei Alexandrescu

Mar 21 '07 #3

P: n/a
On Mar 20, 11:53 pm, "david.baird" <dhba...@gmail.comwrote:
On Mar 17, 8:31 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
if (instance == NULL) {
LockThing();
instance = new SomeObject();
UnlockThing();
}
return instance;

I think this can be improved to:

if (instance == NULL) {
LockThing();
if (instance == NULL) {
instance = new SomeObject();
}
UnlockThing();
}
return instance;
Okay, I read my book a little bit more and found that actually even
this double-checked solution can have problems in SMP systems where
memory writes are committed in non-chronological bursts. Using the
"volatile" keyword might help and there might also be special
concurrency features offered by your platform.

Mar 21 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.