river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <jgr...@simulexinc.com>
Subject Re: com.sun.jini.thread lock contention
Date Fri, 04 Jun 2010 20:29:28 GMT
Would this be roughly equivalent to:

The doc says:
"Creates a thread pool that creates new threads as needed, but will 
reuse previously constructed threads when they are available."

That factory creates a ThreadPoolExecutor with a core size of 0, maximum 
size of Integer.MAX_VALUE, and it kills idle threads after 60 seconds.

We can construct our own ThreadPoolExecutor if we need finer control of 
those parameters.

I may be missing some subtle detail, though.


On 6/4/2010 4:11 PM, Gregg Wonderly wrote:
> 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