org.castor.core.util.concurrent
Class WriterPreferenceReadWriteLock.WriterLock
java.lang.Object
org.castor.core.util.concurrent.WriterPreferenceReadWriteLock.Signaller
org.castor.core.util.concurrent.WriterPreferenceReadWriteLock.WriterLock
- All Implemented Interfaces:
- Sync
- Enclosing class:
- WriterPreferenceReadWriteLock
protected class WriterPreferenceReadWriteLock.WriterLock
- extends WriterPreferenceReadWriteLock.Signaller
- implements Sync
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. |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
WriterPreferenceReadWriteLock.WriterLock
protected WriterPreferenceReadWriteLock.WriterLock()
acquire
public void acquire()
throws InterruptedException
- Description copied from interface:
Sync
- 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.
- Specified by:
acquire
in interface Sync
- Throws:
InterruptedException
release
public void release()
- Description copied from interface:
Sync
- 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.
- Specified by:
release
in interface Sync
attempt
public boolean attempt(long msecs)
throws InterruptedException
- Description copied from interface:
Sync
- 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.
- Specified by:
attempt
in interface Sync
- 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
- Throws:
InterruptedException
Copyright © 2012. All Rights Reserved.