[concurrency-interest] Unsafe publication of new objectsquestion

Gregg Wonderly gregg at cytetech.com
Tue Nov 16 14:44:01 EST 2010


On 11/16/2010 12:57 PM, √iktor Klang wrote:
>
>
> On Tue, Nov 16, 2010 at 7:38 PM, Andrew Trick <andrew.trick at gmail.com
> <mailto:andrew.trick at gmail.com>> wrote:
>
>     I read Joseph's question as "how does one implement a JVM that meets
>     the JVM spec". Maybe this wasn't the best forum for that discussion?
>
>     I think David answered your question to the effect that it's the
>     programmer's responsibility to synchronize constructors in general,
>     but final fields have some implied synchronization.
>
>
> What I'm saying is that if there was no logic in the constructor, all values for
> all fields would have to be allocated before the call, and you would be sure
> that references to the object was not exposed before it was fully constructed.

This is a developer/engineer choice on object lifecycle and initialization.  One 
can create every class instance with a noargs constructor that will thus have to 
create every value it assigns to some internal field.  Or you can pass those 
into constructor.

But in the end, it is the fact that you can create a reference to "this" within 
the construct of <init> being invoked that creates the larger issue.

I know that in some cases where I have leaked "this" into a "callback" mechanism 
during construction, and had the callback method invoked before construction 
completed, that "this" has been referenced in an anonymous method and resulted 
in a NPE.

Lots of things about <init> are important to get right.  Unfortunately, not all 
JVMs do all things (set 'this' for example) in the same order it seems.

These kinds of "ordering" issues are what make "programming in a concurrent 
environment" difficult.  We are all still largely content to look at APIs and 
say "when you use it in this way, with this ordering, it works thusly", instead 
of looking at APIs and saying "I can't guarantee the same results in all 
circumstances, maybe I need to rethink how to do this".

Gregg Wonderly

