public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox