Re: epicsThreadSleep and epicsThreadSleepQuantum

["Johnson, Andrew N. via Core-talk" <core-talk@aps.anl.gov>]

On 6/12/19 11:50 AM, Michael Davidsaver via Core-talk wrote:

I'll second this.  Minimum sleep time is not a meaningful concept for a modern general purpose OS.

Then epicsThreadSleepQuantum() should return 0 in that case — the AppDevGuide says:

If this parameter is unknown or is unpredictable for a particular OS then it is safe to return zero.

All the usages of sleep(0) I've seen have been shortcuts to avoid using real synchronization primitives.
This is something I would discourage.

Calling epicsThreadSleep(0) does yield the CPU on both VxWorks and RTEMS, and since those both have a preemptive priority-based scheduler there are valid use-cases for doing that in OS-independent code. The VxWorks Programmers Guide says:

As a side effect, taskDelay( ) moves the calling task to the end of the ready queue for tasks of the same priority. In particular, you can yield the CPU to any other tasks of the same priority by "delaying" for zero clock ticks.

RTEMS documentation says:

A task calling the rtems_task_wake_after directive with a delay interval of zero ticks will yield the processor to any other ready task of equal or greater priority and remain ready to execute.

I agree that we should discourage general-purpose code from using this instead of the proper synchronization APIs, but our documentation for epicsThreadSleep() does state:

Sleep for the specified period of time, i.e. sleep without using the cpu. If delay is >0 then the thread will sleep at least until the next clock tick. The exact time is determined by the underlying architecture. If delay is <= 0 then a delay of 0 is requested of the underlying architecture. What happens is architecture dependent but often it allows other threads of the same priority to run.

There is also also a difference in behaviour between calling epicsThreadSleep(0) and epicsThreadSleep(epicsThreadSleepQuantum()) on a priority-scheduled OS — the former only permits equal (or higher) priority threads to run, whereas the latter allows any thread to be run for that quantum period. When a task is doing long-running work that doesn't sleep but isn't particularly time-critical the latter call is designed to let lower-priority threads also make some progress.

I don't want to remove that capability from our APIs, even though it's only needed on some OSs, so I'm not keen on Martin's suggestion to deprecate or remove the quantum routines.

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.