Jeff Hill wrote:
Pursuing this a bit further, I notice, using epicsThreadShowAll, that the
OSI => OSD priority mapping maybe isn't working on POSIX (the OSSPRI column
is always zero)?
Again, this is building with USE_POSIX_THREAD_PRIORITY_SCHEDULING = YES.
Two "features" of priority scheduling on linux.
1) On linux you must be running as root in order to be able to set SCHED_FIFO.
The code is written to silently revert to non-priority scheduling if EPERM is returned.
2) Older versions of linux (perhaps all 2.4 versions without special patches) do not seem to support priority scheduling. The implementations seem to just silently ignore the priority scheduling requests even though _POSIX_THREAD_PRIORITY_SCHEDULING is defined.
This it seems that the only way to know if priority scheduling is being used is to run epicsThreadShowAll and see if the OSS prioritys have non zero values.
There should probably be tests added to src/libCom/test/epicsThreadTest.cpp to check for (a) non-zero OSS priorities and (b) whether or not the priority scheduling is strict. The epicsMessageQueue test produces different results with strict and non-strict ('suggestive'??) priority schedulers. A similar set of code would be useful in epicsThreadTest.