EDU.oswego.cs.dl.util.concurrent
Class ObservableSync
- Sync
public class ObservableSync
The ObservableSync class performs no synchronization
itself, but invokes event-style messages to other
observer objects upon invocation of Sync methods.
These observers typically perform monitoring, logging,
or other bookkeeping operations surrounding the object
being managed by this Sync object.
Because ObservableSync does not itself perform any synchronization
control, the attempt operation always succeeds.
This class is typically used (via LayeredSync) as a wrapper
around those that do perform synchronization control.
This class is based around a standard Observer design pattern.
It is not hard to convert this to instead use a Listener
design (as seen in AWT and JavaBeans), by defining associated
EventObjects and forwarding them.
[
Introduction to this package. ]
ObservableSync(Object notificationArgument) - Create an ObservableSync that uses the supplied argument
for all notifications.
|
arg_
protected Object arg_
ObservableSync
public ObservableSync(Object notificationArgument)
Create an ObservableSync that uses the supplied argument
for all notifications. The argument is typically an
object that is being managed by this Sync object.
acquire
public void acquire()
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)
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.
getNotificationArgument
public Object getNotificationArgument()
Return the argument used for notifications
observers
public Iterator observers()
Return an iterator that can be used to traverse through
current set of observers
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
setNotificationArgument
public Object setNotificationArgument(Object notificationArg)
Set the argument used for notifications.
- the previous value of this argument