Monitor lock/unlock semantics in the JMM

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

Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
Hi,

I was asking myself whether the monitor lock/unlock semantics are
present somewhere in the JMM.

What I mean is the behavior that when one thread is holding a lock,
another cannot acquire it. I can find it in Section 17.1, but I would
expect there to be an explicit requirement for the synchronization
order, but it's not there.

Basic example:

final Object lock = new Object();

T1:
synchronized (lock) {
   //some non-synchronization actions
}

T2:
synchronized (lock) {
   //some non-synchronization actions
}

What prevents the synchronization order from being e.g.
1: acquire lock (by T1)
2: acquire lock (by T2)
3: release lock (by T2)
4: release lock (by T1)


Greets,
Felix



--
andrena objects ag
Albert-Nestler-Str. 9
76131 Karlsruhe

t: +49 (0) 721 6105 122
f: +49 (0) 721 6105 140

http://www.andrena.de

Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
On 1/15/19 4:10 PM, Felix Riemann via Concurrency-interest wrote:
> Hi,
>
> I was asking myself whether the monitor lock/unlock semantics are present somewhere in the JMM.
>
> What I mean is the behavior that when one thread is holding a lock, another cannot acquire it. I can
> find it in Section 17.1, but I would expect there to be an explicit requirement for the
> synchronization order, but it's not there.

17.1 should be enough, no?

> Basic example:
>
> final Object lock = new Object();
>
> T1:
> synchronized (lock) {
>   //some non-synchronization actions
> }
>
> T2:
> synchronized (lock) {
>   //some non-synchronization actions
> }
>
> What prevents the synchronization order from being e.g.
> 1: acquire lock (by T1)
> 2: acquire lock (by T2)
> 3: release lock (by T2)
> 4: release lock (by T1)
I think the confusion here is the confusion between "statement" and "action". In JMM sense, (2)
means "T2 had acquired the lock". Note, it is not "T2 had entered synchronized block", not "T2 had
attempted to acquire the lock", it is about the actual acquisition happened.

In that interpretation, this execution is impossible, because JLS 17.1 requires T1 to relinquish the
lock before T2 can acquire it. JMM alone does not allow/forbid everything that happens in the
program, the rest of the specification should also hold. JMM connects with that by requiring that
relatable execution should have the actions that each thread does according to intra-thread
semantics (JLS 17.4.3).

-Aleksey


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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
 > JMM connects with that by requiring that
 > relatable execution should have the actions that each thread does
 > according to intra-thread semantics (JLS 17.4.3).

True, but the locking/unlocking actions are inter-thread I believe.


 > In that interpretation, this execution is impossible, because JLS 17.1
 > requires T1 to relinquish the lock before T2 can acquire it.

Yes, but what "before" actually means only becomes clear in 17.4. I
can't think of any reasonable interpretation of "before" aside from
being derived from SO.



Maybe I should interpret it in this way so that 17.1 has an influence in
the set of allowed SO?



