Exactly when does priority inherit?

I’m having a problem with some background thread apparently running at
too high a priority and taking time from the key real-time threads.
This seems to be a transient priority issue; in “System Process
Inspector”, everything looks good. Some questions:

  1. Thread A at priority P1 does a sem_post. Thread B
    at priority P2 (P2 < P1) was waiting in a sem_wait and now
    becomes ready. Does thread B get boosted to priority P1,
    or does it stay at priority P2? (Note thet thread A does
    NOT do a sem_wait; this is a one-way operation.)

  2. Thread A does a write to a disk. What is the highest
    priority thread in the I/O system that will run as a result?
    To what extent does the priority of thread A affect this?

  3. Are there any useful tools other than “System Process Inspector”
    that would help here? Thanks.

Our main driving control loop only has to cycle every 100ms, and
its worst-case time, measured by the thread itself, is 29ms. Yet
once in a while it misses the 100ms deadline and we shut down.
There’s other stuff running, but it’s all at lower priority, or should be.
We’re logging some data, but the logger is supposed to be running
at priority 9, while the main control code is at at priority 18.

John Nagle
Team Overbot

[QNX 6.21, X86]

John Nagle wrote:

  1. Thread A at priority P1 does a sem_post. Thread B
    at priority P2 (P2 < P1) was waiting in a sem_wait and now
    becomes ready. Does thread B get boosted to priority P1,
    or does it stay at priority P2? (Note thet thread A does
    NOT do a sem_wait; this is a one-way operation.)

Counting semaphores (unlike mutexes) do not have an “owner”, and
so no priority inheritence/adjustment is made.

  1. Thread A does a write to a disk. What is the highest
    priority thread in the I/O system that will run as a result?
    To what extent does the priority of thread A affect this?

All the filesystem components of the disk write will float to
client priority. The disk driver component (talk to h/w
registers and handle completion notification) will run at
fixed priority of “21r”. This can be changed using the
devb “eide priority=” option. Note that if the write is
non-synchronous (not O_SYNC) then the point at which this h/w
thread will run at non-client priority is asynchronous with
respect to the write() call (ie in the future).

Our main driving control loop only has to cycle every 100ms, and
its worst-case time, measured by the thread itself, is 29ms. Yet
once in a while it misses the 100ms deadline and we shut down. There’s
other stuff running, but it’s all at lower priority, or should be.
We’re logging some data, but the logger is supposed to be running
at priority 9, while the main control code is at at priority 18.

You might try reducing the eide priority to 17 (although that component
doesn’t do much actual work, unless non-DMA, in which case it will be
doing the PIO byte transfer - what is your disk IO modes according to
sloginfo?) Also need to be aware that if it is doing PIO, then some
disks will corrupt data if not fed promptly, so be wary of reducing
the priority below anything too time-consuming that would stall it …

Hello, FYI: this excerpt from the 6.3 SP1 release notes is also worth
keeping in mind:

Known issues: Block-oriented drivers
devb-*
High-priority threads can get starved off by lower ones via devb-* because
the filesystem uses sleepon_*() functions, which aren’t
priority-inheriting. (Ref# 2109)
devb-adpu320
Reading DVD-RAM causes devb-adpu320 to become blocked on a CONDVAR. (Ref#
19772)



John Garvey wrote:

John Nagle wrote:

  1. Thread A at priority P1 does a sem_post. Thread B
    at priority P2 (P2 < P1) was waiting in a sem_wait and now
    becomes ready. Does thread B get boosted to priority P1,
    or does it stay at priority P2? (Note thet thread A does
    NOT do a sem_wait; this is a one-way operation.)

Counting semaphores (unlike mutexes) do not have an “owner”, and
so no priority inheritence/adjustment is made.

  1. Thread A does a write to a disk. What is the highest
    priority thread in the I/O system that will run as a result?
    To what extent does the priority of thread A affect this?

All the filesystem components of the disk write will float to
client priority. The disk driver component (talk to h/w
registers and handle completion notification) will run at
fixed priority of “21r”. This can be changed using the
devb “eide priority=” option. Note that if the write is
non-synchronous (not O_SYNC) then the point at which this h/w
thread will run at non-client priority is asynchronous with
respect to the write() call (ie in the future).

Our main driving control loop only has to cycle every 100ms, and
its worst-case time, measured by the thread itself, is 29ms. Yet
once in a while it misses the 100ms deadline and we shut down. There’s
other stuff running, but it’s all at lower priority, or should be.
We’re logging some data, but the logger is supposed to be running
at priority 9, while the main control code is at at priority 18.

You might try reducing the eide priority to 17 (although that component
doesn’t do much actual work, unless non-DMA, in which case it will be
doing the PIO byte transfer - what is your disk IO modes according to
sloginfo?) Also need to be aware that if it is doing PIO, then some
disks will corrupt data if not fed promptly, so be wary of reducing
the priority below anything too time-consuming that would stall it …