Re: [LTP] Question about priority of pthread rwlock on linux

[Garrett C. <yan...@gm...>]

On Fri, Dec 9, 2011 at 5:15 AM, Cyril Hrubis <ch...@su...> wrote:
> Hi!
>> I am working on Yocto( a kind of  embedded linux) to make POSIX test
>> cases pass. It uses kernel 3.0 and eglibc 2.3.
>>
>> There are 3 failed test cases about pthread rwlock:
>> pthread_rwlock_rdlock/2-1 pthread_rwlock_rdlock/2-2
>> pthread_rwlock_unlock/3-1
>>
>> In pthread_rwlock_rdlock/2-1,  main thread*read lock* a rwlock,
>> child thread1 *write lock* the rwlock with a medium priority, so it
>> should be blocked. child thread2 try to *read lock *the rwlock with
>> low priority, the case says child thread2 should block too. But in
>> Yocto linux child thread2 doesn't block and then read lock the
>> rwlock, that make test case fail.
>>
>> In eglibc nptl implementation, rwlock has a element "__flags" to
>> identify prefer write lock or read lock, default is to prefer read
>> lock. If change __flags to prefer write lock, the test case will
>> pass.
>>
>> My questions are:
>> 1 What is the test case base on? I checked the  POSIX.1-2008 but
>> didn't find description priority about the pthread rwlock? Could
>> anyone give me a source that make me to understand it better?
>> 2 Which C library or platform can make this case pass? So that I can
>> compare it with eglibc.
>
> These doesn't work with glibc either, see:
>
> http://old.nabble.com/pthread_rwlock_rdlock%28%29-p32423548.html
>
> I haven't got any reply though :(.
>
> The newer POSIX explicitly says that reader thread acquires the lock if
> no writer is holding the lock and no writers are locked on the lock. And
> it seems that previous standards specified the case of locked writing
> threads as implementation defined...
>
> http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_rwlock_rdlock.html

    Once upon a time I intended to upgrade the POSIX compliance of the
test suite to the 2008 spec -- so I blindly updated the POSIX
compliance to 2008.1 (before it was set to 2001 compliance, IIRC..
which wasn't particularly useful). I got busy with other tasks and
since then my focus has been diverted from this and LTP (for the most
part).
    If it turns out that the testcase doesn't make sense given the new
POSIX spec, or needs to be rewritten, I'll be more than happy to
review either and provide feedback.
Thanks!
-Garrett