org.jikesrvm.scheduler
Class NoYieldpointsMonitor

java.lang.Object
  org.jikesrvm.scheduler.Monitor
      org.jikesrvm.scheduler.NoYieldpointsMonitor

public class NoYieldpointsMonitor
extends Monitor

A heavy condition variable and lock that also disables interrupts while the lock is held. Extremely useful for any locks that may be acquired, released, or waited upon in the process of performing a GC.

Note that calling any of the Nicely 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 Nicely 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.

NoYieldpointsMonitor

public NoYieldpointsMonitor()

lockNoHandshake

public void lockNoHandshake()

Description copied from class: Monitor

Wait until it is possible to acquire the lock and then acquire it. There is no bound on how long you might wait, if someone else is holding the lock and there is no bound on how long they will hold it. As well, even if there is a bound on how long a thread might hold a lock but there are multiple threads contending on its acquisition, there will not necessarily be a bound on how long any particular thread will wait until it gets its turn.

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

Overrides:

lockNoHandshake in class Monitor

lockWithHandshake

public void lockWithHandshake()

Description copied from class: Monitor

Wait until it is possible to acquire the lock and then acquire it. There is no bound on how long you might wait, if someone else is holding the lock and there is no bound on how long they will hold it. As well, even if there is a bound on how long a thread might hold a lock but there are multiple threads contending on its acquisition, there will not necessarily be a bound on how long any particular thread will wait until it gets its turn.

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 lock(), since most VM locks are held for short periods of time.

Overrides:

lockWithHandshake in class Monitor

unlock

public void unlock()

Description copied from class: Monitor

Release the lock. This method should (in principle) be non-blocking, and, as such, it does not notify the threading subsystem that it is blocking.

Overrides:

unlock in class Monitor