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

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Oct 9 09:53:50 EDT 2014


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

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,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/90388988/attachment.html>


More information about the Concurrency-interest mailing list