JSR-133 Cookbook and exit monitor

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

JSR-133 Cookbook and exit monitor

thurstonn
Hello,

If I read the jsr-133 cookbook 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
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

David Holmes-6
thurstonn writes:

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

Not only is it allowed, it can easily be performed by the JIT. If that seems
"unhealthy" you will be really freaked out by lock-coarsening which can
coalesce:

synchronized(x) {
 // aaa
}
// other code
synchronized(x) {
 // bbb
}

into

synchronized(x) {
  // aaa
  // other code
  // bbb
}

where anything in the sync block can of course be further reordered.

Of course this can't be done arbitrarily but it can be done.

Cheers,
David Holmes

>
>
>
> --
> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Viktor Klang
In reply to this post by thurstonn
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.

On Wed, Oct 8, 2014 at 12:19 PM, thurstonn <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

thurstonn
In reply to this post by David Holmes-6
David Holmes-6 wrote
Not only is it allowed, it can easily be performed by the JIT. If that seems
"unhealthy" you will be really freaked out by lock-coarsening which can
coalesce:

synchronized(x) {
 // aaa
}
// other code
synchronized(x) {
 // bbb
}

into

synchronized(x) {
  // aaa
  // other code
  // bbb
}

where anything in the sync block can of course be further reordered.

Of course this can't be done arbitrarily but it can be done.

Cheers,
David Holmes

>
Thanks.
To be precise, there is a hb(aaa, bbb), surely that needs to be respected in the rewritten *coalesced* code; as far as "other code", anything goes I guess
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Doug Lea
In reply to this post by Viktor Klang
On 10/08/2014 06:51 AM, √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.

A memory model just says what reorderings etc are legal,
but doesn't tell you if any are desirable. The rules enable
but don't mandate biased locking, coarsening etc that might
be performed by compilers and processors. In practice, these
sometimes occur for "synchronized" blocks, but not for
j.u.c.locks Locks or related synchronizers, at least
for hotspot running on currently supported processors.

-Doug

>
> On Wed, Oct 8, 2014 at 12:19 PM, thurstonn <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> --
> Cheers,
> √
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Remi Forax
In reply to this post by Viktor Klang

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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Viktor Klang


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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.
 

Rémi



On Wed, Oct 8, 2014 at 12:19 PM, thurstonn <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Remi Forax

On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Viktor Klang


On Wed, Oct 8, 2014 at 2:36 PM, Remi Forax <[hidden email]> wrote:

On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Vitaly Davidovich

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" <[hidden email]> wrote:


On Wed, Oct 8, 2014 at 2:36 PM, Remi Forax <[hidden email]> wrote:

On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Viktor Klang


On Wed, Oct 8, 2014 at 3:55 PM, Vitaly Davidovich <[hidden email]> 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" <[hidden email]> wrote:


On Wed, Oct 8, 2014 at 2:36 PM, Remi Forax <[hidden email]> wrote:

On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Vitaly Davidovich
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 <[hidden email]> wrote:


On Wed, Oct 8, 2014 at 3:55 PM, Vitaly Davidovich <[hidden email]> 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" <[hidden email]> wrote:


On Wed, Oct 8, 2014 at 2:36 PM, Remi Forax <[hidden email]> wrote:

On 10/08/2014 02:30 PM, √iktor Ҡlang wrote:


On Wed, Oct 8, 2014 at 2:09 PM, Remi Forax <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,




--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Cheers,


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Hans Boehm
The original transformation, moving a trailing "y = 43" into a critical section, can typically happen on a weakly ordered architecture like ARM as a result of hardware reordering.   On such an architecture, an ordinary lock release is essentially a fence followed by an unordered CAS (or on ARMv8, a CAS with release semantics).  There is nothing to prevent a later store to y from becoming visible before the CAS releasing the lock.  No compiler transformations required ...

Hans

On Wed, Oct 8, 2014 at 7:34 AM, Vitaly Davidovich <[hidden email]> wrote:
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.



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Vitaly Davidovich
That's fine -- if hardware wants to reorder, no issues (and it typically does that for efficiency anyway).  My curiosity is about compiler-only transformation, as I'm interested in seeing what that code would look like.

