Re: [boost] asio formal review begins

From: Bardur Arantsson (spam_at_[hidden])
Date: 2005-12-15 14:58:15

Arkadiy Vertleyb wrote:
> "christopher baus" <christopher_at_[hidden]> 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_at_[hidden]>
<bardurREMOVE_at_[hidden]>
Hit any user to continue.