RFR: 8313202: MutexLocker should disallow null Mutexes

[Aleksey Shipilev]

On Wed, 26 Jul 2023 22:28:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry the names are awful and confusing.

...

So what would be the good name/convention to capture these three cases:
 1. (default one) Mutex is not null, do not hold the mutex already. This is `MutexLocker` in this PR.
 2. (special case) Check condition before locking the mutex, mutex should not be null otherwise. This is `ConditionalMutexLocker` in this PR.
 3. (special case) Check that mutex is not held, lock otherwise. This is `ReentrantMutexLocker` in this PR.

Ideally, something that would make a casual reader understand that the code like this can actually _skip_ synchronization: 


MutexLockerEx ml(MyLock_lock, ...)
<do-stuff>


>  If you want to special-case this then make an argument to re-instate MutexLockerEx.

I cannot see how `MutexLockerEx` conveys the null-accepting/lock-skipping property. Yes, I understand that before [JDK-8222811](https://bugs.openjdk.org/browse/JDK-8222811), we had that null-accepting form as `MutexLockerEx`, but then I think we can name it better if we are about to backtrack on it.

> I don't think JDK-8313081 is sufficient justification for a change of this nature/scope.

The justification seems to be discussed in the bug report itself, so I'll discuss it there.

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

PR Comment: https://git.openjdk.org/jdk/pull/15043#issuecomment-1653124603