>
>     -Andy
>
>     On Tue, Nov 16, 2010 at 5:59 AM, √iktor Klang <viktor.klang at gmail.com
>     <mailto:viktor.klang at gmail.com>> wrote:
>      > From my point of view the problem is allowing logic in the constructor.
>      >
>      > On Mon, Nov 15, 2010 at 9:08 PM, David Holmes <davidcholmes at aapt.net.au
>     <mailto:davidcholmes at aapt.net.au>>
>      > wrote:
>      >>
>      >> Andy,
>      >>
>      >> The VM is required to "do the right thing" here. Only by examining an
>      >> actual
>      >> VM implementation can you determine how it achieves this, and ensure that
>      >> it
>      >> does achieve it.
>      >>
>      >> David
>      >>
>      >> > -----Original Message-----
>      >> > From: Andrew Trick [mailto:andrew.trick at gmail.com
>     <mailto:andrew.trick at gmail.com>]
>      >> > Sent: Tuesday, 16 November 2010 4:20 AM
>      >> > To: dholmes at ieee.org <mailto:dholmes at ieee.org>
>      >> > Cc: concurrency-interest at cs.oswego.edu
>     <mailto:concurrency-interest at cs.oswego.edu>
>      >> > Subject: Re: [concurrency-interest] Unsafe publication of new
>      >> > objectsquestion
>      >> >
>      >> >
>      >> > Not arguing at all. But I don't want JVM implementers and
>      >> > microarchitects to completely ignore the issue...  optimized object
>      >> > allocation will not involve thread transitions. Pre-zeroing is also
>      >> > not efficient, but moot because the JVM will likely need to do
>      >> > type-specific initialization of the object header (exposing a zero
>      >> > header == crash). Furthermore, the allocating thread need not do any
>      >> > loads to publish a newly instantiated object. It just needs to store
>      >> > the pointer in a field, not necessarily declared volatile. Any pointer
>      >> > store between instantiation and the next barrier may be a publisher
>      >> > (considering only the first publisher is insufficient). So an explicit
>      >> > barrier is needed, resulting in some type of fence on non-TSO
>      >> > machines. Hardware support for a reasonably efficient store-store
>      >> > fence is great to have for this purpose.
>      >> > -Andy
>      >> >
>      >> > On Fri, Nov 12, 2010 at 9:02 PM, David Holmes
>      >> > <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>      >> > > Andrew Trick writes:
>      >> > >>
>      >> > >> I thought the original question referred to object instantiation, not
>      >> > >> the call to <init>. Setting up the object header and zeroing fields
>      >> > >> obviously requires a barrier.
>      >> > >
>      >> > > The original question was somewhat vague.
>      >> > >
>      >> > > The JMM requires that you always see at worst a default
>      >> > initialized object,
>      >> > > so yes there are some implicit barriers in there, but the
>      >> > details depend on
>      >> > > the VM implementation. Pre-zeroing the heap avoids the need for
>      >> > > explicit
>      >> > > zeroing at object allocation. Thread transitions to/from Java/VM code
>      >> > > provide implicit (and sometimes explicit) barrier effects that avoid
>      >> > > the
>      >> > > need for an explicit barrier as part of the object allocation and
>      >> > > initialization sequence.
>      >> > >
>      >> > > On some architectures the theoretical problem of being able to see a
>      >> > > reference to the object before seeing the initialized fields
>      >> > can't happen
>      >> > > anyway (at the hardware level) due to dependent-loads (as Joe
>      >> > Seigh alluded
>      >> > > to in the original post).
>      >> > >
>      >> > > Cheers,
>      >> > > David
>      >> > >
>      >> > >> -Andy
>      >> > >>
>      >> > >> On Fri, Nov 12, 2010 at 7:12 PM, David Holmes
>      >> > >> <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>      >> > >> > Justin T. Sampson writes:
>      >> > >> >> On Fri, Nov 12, 2010 at 2:16 PM, David Holmes
>      >> > >> <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>>
>      >> > >> > wrote:
>      >> > >> >>> Andrew Trick writes:
>      >> > >> >>> > The JVM needs an effective store-store memory barrier between
>      >> > >> >>> > all
>      >> > >> >>> > stores that initialize a new object and any store that
>      >> > may publish a
>      >> > >> >>> > pointer to it. Not easy to do efficiently on all architectures.
>      >> > >> >>>
>      >> > >> >>> The JVM would need this if it were to guarantee
>      >> > >> safe-publication, but it
>      >> > >> >>> doesn't guarantee that.
>      >> > >> >>
>      >> > >> >>
>      >> > >> >> It does for final fields, right? Or is that a different concept?
>      >> > >> >
>      >> > >> > There are additional guarantees regarding the initialization of
>      >> > >> > final
>      >> > >> > fields. I suggest reading Section 17.5 of the Java Language
>      >> > >> Specification
>      >> > >> > for the details, but for a simple formulation see the "Final
>      >> > >> Fields" section
>      >> > >> > of the JMM Cookbook:
>      >> > >> >
>      >> > >> > http://gee.cs.oswego.edu/dl/jmm/cookbook.html
>      >> > >> >
>      >> > >> > Cheers,
>      >> > >> > David Holmes
>      >> > >> >
>      >> > >> > _______________________________________________
>      >> > >> > Concurrency-interest mailing list
>      >> > >> > Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>      >> > >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>      >> > >> >
>      >> > >> _______________________________________________
>      >> > >> Concurrency-interest mailing list
>      >> > >> Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>      >> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>      >> > >>
>      >> > >
>      >> > >
>      >> >
>      >>
>      >> _______________________________________________
>      >> Concurrency-interest mailing list
>      >> Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>      >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>      >
>      >
>      >
>      > --
>      > Viktor Klang,
>      > Code Connoisseur
>      > Work:   Scalable Solutions
>      > Code: github.com/viktorklang <http://github.com/viktorklang>
>      > Follow: twitter.com/viktorklang <http://twitter.com/viktorklang>
>      > Read: klangism.tumblr.com <http://klangism.tumblr.com>
>      >
>      >
>
>
>
>
> --
> Viktor Klang,
> Code Connoisseur
> Work: Scalable Solutions <http://www.scalablesolutions.se>
> Code: github.com/viktorklang <http://github.com/viktorklang>
> Follow: twitter.com/viktorklang <http://twitter.com/viktorklang>
> Read: klangism.tumblr.com <http://klangism.tumblr.com>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list