org.metasyntactic.thread.concurrent
Interface Monitor

All Known Implementing Classes:
CountDown, Latch, Mutex, ReentrantLock, Semaphore

public interface Monitor

Main interface for locks, gates, and conditions.

Mointor objects isolate waiting and notification for particular logical states, resource availability, events, and the like that are shared across multiple threads. Use of Syncs sometimes (but by no means always) adds flexibility and efficiency compared to the use of plain java monitor methods and locking, and are sometimes (but by no means always) simpler to program with.

Most Monitors are intended to be used primarily (although not exclusively) in before/after constructions such as:

 public class X {
	Monitor gate;
	// ...

	public void m() {
	 try {
		gate.acquire(); // block until condition holds
		try {
		 // ... method body
		} finally {
		 gate.release()
		}
	 } catch (InterruptedException ex) {
		// ... evasive action
	 }
	}

	public void m2(Monitor cond) { // use supplied condition
	 try {
		if (cond.attempt(10)) {		 // try the condition for 10 ms
		 try {
			// ... method body
		 } finally {
			cond.release()
		 }
		}
	 }
	 catch (InterruptedException ex) {
		// ... evasive action
	 }
	}
 }
 
Monitor may be used in somewhat tedious but more flexible replacements for built-in Java synchronized blocks. For example:
 class HandSynched {
	private double state_ = 0.0;
	private final Monitor lock; // use lock type supplied in constructor
	public HandSynched(Monitor l) { lock = l; }

	public void changeState(double d) {
	 try {
		lock.acquire();
		try	 { state_ = updateFunction(d); }
		finally { lock.release(); }
	 }
	 catch(InterruptedException ex) { }
	}

	public double getState() {
	 double d = 0.0;
	 try {
		lock.acquire();
		try	 {
		 d = accessFunction(state_);
		} finally {
		 lock.release();
		}
	 } catch(InterruptedException ex){}

	 return d;
	}
	private double updateFunction(double d) { ... }
	private double accessFunction(double d) { ... }
 }
 
If you have a lot of such methods, and they take a common form, you can standardize this using wrappers. Some of these wrappers are standardized in LockedExecutor, but you can make others. For example:
 class HandSynchedV2 {
	private double state_ = 0.0;
	private final Monitor lock; // use lock type supplied in constructor
	public HandSynchedV2(Monitor l) { lock = l; }

	protected void runSafely(Runnable r) {
	 try {
		lock.acquire();
		try { r.run(); }
		finally { lock.release(); }
	 }
	 catch (InterruptedException ex) { // propagate without throwing
		Thread.currentThread().interrupt();
	 }
	}

	public void changeState(double d) {
	 runSafely(new Runnable() {
		public void run() { state_ = updateFunction(d); }
	 });
	}
	// ...
 }
 

One reason to bother with such constructions is to use deadlock- avoiding back-offs when dealing with locks involving multiple objects. For example, here is a Cell class that uses attempt to back-off and retry if two Cells are trying to swap values with each other at the same time.

 class Cell {
	long value;
	Monitor lock = ... // some sync implementation class
	void swapValue(Cell other) {
	while (true)
		try {
		 lock.acquire();
		 try {
			if (other.lock.attempt(100)) {
			 try {
				long t = value;
				value = other.value;
				other.value = t;
				return;
			 } finally { other.lock.release(); }
			}
		 } finally { lock.release(); }
		} catch (InterruptedException ex) { return; }
	 }
	}
 }
 

Here is an even fancier version, that uses lock re-ordering upon conflict:

 class Cell {
	long value;
	Mointor lock = ...;
	private static boolean trySwap(Cell a, Cell b) {
	 a.lock.acquire();
	 try {
		if (!b.lock.attempt(0)) {
		 return false;
		}
		try {
		 long t = a.value;
		 a.value = b.value;
		 b.value = t;
		 return true;
		} finally { other.lock.release();
		}
	 } finally { lock.release();
	 }
	 return false;
	}

  void swapValue(Cell other) {
	 try {
	  while (!trySwap(this, other) &&
			 !tryswap(other, this))
		 Thread.sleep(1);
	 }
	 catch (InterruptedException ex) { return; }
  }

 

Interruptions are in general handled as early as possible. Normally, InterruptionExceptions are thrown in acquire and attempt(msec) if interruption is detected upon entry to the method, as well as in any later context surrounding waits. However, interruption status is ignored in release();

Timed versions of attempt report failure via return value. If so desired, you can transform such constructions to use exception throws via

	if (!c.attempt(timeval)) throw new TimeoutException(timeval);
 

The TimoutSync wrapper class can be used to automate such usages.

All time values are expressed in milliseconds as longs, which have a maximum value of Long.MAX_VALUE, or almost 300,000 centuries. It is not known whether JVMs actually deal correctly with such extreme values. For convenience, some useful time values are defined as static constants.

Monitors may also be used in spinlock constructions. Although it is normally best to just use acquire(), various forms of busy waits can be implemented. For a simple example (but one that would probably never be preferable to using acquire()):

 class X {
	Monitosr lock = ...
	void spinUntilAcquired() throws InterruptedException {
	 // Two phase.
	 // First spin without pausing.
	 int purespins = 10;
	 for (int i = 0; i < purespins; ++i) {
		if (lock.attempt(0)) {
		 return true;
		}
	 }
	 // Second phase - use timed waits
	 long waitTime = 1; // 1 millisecond

	 while (true)
		if (lock.attempt(waitTime)) {
		 return true;
		} else {
		 waitTime = waitTime * 3 / 2 + 1; // increase 50%
		}
	 }
	}
 }
 