On Wed, Oct 8, 2014 at 2:12 PM, Hans Boehm <[hidden email]> wrote:
The original transformation, moving a trailing "y = 43" into a critical section, can typically happen on a weakly ordered architecture like ARM as a result of hardware reordering.   On such an architecture, an ordinary lock release is essentially a fence followed by an unordered CAS (or on ARMv8, a CAS with release semantics).  There is nothing to prevent a later store to y from becoming visible before the CAS releasing the lock.  No compiler transformations required ...

Hans

On Wed, Oct 8, 2014 at 7:34 AM, Vitaly Davidovich <[hidden email]> wrote:
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.




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

David Holmes-6
In reply to this post by thurstonn
Thurston writes:

> David Holmes-6 wrote
> > Not only is it allowed, it can easily be performed by the JIT. If that
> > seems
> > "unhealthy" you will be really freaked out by lock-coarsening which can
> > coalesce:
> >
> > synchronized(x) {
> >  // aaa
> > }
> > // other code
> > synchronized(x) {
> >  // bbb
> > }
> >
> > into
> >
> > synchronized(x) {
> >   // aaa
> >   // other code
> >   // bbb
> > }
> >
> > where anything in the sync block can of course be further reordered.
> >
> > Of course this can't be done arbitrarily but it can be done.
> >
> > Cheers,
> > David Holmes
> >
> >>
>
> Thanks.
> To be precise, there is a hb(aaa, bbb), surely that needs to be
> respected in the rewritten *coalesced* code; as far as "other code",
> anything goes I guess

I don't believe hb has any impact here - as long as intra thread semantics
are obeyed.

Lock coarsening has been employed in hotspot for years now:

http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2

Personally I opposed it on liveness grounds - I presume that if you wrote
two close but seperate sync blocks then you had a good reason to do so, most
likely relating to liveness.

David
-----




>
>
>
> --
> View this message in context:
http://jsr166-concurrency.10961.n7.nabble.com/JSR-133-Cookbook-and-exit-moni
tor-tp11323p11328.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Nathan Reynolds-2
Generally, I am against lock coarsening.  When facing a problematic lock, the first thing I do is move everything out of the lock that can possibly be done.

In HotSpot version 7349, JIT will generate code with aggressive lock coarsening.  If the lock becomes contended, then it will iteratively reduce or remove the coarsening and see if that improves lock throughput.  It will even go further and automatically pull out all of the code which doesn't need to be inside the lock.  ;)

Example #1

Consider this code which models an actual problem seen.  key.hashCode() takes a lot of CPU time but fortunately the result is cached inside the key object.  The problem is that key.hashCode() was being computed inside the lock for most key objects.

synchronized (map)
{
   map.put(key, value);
}

The solution was to simply call key.hashCode() just before the lock.  Fortunately, HotSpot doesn't pull this back inside the lock.

key.hashCode();

synchronized (map)
{
   map.put(key, value);
}

However, there are some cases where lock coarsening makes sense.

Example #2

Consider this code which models an actual problem seen.  In the actual problem, we weren't dealing with a Map however this code suffices to make the point.  Each iteration is going to acquire and release the lock.  The code executed outside of the lock (i.e. the for statement) is very light.  It makes sense to coarsen the lock to surround the entire for loop so that the lock is acquired and released one time.

private Map<String, String> map = Collections.synchronizedMap(new HashMap<>());

...
   for (i = 0; i < array.length; i++)
      map.put(array[i], ""));

Example #3

Consider this code.  If functionA() is inlined into functionB(), then there will be 2 synchronized blocks on the same lock back to back to each other.  The programmer isn't being dumb.  This is where software design creates a situation where lock coarsening is good.

void functionA()
{
   // some code

    synchronized (lock)
    {
        // some more code
    }
}

void functionB()
{
    functionA();

    synchronized (lock)
    {
        // some more code
    }

   // some code
}
-Nathan
On 10/8/2014 8:16 PM, David Holmes wrote:
Thurston writes:
David Holmes-6 wrote
Not only is it allowed, it can easily be performed by the JIT. If that
seems
"unhealthy" you will be really freaked out by lock-coarsening which can
coalesce:

synchronized(x) {
 // aaa
}
// other code
synchronized(x) {
 // bbb
}

into

synchronized(x) {
  // aaa
  // other code
  // bbb
}

where anything in the sync block can of course be further reordered.

Of course this can't be done arbitrarily but it can be done.

