RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix

Thomas Stuefe stuefe at openjdk.java.net
Tue Nov 17 07:29:07 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

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).

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?

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1247


More information about the hotspot-runtime-dev mailing list