[Biojava-dev] Thread safety question

[Matthew Pocock]

Hi Keith,

Yes - I think you're right. So - we need to discard the first check for 
== null?

M

Keith James wrote:

>I was looking at lazy instantiation and thread safety issues. There
>are a few well-publicised articles about the double checked locking
>idiom in Java and how it doesn't quite work e.g.
>
>http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
>
>This rang a bell regarding AbstractChangeable which does this
>
>protected ChangeSupport getChangeSupport(ChangeType ct) {
>    if(changeSupport != null) {
>      return changeSupport;
>    }
>
>    synchronized(this) {
>      if(changeSupport == null) {
>        changeSupport = generateChangeSupport();
>      }
>    }
>
>    return changeSupport;
>  }
>
>The example given in the reference is
>
>// Broken multithreaded version
>// "Double-Checked Locking" idiom
>class Foo {
>  private Helper helper = null;
>  public Helper getHelper() {
>    if (helper == null)
>      synchronized(this) {
>        if (helper == null)
>          helper = new Helper();
>      }
>    return helper;
>    }
>  // other functions and members...
>  }
>
>where the initial test is reversed wrt the biojava example. However,
>it looks to me like there might be a (theoretical) danger here (of
>ChangeSupport being initialised twice). Can someone convince me
>otherwise?
>
>cheers,
>
>Keith
>
>  
>