pthreads works, sorta

Robert Collins
Tue Jun 26 20:15:00 GMT 2001

> -----Original Message-----
> From: Greg Smith [ ]
> Sent: Wednesday, June 27, 2001 11:25 AM
> To:
> 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!


Unsubscribe info:
Bug reporting:

More information about the Cygwin mailing list