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

From: Mats Nilsson (mats.nilsson_at_[hidden])
Date: 2005-04-24 17:57:17

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.

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.

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.

Mats