This is the mail archive of the libc-help@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]

Help for pthread execution scheduling option about pthread_rwlock_rdlock()


Hi,

In POSIX spec IEEE Std 1003.1-2008 POSIX BASE Specificationï Issue  7,
 section pthread_rwlock_rdlock() it talks about pthread execution
scheduling option (line 53780):

   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.

In POSIX test suite, test cases pthread_rwlock_rdlock/2-1 2-2 3-1 test
that circumstance. But when a writer of higher or equal priority are
blocked on the lock, the calling thread still acquire the lock.

First, macro _POSIX_THREAD_PRIORITY_SCHEDULING which means "The
implementation supports the Thread Execution Scheduling option." (Line
14590 in POSIX spec) is defined in
nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h. I suppose that means
linux support Thread Execution Scheduling option.

But in implementation of pthread_rwlock_rdlock() in
nptl/pthread_rwlock_rdlock.c, it doesn't handler the priority. There
is only a flag '__flags' in pthread_rwlock_t to identify whether the
lock is reader preferred or writer preferred.

So my question is why the implementation of pthread_rwlock_rdlock() is
not consistent with POSIX spec? Does the linux doesn't support "Thread
Execution Scheduling" then we need to undefine
_POSIX_THREAD_PRIORITY_SCHEDULING?

Thanks for your patient,

-- 
Regards,
Neil


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