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

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 8 10:34:03 EDT 2014


Yes, as Doug pointed out, the "roach motel" semantics is just an allowed
reordering -- compiler will hopefully not stuff more things into a critical
section unless it has strong evidence that it's worthwhile.  I'd actually
be curious to hear from anyone that's seen such a transformation.

On Wed, Oct 8, 2014 at 10:17 AM, √iktor Ҡlang <viktor.klang at gmail.com>
wrote:

>
>
> On Wed, Oct 8, 2014 at 3:55 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> What is unhealthy about this? That a critical section lifetime is
>> extended? Let's assume both fields are in cache, why would you want two
>> relatively expensive lock acquisitions back to back instead of one?
>>
> (Sidenote: Personally as I wouldn't want -any- expensive lock
> acquisitions—I'd go lock-free.)
>
> I'll have to think about it some more but my "Spidey senses are tingling".
>
> What I reacted to was:
>
> synchronized(x) { do stuff }
> do other stuff
> synchronized(x) { do more stuff }
>
> The thing in the middle there is deliberately put outside of critical
> sections, so it seems more like a compiler suggestion to widen it than a
> runtime decision.
>
> Let me dig a bit in my archives and see if I can find a use case for the
> construct above.
>
> Sent from my phone
>> On Oct 8, 2014 9:36 AM, "√iktor Ҡlang" <viktor.klang at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 8, 2014 at 2:36 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>>>
>>>> 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> 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.
>>>>
>>>
>>> It sounds like an (unhealthy?) possible interaction between roach motel
>>> rule and lock coarsening?
>>>
>>>
>>>>
>>>> Rémi
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Rémi
>>>>>
>>>>>
>>>>>
>>>>> 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,
>>>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing list
>>>>> Concurrency-interest at cs.oswego.edu
>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>  Cheers,
>>>>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>>>>>
>>> _______________________________________________
>>> 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/8334bf23/attachment-0001.html>


More information about the Concurrency-interest mailing list