[concurrency-interest] when is safe publication safe?

Jochen Theodorou blackdrag at gmx.org
Sat Apr 24 08:20:48 EDT 2010


David Holmes wrote:
>> 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).

ok, so I got more or less right. Good to know.


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

yeah, sorry, I did mean that of course..

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

I guess I have here the problem in understanding... is such a barrier 
the only way to avoid reordering? I don't mean in Java, I mean on the 
CPUs that Java targets. I was assuming, without knowing, that there are 
instruction I can give the CPU that avoid reordering of for example the 
next y instructions. Or somehow to mark an area that cannot be reordered.

thnaks for the answer David

bye blackdrag


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



More information about the Concurrency-interest mailing list