Re: boost::asio::deadline_timer and boost::asio::io_service

From: JH (jupiter.hce_at_[hidden])
Date: 2019-09-02 05:54:32

On 9/2/19, Gavin Lambert via Boost <boost_at_[hidden]> wrote:
> It doesn't matter how many timers there are, it only matters how many
> I/O services/contexts you have and how many threads you're calling run()
> on for each service.

Yes, three IO read / write, but only one thread. The thing I am not
clear was your comment, "You may still need locks to protect things
that are accessed from both callbacks".

I always thought like said in document "timers may be implemented in
terms of a single timer queue. The I/O services manage these shared
resources", if the timers callbacks / handlers exclusively run one by
one in one thread, there won't be any preambles, there won't be race
conditions, why still need lock from both callbacks?

I deliberately designed to use a single thread to avoid locks, the
comments I still need locks in a single thread, make me to rethink and
probably to redesign the single thread io_service structure I have
been embraced for many years.

> If you're only doing things in the handlers of timer/read/write
> callbacks, then they're all executing on the I/O thread and so won't be
> called concurrently, so you don't need any locking.

So I was right above comment :-).

> If you have some external code which is running on another thread and
> can touch the same objects (perhaps prior to calling async_write or
> async_wait), then those either need protection or you need to
> dispatch/post their work to the I/O thread instead (so that they cannot
> run concurrently with a callback).

No, my external code are boost libraries such as timers and
io_service, if you have already said, timers won't create threads for
me, then I won't need to worry about it. You comment here they  cannot
run concurrently with a callback is exactly I have tried design for
many years, unless I misunderstood you again :-)

> Bear in mind that if you're writing to that file synchronously, then it
> will also prevent the other callbacks from executing for however long
> that takes.  Depending on what you're doing, that may or may not be a
> good thing.

Understood, it is an embedded MCU with a single processor, satiety and
reliability are the priority in the initial design for using single
thread, when I confident that all software functions are running well
and mature, I might think to use multithreading.

Thank you Gavin.

Kind regards,

- jupiter