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 Sat, 05 Jun 2010 18:55:37 GMT
I am not against the thoughts here.  TaskManager has a very important  
roll that has specific needs.  It is used to dispatch inbound calls  
amongst other things.  It is essential that it never fail to create a  
thread to handle an inbound call.  Without this behavior there is a  
chance for distributed deadlock.

The key clause in TPE is that it says the extra threads are not  
created until the queue is full.  That is another form of "maximum".

If it has a documented behavior that has no maximum, then I am okay  
with using it.  I have just never seen it behave correctly based on  
what I have experienced and so I am concerned about the maximum thread  

There are of course many types of applications that can use a ceiling  
on maximum threads to throttle things.  But if you look at some of the  
bug reports and discussions on the concurrency-interest list, there  
are cases of this behavior popping up in the fork-join pool stuff too,  
where the complexity of hoe work is divided and distributed creates  

Gregg Wonderly

Sent from my iPhone

On Jun 5, 2010, at 8:25 AM, Dennis Reedy <dennis.reedy@gmail.com> wrote:

> On Jun 5, 2010, at 609AM, Patrick Wright wrote:
>> One point I'd like to raise about using java.util.concurrent and TPE:
>> I think that over the long term, it makes sense to (re)use existing
>> utilities which are being maintained by domain experts rather than
>> custom utilities you've written yourself. The concurrent libraries
>> available since Java 5 were written and maintained by people widely
>> recognized to be very, very good at a very hard problem. That doesn't
>> mean they, or the library, is perfect, just that there is value in
>> building on their work and letting them take care of the bugs and
>> optimizations over time. The downside would be that if a River user
>> was stuck with, say, Java 5, they couldn't take advantage of bugfixes
>> or improvements in Java 6. On the other hand, that's true of the
>> entire JDK.
>> The max threads issue seems to me a non-issue. A JVM can allocate  
>> only
>> so many native threads before it runs out of OS resources; that's a
>> hard limit. You can set a max of Integer.MAX_VALUE but your VM would
>> die long, long before it reached that.
>> For me this is more of design policy decision. Re-use, intelligently
>> and selectively, where possible, to reduce your project's workload.
>> Patrick
> +1

View raw message