Cheers,
David Holmes


          
Thanks.
To be precise, there is a hb(aaa, bbb), surely that needs to be
respected in the rewritten *coalesced* code; as far as "other code",
anything goes I guess
I don't believe hb has any impact here - as long as intra thread semantics
are obeyed.

Lock coarsening has been employed in hotspot for years now:

http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2

Personally I opposed it on liveness grounds - I presume that if you wrote
two close but seperate sync blocks then you had a good reason to do so, most
likely relating to liveness.

David
-----






--
View this message in context:
http://jsr166-concurrency.10961.n7.nabble.com/JSR-133-Cookbook-and-exit-moni
tor-tp11323p11328.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

thurstonn
In reply to this post by David Holmes-6
"I don't believe hb has any impact here - as long as intra thread semantics
are obeyed."

Yes, you're right - any other thread that subsequently acquires the monitor will see aaa and other code and bbb no matter what their 'original' execution order; silly comment on my part
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

Florian Binder
In reply to this post by Nathan Reynolds-2
I would like to throw another question into this interesting discussion:

How is the relationship between lock coarsening and biased locking?

Both depends on contention. So if the lock is not contended biased locking can be used and coarsening is not necessary anymore. But is coarsening really useful in the case where it is contended so biased locking can not be used?

Or is it maybe dependent on the degree of contention like this:

no contention: biased locking
low contention: coarsening
high contention: nothing

Flo

Am 09.10.2014 um 06:43 schrieb Nathan Reynolds:
Generally, I am against lock coarsening.  When facing a problematic lock, the first thing I do is move everything out of the lock that can possibly be done.

In HotSpot version 7349, JIT will generate code with aggressive lock coarsening.  If the lock becomes contended, then it will iteratively reduce or remove the coarsening and see if that improves lock throughput.  It will even go further and automatically pull out all of the code which doesn't need to be inside the lock.  ;)

Example #1

Consider this code which models an actual problem seen.  key.hashCode() takes a lot of CPU time but fortunately the result is cached inside the key object.  The problem is that key.hashCode() was being computed inside the lock for most key objects.

synchronized (map)
{
   map.put(key, value);
}

The solution was to simply call key.hashCode() just before the lock.  Fortunately, HotSpot doesn't pull this back inside the lock.

key.hashCode();

synchronized (map)
{
   map.put(key, value);
}

However, there are some cases where lock coarsening makes sense.

Example #2

Consider this code which models an actual problem seen.  In the actual problem, we weren't dealing with a Map however this code suffices to make the point.  Each iteration is going to acquire and release the lock.  The code executed outside of the lock (i.e. the for statement) is very light.  It makes sense to coarsen the lock to surround the entire for loop so that the lock is acquired and released one time.

private Map<String, String> map = Collections.synchronizedMap(new HashMap<>());

...
   for (i = 0; i < array.length; i++)
      map.put(array[i], ""));

Example #3

Consider this code.  If functionA() is inlined into functionB(), then there will be 2 synchronized blocks on the same lock back to back to each other.  The programmer isn't being dumb.  This is where software design creates a situation where lock coarsening is good.

void functionA()
{
   // some code

    synchronized (lock)
    {
        // some more code
    }
}

void functionB()
{
    functionA();

    synchronized (lock)
    {
        // some more code
    }

   // some code
}
-Nathan
On 10/8/2014 8:16 PM, David Holmes wrote:
Thurston writes:
David Holmes-6 wrote
Not only is it allowed, it can easily be performed by the JIT. If that
seems
"unhealthy" you will be really freaked out by lock-coarsening which can
coalesce:

synchronized(x) {
 // aaa
}
// other code
synchronized(x) {
 // bbb
}

into

synchronized(x) {
  // aaa
  // other code
  // bbb
}

where anything in the sync block can of course be further reordered.

Of course this can't be done arbitrarily but it can be done.

Cheers,
David Holmes

Thanks.
To be precise, there is a hb(aaa, bbb), surely that needs to be
respected in the rewritten *coalesced* code; as far as "other code",
anything goes I guess
I don't believe hb has any impact here - as long as intra thread semantics
are obeyed.

Lock coarsening has been employed in hotspot for years now:

http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2

Personally I opposed it on liveness grounds - I presume that if you wrote
two close but seperate sync blocks then you had a good reason to do so, most
likely relating to liveness.

David
-----





--
View this message in context:
http://jsr166-concurrency.10961.n7.nabble.com/JSR-133-Cookbook-and-exit-moni
tor-tp11323p11328.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

