[concurrency-interest] when is safe publication safe?

Doug Lea dl at cs.oswego.edu
Sat Apr 24 09:18:03 EDT 2010


On 04/24/10 08:39, Jochen Theodorou wrote:

>
> I should maybe mention what I want this for. In the Groovy programming
> language, which I have the pleasure to help develop we have a lot of
> runtime data, that is of course shared between threads. But the current
> ways of synchronization do cost a lot of performance and since
> performance of the language is an important point, we have to draw from
> all registers to make it somehow more fast. I made several experiments
> and always come to the conclusion this and that won't work if my
> understanding of the Java Memory Model is right. I come to the
> conclusion that if it were possible to create an object in Thread t1 and
> "write that main memory", so that Thread t2 will eventually see the
> fully initialized object and some point in the future without having to
> go through memory barriers, then I will get more speed out of the
> language.

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

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

-Doug







More information about the Concurrency-interest mailing list