Boost logo

Boost :

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

> 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.


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

Boost list run by bdawes at, gregod at, cpdaniel at, john at