Unless I misunderstood (which is entirely possible, not a crypto expert) that article is answering a different question: whether adding random delays can thwart timing attacks. The GP was asking about implementing a constant-time delay.
To accomplish this, you would need a high-resolution timer that runs before the operation, after the operation, and then you can subtract the two and wait. And maybe that might work.
But you're not running in kernel space.
The resolution of timing information you'd get from this tactic would be noisy, and may reintroduce the signal you were trying to hide. Especially if you're running on multiple threads or physical processors, and aren't careful enough to constrain the operations and timings to the same core.
All it will do is slow your software down and maybe not actually help.
And that's the best case scenario!
Better to just use constant-time algorithms.
start = gettime()
variable_time_crypto_operation()
end = gettime()
sleep(1sec - (end - start)) // Use a loop if necessary here
(I say virtually, because even constant time crypto isn't bulletproof - GoFetch, a recent Apple M-series CPU vulnerability inadvertently broke the "constant" part because of a quirk of the prefetcher. Side channels are hard, no need to make it harder.)
What matters is that the variance of execution time, which memory addresses are accessed, etc. is independent of any secret inputs.
https://soatok.blog/2020/08/27/soatoks-guide-to-side-channel...