Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B38CED1.45B44DBD@trex.rtpnc.epa.gov>
Date: Tue, 26 Jun 2001 14:05:05 -0400
From: Greg Smith <rys AT epaibm DOT rtpnc DOT epa DOT gov>
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cygwin General MailList <cygwin AT cygwin DOT com>
Subject: Re: pthreads works, sorta
References: <3B37D1A6 DOT 39A2685 AT nc DOT rr DOT com> <03c701c0fdd7$82ddbde0$0200a8c0 AT lifelesswks> <3B37F19F DOT C9BCDA23 AT nc DOT rr DOT com> <003d01c0fe1c$1f7e3c80$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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/