In addition pure synchronization control, Monitors may be useful in any context requiring before/after methods. For example, you can use an ObservableMonitor (perhaps as part of a LayeredMonitor) in order to obtain callbacks before and after each method invocation for a given class.


Field Summary
static long ONE_CENTURY
          One century in milliseconds; convenient as a time-out value *
static long ONE_DAY
          One day, in milliseconds; convenient as a time-out value *
static long ONE_HOUR
          One hour, in milliseconds; convenient as a time-out value *
static long ONE_MINUTE
          One minute, in milliseconds; convenient as a time-out value *
static long ONE_SECOND
          One second, in milliseconds; convenient as a time-out value *
static long ONE_WEEK
          One week, in milliseconds; convenient as a time-out value
static long ONE_YEAR
          One year in milliseconds; convenient as a time-out value
 
Method Summary
 void acquire()
          Wait (possibly forever) until successful passage.
 boolean attempt(long msecs)
          Wait at most msecs to pass; report whether passed.
 void release()
          Potentially enable others to pass.
 

Field Detail

ONE_SECOND

public static final long ONE_SECOND
One second, in milliseconds; convenient as a time-out value *

See Also:
Constant Field Values

ONE_MINUTE

public static final long ONE_MINUTE
One minute, in milliseconds; convenient as a time-out value *

See Also:
Constant Field Values

ONE_HOUR

public static final long ONE_HOUR
One hour, in milliseconds; convenient as a time-out value *

See Also:
Constant Field Values

ONE_DAY

public static final long ONE_DAY
One day, in milliseconds; convenient as a time-out value *

See Also:
Constant Field Values

ONE_WEEK

public static final long ONE_WEEK
One week, in milliseconds; convenient as a time-out value

See Also:
Constant Field Values

ONE_YEAR

public static final long ONE_YEAR
One year in milliseconds; convenient as a time-out value

See Also:
Constant Field Values

ONE_CENTURY

public static final long ONE_CENTURY
One century in milliseconds; convenient as a time-out value *

See Also:
Constant Field Values
Method Detail

acquire

public void acquire()
             throws java.lang.InterruptedException
Wait (possibly forever) until successful passage. Fail only upon interuption. Interruptions always result in `clean' failures. On failure, you can be sure that it has not been acquired, and that no corresponding release should be performed. Conversely, a normal return guarantees that the acquire was successful.

java.lang.InterruptedException

attempt

public boolean attempt(long msecs)
                throws java.lang.InterruptedException
Wait at most msecs to pass; report whether passed.

The method has best-effort semantics: The msecs bound cannot be guaranteed to be a precise upper bound on wait time in Java. Implementations generally can only attempt to return as soon as possible after the specified bound. Also, timers in Java do not stop during garbage collection, so timeouts can occur just because a GC intervened. So, msecs arguments should be used in a coarse-grained manner. Further, implementations cannot always guarantee that this method will return at all without blocking indefinitely when used in unintended ways. For example, deadlocks may be encountered when called in an unintended context.

Parameters:
msecs - the number of milleseconds to wait. An argument less than or equal to zero means not to wait at all. However, this may still require access to a synchronization lock, which can impose unbounded delay if there is a lot of contention among threads.
Returns:
true if acquired
java.lang.InterruptedException

release

public void release()
Potentially enable others to pass.

Because release does not raise exceptions, it can be used in `finally' clauses without requiring extra embedded try/catch blocks. But keep in mind that as with any java method, implementations may still throw unchecked exceptions such as Error or NullPointerException when faced with uncontinuable errors. However, these should normally only be caught by higher-level error handlers.