[concurrency-interest] Double Checked Locking in OpenJDK

Henri Tremblay henri.tremblay at gmail.com
Sun Aug 12 16:38:51 EDT 2012


It's a valid flavor of DCL. filePath being volatile there is no issue
about doing a DCL on it.

-
Henri

On 12 August 2012 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/classes/java/io/File.java
> _______________________________________________
> 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