<div>A class is thread-safe if it behaves correctly when accessed from multiple threads, regardless of the scheduling or</div><div>interleaving of the execution of those threads by the runtime environment, and with no additional synchronization or</div>
<div>other coordination on the part of the calling code.</div><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 1:03 PM, Ruslan Cheremin <span dir="ltr"><<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But is there a way to define "safe for data race publishing"? I as<br>
far, as I remember, "immutable and thread-safe" is standard mantra in<br>
JDK javadocs for totally safe objects. j.l.String has same mantra --<br>
and it is safe for any way of publishing. Does you mean, I should<br>
explicitly add "safe even for publishing via data race" in docs? But I<br>
can't remember any such phrase in JDK docs.<br>
<div class="HOEnZb"><div class="h5"><br>
2012/8/13 David Holmes <<a href="mailto:davidcholmes@aapt.net.au">davidcholmes@aapt.net.au</a>>:<br>
> Ruslan Cheremin writes:<br>
>> Well, Path javadoc explicitly says "immutable and safe for<br>
>> multithreaded use". Although it is not strictly defined in java what<br>
>> exactly means "safe for multithreaded use" -- does it mean safe for<br>
>> publishing via data race, among others? -- I suppose, it should be. Am<br>
>> I wrong here?<br>
><br>
> "safe for multi-threaded use" does not generally imply that it is safe to<br>
> publish instances without synchronization of some form.<br>
><br>
> David<br>
> -----<br>
><br>
>> From other side, File.toPath javadoc explicitly says what "returned<br>
>> instance must be the same for every invocation", so sync block is<br>
>> required here for mutual exclusion on initialization phase. Without<br>
>> this requirement it is also safe to live without sync block, afaik.<br>
>><br>
>> 2012/8/13 David Holmes <<a href="mailto:davidcholmes@aapt.net.au">davidcholmes@aapt.net.au</a>>:<br>
>> > Ruslan Cheremin writes:<br>
>> >><br>
>> >> First of all, Path is immutable, so DCL is safe here even without<br>
>> >> volatile. Volatile here is not required from my point of view.<br>
>> ><br>
>> > Without the volatile the Path implementation (Path is an<br>
>> interface) must be<br>
>> > such that an instance of Path can be safely published without<br>
>> any additional<br>
>> > forms of synchronization. Immutability does not in itself<br>
>> ensure that. You<br>
>> > would have to examine the actual implementation class.<br>
>> ><br>
>> > David Holmes<br>
>> > ------------<br>
>> ><br>
>> >><br>
>> >><br>
>> >> 2012/8/12 Dmitry Vyazelenko <<a href="mailto:vyazelenko@yahoo.com">vyazelenko@yahoo.com</a>>:<br>
>> >> > Hi Richard,<br>
>> >> ><br>
>> >> > The variable "filePath" is volatile, so the double-checked<br>
>> >> locking is correct in this case. It would have been a bug<br>
>> prior to Java 5.<br>
>> >> ><br>
>> >> > Best regards,<br>
>> >> ><br>
>> >> > Dmitry Vyazelenko<br>
>> >> ><br>
>> >> > On Aug 12, 2012, at 21:35 , Richard Warburton<br>
>> >> <<a href="mailto:richard.warburton@gmail.com">richard.warburton@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> >> Hello,<br>
>> >> >><br>
>> >> >> The current implementation of java.io.File::toPath [0] appears to be<br>
>> >> >> using the double checked locking pattern:<br>
>> >> >><br>
>> >> >>     public Path toPath() {<br>
>> >> >>         Path result = filePath;<br>
>> >> >>         if (result == null) {<br>
>> >> >>             synchronized (this) {<br>
>> >> >>                 result = filePath;<br>
>> >> >>                 if (result == null) {<br>
>> >> >>                     result = FileSystems.getDefault().getPath(path);<br>
>> >> >>                     filePath = result;<br>
>> >> >>                 }<br>
>> >> >>             }<br>
>> >> >>         }<br>
>> >> >>         return result;<br>
>> >> >>     }<br>
>> >> >><br>
>> >> >> I was going to report the bug, but I'm a little uncertain of the<br>
>> >> >> interaction between the local variable 'result' and DCL since I've<br>
>> >> >> previously only seen the checking condition on the shared field<br>
>> >> >> itself.  Can someone here either confirm that its a bug or<br>
>> explain how<br>
>> >> >> the 'result' variable is fixing things?<br>
>> >> >><br>
>> >> >> regards,<br>
>> >> >><br>
>> >> >>  Richard<br>
>> >> >><br>
>> >> >> [0] See the end of<br>
>> >> >><br>
>> >> <a href="http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/da8649489aff/src/share/clas" target="_blank">hg.openjdk.java.net/jdk8/jdk8/jdk/file/da8649489aff/src/share/clas</a><br>
>> >> ses/java/io/File.java<br>
>> >> >> _______________________________________________<br>
>> >> >> Concurrency-interest mailing list<br>
>> >> >> <a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
>> >> >> <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > Concurrency-interest mailing list<br>
>> >> > <a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
>> >> > <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
>> >> _______________________________________________<br>
>> >> Concurrency-interest mailing list<br>
>> >> <a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
>> >> <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
>> >><br>
>> ><br>
>><br>
><br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br>