|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.logicalcobwebs.concurrent.WriterPreferenceReadWriteLock.Signaller org.logicalcobwebs.concurrent.WriterPreferenceReadWriteLock.ReaderLock
protected class WriterPreferenceReadWriteLock.ReaderLock
Field Summary |
---|
Fields inherited from interface org.logicalcobwebs.concurrent.Sync |
---|
ONE_CENTURY, ONE_DAY, ONE_HOUR, ONE_MINUTE, ONE_SECOND, ONE_WEEK, ONE_YEAR |
Constructor Summary | |
---|---|
protected |
WriterPreferenceReadWriteLock.ReaderLock()
|
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. |
(package private) void |
signalWaiters()
|
Methods inherited from class java.lang.Object |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Constructor Detail |
---|
protected WriterPreferenceReadWriteLock.ReaderLock()
Method Detail |
---|
public void acquire() throws java.lang.InterruptedException
Sync
acquire
in interface Sync
java.lang.InterruptedException
public void release()
Sync
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
void signalWaiters()
signalWaiters
in class WriterPreferenceReadWriteLock.Signaller
public boolean attempt(long msecs) throws java.lang.InterruptedException
Sync
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.
java.lang.InterruptedException
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |