Do I need to use boost::mutex in deadline_timer?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Do I need to use boost::mutex in deadline_timer?

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Do I need to use boost::mutex in deadline_timer?

Boost - Dev mailing list
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 <[hidden email]>
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
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Do I need to use boost::mutex in deadline_timer?

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Do I need to use boost::mutex in deadline_timer?

Boost - Dev mailing list
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 <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Do I need to use boost::mutex in deadline_timer?

Boost - Dev mailing list
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 <[hidden email]>
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 <[hidden email]> 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
>
>
>
> _______________________________________________
>
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> --
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost