RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker

[Coleen Phillimore]

On Thu, 29 Oct 2020 11:41:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.

I agree with Kim and David's comments.  We were talking about doing the mutex ranking fix "really soon now".  If we have to invent another mechanism to subvert it, maybe the priority of the work should be higher for that and this feedback should be included in the design of how we would like it to work.   Please don't rush push this because I haven't had a time to properly review it right now.

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

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