Dean Michael Berris wrote:
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.
Yes, that is likely to be the case since a single io_service will have contention on some shared data. However, your comment below concerns me a little...
Although we use thread locking primitives even on the active objects (which I thought were necessary without using strands).
One of my design goals is that library users shouldn't generally need to use any thread locking primitives at all. If you have a single thread calling io_service::run(), and always use io_service::post() to post work into the active object's thread, then no locking is required. Did you have explicit thread locking when you tried a single io_service with a pool of threads? That could certainly impact performance negatively. Cheers, Chris