Bug ID: JDK-8255678 Add Mutex::try_lock version without rank checks

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 16
16 b26Fixed

The mutex ranking is used as a deadlock prevention technique that assigns a rank to each Mutex. Mutexes have to be acquired in order of decreasing rank which prevents circular waits. Today we validate this order everytime we acquire ownership of a Mutex. We could relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. in cases where the action under the lock is desirable but can be skipped on try_lock() failure. In these cases, even if the Mutex is out of rank order the thread will not block if it already has an owner, so circular waits are not possible.

Changeset: aabc9ca2 Author: Patricio Chilano Mateo <pchilanomate@openjdk.org> Date: 2020-11-23 15:41:19 +0000 URL: https://github.com/openjdk/jdk/commit/aabc9ca2
23-11-2020
Testing https://github.com/pchilano/jdk/commits/8255678-trylock
16-11-2020
I changed the title of the bug since skipping rank checks in try_lock is not right in all cases. If failure to acquire ownership of the lock blocks progress then rank checks should still be made. For example, we could have the following pattern with locks A and B, where A has greater rank than B: Thread1: B->lock() while(true) { if (A->try_lock()) { // do something A->unlock() break; } } B->unlock() Thread2: A->lock() B->lock() // do something B->unlock() A->unlock() i.e. calling try_lock() in an infinite loop waiting for the call to be successful to make progress is equivalent to calling lock(). So by default try_lock() should still do rank checks, but we could add try_lock_without_rank_check() for those cases where the action under the lock is only desirable and doesn't block progress, e.g. JDK-8254877. (Updated Github link above with patch)
16-11-2020
Sorry, we didn't see that it was blocking.
04-11-2020
Thank you!
04-11-2020
Hi Stefan, I didn't add the oracle-triage-16 label when I created it so I guess they gave it the default rt-notfor-16. I fixed it.
03-11-2020
[~pchilanomate] [~mseledtsov] This RFE is currently is set as blocking the bug JDK-8254877. Did you consider that when tagging this as rt-notfor-16?
03-11-2020

Blocks :	JDK-8256382 - Use try_lock for hs_err EventLog printing
Blocks :	JDK-8254877 - GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
Relates :	JDK-8256383 - PlatformMutex::try_lock has different semantics on Windows and Posix