Mail Archives: cygwin/2001/06/26/14:30:53
I've been doing a little experimenting ;-)
First off, using an old cygwin and the Pthreads-win32 pthreads, my
application reaches a certain point in 4:00 minutes (elapsed).
Using the current cygwin with the timedwait patch takes about 21:15 minutes
to reach the same point.
Adding a new function, verifyable_object_isvalid2() to thread.cc, which
*doesn't* call check_valid_pointer(), and changing __pthread_mutex_lock,
__pthread_mutex_unlock, __pthread_cond_signal, __pthread_cond_wait and
__pthread_cond_timedwait to call this function instead, results in an
elapsed time of 4:15 minutes !!
Now check_valid_pointer() calls VirtualQuery(), which must be a hog.
I tried changing check_valid_pointer to not call VirtualQuery, but the
shell bombs right off the bat, so something is dependent on being told
that it passed a bad pointer.
I'm not quite sure how to fix this, but I'm thinking about it ;-)
Greg
Robert Collins wrote:
> I've just reviewed my reading, and it doesn't look as though critical
> sections are going to be _much_ faster.
>
> --> Greg, do you know that your issue is thread syncronisation
> performance, or performance of I/O or other posix calls in between ? You
> program shouldn't crash unless it manages to deadlock or trigger a
> race... certainly the pthread calls cannot happen except when your
> threads are active and have got cpu :].
>
> How many concurrent threads and mutexs and cond variables are we talking
> here?
>
> 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/
- Raw text -