[concurrency-interest] Double Checked Locking in OpenJDK

Ruslan Cheremin cheremin at gmail.com
Mon Aug 13 00:38:48 EDT 2012


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?

>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