[concurrency-interest] a question regarding the double-checke dlocking

Yechiel Feffer yechielf at gigaspaces.com
Sun Jun 18 09:15:25 EDT 2006


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/20060618/a72602b5/attachment-0001.html 


More information about the Concurrency-interest mailing list