|
Boost : |
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-09-02 04:10:51
On 2/09/2019 15:54, JH wrote:
> Does that mean if any callbacks to involve IO write / read, it still
> need locks? What about just to copy shared global buffer to own local
> buffers?
>
> The two timer callbacks only copy contents from one globe buffer to
> its own local buffer, then use own local buffer to write file, I think
> that should be safe, no locks need.
>
> Another timer callback is to read / write chip registers from a serial
> line, that looks like must either lock the global buffer or copy
> global buffer to a local buffer, right?
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.
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.
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).
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk