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

David Holmes dcholmes at optusnet.com.au
Sun Jun 18 19:19:22 EDT 2006

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?

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yechiel
  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

  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

  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

    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

    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.

    David Holmes

     -----Original Message-----
    From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yechiel
    Sent: Sunday, 18 June 2006 9:42 PM
    To: concurrency-interest at cs.oswego.edu
    Subject: [concurrency-interest] a question regarding the

      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
      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;

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

More information about the Concurrency-interest mailing list