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

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


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

On Thu, Oct 9, 2014 at 2:45 PM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> wrote:

> This is certainly part of the language spec.
>
> unlock/lock for the same object synchronize-with each other. This enables
> us to only establish happens-before between writes before the unlock in
> program order and reads after a lock in program order. This does not
> establish any ordering with any actions following unlock, or preceding lock.
>
> Alex
>
>
> On 08/10/2014 11:19, thurstonn wrote:
>
>> Hello,
>>
>> If I read the  jsr-133 cookbook
>> <http://gee.cs.oswego.edu/dl/jmm/cookbook.html>   correctly, given the
>> following:
>>
>>
>> <code>
>> //y is a global, non-volatile
>> enter monitor x
>> ...
>> //do some work not involving y
>> . . .
>> exit monitor x
>> y = 43
>>
>> </code>
>>
>> then at least according to the JMM, the following execution is possible:
>> <code>
>> //y is a global, non-volatile
>> enter monitor x
>> ...
>> //do some work not involving y
>> y = 43
>> exit monitor x
>> </code>
>>
>> as in the first table in the cookbook, *normal stores* are allowed to be
>> re-ordered before a *monitor exit* (but not before a *monitor enter*).
>>
>> Although the issue isn't really one involving memory consistency, is that
>> really allowed?  Because *increasing* the size of a critical section
>> seems .
>> . . I don't know . . . unhealthy.
>> What if the program code computed the first 1000 prime numbers or
>> something
>> and wrote them to a global array (after the monitor exit)?
>>
>> I was always under the impression that only the operations specified
>> within
>> a critical section would actually be executed between the enter/exit
>> monitor
>> pair
>>
>> NB: Although, presumably the runtime/CPU would only do this if the
>> critical
>> section was leading to CPU stalls or the like and so in reality, not
>> really
>> producing a longer critical section execution time
>>
>>
>>
>>
>> --
>> View this message in context: http://jsr166-concurrency.
>> 10961.n7.nabble.com/JSR-133-Cookbook-and-exit-monitor-tp11323.html
>> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/e6bb7e20/attachment-0001.html>


More information about the Concurrency-interest mailing list