EDU.oswego.cs.dl.util.concurrent
Class TimeoutSync
- Sync
A TimeoutSync is an adaptor class that transforms all
calls to acquire to instead invoke attempt with a predetermined
timeout value.
Sample Usage. A TimeoutSync can be used to obtain
Timeouts for locks used in SyncCollections. For example:
Mutex lock = new Mutex();
TimeoutSync timedLock = new TimeoutSync(lock, 1000); // 1 sec timeouts
Set set = new SyncSet(new HashSet(), timedlock);
try {
set. add("hi");
}
// SyncSets translate timeouts and other lock failures
// to unsupported operation exceptions,
catch (UnsupportedOperationException ex) {
System.out.println("Lock failure");
}
[
Introduction to this package. ]
TimeoutSync(Sync sync, long timeout) - Create a TimeoutSync using the given Sync object, and
using the given timeout value for all calls to acquire.
|
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.
|
sync_
protected final Sync sync_
timeout_
protected final long timeout_
TimeoutSync
public TimeoutSync(Sync sync,
long timeout)
Create a TimeoutSync using the given Sync object, and
using the given timeout value for all calls to acquire.
acquire
public void acquire()
throws 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.
- acquire in interface Sync
attempt
public boolean attempt(long msecs)
throws 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.
- attempt in interface Sync
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.
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.
- release in interface Sync