Re: Double checked locking and GCJ?

[Andrew Haley <aph at redhat dot com>]

Hans Boehm writes:
 > 
 > On Tue, 28 Jun 2005, Andrew Haley wrote:
 > 
 > > Martin Egholm Nielsen writes:
 > >  > Hi there,
 > >  >
 > >  > Sorry for bringing up what may be the most tedious thread ever. But does
 > >  > "double checked locking" work with GCJ:
 > >  >
 > >  > // Works with acquire/release semantics for volatile
 > >  > // Broken under current semantics for volatile
 > >  >    class Foo {
 > >  >          private volatile Helper helper = null;
 > >  >          public Helper getHelper() {
 > >  >              if (helper == null) {
 > >  >                  synchronized(this) {
 > >  >                      if (helper == null)
 > >  >                          helper = new Helper();
 > >  >                  }
 > >  >              }
 > >  >              return helper;
 > >  >          }
 > >  >      }
 > >  >
 > >  > (From:
 > >  > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
 > >
 > > I think it depends on the memory model of the particular hardware on
 > > which the program is executing.  For it to be otherwise, every access
 > > to a volatile would require a full memory barrier, and I don't think
 > > we do that.
 > 
 > We do realize that as of 1.5 this is broken, right?  It does need to be
 > fixed.
 > 
 > The kind of barrier that's required here varies.  For details, google
 > "JSR 133 Cookbook".

I don't know if there is any generic support for this in gcc.  There
are builtins like __builtin_ia32_mfence(), but that's very CPU
specific.  We could, of course, wrap every access to a volatile
variable in a mutex.  As we'd release the mutex immediately, we'd only
need one.  However, this wouldn't help us with CNI code.

Andrew.