This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Help for pthread execution scheduling option about pthread_rwlock_rdlock()
- From: Neil <freeordie dot k at gmail dot com>
- To: libc-help <libc-help at sourceware dot org>
- Date: Tue, 7 Feb 2012 14:42:37 +0800
- Subject: 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