[concurrency-interest] JSR-133 Cookbook and exit monitor

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Oct 9 10:57:40 EDT 2014


I am not sure what scenario you have in mind, but it is always safe to 
subsume any "last level" lock - ie a lock/unlock pair between which 
there is no lock acquired.

If you mean that a class initializer has a lock acquisition inside, then 
deadlocks can happen with or without lock coarsening. This is a fact of 
life, and the cause is lazy class loading/initialization/lack of control 
over class lifecycle.

Alex

On 09/10/2014 15:16, √iktor Ҡlang wrote:
>
>
> On Thu, Oct 9, 2014 at 4:11 PM, Aleksey Shipilev 
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
>
>     On 10/09/2014 05:25 PM, √iktor Ҡlang wrote:
>     > But given the following logic:
>     >
>     > method A = {
>     > synchronized(foo) {
>     >   …
>     > }
>     >
>     > synchronized(bar) {
>     >   …
>     > }
>     >
>     > synchronized(foo) {
>     >   …
>     > }
>     > }
>     >
>     > method B = {
>     >   synchronized(bar) {
>     >     …
>     >     synchronized(foo) {
>     >       …
>     >     }
>     >   }
>     > }
>     >
>     > If method A's synchronized(foo)s are coarsened to -contain- the
>     > synchronized(bar), we now had a deadlock situation between A and B,
>     > where there was none before. Does the lock coarsening take
>     things like
>     > this into account? (I hope?)
>
>     Lock/unlock actions are synchronization actions, and are in total
>     order
>     which is consistent with program order. The transformation you are
>     proposing is violating "unlock(foo) --so/po--> lock(bar) --so/po-->
>     unlock(bar) --so/po--> lock(foo)" constraint, and it is therefore
>     prohibited under JMM rules.
>
>     In other words, you can coarsen the locks, but not when you mess with
>     other synchronization actions.
>
>
> Yes, agreed, my point was that class loading is a synchronization 
> action, so that means that coarsening would only ever be able to 
> subsume/merge adjacent locking on the same monitor if the instructions 
> in between are not referring to possibly unloaded classes. (amongst 
> other things).
>
>
>     -Aleksey.
>
>
>
>
>
> -- 
> Cheers,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/79672bd1/attachment-0001.html>


More information about the Concurrency-interest mailing list