Just to clarify - many high performance applications of asio only use one
thread, even for thousands of connections. That’s the point of async IO -
you maximise the throughout of a single thread.
On Thu, 10 Sep 2020 at 02:59, Jupiter via Boost
Thanks Richard and Gavin.
You right, I'll limit the one thread write inside of class, never
calling the write outside of class. the single thread wasted too much
resources where it is running an intensive MOSI and MISO UART process.
I think it is a design issue, if I can design different threads to run
different IO spaces, a simple boost::thread should do the job nicely.
Thank you very much.
jupiter
On 9/8/20, Gavin Lambert via Boost
wrote: On 7/09/2020 22:12, Richard Hodges wrote:
If your implementation is single threaded, you don't need to worry about
concurrency issues at all. All completion handlers will be scheduled to
run
sequentially.
That's almost true. The one other place you need to be careful of is
when initiating operations externally (usually writes, since reads are
typically only initiated from completion handlers, but writes can come
from both inside and outside).
The best thing to do there is to not try to directly issue writes from
"outside", but instead post() the request to start the write to the same
io_context that's managing the socket.
(The fundamental write operation itself doesn't really care which thread
you start it from, but usually you'll want to manage other state
variables in the class when initiating writes, and those can be
protected by ensuring you only touch them from the io_context thread.)
_______________________________________________
Unsubscribe & other changes:
--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212