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

Remi Forax forax at univ-mlv.fr
Wed Oct 8 08:09:45 EDT 2014


On 10/08/2014 12:51 PM, √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.

even in this case,
class Foo {
   public synchronized void setBar(Bar bar) { ... }
   public synchronized void setBaz(Baz baz) { ... }
}
...
   Foo foo = ...
   foo.setBar(bar);
   foo.setBaz(baz);

because sadly this code is very common :(

Rémi

>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141008/846735ca/attachment.html>


More information about the Concurrency-interest mailing list