Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Subject: RE: pthreads works, sorta Date: Wed, 27 Jun 2001 13:05:05 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: pthreads works, sorta Thread-Index: AcD+skdxI42+9JIjQYWJ2UkBxuUDYQAApI7w From: "Robert Collins" To: "Greg Smith" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id AAA28536 > -----Original Message----- > From: Greg Smith [mailto:gsmith AT nc DOT rr DOT com] > Sent: Wednesday, June 27, 2001 11:25 AM > To: cygwin AT cygwin DOT com > Subject: Re: pthreads works, sorta > > > More experimenting with my home computer, dual pIII 850: > > 1. 117 157 328 > 2. 822 1527 --- > 3. 194 240 453 > 4. 169 181 516 > > The entries in the array represent the number of seconds it > took to get to a certain milestone in the application. The > columns, 1 thru 3, are the milestones. The rows are defined as: > > 1. linux (however, linux had an advantage, since all the data is > on the hard drive, and on the windows side some of the data > had to be contained on cdrom). > 2. cygwin current, with the condtimedwait patch > 3. cygwin 1.3.2, but with the Pthread-win32 implementation > 4. cygwin current, plus using the verifiable_object_isvalid2() > routine, for the lock/unlock, signal, wait/timedwait calls > (which doesn't call VirtualQuery()). > > There is an additional error in cygwin current, I think related > to pthread_kill, that occurs between milestone 2 and 3, that > possibly skewed the results for row 4. Milestone 3 is never > reached for row 2 because all processing becomes dedicated to > pthreads overhead and no useful work gets done (ie thrashing). > > I think this shows that VirtualQuery *is* a hog. > These results were obtained on Windows2000 sp1 and my previous > results were on NT4 sp6 (on a pIII 650). > > Thanks, Greg > The VirtualQuery is used to ensure that cygwin doesn't segfault when invalid pthread_t variables are passed to the kernel. The pre-robert-hacking code used a fixed size array to store the thread data , and had to enter a critical section, walk the array, exit the section on every call. This artificially increases the syncronisation between threads of the sme process, as well as articificially limiting the max thread count. The problem being that the POSIX spec doesn't require that non-valid pthread variables are NULL. So we can be given any random value and be expected to know whether it's valid or not. Now there are two routes to doing that: fixed structs for a library version, requiring a recompile as features are added, or the use of "kernel" memory to store the detailed thread data, and the external symbol becomes an opaque pointer. The POSIX spec utilises an opaque variable - we could make that a struct, or a pointer. The problem is that with the rather rapid cygwin development cycle, breaking the ABI is a bad thing. Thus the pointer into kernel alloc'd memory. What does all this mean? We need to catch invalid memroy access, and ValidQuery was supplied by Chris as a tool to do that. So the question for all the win32 gurus: Whats a fast way to catch (in-cygwin-dll) invalid memory access's. Can we use structed exception handling there? Or...? Remembering that code that depends on pthreads _probably cannot_ be used, as we are the pthreads implementation! Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/