Optimal multithread model

Christophe Meessen christophe at meessen.net
Mon Mar 15 14:58:14 CET 2010


Le 15/03/2010 13:09, Marc Lehmann a écrit :
> On Mon, Mar 15, 2010 at 11:48:54AM +0100, Christophe Meessen<christophe at 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.

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



--
Ch. Meessen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3277 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20100315/c9889a09/attachment.bin>


More information about the libev mailing list