[concurrency-interest] Double Checked Locking in OpenJDK

David Holmes davidcholmes at aapt.net.au
Sun Aug 12 21:46:24 EDT 2012


For a data race to be benign the object to be installed must be idempotent (ie always the same no matter who wins the race) and safely published. I don't know whether this particular API defines an idempotent value. If it did then you wouldn't need the sync block, just the volatile, for correctness. You may still want the sync block for performance reasons.

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of R Samuel Klatchko
  Sent: Monday, 13 August 2012 11:10 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Double Checked Locking in OpenJDK


  Also, wouldn't this be a benign data race as wanting to call FileSystems.getDefault().getPath only once is for performance and not for correctness.


  On Sun, Aug 12, 2012 at 3:30 PM, David Holmes <davidcholmes at aapt.net.au> wrote:

    Ruslan Cheremin writes:
    >
    > First of all, Path is immutable, so DCL is safe here even without
    > volatile. Volatile here is not required from my point of view.


    Without the volatile the Path implementation (Path is an interface) must be
    such that an instance of Path can be safely published without any additional
    forms of synchronization. Immutability does not in itself ensure that. You
    would have to examine the actual implementation class.

    David Holmes
    ------------


    >
    >
    > 2012/8/12 Dmitry Vyazelenko <vyazelenko at yahoo.com>:
    > > Hi Richard,
    > >
    > > The variable "filePath" is volatile, so the double-checked
    > locking is correct in this case. It would have been a bug prior to Java 5.
    > >
    > > Best regards,
    > >
    > > Dmitry Vyazelenko
    > >
    > > On Aug 12, 2012, at 21:35 , Richard Warburton
    > <richard.warburton at gmail.com> wrote:
    > >
    > >> Hello,
    > >>
    > >> The current implementation of java.io.File::toPath [0] appears to be
    > >> using the double checked locking pattern:
    > >>
    > >>     public Path toPath() {
    > >>         Path result = filePath;
    > >>         if (result == null) {
    > >>             synchronized (this) {
    > >>                 result = filePath;
    > >>                 if (result == null) {
    > >>                     result = FileSystems.getDefault().getPath(path);
    > >>                     filePath = result;
    > >>                 }
    > >>             }
    > >>         }
    > >>         return result;
    > >>     }
    > >>
    > >> I was going to report the bug, but I'm a little uncertain of the
    > >> interaction between the local variable 'result' and DCL since I've
    > >> previously only seen the checking condition on the shared field
    > >> itself.  Can someone here either confirm that its a bug or explain how
    > >> the 'result' variable is fixing things?
    > >>
    > >> regards,
    > >>
    > >>  Richard
    > >>
    > >> [0] See the end of
    > >>
    > hg.openjdk.java.net/jdk8/jdk8/jdk/file/da8649489aff/src/share/clas
    > ses/java/io/File.java
    > >> _______________________________________________
    > >> Concurrency-interest mailing list
    > >> Concurrency-interest at cs.oswego.edu
    > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
    > >
    > >
    > > _______________________________________________
    > > Concurrency-interest mailing list
    > > Concurrency-interest at cs.oswego.edu
    > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
    > _______________________________________________
    > Concurrency-interest mailing list
    > Concurrency-interest at cs.oswego.edu
    > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
    >

    _______________________________________________
    Concurrency-interest mailing list
    Concurrency-interest at cs.oswego.edu
    http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120813/6219bdd4/attachment-0001.html>


More information about the Concurrency-interest mailing list