[concurrency-interest] when is safe publication safe?
dl at cs.oswego.edu
Sun Apr 25 08:44:32 EDT 2010
On 04/25/10 05:31, Jochen Theodorou wrote:
>> 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
It seems implausible that you could do enough
analysis at load/run time to determine whether you need
full locking in the presence of multithreaded racy initialization
vs much cheaper release fences. This would require at least some
high-quality escape analysis. And the code generated
would differ both for the writing and reading callers.
As I mentioned, an alternative is to lay down some rules.
If people stick to the rules they get consistent (in the sense
of data-race-free) executions, else they might not. And of
such rules, I think the ones that can apply here amount
to saying that other threads performing initializations cannot
trust any of their reads of the partially initialized object.
And further, they cannot leak refs to that object outside of the
group of initializer threads.
This is not hugely different than the Swing threading rules
but applies only during initialization.
More information about the Concurrency-interest