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

√iktor Ҡlang viktor.klang at gmail.com
Wed Oct 8 10:17:01 EDT 2014


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/76d50a79/attachment-0001.html>


More information about the Concurrency-interest mailing list