[concurrency-interest] do constructors ever involve threading under the covers?
vitalyd at gmail.com
Wed Oct 3 12:05:58 EDT 2012
You might be right Aleksey - it's a bit unclear to me as to where exactly
the StoreStore is placed; it's definitely before the assignment to the
shared ref, but not sure if it's immediately after the final store or at
the end of constructor. Putting it at the end of ctor even if assignment
happened at the beginning would possibly be a perf impact on something like
ARM/PPC since more stores will have to drain, but I'm not that familiar
with ARM/PPC barrier performance.
Sent from my phone
On Oct 3, 2012 11:52 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> On 10/03/2012 07:48 PM, Aleksey Shipilev wrote:
> > On 10/03/2012 07:22 PM, Vitaly Davidovich wrote:
> >> 1) assigning to final list *before* populating it doesn't conform to
> >> JMM. It may work in practice if JIT doesn't rearrange things just
> >> because there's *any* final assignment in the ctor, but it could. You'd
> >> have to instead populate a temp list and then assign it to the final
> >> field.
> > This is true for volatile fields. But the semantics for final fields
> > seems to guarantee that the added element would be visible, because
> > (List.add) hb (freeze) in program order, and (freeze) hb (read reference
> > to new obj). Am I reading the spec incorrectly? Is it wrong to say
> > freeze action is the last action in program order of constructor?
> Otherwise, BTW, it is unclear for me how come this code is safe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest