This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

rwlocks and priority


Jakub wrote in bug 4979:

  AFAIK POSIX just sais that implementations may favor writers over
  readers, it doesn't say they must, so the choice of the default (or
  even the existance of different rwlock policies) is implementation
  choice.

I'm staring at the specification, and I can see where it says that for
normal threads on systems that don't support the Thread Execution
Scheduling option.  But glibc says that it does, by defining
_POSIX_THREAD_PRIORITY_SCHEDULING.

  If the Thread Execution Scheduling option is supported, and the
  threads involved in the lock are executing with the scheduling
  policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire
  the lock if a writer holds the lock or if writers of higher or equal
  priority are blocked on the lock; otherwise, the calling thread shall
  acquire the lock.

So if you've set your threads to SCHED_FIFO or SCHED_RR, and your
rwlocks still prefer readers over high priority writers, isn't that
against POSIX since _POSIX_THREAD_PRIORITY_SCHEDULING is defined?

The case of a bunch of SCHED_OTHER threads without fixed priorities
depends on how you parse the sentence quoted above.  The specification
only says that prefering readers/writers is an implementation defined
choice when Thread Execution Scheduling is not supported, and to me
that means the "otherwise" in the above paragraph applies.

I'm guessing the answer is "glibc doesn't really support Thread
Execution Scheduling, even though it defines the feature macro".

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]