[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Aug 13 06:12:14 EDT 2013


Yes, how to handle a failure that is not just "drop on the floor", you 
mean. A "drop on the floor" solution is to pass exceptions throughout 
the stack, which is the same as declaring "throws Exception" everywhere, 
or wrap all exceptions into RuntimeException, like some do. A 
"not-so-drop-on-the-floor" solution in evented case is not-so-simple either.

The difference is that one paradigm encourages a particular design, 
different from the design encouraged by the other.

Alex


On 13/08/2013 10:58, √iktor Ҡlang wrote:
> Something I feel most people forget is fault tolerance.
> If you are running code isolated in threads then how do you handle 
> failures in a thread? Who handles it? How do you recover from it?
>
> Cheers,
>>
>
> On Tue, Aug 13, 2013 at 11:44 AM, Oleksandr Otenko 
> <oleksandr.otenko at oracle.com <mailto:oleksandr.otenko at oracle.com>> wrote:
>
>     Well, my takeaway from the slides is that the marketing of NIO is
>     not necessarily the whole story, certainly not today.
>
>     Applying your own policy for ordering and priorities is good, but
>     this no longer is a "simple fork-join" / ExecuteService thread
>     pool. On the other hand, if you need to implement your own execute
>     service just to get going, it seems too much buck for the bang.
>
>     Latency is usually a underestimated beast. To start with,
>     diagnostic tools simply don't measure it. Then also load tests
>     usually are not suited to test latency, and they hit the system
>     with regularly spaced requests.
>
>
>     Alex
>
>
>     On 13/08/2013 09:29, Stanimir Simeonoff wrote:
>>     The main benefit of the NIO is the lower AND predictable latency
>>     per client. You may apply your own policy, order and priority.
>>     The paper mentions nothing about latency and you are at mercy of
>>     the OS scheduler to serve your clients properly.
>>     Thread.setPriority virtually doesn't work, so everything has
>>     equal priority  but the OS may boost some threads if they feel so.
>>     For some applications that might not be critical, of course...
>>     Actually, 1000 I/O bound threads on modern hardware is probably
>>     low load.
>>
>>
>>     Stanimir
>>
>>
>>     On Mon, Aug 12, 2013 at 5:06 PM, Oleksandr Otenko
>>     <oleksandr.otenko at oracle.com
>>     <mailto:oleksandr.otenko at oracle.com>> wrote:
>>
>>         http://www.slideshare.net/e456/tyma-paulmultithreaded1
>>
>>         Alex
>>
>>
>>         On 12/08/2013 14:03, Unmesh Joshi wrote:
>>>         Hi,
>>>
>>>         Most of the books on node.js, Akka, Play or any other event
>>>         IO based system frequently talk about 'Threads' being heavy
>>>         and there is cost we have to pay for all the booking the OS
>>>         or the JVM has to do with all the threads.
>>>         While I agree that there must be some cost and for doing CPU
>>>         intensive tasks like matrix multiplication, and fork-join
>>>         kind of framework will be more performant, I am not sure if
>>>         for web server kind of IO intensive application that's the case.
>>>
>>>         On the contrary, I am seeing web servers running on tomcat
>>>         with 1000 + threads without issues.  For web servers. I
>>>         think that Linux level thread management has improved a lot
>>>         in last 10 years. Same is with the JVM.
>>>
>>>         Do we have any benchmark which shows how much Linux thread
>>>         management and JVM thread management have improved over the
>>>         years?
>>>
>>>         Thanks,
>>>         Unmesh
>>>
>>>
>>>         _______________________________________________
>>>         Concurrency-interest mailing list
>>>         Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>         _______________________________________________
>>         Concurrency-interest mailing list
>>         Concurrency-interest at cs.oswego.edu
>>         <mailto:Concurrency-interest at cs.oswego.edu>
>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> -- 
> *Viktor Klang*
> /Director of Engineering/
> Typesafe <http://www.typesafe.com/>
>
> Twitter: @viktorklang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130813/87a2b37c/attachment-0001.html>


More information about the Concurrency-interest mailing list