ev_async_send() not trigerring corresponding async handler in target loop ?

Marc Lehmann schmorp at schmorp.de
Thu Dec 31 05:40:45 CET 2009


On Wed, Dec 30, 2009 at 03:26:03PM -0600, Brandon Black <blblack at gmail.com> wrote:
> What he's referring to is that in the general case, a multi-process
> program will scale better over increasingly large core counts than a
> multi-threaded program, because the shared address space of the
> threads tends to lead to memory/cache performance issues even on
> non-NUMA machines, and obviously on NUMA machines the problems get
> even worse when the threads that share active chunks of memory might
> want to be scheduled on several different NUMA nodes.

Thanks for explaining this in more detail, I always think people should
know the trade-offs of threads and their purpose, but some marketing
forces must have contorted the "threads" concept into something completely
different over the past decades.

That's not the only issue - the only purpose threads wree invented for was
keeping values in many cpu registers constant (e.g. mmu table pointers)
across "processes".

what is a feature on a single core is a burden on multiple cores as now
memory allocations, mapping changes etc. will have to be communicated between
all cpu cores.

in addition, you do need more locking for almost everything, such as
memory allocation (which can be mitigated by pools, but not avoided
completely).

> However, a *carefully designed* multi-threaded program can avoid these
> sorts of memory issues in many cases, but then that gets back into
> another component of why "multithreading is (imho) extremely
> complicated".

True, but not in all. I cannot imagine that a shared-everything approach
can be faster than a shared-selectively approach in general. Maybe if you
mainly share file descriptors, but cetrainly not for address space.

That's for theory. In practise, operating systems gained support for
threads, which makes things slow, but *easy*.

libeio for example uses threads because there is no good and portable
communication path between processes. of course, libeio actually suffers
a lot from the "threads on multicores" issue - libeio for example gains
considerable speed when you force the process to a single core on linux,
because all of eventfd, cache and the scheduler work against it in that
case.

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



More information about the libev mailing list