From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-29 18:59:09
--- Peter Dimov <pdimov_at_[hidden]> wrote:
> Specific undesirable effects (such as reduced performance) can
> be bad. Synchronization, by itself, is not. It's merely a way
> (not the only way) to implement the documented thread safety
> guarantee of ::run.
Regarding other ways of implementing the demuxer without
I'm no expert (not even close) on lock-free lists and the like,
but it is my belief that the task_demuxer_service can be
implemented using some sort of lock-free list or queue plus some
atomic integer operations. The locking_dispatcher implementation
is also a candidate for this treatment.
When it comes to the epoll_reactor, I think it could be
implemented without locking by having it adopt a one-way message
passing interface. It would use a locking_dispatcher internally
to ensure that the critical regions are not called concurrently.
Alternatively the epoll_reactor might be amenable to an
implementation using lock-free lists directly, i'm not sure.
> (One example of a specific undesirable effect that springs to
> mind is the possibility of deadlock if a callback invokes
Just to clarify, the task demuxer's lock is not held when
invoking callbacks. I'm not sure what it actually means for a
program to make a nested call to demuxer.run(), but it should
The reactor lock is held when making I/O calls, but these are
non-blocking. It is also on my to-do list to investigate
separating the reactor wait from the subsequent I/O calls so
that it can scale better across multiple CPUs (i.e. the I/O
calls on different sockets can be made concurrently).