Do I need to use boost::mutex in deadline_timer?
Hi, I used boost::asio::io_service for a single thread implementation but with multiple boost::asio::deadline_timer objects, because it is a single thread, I don't think I need to use boost::mutex to lock and unlock tasks running by deadline_timer, am I wrong about it? Thank you. Kind regards, jupiter
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. In other words, no need for a mutex. If you later decide to make your program multi-threaded (i.e. multiple threads per io_context) then the idiomatic method to control concurrency is to use an asio::strand<asio::any_io_executor> as your executor type for each io_enabled concern (such as a connection). In asio, (and net.ts) the strand is a special executor adapter that guarantees that although multiple completion handlers can execute concurrently through the *underlying executor*, they can only complete *sequentially* through the strand which is *adapting* that underlying executor. On Mon, 7 Sep 2020 at 11:54, Jupiter via Boost <boost@lists.boost.org> wrote:
Hi,
I used boost::asio::io_service for a single thread implementation but with multiple boost::asio::deadline_timer objects, because it is a single thread, I don't think I need to use boost::mutex to lock and unlock tasks running by deadline_timer, am I wrong about it?
Thank you.
Kind regards,
jupiter
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
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.)
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 <boost@lists.boost.org> 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: http://lists.boost.org/mailman/listinfo.cgi/boost
-- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs
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 <boost@lists.boost.org> wrote:
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 <boost@lists.boost.org> 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
participants (3)
-
Gavin Lambert -
Jupiter -
Richard Hodges