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

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


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

>  Sure. lock/unlock are synchronization actions, so they form a total order.
>

Yes, so let's say that synchronized(bar) in the code is really a reference
to the class Bar, and the static initializer of Bar does synchronized(foo)…


>
> Alex
>
>
> On 09/10/2014 14:25, √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?)
>
> 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,
>>
>
>


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


More information about the Concurrency-interest mailing list