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

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Oct 9 10:48:39 EDT 2014


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 <mailto: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
>>     <mailto: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
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>         _______________________________________________
>>         Concurrency-interest mailing list
>>         Concurrency-interest at cs.oswego.edu
>>         <mailto: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/353834c3/attachment.html>


More information about the Concurrency-interest mailing list