Gregg,
Thanks for sharing these nuggets of wisdom.
Peter.
Shay Hassidim wrote:
Amen.
This is exactly what we have learned in GigaSpaces when had to address these Jini lock contention issues long time ago.
Shay
----- Original Message -----
From: Gregg Wonderly <[email protected]>
To: [email protected] <[email protected]>
Sent: Fri Jun 04 13:11:15 2010
Subject: Re: com.sun.jini.thread lock contention
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
