[concurrency-interest] synchronized constructors

Ruslan Cheremin cheremin at gmail.com
Fri Dec 16 06:52:42 EST 2011


>>> 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. 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).



> Regards,
>
> Roland
>
> --
> Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.
>  -- Dijkstra
>



More information about the Concurrency-interest mailing list