TCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines TCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines multithreading multithreading

TCP Server w/ boost::asio, scalability of thread pool vs stackless coroutines


I have recently looked at the scalability of boost.asio on multi-core machines. The main conclusion so far is that it does introduce overhead, lock contention and additional context switches (at least on Linux), see some of my blog posts on these topics:

I also started a thread on the asio mailing list to check that I haven't missed anything obvious, see http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133

If your main concerns are performance and scalability then I am afraid, that there is no clear-cut answer - you might have to do some prototyping and look at the performance.

If you have any blocking operations then you would definitely want to use multiple threads - on the other hand, context switching and lock contention can decrease performance with multiple threads (at least you will have to be very careful).

Edit: just to clarifly the stackless coroutines stuff: it's essentially just some syntactic sugar to make the asynchronous API look a bit more like sequential/blocking calls.


You need to measure the effects to be certain what will actually happen due to the difficulty of predicting the relative effects of locality of reference, CPU instruction caching, scheduling delays, etc.

If you want a heuristic guess, consider that using n threads with stack size S each always takes nS bytes however much of the stack space each thread actually uses. If that pushes you across a page boundary, it could decrease performance measurably.