David Holmes-6
HI Florian,
 
Biased-locking and lock coarsening are orthogonal issues. The JIT will impose lock coarsening when compiling the code. Biased-locking is applied when actually acquiring a lock.
 
David
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Florian Binder
Sent: Thursday, 9 October 2014 9:01 PM
To: [hidden email]
Subject: Re: [concurrency-interest] JSR-133 Cookbook and exit monitor

I would like to throw another question into this interesting discussion:

How is the relationship between lock coarsening and biased locking?

Both depends on contention. So if the lock is not contended biased locking can be used and coarsening is not necessary anymore. But is coarsening really useful in the case where it is contended so biased locking can not be used?

Or is it maybe dependent on the degree of contention like this:

no contention: biased locking
low contention: coarsening
high contention: nothing

Flo

Am 09.10.2014 um 06:43 schrieb Nathan Reynolds:
Generally, I am against lock coarsening.  When facing a problematic lock, the first thing I do is move everything out of the lock that can possibly be done.

In HotSpot version 7349, JIT will generate code with aggressive lock coarsening.  If the lock becomes contended, then it will iteratively reduce or remove the coarsening and see if that improves lock throughput.  It will even go further and automatically pull out all of the code which doesn't need to be inside the lock.  ;)

Example #1

Consider this code which models an actual problem seen.  key.hashCode() takes a lot of CPU time but fortunately the result is cached inside the key object.  The problem is that key.hashCode() was being computed inside the lock for most key objects.

synchronized (map)
{
   map.put(key, value);
}

The solution was to simply call key.hashCode() just before the lock.  Fortunately, HotSpot doesn't pull this back inside the lock.

key.hashCode();

synchronized (map)
{
   map.put(key, value);
}

However, there are some cases where lock coarsening makes sense.

Example #2

Consider this code which models an actual problem seen.  In the actual problem, we weren't dealing with a Map however this code suffices to make the point.  Each iteration is going to acquire and release the lock.  The code executed outside of the lock (i.e. the for statement) is very light.  It makes sense to coarsen the lock to surround the entire for loop so that the lock is acquired and released one time.

private Map<String, String> map = Collections.synchronizedMap(new HashMap<>());

...
   for (i = 0; i < array.length; i++)
      map.put(array[i], ""));

Example #3

Consider this code.  If functionA() is inlined into functionB(), then there will be 2 synchronized blocks on the same lock back to back to each other.  The programmer isn't being dumb.  This is where software design creates a situation where lock coarsening is good.

void functionA()
{
   // some code

    synchronized (lock)
    {
        // some more code
    }
}

void functionB()
{
    functionA();

    synchronized (lock)
    {
        // some more code
    }

   // some code
}
-Nathan
On 10/8/2014 8:16 PM, David Holmes wrote:
Thurston writes:
David Holmes-6 wrote
Not only is it allowed, it can easily be performed by the JIT. If that
seems
"unhealthy" you will be really freaked out by lock-coarsening which can
coalesce:

synchronized(x) {
 // aaa
}
// other code
synchronized(x) {
 // bbb
}

into

synchronized(x) {
  // aaa
  // other code
  // bbb
}

where anything in the sync block can of course be further reordered.

Of course this can't be done arbitrarily but it can be done.

Cheers,
David Holmes

Thanks.
To be precise, there is a hb(aaa, bbb), surely that needs to be
respected in the rewritten *coalesced* code; as far as "other code",
anything goes I guess
I don't believe hb has any impact here - as long as intra thread semantics
are obeyed.

Lock coarsening has been employed in hotspot for years now:

http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2

Personally I opposed it on liveness grounds - I presume that if you wrote
two close but seperate sync blocks then you had a good reason to do so, most
likely relating to liveness.

David
-----




--
View this message in context:
http://jsr166-concurrency.10961.n7.nabble.com/JSR-133-Cookbook-and-exit-moni
tor-tp11323p11328.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR-133 Cookbook and exit monitor

oleksandr otenko
In reply to this post by thurstonn
This is certainly part of the language spec.

unlock/lock for the same object synchronize-with each other. This
enables us to only establish happens-before between writes before the
unlock in program order and reads after a lock in program order. This
does not establish any ordering with any actions following unlock, or
preceding lock.

Alex

On 08/10/2014 11:19, thurstonn 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
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
12