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

√iktor Ҡlang viktor.klang at gmail.com
Wed Oct 8 06:51:20 EDT 2014


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.

On Wed, Oct 8, 2014 at 12:19 PM, thurstonn <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
> 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/20141008/0331f508/attachment.html>


More information about the Concurrency-interest mailing list