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