[sorry, didn't replay to the list the first time]


--
andrena objects ag
Albert-Nestler-Str. 9
76131 Karlsruhe

t: +49 (0) 721 6105 122
f: +49 (0) 721 6105 140

http://www.andrena.de

Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
Felix Riemann writes:

>
>  > JMM connects with that by requiring that  > relatable execution should have the actions that each thread does  > according to intra-
> thread semantics (JLS 17.4.3).
>
> True, but the locking/unlocking actions are inter-thread I believe.
>
>  > In that interpretation, this execution is impossible, because JLS 17.1  > requires T1 to relinquish the lock before T2 can acquire it.
>
> Yes, but what "before" actually means only becomes clear in 17.4. I can't think of any reasonable interpretation of "before" aside from
> being derived from SO.

"before" is the simple/obvious temporal ordering. The semantics of monitors means that only one thread can hold a given monitor at a time, so an acquire-the-lock in T2 can only happen temporally after the release-the-lock in T1. There's nothing subtle here.

David
-------
 

>
>
> Maybe I should interpret it in this way so that 17.1 has an influence in the set of allowed SO?
>
>
>
> [sorry, didn't replay to the list the first time]
>
>
> --
> andrena objects ag
> Albert-Nestler-Str. 9
> 76131 Karlsruhe
>
> t: +49 (0) 721 6105 122
> f: +49 (0) 721 6105 140
>
> http://www.andrena.de
>
> Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Sch rle
> Aufsichtsratsvorsitzender: Rolf Hetzelberger
>
> Sitz der Gesellschaft: Karlsruhe
> Amtsgericht Mannheim, HRB 109694
> USt-IdNr. DE174314824
> _______________________________________________
> 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: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
On 1/15/19 9:37 PM, David Holmes via Concurrency-interest wrote:

>>> JMM connects with that by requiring that  > relatable execution should have the actions that
>>> each thread does  > according to intra-
>> thread semantics (JLS 17.4.3).
>>
>> True, but the locking/unlocking actions are inter-thread I believe.
>>
>>> In that interpretation, this execution is impossible, because JLS 17.1  > requires T1 to
>>> relinquish the lock before T2 can acquire it.
>>
>> Yes, but what "before" actually means only becomes clear in 17.4. I can't think of any
>> reasonable interpretation of "before" aside from being derived from SO.
>
> "before" is the simple/obvious temporal ordering. The semantics of monitors means that only one
> thread can hold a given monitor at a time, so an acquire-the-lock in T2 can only happen
> temporally after the release-the-lock in T1. There's nothing subtle here.
This.

But in case you want a constructionist explanation, that gives some JMM-style intuition about
"before", consider this. "Acquire lock" has to observe the lock state "unlocked", and it changes it
to "locked", atomically. "Release lock" changes the lock state to "unlocked". This is intuitive from
17.1 about locking semantics.

So, your execution here, assuming that these actions are in SO:

1: acquire lock (by T1)
2: acquire lock (by T2)
3: release lock (by T2)
4: release lock (by T1)

...says that (2) had observed the lock state "unlocked". Which violates SO consistency, because all
the actions that change the lock state to "unlocked" are either after (2) in SO, like (3) or (4), or
before (2) in SO, but protected by (1) that definitely changed the value to "locked".

-Aleksey


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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
 >> "before" is the simple/obvious temporal ordering.

After all I've read about JMM, to me the implications that time has on
the possible executions of a program seem far from obvious.

Aleksey, you once wrote yourself in a footnote of one of your blogposts
once how the "intuitive notion of simultaneity and global time" gets
deconstructed.

 > But in case you want a constructionist explanation

Yes, that's exactly what I was aiming for: I believe that 17.1 can (and
actually should) be translated purely into SO rules, and your
explanation can serve as a basis for that (one would still need to
include that a lock can be acquired multiple times).

Thanks.

Am 15.01.2019 um 22:03 schrieb Aleksey Shipilev:

> On 1/15/19 9:37 PM, David Holmes via Concurrency-interest wrote:
>>>> JMM connects with that by requiring that  > relatable execution should have the actions that
>>>> each thread does  > according to intra-
>>> thread semantics (JLS 17.4.3).
>>>
>>> True, but the locking/unlocking actions are inter-thread I believe.
>>>
>>>> In that interpretation, this execution is impossible, because JLS 17.1  > requires T1 to
>>>> relinquish the lock before T2 can acquire it.
>>>
>>> Yes, but what "before" actually means only becomes clear in 17.4. I can't think of any
>>> reasonable interpretation of "before" aside from being derived from SO.
>>
>> "before" is the simple/obvious temporal ordering. The semantics of monitors means that only one
>> thread can hold a given monitor at a time, so an acquire-the-lock in T2 can only happen
>> temporally after the release-the-lock in T1. There's nothing subtle here.
> This.
>
> But in case you want a constructionist explanation, that gives some JMM-style intuition about
> "before", consider this. "Acquire lock" has to observe the lock state "unlocked", and it changes it
> to "locked", atomically. "Release lock" changes the lock state to "unlocked". This is intuitive from
> 17.1 about locking semantics.
>
> So, your execution here, assuming that these actions are in SO:
>
> 1: acquire lock (by T1)
> 2: acquire lock (by T2)
> 3: release lock (by T2)
> 4: release lock (by T1)
>
> ...says that (2) had observed the lock state "unlocked". Which violates SO consistency, because all
> the actions that change the lock state to "unlocked" are either after (2) in SO, like (3) or (4), or
> before (2) in SO, but protected by (1) that definitely changed the value to "locked".
>
> -Aleksey
>

--
andrena objects ag
Albert-Nestler-Str. 9
76131 Karlsruhe

t: +49 (0) 721 6105 122
f: +49 (0) 721 6105 140

http://www.andrena.de

Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Monitor lock/unlock semantics in the JMM

JSR166 Concurrency mailing list
“Global time” means total order. Not all things have total order, but synchronization actions are in a total order (so they do have a notion of “global time”)

Alex

On 15 Jan 2019, at 21:58, Felix Riemann via Concurrency-interest <[hidden email]> wrote:

>> "before" is the simple/obvious temporal ordering.

After all I've read about JMM, to me the implications that time has on the possible executions of a program seem far from obvious.

Aleksey, you once wrote yourself in a footnote of one of your blogposts once how the "intuitive notion of simultaneity and global time" gets deconstructed.

> But in case you want a constructionist explanation

Yes, that's exactly what I was aiming for: I believe that 17.1 can (and actually should) be translated purely into SO rules, and your explanation can serve as a basis for that (one would still need to include that a lock can be acquired multiple times).

Thanks.

Am 15.01.2019 um 22:03 schrieb Aleksey Shipilev:
On 1/15/19 9:37 PM, David Holmes via Concurrency-interest wrote:
JMM connects with that by requiring that  > relatable execution should have the actions that
each thread does  > according to intra-
thread semantics (JLS 17.4.3).

True, but the locking/unlocking actions are inter-thread I believe.

In that interpretation, this execution is impossible, because JLS 17.1  > requires T1 to
relinquish the lock before T2 can acquire it.

Yes, but what "before" actually means only becomes clear in 17.4. I can't think of any
reasonable interpretation of "before" aside from being derived from SO.

"before" is the simple/obvious temporal ordering. The semantics of monitors means that only one
thread can hold a given monitor at a time, so an acquire-the-lock in T2 can only happen
temporally after the release-the-lock in T1. There's nothing subtle here.
This.
But in case you want a constructionist explanation, that gives some JMM-style intuition about
"before", consider this. "Acquire lock" has to observe the lock state "unlocked", and it changes it
to "locked", atomically. "Release lock" changes the lock state to "unlocked". This is intuitive from
17.1 about locking semantics.
So, your execution here, assuming that these actions are in SO:
1: acquire lock (by T1)
2: acquire lock (by T2)
3: release lock (by T2)
4: release lock (by T1)
...says that (2) had observed the lock state "unlocked". Which violates SO consistency, because all
the actions that change the lock state to "unlocked" are either after (2) in SO, like (3) or (4), or
before (2) in SO, but protected by (1) that definitely changed the value to "locked".
-Aleksey

-- 
andrena objects ag
Albert-Nestler-Str. 9
76131 Karlsruhe

t: +49 (0) 721 6105 122
f: +49 (0) 721 6105 140

http://www.andrena.de

Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
_______________________________________________
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