On 9/2/19, Gavin Lambert via Boost
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