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.