RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix
Stefan Karlsson
stefank at openjdk.java.net
Tue Nov 17 07:29:06 UTC 2020
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
Thanks for updating Mutex::try_lock and adding the comments!
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?
-------------
Changes requested by stefank (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1247
More information about the hotspot-runtime-dev
mailing list