public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: pthreads-w32 2.2.0 test failures
@ 2005-04-05  3:59 Tim Theisen
  2005-04-05  6:03 ` Ross Johnson
  2005-04-05  7:03 ` Steve Croall
  0 siblings, 2 replies; 8+ messages in thread
From: Tim Theisen @ 2005-04-05  3:59 UTC (permalink / raw)
  To: Ross Johnson, Pthreads-Win32 list

I agree with your assessment.  Those tests need improvement.

At least you know someone is giving pthreads-w32 a run for its
money on a multiprocessor system.

...Tim

-----Original Message-----
From: pthreads-win32-owner@sources.redhat.com
[mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross
Johnson
Sent: Monday, April 04, 2005 21:06
To: Pthreads-Win32 list
Subject: Re: pthreads-w32 2.2.0 test failures


All of these are unserialised shared global variables in the tests
themselves!! Sketchy test coding that didn't show up on my single
processor.

Almost certain it's not a problem with the library.

Thanks.
Ross

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: pthreads-w32 2.2.0 test failures
  2005-04-05  3:59 pthreads-w32 2.2.0 test failures Tim Theisen
@ 2005-04-05  6:03 ` Ross Johnson
  2005-04-05  7:03 ` Steve Croall
  1 sibling, 0 replies; 8+ messages in thread
From: Ross Johnson @ 2005-04-05  6:03 UTC (permalink / raw)
  To: Pthreads-Win32 list

On Mon, 2005-04-04 at 22:59 -0500, Tim Theisen wrote:
> I agree with your assessment.  Those tests need improvement.

I've visually checked all the tests for this problem and those listed
below have been modified. They'll be committed to CVS after I've booted
into Windows and run them.

cleanup0.c
cleanup1.c
cleanup2.c
cleanup3.c
once2.c
once3.c

Obviously the same problem or two has been inherited down the line. New
tests are added by taking an old one as a template.

Are there any other specific improvements you think are needed?

> At least you know someone is giving pthreads-w32 a run for its
> money on a multiprocessor system.

It may be awhile before I get one myself. So please do.

Thanks.
Ross

> ...Tim
> 
> -----Original Message-----
> From: pthreads-win32-owner@sources.redhat.com
> [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross
> Johnson
> Sent: Monday, April 04, 2005 21:06
> To: Pthreads-Win32 list
> Subject: Re: pthreads-w32 2.2.0 test failures
> 
> 
> All of these are unserialised shared global variables in the tests
> themselves!! Sketchy test coding that didn't show up on my single
> processor.
> 
> Almost certain it's not a problem with the library.
> 
> Thanks.
> Ross
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pthreads-w32 2.2.0 test failures
  2005-04-05  3:59 pthreads-w32 2.2.0 test failures Tim Theisen
  2005-04-05  6:03 ` Ross Johnson
@ 2005-04-05  7:03 ` Steve Croall
  2005-04-05 16:03   ` Ross Johnson
  1 sibling, 1 reply; 8+ messages in thread
From: Steve Croall @ 2005-04-05  7:03 UTC (permalink / raw)
  To: Pthreads-Win32 list

FYI I'm running pthreads on a number of multi-CPU machines.  My twin :( 
  And three 8-Ways in the office.  It's also been run on a 32-way and it 
has been given a damn good thrashing.

More and more of our server applications are being made multi-threaded. 
  For example, two single-thread RPC servers in C have been 
re-implmented as mulit-threaded RPC servers in C++.  From taking 25% CPU 
load on a quad-machine I can now max-out most multi-CPU machines. Woo woo :)

(The main problem we found was that RPC is not thread-safe so we had to 
implement our own thread-safe version using Sun's implementation.  Even 
the RPC on Solaris is not thread-safe.)

Our server applications runs on a number of different platforms (it has 
been reduced).  Currently Windows, Solaris, AIX & HP-UX.  So this 
project has been a help over a few years now.

We did find problems with older implementations, small bugs etc... that 
have been fixed in later releases.

I'm a bit concerned about the pthread_once() bug though.   Have you a 
test application that shows this problem or are the test applications 
enough to show this?

Thanks, Steve Croall.

Tim Theisen wrote:
> I agree with your assessment.  Those tests need improvement.
> 
> At least you know someone is giving pthreads-w32 a run for its
> money on a multiprocessor system.
> 
> ...Tim
> 
> -----Original Message-----
> From: pthreads-win32-owner@sources.redhat.com
> [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross
> Johnson
> Sent: Monday, April 04, 2005 21:06
> To: Pthreads-Win32 list
> Subject: Re: pthreads-w32 2.2.0 test failures
> 
> 
> All of these are unserialised shared global variables in the tests
> themselves!! Sketchy test coding that didn't show up on my single
> processor.
> 
> Almost certain it's not a problem with the library.
> 
> Thanks.
> Ross
> 

-- 

J. Senior Software Engineer, TIBCO BPM Group.
T. +44 (0) 1792 360773
M. +44 (0) 7788 971394
E. scroall@tibco.com
W. www.tibco.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pthreads-w32 2.2.0 test failures
  2005-04-05  7:03 ` Steve Croall
@ 2005-04-05 16:03   ` Ross Johnson
  0 siblings, 0 replies; 8+ messages in thread
From: Ross Johnson @ 2005-04-05 16:03 UTC (permalink / raw)
  To: Pthreads-Win32 list

On Tue, 2005-04-05 at 08:03 +0100, Steve Croall wrote: 
> FYI I'm running pthreads on a number of multi-CPU machines.  My twin :( 
>   And three 8-Ways in the office.  It's also been run on a 32-way and it 
> has been given a damn good thrashing.

Fantastic! Thanks for posting.

> I'm a bit concerned about the pthread_once() bug though.   Have you a 
> test application that shows this problem or are the test applications 
> enough to show this?

The bug is identified from code inspection. I have to thank Gottlob
Frege for pointing out that the starvation problem is still there, only
shifted.

I'm referring to version 2 of the library (not version 1) and I actually
have an experimental version 3 (which fixes the bug I believe) in a CVS
branch. Changing pthread_once(), if it's wrong, tends to require ABI
changes because of PTHREAD_ONCE_INIT.

You need 3 conditions before the bug becomes a threat (only need the
first 2 on a single processor machine). They are:
- a possibility that the once_routine can be cancelled; AND,
- threads with different priorities accessing the same once_control; AND
- no other available CPUs that the lower priority threads can run on.

If you look at the code in version 2.2.0 and consider what happens if
the once_routine is cancelled, you'll see that newly arriving threads,
and any currently waiting threads compete again to run the once_routine.
The winner must reset both a flag and a manual reset event to cause
other threads to wait again. But if the winner suspends before
completing this then there's an opportunity for some higher priority
thread to begin busy looping and keep the winner (once_routine thread)
from ever resuming.

This may not even be a problem at all if Windows promotes threads caught
in this situation. I've read that it does this by incrementing a
thread's priority by 1 each time it misses a turn. This may only be in
some situations though.

For the record:
Gottlob provided an efficient working version without once_routine
cancellability. I wanted to take the opportunity to conform to SUS v3
and add cancellability. That complicated things a little.

The experimental version 3 is similar to version 2 in order to retain
the fast uncontended track. Current options for fixing the bug are:
- change the current manual reset event, that threads wait on, into an
auto reset event, and have each waking thread set it to wake the next
waiting thread; OR
- add priority inheritance, to ensure the once_routine thread always
gets a turn.

Both of these options are only necessary in the post cancellation logic.
I'm not real keen on daisy chained event setting because of the
cumulative effects, while priority inheritance is a standard way to
solve priority inversion and starvation problems.

I hope to have version 3 out soon.

Ross


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: pthreads-w32 2.2.0 test failures
@ 2005-04-05 12:50 Tim Theisen
  0 siblings, 0 replies; 8+ messages in thread
From: Tim Theisen @ 2005-04-05 12:50 UTC (permalink / raw)
  To: scroall, Pthreads-Win32 list

I do not have a real world example of a problem with the pthread
library.  I have simply run the test cases.  Inspection of the
once2 test case reveals that it will likely report failures on a
multi-processor system.  In this case, Ross and I believe that the
test case is defective, not the library.

I think that it is wonderful to have the test cases distributed
with the library.  Whenever I pick up a new version of the library,
I run the test cases.  With multi-threaded code, you never know
what timing differences may reveal a problem.  Having these test
cases available gives my much more comfort and assurance that the
library is correct.

...Tim

-----Original Message-----
From: pthreads-win32-owner@sources.redhat.com
[mailto:pthreads-win32-owner@sources.redhat.com] On Behalf Of Steve
Croall
Sent: Tuesday, April 05, 2005 02:03
To: Pthreads-Win32 list
Subject: Re: pthreads-w32 2.2.0 test failures


FYI I'm running pthreads on a number of multi-CPU machines.  My twin :( 
  And three 8-Ways in the office.  It's also been run on a 32-way and it

has been given a damn good thrashing.

More and more of our server applications are being made multi-threaded. 
  For example, two single-thread RPC servers in C have been 
re-implmented as mulit-threaded RPC servers in C++.  From taking 25% CPU

load on a quad-machine I can now max-out most multi-CPU machines. Woo
woo :)

(The main problem we found was that RPC is not thread-safe so we had to 
implement our own thread-safe version using Sun's implementation.  Even 
the RPC on Solaris is not thread-safe.)

Our server applications runs on a number of different platforms (it has 
been reduced).  Currently Windows, Solaris, AIX & HP-UX.  So this 
project has been a help over a few years now.

We did find problems with older implementations, small bugs etc... that 
have been fixed in later releases.

I'm a bit concerned about the pthread_once() bug though.   Have you a 
test application that shows this problem or are the test applications 
enough to show this?

Thanks, Steve Croall.

Tim Theisen wrote:
> I agree with your assessment.  Those tests need improvement.
> 
> At least you know someone is giving pthreads-w32 a run for its money 
> on a multiprocessor system.
> 
> ...Tim
> 
> -----Original Message-----
> From: pthreads-win32-owner@sources.redhat.com
> [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross 
> Johnson
> Sent: Monday, April 04, 2005 21:06
> To: Pthreads-Win32 list
> Subject: Re: pthreads-w32 2.2.0 test failures
> 
> 
> All of these are unserialised shared global variables in the tests 
> themselves!! Sketchy test coding that didn't show up on my single 
> processor.
> 
> Almost certain it's not a problem with the library.
> 
> Thanks.
> Ross
> 

-- 

J. Senior Software Engineer, TIBCO BPM Group.
T. +44 (0) 1792 360773
M. +44 (0) 7788 971394
E. scroall@tibco.com
W. www.tibco.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pthreads-w32 2.2.0 test failures
  2005-04-04 21:41 Tim Theisen
@ 2005-04-05  2:06 ` Ross Johnson
  0 siblings, 0 replies; 8+ messages in thread
From: Ross Johnson @ 2005-04-05  2:06 UTC (permalink / raw)
  To: Pthreads-Win32 list

All of these are unserialised shared global variables in the tests
themselves!! Sketchy test coding that didn't show up on my single
processor.

Almost certain it's not a problem with the library.

Thanks.
Ross

On Mon, 2005-04-04 at 16:41 -0500, Tim Theisen wrote:
> I compiled the 2.2.0 release on my machine with the Visual Studio .NET
> 2003 and the following tests fail:
> 
> ... Running VC test: once2.exe
> Assertion failed: (numThreads == NUM_THREADS * NUM_ONCE), file once2.c,
> line 91
> 
> ... Running VC test: cleanup0.exe
> Assertion failed: (pop_count == NUMTHREADS), file cleanup0.c, line 202
> 
> ... Running VC test: cleanup1.exe
> Assertion failed: (pop_count == NUMTHREADS), file cleanup1.c, line 215
> 
> The once2 test fails fairly consistently (about 90% of the time).
> The cleanup tests fail intermittently (about 20% of the time).
> 
> I am using a dual processor 2.6GHz Pentium 4 Xeon with Hyperthreading
> enabled.
> 
> ...Tim
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* pthreads-w32 2.2.0 test failures
@ 2005-04-04 21:49 Tim Theisen
  0 siblings, 0 replies; 8+ messages in thread
From: Tim Theisen @ 2005-04-04 21:49 UTC (permalink / raw)
  To: pthreads-win32

I compiled the 2.2.0 release on my machine with the Visual Studio .NET
2003 and the following tests fail:

... Running VC test: once2.exe
Assertion failed: (numThreads == NUM_THREADS * NUM_ONCE), file once2.c,
line 91

... Running VC test: cleanup0.exe
Assertion failed: (pop_count == NUMTHREADS), file cleanup0.c, line 202

... Running VC test: cleanup1.exe
Assertion failed: (pop_count == NUMTHREADS), file cleanup1.c, line 215

The once2 test fails fairly consistently (about 90% of the time).
The cleanup tests fail intermittently (about 20% of the time).

I am using a dual processor 2.6GHz Pentium 4 Xeon with Hyperthreading
enabled.

...Tim 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* pthreads-w32 2.2.0 test failures
@ 2005-04-04 21:41 Tim Theisen
  2005-04-05  2:06 ` Ross Johnson
  0 siblings, 1 reply; 8+ messages in thread
From: Tim Theisen @ 2005-04-04 21:41 UTC (permalink / raw)
  To: pthreads-win32

I compiled the 2.2.0 release on my machine with the Visual Studio .NET
2003 and the following tests fail:

... Running VC test: once2.exe
Assertion failed: (numThreads == NUM_THREADS * NUM_ONCE), file once2.c,
line 91

... Running VC test: cleanup0.exe
Assertion failed: (pop_count == NUMTHREADS), file cleanup0.c, line 202

... Running VC test: cleanup1.exe
Assertion failed: (pop_count == NUMTHREADS), file cleanup1.c, line 215

The once2 test fails fairly consistently (about 90% of the time).
The cleanup tests fail intermittently (about 20% of the time).

I am using a dual processor 2.6GHz Pentium 4 Xeon with Hyperthreading
enabled.

...Tim

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-04-05 16:03 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-05  3:59 pthreads-w32 2.2.0 test failures Tim Theisen
2005-04-05  6:03 ` Ross Johnson
2005-04-05  7:03 ` Steve Croall
2005-04-05 16:03   ` Ross Johnson
  -- strict thread matches above, loose matches on Subject: below --
2005-04-05 12:50 Tim Theisen
2005-04-04 21:49 Tim Theisen
2005-04-04 21:41 Tim Theisen
2005-04-05  2:06 ` Ross Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).