RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker

Robbin Ehn rehn at openjdk.java.net
Thu Oct 29 11:19:45 UTC 2020


On Thu, 29 Oct 2020 11:11:10 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Semaphores can be used as low-level locks, but the readability of the code using them could be better. I propose that we introduce two new classes:
>> 
>> SemaphoreLock - which provides the operations lock, unlock, try_lock.
>> 
>> SemaphoreLocker - Equivalent to MutexLocker.
>
> For low-level locks, an alternative could be to use PlatformMutex.

If you are using a semaphore exactly like a mutex, why are you not using a mutex?
Since they are not part of lock ranks they are deadlock-prone.
Main uses seems to be people not wanting to deal with lock ranks, but that only leads to deadlocks sooner or later. 

Another issue is:
SemaphoreLock sl;
sl.unlock();
sl.unlock();

Might even be correct code if you wished to signal twice.
Thus, the whole:
{
  SemaphoreLocker sl(&lock);
  // Not mutual exclusive
}

If you are not suppose to being able to unlock twice then it works exactly like a Mutex and I think we instead should fix lock ranks (whatever that means).
If you are suppose to be able to unlock twice, then it's not a lock, is it ? :)

E.g.: ThreadIdExclusiveAccess is one of the places where this SemaphoreLocker could be used, but there seems to be no issues using a Mutex instead (except choosing a rank).

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

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


More information about the hotspot-dev mailing list