[concurrency-interest] when is safe publication safe?

jason marshall jdmarshall at gmail.com
Fri Apr 23 20:51:28 EDT 2010

Some people insist on an intermediate state between published and
uninitialized where collaboration between or within modules is possible.
It's not so clear to me how exactly within Java semantics one would
articulate this twilight state adequately.

Unfortunately the only examples I can think of off the top of my head
involve pooling of resources.  I'm not too keen on using caching as a
defense for any language feature, and any language features that encourage
other solutions to amortizing the cost of a calculation over multiple uses,
I'm energetically in favor of (such as linear programming techniques).

I'm sure there's something in the Publish-Subscribe world that illustrates
this need, especially where composition happens (your PubSub object itself
relies on PubSub behavior internally).  Composition seems to be the achilles
heel of a lot of very interesting programming idioms.  (STM, I'm looking at
you, with no small sense of irony)


On Fri, Apr 23, 2010 at 3:32 PM, David Holmes <davidcholmes at aapt.net.au>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).
> > 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.
> Cheers,
> David Holmes
> > bye blackdrag
> >
> > --
> > Jochen "blackdrag" Theodorou
> > The Groovy Project Tech Lead (http://groovy.codehaus.org)
> > http://blackdragsview.blogspot.com/
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

- Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100423/d232856f/attachment.html>

More information about the Concurrency-interest mailing list