RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker

[David Holmes]

On Thu, 29 Oct 2020 11:39:32 GMT, Kim Barrett <kbarrett 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.
>
> I don't think we should be using semaphores as a substitute for fixing mutex rankings or using some rankless mutex (like PlatformMutex).  So I'm not in favor of this change.

As I recall one of the reasons Semaphore is used as a lock in places is because of initialization constraints related to Mutex and PlatformMutex. Then there is also the ability to use semaphores in signal handlers. 

The key difference between "locks" and "a binary semaphore used like a lock" is that true locks have a notion of ownership and can generally only be unlocked by their owner. That is not enforced by SemaphoreLock making it somewhat not-a-lock. That said the name and API at least convey the intent. But it is critical to document why you need to use a semaphore as a lock instead of using a "real" lock like Mutex or PlatformMutex. If it only to avoid rank issues then I agree with others that that is not sufficient justification.

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

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