I know there are bunch of defects of thread programing and not every one like to use it

but I am still wondering the real efficiency of these two model

if we use multi-core cpu, which one is faster, or it just depends on the compiler's optimization~

It's a different programming model. I don't think there is an inherent difference in efficiency between the two models, except maybe the overhead of spawning a new thread. Even that can be remedied by using a thread pool.

Michael.

Threads can lead to significant performance gain even on a single core, if used properly. Used incorrectly however they will lead to a slower execution if nothing else due to time lost in switching, cache flushing and thread synchronization. In multicore the performance gain can be huge, but the danger of lost performance due to bad thread synchronization still exists. Almost every single application I have written in the last 12 years has been multithreaded at least partially. Multithreading can offer a lot if used properly.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

D?a ?t, 2008-08-28 o 14:41 +0800, davy zhang nap?sal:

Yes, lNet by default wouldn't use multiple cores but in most cases this is ok (you don't want to use all cores on just networking events watch). If you want to make a "really efficient" high-end server tho, try out the trunk version. I added a TLThreadedEventer which enables you to specify # of threads which will be used to watch sockets. The eventer will then fill up those threads with "subeventer" as the sockets come in. You need to know what you're doing tho, as each callback then gets executed in its thread!

So in the end, say you specified 200 threads and got 2000 sockets, you end up with 10 sockets per thread being watched (more or less in a blocking manner) for events.

This eventer however is really only useful for corner cases like slashdot effect surviving web servers (note that YOU need to use threads to handle requests too to make use of cores. Say you forward the request to PHP via fastcgi, you should do it in ADDITIONAL thread so that the event-watch threads are independent of the processing).

So.. it's always a choice, having 1 thread per socket would constitute a huge bottleneck because of scheduling with 10k+ sockets, and having too many sockets per thread you end up serializing the events to it doesn't keep up. Best is to find the right balance.

Ales