> almost all of the calls to thread_sleep wanted to yield to allow another thread to make progress, rather than to guarantee some time had elapsed.
That's .. deeply alarming and likely indicates the bad code. I've seen many beginner programmers use sleep/yield to busy-wait on something, and it's almost always a bad design decision: using proper synchronization primitive would be safer and more performant too.
Just to make sure that my guess was correct, I've searched CHERIoT codebase for some thread_sleep calls. There were only 15 hits, and most of them were related to implementation; only two examples were actual use in the code: busy-wait in TLS stack and polling for response in SNTP driver. Both of those are bad design - they should be using proper synchronization mechanisms.
You're not necessarily wrong, but I wouldn't call it alarming in the context of an RTOS. Sometimes you just want to invoke the scheduler and let other stuff run for a while. In an RTOS, yielding or sleeping for a number of ticks has deterministic behavior. If you sleep for a few ticks, come back, and then have to sleep again, it's not the end of the world. Blocking on a concurrency primitive would be better, since you wouldn't get scheduled at all, of course, but sometimes you just don't have what you need hooked up. I'm not surprised to see them in the net stack - there's a lot of layers involved in networking, and network latencies are usually orders of magnitude longer than a scheduler tick.
That's a context where it makes a lot of sense to use sleep. I've written similar test code myself for a different RTOS. Most of the callers are testing various form of synchronization mechanisms themselves, so using proper synchronization isn't really an option.
The non-test uses you found are more dubious though.
That's .. deeply alarming and likely indicates the bad code. I've seen many beginner programmers use sleep/yield to busy-wait on something, and it's almost always a bad design decision: using proper synchronization primitive would be safer and more performant too.
Just to make sure that my guess was correct, I've searched CHERIoT codebase for some thread_sleep calls. There were only 15 hits, and most of them were related to implementation; only two examples were actual use in the code: busy-wait in TLS stack and polling for response in SNTP driver. Both of those are bad design - they should be using proper synchronization mechanisms.