Message-Id: <9512080012.AA15468@jimi.MIT.EDU>
To: chua_dy@ee.uwa.edu.au (darren chua)
Cc: proven@MIT.EDU, proven@MIT.EDU
Subject: Re: pthread_cond_wait 
In-Reply-To: Your message of "Thu, 07 Dec 1995 16:52:21 +0700."
             <9512070852.AA00730@s15.ee.uwa.edu.au> 
Date: Thu, 07 Dec 1995 19:12:39 EST
From: Christopher Provenzano  <proven@MIT.EDU>


> Hi Chris,
> 
> I'm hoping you can answer this question for me.
> I'm an honours student at the University of Western Australia, and I've been 
> doing some work for my supervisor using your Pthreads package.
> 
> After doing some benchmarking, I've found that the pthread_cond_wait and 
> timedwait functions are taking in the order of 200-400 milliseconds.
> This is really unacceptable for our purposes. Can you offer any explanation
> as to why this might occur? We were expecting it to take in the order of 100
> microseconds!!
> 
> The benchmarking routine I used to test your functions was quite simple,
> and I really can't see how I could have done anything wrong.
> 
> Thanks in advance,
> 
> Darren Chua.

What version are you using, what platform is this on, and can you send me your
benchmarking routine? I haven't done a lot of performance analysis so I don't
really know why it's taking so long. 

My first guess is that you are using an older beta. In the latest code I 
changed pthread/signal.c to use an array of sigatomic_t's instead of a 
sigset_t to store signals that need to be processed. This speed up the 
pthread_sched_prevent()/pthread_sched_resume() functions a lot for systems 
that don't use an int for sigset_t, and actually speed up other systems too 
but only marginally. 

Looking at the code I find that there aren't a lot of systems calls. The two
I found immediately are gettimeofday() and setitimer(). It would be 
interesting to know the expense of those two calls on your systems, but I 
doubt that they are taking a significant portion of the time you are seeing.

CAP