RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix [v2]
Daniel D.Daugherty
dcubed at openjdk.java.net
Tue Nov 17 23:36:12 UTC 2020
On Tue, 17 Nov 2020 07:25:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Feedback from Stefan and Thomas: prefer a check against self rather than NULL
>
> 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()) {
>
> It's not obvious that's it is correct to check == NULL. Couldn't there be a lingering value from another thread, causing a spurious failure to acquire the lock? Could this be changed to _owner != self? That way we only check for a value that only the current thread could have written.
>
> Also, this is a racy read, should this be using Atomic::load?
I agree with the switch to checking `_owner != self`. The ObjectMonitor
code does checks in the same way because a thread should only check
for a value that it could have written.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1247
More information about the hotspot-runtime-dev
mailing list