Optimal multithread model

Marc Lehmann schmorp at schmorp.de
Wed Mar 17 02:15:34 CET 2010


On Tue, Mar 16, 2010 at 04:51:49PM +0100, Christophe Meessen <christophe at meessen.net> wrote:
>> The thing we all seem to agree on is that eventloops
>> beat threads within one process, but the thing we disagree on is
>> whether it's better to have the top-level processes be processes or
>> threads.
>>   
> I'm really not so sure about the former. The ICE system developers   

Well, the event loop has much lower cpu costs overall for the same jobs.

Benchmarks can still say threads are faster, for many reasons, for example:

a) they call application code, and the application blocks in I/O.
b) the event loop used is having lots of internal overhead - you
   can make everything slow.
c) you use the wrong API, for example, select. It is extremely hard to get
   low latency with select, and still very hard to get good throughput.

Incidentally, corba actually *does* call application code, which then
might do all kinds of evil things that might work better within a thread,
as it doesn't block your process.

> This is probably also because the application can't be easily turned  
> into an event loop program because the "callbacks" may have a long  
> execution time.

Absolutely, but that's convenience, not efficiency. Convenience is very
important, of course.

> These would have to be turned into state machines using the timer to go
> from one state to the other. This is weird and doesn't seem at all more
> efficient than a plain basic thread.

Contetx switching is very expensive - and you cna always use cooperative
threads and do inversion of control. You end up with threads, but since
they are cooperative, they don't suffer form all the "bad" effects of
kernel threads (and do not take advantage of any parallle hardware...)

> Users would dislike it.

Well, many users prefer event-based approaches because they are much simpler
than dealing with threads.

They might seem complicated, but if you don't have to crae about weird race
conditions and lock contention, things might even out.

Maybe it's even a stylistic question. All I do in perl mixes (cooperative)
threads with event-based approached freely, often within 5 lines of code.

Sometimes events are easier to use, sometimes the linear structure of a
thread is greatly preferable.

I sure think both approaches should be easily available.

> My impression is that the discussion is biased by a particular use case  
> pattern in mind and a focus nearly exclusive on performance.

Well, the whole point of this thread is to focus on efficiency, which is
an important form of "performance", so your impression is certainly right.

Consider the guy who started this thread, he purely asked and talked about
performance and efficiency in his mail :)

> But as you know,  when you have a hammer, everything looks like a nail ;).

Oh yes.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list