On Tue, Dec 20, 2011 at 03:26:22PM +0100, Hongli Lai <hon...@phusion.nl> wrote:
> event loop per thread. I'm thinking about multiple eio contexts with
> each context having its own thread pool.
This is strictly less useful though, as you lose control over scheduling,
which might not be an issue for you though.
> The reasons why I have multiple threads are:
> 1. I want to make full use of all CPU cores.
Threads were meant as an optimisation for single cpu systems though, and
processes are meant for multiple cpus (or cores), and use the available
hardware more efficiently.
> 2. All threads are mostly independent, but share one data structure.
> It's faster to query and to manipulate this data structure with locks
> and shared memory than to use message passing and multiple processes.
Even if true (I am a bit doubtful) thats a difference between message
passing and shared memory, not between processes and threads, Processes
would still be more efficient overall.
> 3. I want to minimize context switching overhead. Context switching
> between processes involves flushing the TLB while context switching
> between threads does not (at least on Linux).
Whether context switching flushes the TLB depends on the architecture,
not so much on Linux (which presumably suppreses it if unnecessary). Note
that threads incur extra overheads on multiple cpu cores as well, where
processes are more efficient.
> Manipulating a shared data structure through message passing *always*
> involves a context switch, even in the uncontended case, while mutexes
> do not impose such overhead in the uncontended case.
Thats not true either, where did you pick this up?
While there are drawbacks to every method, you argue that the proposed
style has drawbacks, so it's worse. But at no time do you consider the
overheads you would impose by changing the method. That doesn't make much
sense.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
