[concurrency-interest] synchronized constructors

Roland Kuhn rk at rkuhn.info
Fri Dec 16 07:09:40 EST 2011


On Dec 16, 2011, at 12:52 , Ruslan Cheremin wrote:

>>>> I don’t see anything in chapter 8 which allows synchronized to be elided at all. Viewed from a single thread, the main guarantees of synchronized are “fresh reads after lock” and “writes flushed before unlock”, and these cannot be elided. If the VM sees that nobody else is ever locking on the same object, I would assume that the “mutual exclusion” part may be elided, but not the memory effects.
>>> 
>>> Main guarantee of synchronized is ordering (HB edges). So, if
>>> happens-before edges it creates is subset of already exists
>>> happens-before edges -- such synchronization can be elided. For
>>> example, if lock used by only one thread -- it ca be proved, that HB
>>> edges it creates is subset of HB edges which just simple program order
>>> creates.So -- it can be elided. And HotSpot actually do such
>>> optimization in several cases, when it can prove monitor not leaving
>>> single thread.
>>> 
>>> Biased locking optimization is another example.
>> 
>> 
>> The JVM spec is very clear on prescient writes, and there is no constraint there wrt. lock eliding. This means that IF locks are elided, this cannot weaken memory consistency guarantees. Please provide pointers to the spec where this is allowed in case I’m wrong.
> 
> Yes, sure, IF lock are elided memory consistency effect still must be
> the same, as if it still here.

Okay, then JVM spec 8.8 says that no “lock” operation can take place between a relocated “store” and its “assign”, so we are safe here, i.e. synchronized {} within constructor makes even unsafe publication impossible before the lock is entered. The remaining problem is that without acquiring the lock from the other thread, that thread may see partially initialized state. So to make sure that everything is okay, is it enough to have one final field which forces publication to happen after the constructor finishes?

> But JMM does not specify memory effects
> of locking as “fresh reads after lock” or “writes flushed before
> unlock” -- memory effects specified in terms of HB-edges lock/unlock
> creates. And if such edges are redundant -- they are still exists even
> without specific lock, since, for example, the same edges are created
> by program order -- the lock can be thrown out, and this does not
> change memory semantics (full set of HB edges in execution will not be
> changed). This is one of the greatest benefits of new JMM, which
> allows kind of optimization I've noted (lock ellision/biased locking).
> 
Yes, certainly. Unless it becomes impossible to create a mutable object which has the same memory visibility guarantees wrt. construction as compared to one which has only final fields.

Regards,

Roland

--
I'm a physicist: I have a basic working knowledge of the universe and everything it contains!
    - Sheldon Cooper (The Big Bang Theory)




More information about the Concurrency-interest mailing list