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

√iktor Ҡlang viktor.klang at gmail.com
Thu Oct 9 10:16:12 EDT 2014


On Thu, Oct 9, 2014 at 4:11 PM, Aleksey Shipilev <
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/fe4920e0/attachment.html>


More information about the Concurrency-interest mailing list