[boost] Re: [network] An RFC - updated

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-24 20:03:50

Hi Mats,

>
>Don G wrote:
>> Yes. The "generic async library" I keep mentioning is
>> where this is handled w/o the user A) being called in
>> the wrong thread or B) the user manually doing any
>> posting.
>
> Sorry if this is covered somewhere, but would the user
> have any say in what goes down if an async_read and an
> async_write on the same socket complete more or less
> simultaneously? (In the presence of multiple worker
> threads)
>
> Sometimes the application logic calls for serializing
> the callbacks and sometimes it would be better to
> allocate each callback to a different thread,
> possibly allowing them to run in parallel.

In the approach I was describing, yes, each callback can be bound to
a different channel.

> I have recently had to deal with synchronization/
> starvation issues caused by this kind of design
> (simultaneous pending async_read and _write on
> the same socket) in an application using Windows'
> OverlappedCompletionPort mechanisms. 
>
> If the callbacks for the read and write operations
> both race to lock the same resource (e.g. the
> session object mutex), one of the completed
> operations will obviously have to wait for the
> other. This wastes one precious working thread,
> because it is just sitting there waiting while it
> could be serving other connections instead.

It sounds like you would prefer that both go to the same thread in
this case? Again, either would be supported using the design I am
proposing.

> I tried to alleviate this waste by transferring
> the "completion-token" to the first thread. Once
> the first thread was done with its first callback
> (e.g 'on_read'), it would proceed to handle the
> transferred callback (e.g 'on_written') before
> returning itself to the pool.
>
> This made the situation much better, but somehow
> tended to cluster related operations, since each
> thread would do comparatively more work on one
> socket before allowing another session's callbacks
> to be processed.
>
> It made better use of the threads, but possibly on
> the expense of fairness.

I suppose it always will depend on what happens in the callback
whether it is best to have lots of threads banging away or serialize
them or plod along with a pool of 1/CPU. All are valid, but a library
would be unable to chose which is best.

Best,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com