From: Gavin Lambert (boost_at_[hidden])
Date: 2019-08-22 03:06:05
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.)