A cautionary tale on thread safety

[lucasart]

More important is I've just learned that usleep() is officially deprecated, so that means that it's got to go.

I doubt you will ever get sub msec accuracy on any OS (unless it'd use some hybrid approach that spins).

My experience is that Linux easily gives sub millisecond precision. Forget about nano or even micro seconds, though. There's too much overhead and background noise to hope for such precision in a reliable way. Maybe 100us can be trusted, but not 10us or 1us.

[bob]

More important is I've just learned that usleep() is officially deprecated, so that means that it's got to go.

I doubt you will ever get sub msec accuracy on any OS (unless it'd use some hybrid approach that spins).

My experience is that Linux easily gives sub millisecond precision. Forget about nano or even micro seconds, though. There's too much overhead and background noise to hope for such precision in a reliable way. Maybe 100us can be trusted, but not 10us or 1us.

Forget about sub-ms accuracy. The Kernel has to unblock the task, schedule the task for execution and you have to hope you are the highest priority runnable process. It is not going to be able to do that in less than 1 ms most of the time. This (usleep()) was really intended to give a resolution of the usual system timer, which for unix generally means 10ms (millisecond) resolution. With linux you can run at a 1ms resolution, but that will NOT give you a sub-1ms accuracy, In reality it won't even get you to 1ms because of the process scheduler issues mentioned... The "jiffy" is just the lower bound on resolution (1ms). In reality it is always higher.