[concurrency-interest] a question regarding thedouble-checke dlocking

Yechiel Feffer yechielf at gigaspaces.com
Mon Jun 19 05:29:08 EDT 2006


I am concerned with general correctness of my code,
want to avoid the price of volatile, here is a quote from jsr133 FAQ
"However, for fans of double-checked locking (and we really hope there are
none left), the news is still not good. The whole point of double-checked
locking was to avoid the performance overhead of synchronization. Not only
has brief synchronization gotten a LOT less expensive since the Java 1.0
days, but under the new memory model, the performance cost of using volatile
goes up, almost to the level of the cost of synchronization. So there's
still no good reason to use double-checked-locking"
 
 
 

-----Original Message-----
From: David Holmes [mailto:dcholmes at optusnet.com.au]
Sent: Monday, June 19, 2006 01:19
To: Yechiel Feffer; concurrency-interest at cs.oswego.edu
Subject: RE: [concurrency-interest] a question regarding thedouble-checke
dlocking


Thinking of this in terms of "cache flushing" is guaranteed to get you into
trouble. On mainstream PC hardware for example, the cache never needs to be
flushed. The memory model establishes happens-before orderings between
operations and, in simple terms, that means the reader that sees ref as
non-null and the writer that creates the object and sets the ref non-null
*must* either lock/unlock the same monitor or read/write the same volatile
field. Neither of which occurs in your code and so the requisite
happens-before ordering is not present.
 
Reading a volatile field is almost free on many systems. What platform are
you concerned with?
 
Cheers,
David Holmes

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yechiel
Feffer
Sent: Sunday, 18 June 2006 11:15 PM
To: dholmes at ieee.org; concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] a question regarding thedouble-checke
dlocking


Thanks.
Lets ignore the static, my mistake.
I want to avoid declaring the instance ref as volatile and pay the price
volatile-check in every instance check.
I was referring to the example of double-checked locking from jsr133 FAQ
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl
<http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl> 
 
which I altered a little. Object A and Object B are just 2 objects
constructed when the main object was created.
Since , upon monitor release, the cache is flushed to main memory, and since
the "instance" ref is updated only after the inner monitor is exited and the
"Something" object created
inside it, would it ensure a consistent view of the instance pointed-to
object ? 
 
 

-----Original Message-----
From: David Holmes [mailto:dcholmes at optusnet.com.au]
Sent: Sunday, June 18, 2006 13:20
To: Yechiel Feffer; concurrency-interest at cs.oswego.edu
Subject: RE: [concurrency-interest] a question regarding the
double-checkedlocking


I don't quite understand the static versus non-static parts of this. What
are "some object a" and "some object b" ?  A happens-before relationship
only occurs between an unlock and subsequent lock of a monitor on the same
object.
 
But why would you bother even trying this when a single lock and making the
static instance volatile will work. Or even better use static
initialization, whether direct or via the static nested class idiom.
 
You have to ensure there is a happens-before relationship between the
construction of the instance, the writing of the instanace field ref and the
subsequent reading of it. I just described the minimal solution. There are
probably an unlimited number of strange things you could do to get the same
effect.
 
Don't know what you mean by "unify" nested locks. The compiler can't do
anything you could detect in the program as being incorrect.
 
Cheers,
David Holmes
 
 -----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yechiel
Feffer
Sent: Sunday, 18 June 2006 9:42 PM
To: concurrency-interest at cs.oswego.edu
Subject: [concurrency-interest] a question regarding the
double-checkedlocking



Hi all
will the following double-checked locking code work ?
note that when instance   is assigned a ref to the object, its after the
assigning thread have exited the inner synchronized block,
so the ref dummy_instance must contain a completly initialized object image.
If it works, will replacing the inner synchronized by a  dummy_instance
which is volatile do the job too ?
Are there compiler optimizations which "unify" nested lockes ?
  
 
 
private static Something instance = null;

private  Something dummy_instance = null;


public Something getInstance() {
  if (instance == null) {
    synchronized (some object A) {
        synchronized (some object B) {
          if (instance == null)
            dummy_instance = new Something();
        }
        instance = dummy_instance;
            }
    }
  }
  return instance;
}

Regrds,
Yechiel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060619/797a9003/attachment-0001.html 


More information about the Concurrency-interest mailing list