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.
