Optimal multithread model

[Marc Lehmann]

On Wed, Mar 17, 2010 at 12:13:49PM +0100, Christophe Meessen <christophe at meessen.net> wrote:
> My project is a CORBA like application with the difference that the  
> encoding is designed for stream oriented processing. It is thus a  
> middleware and the task to be performed is in general user defined. And  
> such a user defined task could be to compute a few thousand decimals of  
> Pi which will monopolize the CPU if not preempted.

Yes, or worse, it's a library that can block your whole process for
seconds and cannot be event-ised (some database interfaces are like that).

> Is there a way to have a pure single threaded EDSM model per CPU core  
> and still be able to cope with such type of use cases ?

Well, in your example specifically, you actually *do* use your CPU, so from a
cpu efficiency standpoint, it is optimal.

More real-world is your app not doing number crunching but disk I/O or
database lookups, and if you can't control those, you kind of have little
choice than to use threads.

> could a signal triggered by a timer be used to switch coroutines and  
> emulate a preemptive multithreaded system ?

Yes (an example in perl: http://ue.tst.eu/a2499e8b0dc6c0bff8a6a33840344050.txt)

But it is nasty. And slow:

> I thought about this but it seemed like reinventing the wheel, so I gave
> up and decided to rely on kernel developers to do things right.

I would agree, before going down that road, use threads. Not the least
because signal delivery is enourmously slow and eats any advantage (*).

It would be nice if you could know in advance if a callback is doing
"nasty" things (often, you cna mark a callback as being "fast" in such
libraries - keeping the loop locked) and choose threads in that case only,
that would be about ideal.

So go for your leader/follower pattern. It's not trivial but I see no
alternative to threads if you can't know what your callbacks do.

(*) Not always true, as the Linux scheduler is kind of totally broken
for years now (**), so explicit scheduling can often beat the kernel by
a large factor, but that's not usually something that a taskset 1 cannot
fix.

(**) The loviest example I tried is running 5 burncpu programs on my
quad core. This results in three busy cores and one core completely
idling. Yeah.

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