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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk