[concurrency-interest] synchronized constructors

Vitaly Davidovich vitalyd at gmail.com
Fri Dec 16 19:06:09 EST 2011

my point is that lazySet  ensures that prior writes are visible if get()
returns non null, which covers your concern about writes done after
construction but before publication.

By wrap I meant instead of publishing FooClass you publish
On Dec 16, 2011 7:00 PM, "Roland Kuhn" <rk at rkuhn.info> wrote:

> That does not seem to address the issue: lazySet may be reordered with
> later writes, according to the j.u.c package docs, the potential data race
> publication by untrusted code being just such a write. Also, the object I
> need to return must implement a specific interface, so it is not clear to
> me what you mean by “wrapping”. Subclassing AtomicReference also does not
> work because of single inheritance.
> On Dec 17, 2011, at 00:44 , Vitaly Davidovich wrote:
> Sounds like you control publishing ... cheapest for you would be to wrap
> your object in AtomicReference and lazySet it before publishing the
> reference.
> On Dec 16, 2011 5:57 PM, "Roland Kuhn" <rk at rkuhn.info> wrote:
>> This sounds like it is impossible to construct a mutable object in a way
>> so that it is immune against improper publication. If the aforementioned is
>> wrong—which I hope—then would you please tell me what the cheapest way is
>> of achieving this goal? One thing I could think of is just putting all
>> non-final fields in another class and have a reference to that be held in a
>> final field; if this works, it would be quite expensive, so any better
>> solution would be welcome.
>> You might ask, why have a non-final field without proper synchronization,
>> so let me add that the background to this question is that in my case the
>> construction of the object needs to proceed in two phases because of other
>> inter-dependencies, which requires certain fields to be written to after
>> the constructor has finished; they will be written to only exactly once,
>> and this happens before “untrusted” client code obtains the reference (in
>> program order).
>> Thanks in advance,
>> Roland
>> On Dec 16, 2011, at 22:49 , Boehm, Hans wrote:
>> Just to be clear: Safe publication for final fields requires that you do
>> not make a pointer to the object available to other threads (publish it)
>> before the constructor finishes.  “Safe publication” as used below is a
>> slightly stronger property; you also should not communicate the pointer
>> post-construction to another thread via a data race.  Avoiding them both is
>> great advice, but the second one may be difficult to avoid if you need to
>> give a reference to your object to code you don’t trust.  Malicious code
>> could always pass the object to a third thread through a race, hoping that
>> the third thread, which has no happens-before relationship to the other
>> two, would find your object in an inconsistent state.  My intuition is that
>> this is a rare case, but one that does occur.  When it does occur, the odds
>> of an actual security hole are probably small, but so are the odds of
>> proving security properties without addressing the issue.****
>> ** **
>> Hans****
>> ** **
>>  *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
>> concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *Yuval Shavit
>> *Sent:* Friday, December 16, 2011 11:59 AM
>> *To:* Zhong Yu
>> *Cc:* concurrency-interest at cs.oswego.edu
>> *Subject:* Re: [concurrency-interest] synchronized constructors****
>> ** **
>> On Fri, Dec 16, 2011 at 2:10 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:**
>> **
>> On Fri, Dec 16, 2011 at 8:38 AM, Yuval Shavit <yshavit at akiban.com> wrote:
>> > Several people have made the claim that you could see partially
>> initialized
>> > state even if the constructor were synchronized, and I don't see how
>> this
>> > could be. Yes, you could assign MyPoint myUnsafeRef before MyPoint()
>> > finishes -- but if you ever tried to *use* myUnsafeRef, you would run
>> into a
>> > synchronized block which would then ensure that the constructor
>> > happened-before whatever method you're writing. Seems to me you should
>> see
>> > the fully-thread-safe, not-partially-initialized object at that point.*
>> ***
>> If the reference is unsafely published, another thread can get the
>> reference early; it then calls an instance method which may obtain the
>> lock before the creation thread can obtain the lock for the
>> constructor. Therefore the other thread can observe the blank state.
>> As Ruslan corrected me, no partial state can be observed though.****
>> ** **
>> Ah yes, I hadn't thought of that.****
>> ** **
>> So now, in order to have my class be over-achievingly thread safe, I need
>> to replace my synchronized methods with a latch that waits for construction
>> to finish and *then* a synchronized (this) {...}. But I probably decide
>> that this is really going far out of my way to support a bad usage pattern,
>> so I throw up my arms and say "you'll see either totally blank or
>> post-initialization state, but not partial initialization."  But that means
>> I have to guard against uninitialized state in each method, so I probably
>> throw up my arms again and say "just publish the darn object safely!"  And
>> then the JLS people come to me and say, "well if that's your requirement,
>> why do you want a synchronized constructor?"  And suddenly the whole thing
>> makes sense.****
>> ** **
>> This has been an interesting discussion for me! Thanks everyone. :)****
>> ** **
>> -Yuval****
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>  --
>> [scala-debate on 2009/10/2]
>> Viktor Klang: When will the days of numerical overflow be gone?
>> Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> --
> I'm a physicist: I have a basic working knowledge of the universe and
> everything it contains!
>     - Sheldon Cooper (The Big Bang Theory)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111216/a9dd943d/attachment-0001.html>

More information about the Concurrency-interest mailing list