99.999% of the time if you've hardcoded a delay, you should have done anything else. The correct tool here is cross-thread synchronization. You can do this in m

99.999% of the time if you've hardcoded a delay, you should have done anything else. The correct tool here is cross-thread synchronization. You can do this in many ways, but for a simple situation like this, I'd use a mutex or a semaphore or something. In my opinion as an embedded programmer, the only time it's appropriate to hardcode a delay this way is if you're actually waiting on a physical process to happen. For instance, when I bring up a power rail in my widget, I have a delay of a few hundred milliseconds for capacitors to charge, power to stabilize, and chips to boot. Waiting five seconds for another thread to push data is not appropriate. We have entire ecosystems of tools to communicate between threads. Sleeping a thread is not one of those, and you typically only see that if the author doesn't understand the tools properly. It's a very beginner mistake.