<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19258"></HEAD>
<BODY>
<DIV><SPAN class=671464301-13082012><FONT color=#0000ff size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV><SPAN class=671464301-13082012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=671464301-13082012><FONT color=#0000ff size=2 
face=Arial>David</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px">
  <DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2 
  face=Tahoma>-----Original Message-----<BR><B>From:</B> 
  concurrency-interest-bounces@cs.oswego.edu 
  [mailto:concurrency-interest-bounces@cs.oswego.edu]<B>On Behalf Of </B>R 
  Samuel Klatchko<BR><B>Sent:</B> Monday, 13 August 2012 11:10 AM<BR><B>To:</B> 
  concurrency-interest@cs.oswego.edu<BR><B>Subject:</B> Re: 
  [concurrency-interest] Double Checked Locking in 
  OpenJDK<BR><BR></FONT></DIV>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.<BR><BR>
  <DIV class=gmail_quote>On Sun, Aug 12, 2012 at 3:30 PM, David Holmes <SPAN 
  dir=ltr><<A href="mailto:davidcholmes@aapt.net.au" 
  target=_blank>davidcholmes@aapt.net.au</A>></SPAN> wrote:<BR>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
  class=gmail_quote>
    <DIV class=im>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></DIV>Without the volatile the 
    Path implementation (Path is an interface) must be<BR>such that an instance 
    of Path can be safely published without any additional<BR>forms of 
    synchronization. Immutability does not in itself ensure that. You<BR>would 
    have to examine the actual implementation class.<BR><SPAN class=HOEnZb><FONT 
    color=#888888><BR>David Holmes<BR>------------<BR></FONT></SPAN>
    <DIV class=HOEnZb>
    <DIV class=h5><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 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 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>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></BLOCKQUOTE></BODY></HTML>