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
next prev 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).