Hello,
One strategy to load-balance I/O processing across multiple
threads is to use a single io_context object for multiplexing and
to call io_context::run from all threads in the thread pool. This
can be set up by, for example, defining a type which holds a
vector of threads, all of which are calling io_context::run. My
first question is: is this approach of calling io_context::run
from several threads somewhat equivalent to using
boost::asio::thread_pool as the default execution context and
not (explicitly, at least) creating a boost::asio::io_context
object at all?
It's not equivalent because in the case of one thread per io_context, the completion handler of asynchronous operations will always be invoked on a known thread. Therefore concurrency protection is not a concern.
If you use the executor of a thread_pool, there is no guarantee which thread will invoke the completion handler, and no guarantee that two completion handlers will not touch the same user object. This argues for the use of asio::strand<asio::thread_pool::executor_type> as the executor to be associated with the completion handler (or set as the default executor of related io objects).
Somewhat more specifically, is it safe to define TCP
sockets/acceptors/etc. with execution contexts set to a
boost::asio::thread_pool instead of io_context, and will that
work as expected (i.e., as a single io_context object scheduling
tasks out to several threads calling io_context::run would)?
It will work. You will need to add concurrency protection, and it will be less efficient. From your line of questioning I don't think it will work as you are expecting or hoping.
Is there a use case or is this a question out of curiosity?
-Ani
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users