Re: Optimal multithread model

[Christophe Meessen]

Le 15/03/2010 13:09, Marc Lehmann a écrit :

On Mon, Mar 15, 2010 at 11:48:54AM +0100, Christophe 
Meessen<christo...@meessen.net>  wrote:

It looks like libev is designed to have one thread calling the ev_loop
and executing the callbacks (assumed to be fast and never blocking).

This is a straightforward design but it is not performance optimal when
requests take a very short time to execute and the system is very loaded

It's probably the most efficient model, actually?

Thank you for answering. Or mails have crossed each other.

My statement was confusing. You are right of course, for short requests the event model is more efficient. I was considering requests which may vary a lot in execution time. The latency of passing the request to another thread will become perceptible with short to execute requests and the server has many threads competing for the CPU(s). This latency can be avoided by the suggested usage model.

(many threads/process). This due to passing the request to another

Keep in mind thatthe primary use for threads is improve context switching
times in single processor situations - event loops are usually far faster at
context switches.

Now that multi cores become increasingly more common and scalability to
multiple cpus and even hosts is becoming more important, threads should be
avoided as they are not efficiently using those configs (again, they are a
single-cpu thing).

While there are exceptions (as always), in the majority of cases you will
not be able to beat event loops, especially whne using multiple processes,
as they use the given resources most efficiently.

I fully agree. The idea was not to use threads in order to be faster than event loop. I use threads/process to execute the requests which are not event driven. Some requests take a very short time to execute and some may take a very long time. Obviously it is not the callbacks that should execute these requests. So my aim is to optimize this use case where request processing has to be performed by threads since I have no idea how much time the execution of a task will take. The optimization simply avoids the latency induced by systematically passing requests to another thread for processing.

thread for processing. If the system is well loaded, it may take a
significant time until the worker thread is given the CPU by the
scheduler to process the request.

Yes, threads were not meant for these kinds of workloads, and their
overheads are enourmous even on systems that are very fast (such as
GNU/Linux).

itself. But some requests may take a long time to execute. So trick is
to make the worker threads waiting to be able to monitor. When the
monitoring thread detects an event, it signals the worker thread pool,

That sounds very very slow.

Why ? The code skeleton provided in the next mail may have made the idea more explicit.

When you can't use a more efficient process model
and for some reason *have* to use threads, a lader/follower pattern, or
multiple event loops, are usually more preferable. YMMV.

The pattern I describe is the leader/follower pattern. I just learned it was called like that :) So the question is how to efficiently implement the leader/follower patter with libev.

--
Ch. Meessen

Is the suggested use of ev_loop( ONE_SHOT ) ok to implement this pattern or is there a better way ?

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev