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

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


On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:
>
>
> On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>
>     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 :(
>
>
> Agreed. The case above is not really problematic since there are no 
> invocations/reads/writes in between.

sorry my code was not clear, I should have written:
   Foo foo = ...
   foo.setBar(this.bar);
   foo.setBaz(this.baz);

there is a load of the field baz in between the call to setBar and the 
call to setBaz.

Rémi

>
>     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  <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/20141008/17bfaed8/attachment-0001.html>


More information about the Concurrency-interest mailing list