From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-10-19 04:52:15
On 10/19/06, Christopher Kohlhoff <chris_at_[hidden]> wrote:
> Dean Michael Berris wrote:
> > The question would be whether there will be (or whether there
> > already is) a "generic" active object implementation? We've
> > found that Boost.Asio's io_service is a good scheduler/queue
> > and using a futures wrapper for the result types.
> An alternative to having an io_service per active object is to
> have multiple active objects share a single io_service (would
> these be called "semi-active objects"?).
This sounds alright, though the problem I see with this is that when
we profiled a single io_service solution as compared to one io_service
per active object, we saw significant improvements (on multi-core
systems) on the one io_service per active object. Of course, this is a
case-to-case basis analysis, and it shouldn't be hard to make this
work semlessly. For example, a set of active objects can use a single
io_service while another set of objects can use another one.
> If you also use a strand per active object, then the active
> objects can even share an io_service with a thread pool calling
> io_service::run(). The strand will ensure that the operations
> for a single active object don't execute concurrently.
This sounds like a good approach indeed. I haven't tried strands yet,
but this does seem to make a lot of sense. Although we use thread
locking primitives even on the active objects (which I thought were
necessary without using strands).
-- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean_at_[hidden] mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk