This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Double checked locking and GCJ?
- From: Hans Boehm <Hans dot Boehm at hp dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Martin Egholm Nielsen <martin at egholm-nielsen dot dk>,java at gcc dot gnu dot org
- Date: Tue, 28 Jun 2005 08:42:08 -0700 (PDT)
- Subject: Re: Double checked locking and GCJ?
- References: <d9r853$5vn$1@sea.gmane.org> <17089.10221.39099.484260@zapata.pink>
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.
>
>