Priority inheritance with pthread_rwlock

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
#1

I have a high priority (H) and a low priority (L) process using a rwlock.
Consider the case:

  • (L) is running
  • (L) is locking the rwlock
  • (H) interrupts (L) and runs
  • (H) runs into the rwlock that is taken by (L)
  • (L) runs again
  • (L) is interrupted by a process (X) that is higher than (L) but lower then
    (H)
  • (X) takes a long time and is able to delay (H) any time, because (L) can’t
    run and remove the lock because of (X)

Is there something like priority inheritance with pthread_rwlock? Such that
(L) would temporarily get the priority of (H)? I have seen that for message
passing and also found something for mutexes, but didn’t get any info about
pthread_rwlock.
Thanks
Markus

#2

In article <8vvbca$hr6$1@inn.qnx.com>,
Markus Loffler <loffler@ces.clemson.edu> wrote:

I have a high priority (H) and a low priority (L) process using a rwlock.
Consider the case:

  • (L) is running
  • (L) is locking the rwlock
  • (H) interrupts (L) and runs
  • (H) runs into the rwlock that is taken by (L)
  • (L) runs again
  • (L) is interrupted by a process (X) that is higher than (L) but lower then
    (H)
  • (X) takes a long time and is able to delay (H) any time, because (L) can’t
    run and remove the lock because of (X)

Is there something like priority inheritance with pthread_rwlock? Such that
(L) would temporarily get the priority of (H)? I have seen that for message
passing and also found something for mutexes, but didn’t get any info about
pthread_rwlock.

Regrettably – in a way – no. The problem here of course is that there
may be multiple readers, resulting in a demand for additional kernel-level
synchronization, additional data and non-constant time for a wrlock
operation.

There is also a question of semantics. Should priority inheritance
only take place for wrlock operations?

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.