Class ConcurrentBarrier
java.lang.Object
org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier
A barrier used to execute code in a context where it is guarded by read/write locks. In addition, handles upgrading
read locks to write locks (and vice versa). Execution of code within a lock is in terms of a
Runnable object
(that returns no value), or a Invokable object (which does return a value).-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionbooleantryWithWrite(Runnable runnable, long timeout, TimeUnit timeoutUnit) Try to aquire the exclusive write lock and invoke the Runnable.voidAs withwithRead(Invokable), creating anInvokablewrapper around the runnable object.<T> TInvokes the object after acquiring the read lock (if necessary).voidAs withwithWrite(Invokable), creating anInvokablewrapper around the runnable object.<T> TAcquires the exclusive write lock before invoking the Invokable.
-
Constructor Details
-
ConcurrentBarrier
public ConcurrentBarrier()
-
-
Method Details
-
withRead
Invokes the object after acquiring the read lock (if necessary). If invoked when the read lock has not yet been acquired, then the lock is acquired for the duration of the call. If the lock has already been acquired, then the status of the lock is not changed. TODO: Check to see if the write lock is acquired and not acquire the read lock in that situation. Currently this code is not re-entrant. If a write lock is already acquired and the thread attempts to get the read lock, then the thread will hang. For the moment, all the uses of ConcurrentBarrier are coded in such a way that reentrant locks are not a problem.- Type Parameters:
T-- Parameters:
invokable-- Returns:
- the result of invoking the invokable
-
withRead
As withwithRead(Invokable), creating anInvokablewrapper around the runnable object. -
withWrite
Acquires the exclusive write lock before invoking the Invokable. The code will be executed exclusively, no other reader or writer threads will exist (they will be blocked waiting for the lock). If the current thread has a read lock, it is released before attempting to acquire the write lock, and re-acquired after the write lock is released. Note that in that short window, between releasing the read lock and acquiring the write lock, it is entirely possible that some other thread will sneak in and do some work, so theInvokableobject should be prepared for cases where the state has changed slightly, despite holding the read lock. This usually manifests as race conditions where either a) some parallel unrelated bit of work has occured or b) duplicate work has occured. The latter is only problematic if the operation is very expensive.- Type Parameters:
T-- Parameters:
invokable-
-
withWrite
As withwithWrite(Invokable), creating anInvokablewrapper around the runnable object. -
tryWithWrite
Try to aquire the exclusive write lock and invoke the Runnable. If the write lock is obtained within the specfied timeout, then this method behaves aswithWrite(Runnable)and will return true. If the write lock is not obtained within the timeout then the runnable is never invoked and the method will return false.- Parameters:
runnable- Runnable object to execute inside the write lock.timeout- Time to wait for write lock.timeoutUnit- Units of timeout.- Returns:
- true if lock was obtained and the runnable executed, or false otherwise.
-