[concurrency-interest] Double Checked Locking in OpenJDK

David Holmes davidcholmes at aapt.net.au
Mon Aug 13 00:51:22 EDT 2012


Ruslan Cheremin writes:
> Well, Path javadoc explicitly says "immutable and safe for
> multithreaded use". Although it is not strictly defined in java what
> exactly means "safe for multithreaded use" -- does it mean safe for
> publishing via data race, among others? -- I suppose, it should be. Am
> I wrong here?

"safe for multi-threaded use" does not generally imply that it is safe to
publish instances without synchronization of some form.

David
-----

> From other side, File.toPath javadoc explicitly says what "returned
> instance must be the same for every invocation", so sync block is
> required here for mutual exclusion on initialization phase. Without
> this requirement it is also safe to live without sync block, afaik.
>
> 2012/8/13 David Holmes <davidcholmes at aapt.net.au>:
> > 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
> >>
> >
>



More information about the Concurrency-interest mailing list