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

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 8 09:55:34 EDT 2014


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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141008/1abb6e45/attachment.html>


More information about the Concurrency-interest mailing list