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

√iktor Ҡlang viktor.klang at gmail.com
Thu Oct 9 14:45:13 EDT 2014


That covers my question! Thanks
On Oct 9, 2014 4:48 PM, "Oleksandr Otenko" <oleksandr.otenko at oracle.com>
wrote:

>  So they will appear in program order.
>
> Lock fusing / coarsening can only occur if no one can observe the absence
> of lock/unlock. That is, if there is nothing that someone can
> synchronize-with between unlock and lock.
>
> Alex
>
> On 09/10/2014 14:56, √iktor Ҡlang wrote:
>
>
>
> 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/af155070/attachment.html>


More information about the Concurrency-interest mailing list