Extending a concurrent construct (for example CyclicBarrier,
ThreadPoolExecutor, etc.) may impose limitations
especially when it regards to internal locking mechanisms used by the
'super' class.
My specific extended use has no additional value to this post, thus I
will refrain from elaborating on it - unless interest arises.
The concurrency difficulty here is that my extended code needs to be
atomic in respect to other code conducted
through the same API. If I choose an 'outer' locking it may lead to a
deadlock if 'inner' (super's) locking is in await states
waiting for a condition to settle.
Exposing the lock (via getter) would impose ambiguities between
different lock implementations (more specifically backport vs.
java.util.concurrent package) - not to mention misuse.
The option that I am raising is having a protected V
underLock(Callable<V> c) that will be used to delegate logic
from the
extending class to be performed under the 'inner' lock used by the
super implementation.
>From the extending class point of view, the 'inner' lock can be of any
kind, including a synchronization of an Object used by backport.
The ThreadPoolExecutor has in this regard an afterExecute(Runnable,
Throwable) and beforeExecute(Thread, Runnable) calls.
Those have been used successfully.
But, does anyone see another option under the current limitations
(besides reflection to get the inner lock...)?
Thanks.
--
Moran Avigdor
GigaSpaces Technologies Inc.
|
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@xxxxxxxxxxxxxxxxxxxx
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
| 