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 21:03:44 GMT
If you set maximumPoolSize to Integer.MAX_VALUE, then you have created a TPE 
instance that won't fail to invoke a needed task, so that would be okay.  I'm 
just trying to make the point that any maximumPoolSize that is not essentially 
infinite can, at some point, create problems.

Infinite is relative to the size of the application, so there are values that 
will work, I just want to try and make the point that guessing the appropriate 
value can be problematic, so having behavior where there is essentially no 
maximum is really what we need.

At some point, a large enough machine and application could even make 
Integer.MAX_VALUE problematic... :=)

Gregg Wonderly

James Grahn wrote:
> Would this be roughly equivalent to:
> Executors.newCachedThreadPool()?
> 
> 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.
> 
> jamesG
> 
> 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
>>>
>>>
>>
>>
> 


Mime
View raw message