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

Doug Lea dl at cs.oswego.edu
Wed Oct 8 07:49:51 EDT 2014


On 10/08/2014 06:51 AM, √iktor Ҡlang wrote:
> Sounds really bad if this is the case. I can totally understand eliding locks
> that are re-taken in a nested fashion, but coarsening in terms of coalescing
> neighboring acquisitions seems dubious.

A memory model just says what reorderings etc are legal,
but doesn't tell you if any are desirable. The rules enable
but don't mandate biased locking, coarsening etc that might
be performed by compilers and processors. In practice, these
sometimes occur for "synchronized" blocks, but not for
j.u.c.locks Locks or related synchronizers, at least
for hotspot running on currently supported processors.

-Doug

>
> On Wed, Oct 8, 2014 at 12:19 PM, thurstonn <thurston at nomagicsoftware.com
> <mailto:thurston at nomagicsoftware.com>> 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
>
>
>
>
> --
> Cheers,
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>





More information about the Concurrency-interest mailing list