[concurrency-interest] Safe publishing strategy

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 23 16:25:11 EST 2015


>
> Yes, if you have enough field stores to spill over the publication of
> the object. See also:
>  http://shipilev.net/blog/2014/safe-public-construction/


Can you elaborate on what you mean by "enough field stores to spill over
the publication"?

On Fri, Jan 23, 2015 at 1:50 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 23.01.2015 19:17, Luke Sandberg wrote:
> > Thanks, the wrapper was another strategy discussed (and is likely the
> > best due to simplicity).
>
> Final wrapper is a cute trick, but I think it only works if you have
> constructed the input in this very thread, or get the input from
> somewhere else safely.
>
> I.e. this is still broken:
>
> static final class Wrapper<T> {
>     ListenableFuture<T> input;
>     public Wrapper(ListenableFuture<T> input) { this.input = input; }
> }
>
> private static class FallbackFuture<V>
>     final Wrapper<? extends V> wrapper;
>
>     FallbackFuture(ListenableFuture<? extends V> input, ...) {
>       wrapper = new Wrapper(input);
>       /// a bunch of stuff with listeners
>     }
>     ...
> }
>
>
> Future f;
>
> Thread 1:
>   Future lf1 = <get a future from somewhere>
>   f = lf1; // racy write
>
> Thread 2:
>   Future lf2 = f; // racy read
>   Future ff = new FallbackFuture(lf2); // oops, too late!
>
> Even if lf2 is not null, you can't possibly instruct the writer that you
> need all the (initializing) stores for lf1 from Thread 1 right now,
> here, in Thread 2.
>
> Because of this, the subsequent (unsafe) publishing of ff with final
> wrapper on-board would not also be protected, since we are have been
> given the rotten $input.
>
>
> > Still it seem lame to have to _allocate_ to fix a visibility issue.  It
> > seems like there should be something similar to the 'freeze action' for
> > non-final
> > fields:
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.1
>
> Will only work for not-yet-published objects. And if you have to only
> deal with non-published objects, there are only a few corner cases that
> do not fit into object constructors.
>
>
> > Also, (just for my own edification) is it actually possible to observe
> > this bug on x86?
>
> Yes, if you have enough field stores to spill over the publication of
> the object. See also:
>  http://shipilev.net/blog/2014/safe-public-construction/
>
> -Aleksey.
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150123/19e4b628/attachment.html>


More information about the Concurrency-interest mailing list