[concurrency-interest] when is safe publication safe?

Jochen Theodorou blackdrag at gmx.org
Sun Apr 25 05:31:28 EDT 2010

Doug Lea wrote:
> Yes, this was the main motivation for creating the (messy!)
> rules for final fields in the JMM, that only conditionally
> preserve consistency (i.e., you get what you expect only if
> no leaks of "this" in constructors etc).

better some messy rules than not at all in this case.

> Unfortunately, your fields aren't always final. This is not an
> uncommon problem. It is the first example in the draft Fences API
> javadoc
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html 
> It would be nice to put into place some means to cope.
> However, the Fences API itself met a fair amount
> of resistance so we are still not sure where this will go.

your example was more or less the reason I started writing here. And we 
people from JSR 292 are absolutely interested in such things I would 
say. But our focus is not so much if the user can do bad things with 
that, our focus is to somehow fight the limitations of the JVM. Because 
many of these limitations do make dynamic language on the JVM 
unnecessarily slow and complex. A normal user is maybe ok if 1 in a 
10000 method calls is a bit slower, but in my case it is each of the 
10000 method calls, that is much slower. Every little bit extra I have 
to pay makes it slower.

>> The problem is that I have mutable objects I need to publish,
>> so the point of being fully initialized is important to me. That t2 may
>> not see the object unless some memory barrier is used is ok for me too.
>> If the Groovy programmer wants it being visible, he can ensure with
>> memory barriers it is going to be so.
> As a first step, consider exactly what effects/semantics you want
> here, and the ways you intend people to be able to write conditionally
> correct Groovy code. 

People wouldn't have to write conditionally correct Groovy code. they 
would write normal code as they would in Java (Groovy and Java are very 
near). Imagine Groovy as a kind of library that is involved in each 
method call, so the effects/semantics are solely reduced to the library 
itself and that user code may cause a more early publication due to a 
piggyback ride on memory barriers the user used.

> Is there a well defined publication-ready state
> such that any thread seeing it is either helping to initialize it
> (with no guarantees about what values are read) or already incorrect
> on some other grounds?

the initialization is done by the thread first needing that object. 
There is further normal synchronization if that object is not there yet. 
Which means If threads t1 and t2 request the object then for example t1 
does the init, and t2 will have to wait. I was considering changing that 
into t1 and t2 doing their own versions and who ever writes last, gets 
the real version. But that would be for me a next step and I am not yet 
sure how to do that yet. I would have to handle different versions of 
the object for a write, which makes it much more difficult, because the 
current semantics would maybe not fully allow this.

> If so, forcing release-style fences on
> each field write may suffice. Except that we don't support a
> reasonable way to do this from Java level yet.

from the Java level sounds like there would be some way...

bye blackdrag

Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)

More information about the Concurrency-interest mailing list