[concurrency-interest] Double Checked Locking in OpenJDK

R Samuel Klatchko rsk at moocat.org
Sun Aug 12 21:09:51 EDT 2012


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/20120812/5492e95c/attachment.html>


More information about the Concurrency-interest mailing list