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

David Holmes dcholmes at optusnet.com.au
Mon Jun 19 04:20:44 EDT 2006


That quote is somewhat dated and was deliberately trying to dissuade people
from thinking they need DCL. There were some recent posts concerning the
costs of volatiles, I'll see if I can dig up a specific reference.

Otherwise use the initialization holder idiom to avoid the need for the
volatile.

Cheers,
David Holmes
  -----Original Message-----
  From: Yechiel Feffer [mailto:yechielf at gigaspaces.com]
  Sent: Monday, 19 June 2006 7:29 PM
  To: dholmes at ieee.org; Yechiel Feffer; concurrency-interest at cs.oswego.edu
  Subject: RE: [concurrency-interest] a question regarding thedouble-checke
dlocking


  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

      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/a96f3920/attachment.html 


More information about the Concurrency-interest mailing list