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

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Oct 9 10:11:50 EDT 2014


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.

-Aleksey.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/62680c69/attachment-0001.bin>


More information about the Concurrency-interest mailing list