public class NoYieldpointsMonitor extends Monitor
Note that calling any of the withHandshake methods on an instance of this class is extremely dangerous. These methods may cause you to block on GC, which seemingly goes against the very intent of this being a "no interrupts" condition variable and lock. However, it makes a subtle kind of sense to use these methods, if you're calling them on the instance of NoInterruptsCondLock that your thread will wait on when blocking on GC. This idiom is used quite a bit.
To ensure that the withHandshake methods are used correctly - that is, that they are only used by the thread that owns the lock - there are assertions in place to ensure that the caller is the owner.
acquireCount, holderSlot, monitor, recCount
Constructor and Description |
---|
NoYieldpointsMonitor() |
Modifier and Type | Method and Description |
---|---|
void |
lockNoHandshake()
Wait until it is possible to acquire the lock and then acquire it.
|
void |
lockWithHandshake()
Wait until it is possible to acquire the lock and then acquire it.
|
void |
unlock()
Release the lock.
|
broadcast, finalize, lockedBroadcastNoHandshake, lockNoHandshake, lockWithHandshake, relockNoHandshake, relockWithHandshake, timedWaitAbsoluteNoHandshake, timedWaitAbsoluteWithHandshake, timedWaitRelativeNoHandshake, timedWaitRelativeWithHandshake, unlock, unlockCompletely, waitNoHandshake, waitWithHandshake
public NoYieldpointsMonitor()
public void lockNoHandshake()
Monitor
This blocking method method does not notify the threading subsystem
that it is blocking. Thus, if someone (like, say, the GC) requests
that the thread is blocked then their request will block until this
method unblocks. If this sounds like it might be undesirable, call
Monitor.lockWithHandshake()
instead.
lockNoHandshake
in class Monitor
public void lockWithHandshake()
Monitor
This blocking method method notifies the threading subsystem that it is blocking. Thus, it may be safer than calling lock. But, its reliance on threading subsystem accounting methods may mean that it cannot be used in certain contexts (say, the threading subsystem itself).
This method will ensure that if it blocks, it does so with the mutex not held. This is useful for cases where the subsystem that requested you to block needs to acquire the lock you were trying to acquire when the blocking request came.
It is usually not necessary to call this method instead of
Monitor.lockNoHandshake()
since most VM locks are held for short
periods of time.
lockWithHandshake
in class Monitor