From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
To: Jan Stancek <jstancek@redhat.com>
Cc: LTP <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc
Date: Fri, 26 Jul 2013 16:30:44 +0800 [thread overview]
Message-ID: <51F233B4.2030804@cn.fujitsu.com> (raw)
In-Reply-To: <1515555986.6425405.1374827280068.JavaMail.root@redhat.com>
On 07/26/2013 04:28 PM, Jan Stancek wrote:
>
>
> ----- Original Message -----
>> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
>> To: "Jan Stancek" <jstancek@redhat.com>
>> Cc: "LTP" <ltp-list@lists.sourceforge.net>
>> Sent: Friday, 26 July, 2013 9:52:25 AM
>> Subject: Re: [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc
>>
>> On 07/26/2013 03:07 PM, Jan Stancek wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
>>>> To: "LTP" <ltp-list@lists.sourceforge.net>
>>>> Cc: "Cyril Hrubis" <chrubis@suse.cz>, "Caspar Zhang"
>>>> <caspar@casparzhang.com>, "Garrett Cooper" <yanegomi@gmail.com>,
>>>> "Mike Frysinger" <vapier@gentoo.org>, jstancek@redhat.com, "Wanlong Gao"
>>>> <gaowanlong@cn.fujitsu.com>
>>>> Sent: Friday, 26 July, 2013 4:56:18 AM
>>>> Subject: [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc
>>>>
>>>> Since the reader can always acquire the rwlock if there's not a writer
>>>> held the lock.
>>>>
>>>> Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>>>
>>> Hi,
>>>
>>> I agree that these 3 fail by default on glibc at the moment.
>>> Since we are adding a GLIBC ifdef, I'm wondering if we could use
>>> glibc specific api to change default behaviour with
>>> pthread_rwlockattr_setkind_np() and still run the testcase.
>>
>> The first 2 *_rdlock cases can change to WRITER_PREFER to let them pass,
>> but the last *_unlock one can't, because *_unlock will choose the writer
>> first without any care of the NP KIND.
>> How about change the first two cases to WRITER_PREFER and just skip the third
>> *_unlock one?
>
> I agree with skipping third one and let's see what other guys think about first two.
> When you say "WRITER_PREFER", is that an actual define on your system? Or just
> a shortcut for PTHREAD_RWLOCK_PREFER_WRITER...?
Surly means shortcut in glibc:
113 enum
114 {
115 PTHREAD_RWLOCK_PREFER_READER_NP,
116 PTHREAD_RWLOCK_PREFER_WRITER_NP,
117 PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP,
118 PTHREAD_RWLOCK_DEFAULT_NP = PTHREAD_RWLOCK_PREFER_READER_NP
119 };
Thanks,
Wanlong Gao
>
> Regards,
> Jan
>
>>
>> Thanks,
>> Wanlong Gao
>>
>>>
>>> Regards,
>>> Jan
>>>
>>>> ---
>>>> .../conformance/interfaces/pthread_rwlock_rdlock/2-1.c | 6
>>>> ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git
>>>> a/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c
>>>> b/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c
>>>> index c6c1412..62a4b3b 100644
>>>> ---
>>>> a/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c
>>>> +++
>>>> b/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c
>>>> @@ -141,6 +141,12 @@ int main(void)
>>>> return PTS_UNSUPPORTED;
>>>> #endif
>>>>
>>>> +#ifdef __GLIBC__
>>>> + printf("The reader can always acquire rwlock if there's"
>>>> + " not a writer held this lock in glibc\n");
>>>> + return PTS_UNTESTED;
>>>> +#endif
>>>> +
>>>> int cnt = 0;
>>>> pthread_t rd_thread, wr_thread;
>>>> int priority;
>>>> --
>>>> 1.8.3.3.754.g9c3c367
>>>>
>>>>
>>>
>>
>>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2013-07-26 8:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1374807380-20319-1-git-send-email-gaowanlong@cn.fujitsu.com>
2013-07-26 7:07 ` [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc Jan Stancek
2013-07-26 7:52 ` Wanlong Gao
2013-07-26 8:28 ` Jan Stancek
2013-07-26 8:30 ` Wanlong Gao [this message]
2013-07-31 11:16 ` chrubis
[not found] ` <52836390.5080104@cn.fujitsu.com>
2013-11-13 15:13 ` chrubis
[not found] ` <52D5F124.3090204@cn.fujitsu.com>
2014-01-28 13:23 ` chrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F233B4.2030804@cn.fujitsu.com \
--to=gaowanlong@cn.fujitsu.com \
--cc=jstancek@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.