[concurrency-interest] when is safe publication safe?
davidcholmes at aapt.net.au
Fri Apr 23 18:32:31 EDT 2010
> Jochen Theodorou writes:
> assuming I have Thread t1, that creates an object x and assigns it for
> example to a field and Thread t2 is reading that field. Am I now right
> in assuming that unless I have memory barriers in t1 and t2 I have no
> way to ensure that t2 will see a fully initialized object (x represents
> a mutable)? Am I right that for example AtomicReference#lazySet will not
> help me here? I am aware that this question goes in the direction of
> double checked locking (only no instantaneous visibility and no
> singleton), that is why I assume that it cannot be guaranteed.
> Especially since there will be no "happens-before" relation in t2.
The key point is that for safe-publication there must be a happens-before
ordering between the read of x and the construction of the object that x
refers to. As with DCL there's no solution that only does something special
on the writer-side - so lazySet, or non-lazy-set won't help if there's no
AtomicReference.get (and I think in that case lazySet won't help anyway).
> Assuming that I am right I have further questions... For example why was
> it decided that an object can be seen uninitialized by another thread? I
> mean, sure I am aware of reordering of instructions, but does it give
> really that much to make an object visible to another thread without
> having it initialized?
It can't be seen uninitialized, but it can be seen in a state anywhere
between default-initialized and fully-constructed.
To make every object safe for publication would require additional
"barriers" that would severely impact performance - given that the vast
majority of objects created are not intended to be shared.
> And finally I did read here about Fences. Would they help making my safe
> publication possible?
Probably/possibly ... but that's the thing about Fences, trying to figure
out exactly what they do for you. ;-) Someone else may have a more helpful
answer on Fences.
> bye blackdrag
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest