Double checked locking and GCJ?

[Hans Boehm]

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".

Hans

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.
>
> Andrew.
>
>