On 22/08/2019 13:55, JH wrote:
Yes, I am doing the experiment to increase process priority, it will help, but don't know how much. I am not quite sure if replace boost::asio::deadline_timer by high_resolution_timer will help or not, or if multithreading will help, the device is running simple process to generate data and to transmit data, there will be lots of work to change to multithreading structure in application, but I doubt the benefits running single threading vs multithreading in a single processor using i.MX6 MCU, appreciate your opinion.
Timer resolution doesn't matter if you're looking at one-second-level precision anyway. Your problem lies elsewhere. If you have a higher-priority thread which is mostly asleep but scheduled to wake up every minute, it can interrupt the lower priority processing and do that critical work quickly and on time -- as long as you write it in a way that it doesn't need to acquire a mutex or otherwise go back to sleep as soon as it wakes up. This is a good thing, but you do have to write it carefully and correctly, and use the right data structures for the task. If you have a single thread then you're at the mercy of whatever other work you're doing -- if that runs late then your timed work will also run late. (This also applies to single process vs. multi process -- if it's easier for you to put your high priority code in a separate process rather than a separate thread, then that would also work. Some people find processes easier to work with than threads.)