Re: [boost] asio formal review begins
What I did was to have the main thread accept incomming requests, and put them in the queue, whereas a number of worker threads was taking these requests from the queue, and execute them. I don't see how this model can be absolutely inferior in all possible contexts.
I think your argument regarding the sync interface *might* be valid for other reasons, but I want to point out that this architecture only scales if you have an async front end that reads and writes from the socket and parses the connection into tasks in the main thread, and then handles these tasks synchronously in a thread pool. Say for instance a web server which handles HTTP request pipelines asynchronously and database connections synchronously. If the system contains long lived connections, then you are basically only servicing the number of connections in your thread pool, and there is a good chance the other connections will timeout. I do agree with Peter. If asio leads developers away from thread/connection architectures, then it has succeeded. As with a lot of technologies that are shiny and new, I think the industry has put too much emphasis on threads as the solution to all concurrency problems. I think we understand the problems better now. Christopher
"christopher baus" <christopher@baus.net> wrote
As with a lot of technologies that are shiny and new, I think the industry has put too much emphasis on threads as the solution to all concurrency problems. I think we understand the problems better now.
What you can't take away from threads, though, is that they do help to manage complexity by decoupling the networking issues from the processing algorithm, whereas with asynchronicity you have to specifically re-write you algoritms to work in asynchronous way. AFAIK, it is generally agreed that threads are easier to write/understand/debug than asynchronous calls. Than what is your definition of superiority? If this is only about performance issues, we are not on the same page. Regards, Arkadiy
algoritms to work in asynchronous way. AFAIK, it is generally agreed that threads are easier to write/understand/debug than asynchronous calls.
I respectfully disagree with that statement. My experience has been that the complexity of correctly and effeciently synchronizing multiple threads is far more difficult to debug and understand than an async model where all I/O happens in one thread, but that is a subjective statement. If you take my previous example where an async server passes tasks off to worker threads and those threads require synchronous I/O (again real world example is an async web server with database connections), then you might have a valid argument. If I was to write an asio application today that had to access MySQL, that's what I would do.
Arkadiy Vertleyb wrote:
"christopher baus" <christopher@baus.net> wrote
As with a lot of technologies that are shiny and new, I think the industry has put too much emphasis on threads as the solution to all concurrency problems. I think we understand the problems better now.
What you can't take away from threads, though, is that they do help to manage complexity by decoupling the networking issues from the processing algorithm, whereas with asynchronicity you have to specifically re-write you algoritms to work in asynchronous way. AFAIK, it is generally agreed that threads are easier to write/understand/debug than asynchronous calls.
Is it? In my experience the key to managing complexity in asynchronous designs is simply to build a few small state machines hooked up to each other (through e.g. boost::function callbacks) instead of trying to manage all the state in one big state machine. Furthermore state machines are very often easily composable in constrast to threaded designs which seldom compose well. Actually, I've found that code complexity can be a very good indicator of when to split some single state machine (which an async server basically is) into smaller state machines. The fact that there are basically no locking issues in an async server can also be a tremendous help. I realize that most experienced developers would probably tend to simply refrain from using anything except thread safe queues for communication between threads, thus avoiding some of the nasty safety/composability issues. Novices, however... I've found it much easier to explain the concept of state machines to novices (and have them understand!) than explaining all the issues with thread-based programming, e.g. priority inversion. I'm assuming that "debug" was a typo, btw. Threads are absolute HELL to debug unless you've got very good debugger support, ie. NOT gdb or anything derived/based on it. Cheers, -- Bardur Arantsson <bardurREMOVE@THISimada.sdu.dk> <bardurREMOVE@THISscientician.net> Hit any user to continue.
algoritms to work in asynchronous way. AFAIK, it is generally agreed that threads are easier to write/understand/debug than asynchronous calls.
Just to jump in quickly, I've done a fair share of network and multi-threaded programming (including a multi-threaded web server) and I have to completely disagree that threads are in any way easier to debug, ever. cheers Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: 15/12/2005
participants (8)
-
Arkadiy Vertleyb -
Bardur Arantsson -
christopher baus -
Martin Slater