public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Steve Croall <s.croall@btinternet.com>
To: Pthreads-Win32 list <pthreads-win32@sources.redhat.com>
Subject: Re: pthreads-w32 2.2.0 test failures
Date: Tue, 05 Apr 2005 07:03:00 -0000	[thread overview]
Message-ID: <42523837.1060309@btinternet.com> (raw)
In-Reply-To: <1E2E66102E75104D8C740340EBCD9867144A37@tomoex.tomotherapy.com>

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

  parent reply	other threads:[~2005-04-05  7:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-05  3:59 Tim Theisen
2005-04-05  6:03 ` Ross Johnson
2005-04-05  7:03 ` Steve Croall [this message]
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

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=42523837.1060309@btinternet.com \
    --to=s.croall@btinternet.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=scroall@tibco.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).