RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix
David Holmes
david.holmes at oracle.com
Tue Nov 17 09:00:08 UTC 2020
Hi Thomas,
Thanks for reviewing this.
On 17/11/2020 5:29 pm, Thomas Stuefe wrote:
> On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes <dholmes at openjdk.org> wrote:
>
>> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking.
>>
>> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes.
>>
>> Testing: GHA, mach5 tiers 1-3
>
> Hi David,
>
> LGTM. Minor remarks below.
>
> Thanks, Thomas
>
> src/hotspot/share/runtime/mutex.cpp line 147:
>
>> 145: // safepoint state, but can check blocking state.
>> 146: check_block_state(self);
>> 147: if (_owner == NULL && _lock.try_lock()) {
>
> `_owner != self` may be a bit clearer, at the expense of maybe unnecessarily calling into platform code (but before, we did that unconditionally).
Right - see my response to Stefan.
> src/hotspot/share/runtime/mutex.cpp line 141:
>
>> 139: // Returns true if thread succeeds in grabbing the lock, otherwise false.
>> 140: // Checking for a NULL owner avoids the call into platform code and hides the
>> 141: // potential difference in recursive locking behaviour on some platforms.
>
> Maybe move comment down to 146?
I'll move it and modify it.
Thanks,
David
-----
> -------------
>
> Marked as reviewed by stuefe (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/1247
>
More information about the hotspot-runtime-dev
mailing list