Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[Jan Stancek]

----- 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.

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

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[Wanlong Gao]

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?

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

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[Jan Stancek]

----- 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...?

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

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[Wanlong Gao]

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

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[chrubis]

Hi!
> Since the reader can always acquire the rwlock if there's not a writer
> held the lock.

Since there was recently a discussion about this on glibc ML and some
clarfication requests for Austin Group were created, I would wait a
little more until the POSIX is clear on how this locks should behave and
then we can fix the tests (and possibly skip them on glibc).

See:

http://austingroupbugs.net/view.php?id=722
http://austingroupbugs.net/view.php?id=720

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[chrubis]

Hi!
> > Since there was recently a discussion about this on glibc ML and some
> > clarfication requests for Austin Group were created, I would wait a
> > little more until the POSIX is clear on how this locks should behave and
> > then we can fix the tests (and possibly skip them on glibc).
> > 
> > See:
> > 
> > http://austingroupbugs.net/view.php?id=722
> > http://austingroupbugs.net/view.php?id=720
> 
> 
> Hi Cyril,
> 
> How about the discuss status? It's a POSIX SPEC bug? Do we need to fix our test suite?

I haven't been following the discussion for a while, I've read the
resolutions now.

So they removed the contradicting line from pthread_rwlock_wrlock() and
clarified the deadlock conditions.

If I understand the changes right, the write locks can now be
implemented to take precedence before the read locks, the testcase is
correct (actually three testcases pthread_rwlock_unlock_3-1,
pthread_rwlock_rdlock_2-1 and pthread_rwlock_rdlock_2-2) and the ball is
on glibc side. I will write a mail to the glibc ML to discuss it.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 1/3] pthread_rwlock_rdlock:2-1: do not test on glibc

[chrubis]

Hi!
> 
> Whether there are some new progress about these three cases?
> 

Sorry, not yet, but I keep it on my TODO.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list