Synchronous and asynchronous programming

When designing a server, we consider two approaches:

  • An asynchronous (select based) approach, so the backend rpc can be parallelized on a single thread.

  • A synchronous approach where each backend rpc is processed on a different thread from the thread pool.

There are trade-offs: 1 has better performance and 2 less. Does it really matter now that a machine is running multi-core and 64 bits?

0


a source to share


4 answers


I would recommend reading these books at ACE



to get an idea of ​​the templates to create an efficient server.

+2


a source


I think it should be the other way around, the async select () method makes the code simpler because there is no thread synchronization.

All you have to do is pass the list of socket descriptors to the select () function. It will block and return only when something happens on one or more socket descriptors. How versus using a thread pool where you have to have a job dispatch queue where all threads in the thread pool take over jobs.



The downside of the async select () approach is that it won't scale with the number of cpu cores because everything was done in a single thread.

0


a source


Without knowing the details of your server requirements, it's hard to tell which of these approaches can give you better performance and / or reduce code complexity.

The funny thing is that performance and simplicity are usually combined in a real server design (but it's hard to come up with a simplified design). select / poll by itself does not give you the best performance. And the thread pool definitely doesn't reduce the complexity of the code.

To answer your question: 1 is still a question. Asynchronous design doesn't scale enough for a multiprocessor machine, but this is only true if your server is running in a single process. What if your server is designed to spawn multiple processes on a multiprocessor machine? Different processes can run under different user accounts and have different security settings. How about virtual machines? One thread per process doesn't mean you can't use multi-core machines.

However, I really can't remember the last time I saw a real server side design based on async select (). Perhaps in text books when I was in college, but not in a real production system.

0


a source


This is the actual reading (sort of a minority report):

http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf

It's also a good resource:

http://www.kegel.com/c10k.html

Remember, you can combine the two approaches to maximize the usefulness of multi-core architectures. Assuming your server ("Krumpets here!";) Is partionable - this means you can run multiple instances on the same machine - write the server with select and then start one server instance for the processor core.

0


a source







All Articles