river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: com.sun.jini.thread lock contention
Date Fri, 04 Jun 2010 20:11:15 GMT
I'd have to say no for the existing Executor implementations in the JDK.  The 
concurrency utilities related to Executor in the JDK are tailored for, and 
specifically limited to applications where you have unrelated tasks that need to 
be throttled amongst a limited set of threads.

River's TaskManager will always create more threads, but will prune those 
threads after they sit idle for too long.  We need this behavior to keep away 
from distributed deadlock which can occur anytime another remote operation might 
be the only way that progress can happen in the overall processing of a 
distributed application.

Be very careful where you use j.u.c ThreadPoolExecutor et.al, because of their 
design.  It would be possible to use an appropriate Executor implementation, but 
it would have to behave like TaskManager and always create a new thread for new 
work, when no idle threads are available.

Gregg Wonderly

Dennis Reedy wrote:
> Hi Gregg,
> Does it make sense to move to concurrency utilities and move away from TaskManager altogether?
> Dennis
> On Jun 4, 2010, at 1100AM, Gregg Wonderly wrote:
>> The TaskManager class has a subclass of Thread that it uses to run tasks.  The problem
with subclassing Thread, is that there is a lock that is used in Thread to see if some methods
are overridden so that security can be maintained.  So, in an environment where Thread is
used with a SecurityManager, it is better to use a Runnable to encapsulate the custom code,
instead of a Thread.
>> The TaskThread class should be a Runnable instead of a Thread, and then there are
just 3 other places where it is referenced that need some adjustment.  The thread that is
running inside of the runnable needs to be put into a per instance variable for one place
where interrupt processing is handled.
>> Gregg Wonderly

View raw message