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