org.jikesrvm.scheduler
Class SpinLock

java.lang.Object
  org.jikesrvm.scheduler.SpinLock

All Implemented Interfaces:

Constants, HeapLayoutConstants, ThinLockConstants, TIBLayoutConstants, SizeConstants

public final class SpinLock
extends Object
implements Constants

Alternative (to Java monitors) light-weight synchronization mechanism to implement Java monitors Lock. These locks should not be used where Java monitors would suffice, or where an adaptive mutex is required. They are intended to be held only briefly!

Normally, contending RVMThreads will spin on this processor lock's latestContender field. If MCS_Locking is set, the processors spin on processor local data. This is loosely based on an idea in Mellor-Crummey and Scott's paper in ASPLOS-IV (1991). 1. Possible project: determine those conditions under which MCS locking performs better than spinning on a global address.

Acquiring or releasing a lock involves atomically reading and setting the lock's latestContender field. If this field is null, the lock is unowned. Otherwise, the field points to the virtual processor that owns the lock, or, if MCS locking is being used, to the last vp on a circular queue of virtual processors spinning until they get the lock, or, if MCS locking is being used and the circular spin queue is being updated, to IN_FLUX.

Contention is best handled by doing something else. To support this, tryLock obtains the lock (and returns true) if the lock is unowned (and there is no spurious microcontention). Otherwise, it returns false.

Only when "doing something else" is not an attractive option (locking global thread queues, unlocking a thick lock with threads waiting, avoiding starvation on a thread that has issued several tryLocks, etc.) should lock() be called. Here, any remaining contention is handled by spinning on a local flag.

To add itself to the circular waiting queue, a processor must succeed in setting the latestContender field to IN_FLUX. A backoff strategy is used to reduce contention for this field. This strategy has both a pseudo-random (to prevent two or more virtual processors from backing off in lock step) and an exponential component (to deal with really high contention).

Releasing a lock entails either atomically setting the latestContender field to null (if this processor is the latestContender), or releasing the first virtual processor on the circular spin queue. In the latter case, the latestContender field must be set to IN_FLUX. To give unlock() priority over lock(), the backoff strategy is not used for unlocking: if a vp fails to set set the field to IN_FLUX, it tries again immediately.

Usage: system locks should only be used when synchronized methods cannot. Do not do anything, (such as trigger a type cast, allocate an object, or call any method of a class that does not implement Uninterruptible) that might allow a thread switch or trigger a garbage collection between lock and unlock.

See Also:

RVMThread, Monitor, Lock

MCS_Locking

private static final boolean MCS_Locking

Should contending RVMThreads spin on thread local addresses (true) or on a globally shared address (false).

See Also:

Constant Field Values

latestContender

RVMThread latestContender

The state of the processor lock.

• null, if the lock is not owned;
• the processor that owns the lock, if no processors are waiting;
• the last in a circular chain of processors waiting to own the lock; or
• IN_FLUX, if the circular chain is being edited.

Only the first two states are possible unless MCS locking is implemented.

delayMultiplier

private static final int delayMultiplier

See Also:

Constant Field Values

delayBase

private static final int delayBase

See Also:

Constant Field Values

delayIndex

private static int delayIndex

delayCount

private static final int[] delayCount

IN_FLUX

private static final Address IN_FLUX

For MCS locking, indicates that another processor is changing the state of the circular waiting queue.

SpinLock

public SpinLock()

lockHeld

public boolean lockHeld()

lock

public void lock(String s)

lock

public void lock()

Acquire a processor lock.

tryLock

public boolean tryLock()

Conditionally acquire a processor lock.

Returns:

whether acquisition succeeded

unlock

public void unlock()

Release a processor lock.

handleMicrocontention

private void handleMicrocontention(int n)

An attempt to lock or unlock a processor lock has failed, presumably due to contention with another processor. Backoff a little to increase the likelihood that a subsequent retry will succeed.