Incorrect calculation oss priorities for posix threads

Bug #835138 reported by mdavidsaver on 2011-08-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Till Straumann

Bug Description

For the posix implementation of osdThread the mapping of epics priorities to OS priorities uses sched_get_priority_max. However, the value returned does not reflect any current administrative limits which may be in place (eg. /etc/security/limits.conf).

Currently trying to set a priority which is higher then allowed leaves the priority at the current level (default 0). This can lead to a situation where low priority threads (eg errlog) have a higher priority then the scan and callback threads.

Till Straumann (strauman) wrote :

The described behavior was observed under linux -- it does not necessarily apply to other posix systems

Changed in epics-base:
status: New → Confirmed
Till Straumann (strauman) wrote :

The existing code determines the available priority range once and caches the return values of sched_get_priority_min()/sched_get_priority_max().

The proposed fix (implemented by the patch) creates a helper thread (this happens only a single time, i.e., when the the epicsThreads facility is initialized) which takes the above min/max values as a starting point for a binary search for the maximal priority that can be set on the system.

Changed in epics-base:
assignee: Till Straumann (strauman) → nobody
Andrew Johnson (anj) on 2011-08-30
Changed in epics-base:
assignee: nobody → Till Straumann (strauman)
status: Confirmed → Fix Committed
Till Straumann (strauman) wrote :

Unfortunately, the previously submitted patch had a flaw:
When an EPICS process was started intentionally
w/o real-time privileges (e.g., a CA client, tool or the like)
a warning message

sched_get_priority_max failed set to 0
sched_get_priority_min failed set to 0

would pop up.

This new version of the patch fixes this and restores
old semantics:

- process has no RT privileges: priority range is silently set to 1..1
  (this lets epicsThreadCreate detect that it doesn't have permission
  to use the RT scheduler)
- process has no RT privileges but sched_get_priority_max()/_min()
  fail: above warning shows
- process has RT privilege: compute available priority range (under
  resource limit constraints).

Till Straumann (strauman) wrote :
Till Straumann (strauman) wrote :

Here is a differential patch that can be applied over the original one
(which has been removed from this page; the differential patch is
intended for maintainers who already applied the original patch).

Andrew Johnson (anj) on 2011-12-12
Changed in epics-base:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers