From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5913 invoked by alias); 5 Apr 2005 12:50:44 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 5809 invoked from network); 5 Apr 2005 12:50:34 -0000 Received: from unknown (HELO tomoex.tomotherapy.com) (66.170.4.179) by sourceware.org with SMTP; 5 Apr 2005 12:50:34 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: pthreads-w32 2.2.0 test failures Date: Tue, 05 Apr 2005 12:50:00 -0000 Message-ID: <1E2E66102E75104D8C740340EBCD9867144A38@tomoex.tomotherapy.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Tim Theisen" To: , "Pthreads-Win32 list" X-SW-Source: 2005/txt/msg00062.txt.bz2 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 :(=20 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.=20 For example, two single-thread RPC servers in C have been=20 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=20 implement our own thread-safe version using Sun's implementation. Even=20 the RPC on Solaris is not thread-safe.) Our server applications runs on a number of different platforms (it has=20 been reduced). Currently Windows, Solaris, AIX & HP-UX. So this=20 project has been a help over a few years now. We did find problems with older implementations, small bugs etc... that=20 have been fixed in later releases. I'm a bit concerned about the pthread_once() bug though. Have you a=20 test application that shows this problem or are the test applications=20 enough to show this? Thanks, Steve Croall. Tim Theisen wrote: > I agree with your assessment. Those tests need improvement. >=20 > At least you know someone is giving pthreads-w32 a run for its money=20 > on a multiprocessor system. >=20 > ...Tim >=20 > -----Original Message----- > From: pthreads-win32-owner@sources.redhat.com > [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross=20 > Johnson > Sent: Monday, April 04, 2005 21:06 > To: Pthreads-Win32 list > Subject: Re: pthreads-w32 2.2.0 test failures >=20 >=20 > All of these are unserialised shared global variables in the tests=20 > themselves!! Sketchy test coding that didn't show up on my single=20 > processor. >=20 > Almost certain it's not a problem with the library. >=20 > Thanks. > Ross >=20 --=20 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