Re: Timers and timing, was: MySQL Performance 6.0rc1

From: David Xu <davidxu_at_freebsd.org>
Date: Sat, 29 Oct 2005 09:09:22 +0800
Robert Watson wrote:

> Another important question is whether using these alternative time 
> access methods in user space improves the performance of any of the 
> applications we care about.  Hence providing a patch that someone can 
> try -- while the microbenchmarks seem to show improved performance, 
> will the applications? I suspect it will in some important cases, but 
> there's only one way to find out.
>
> It strikes me that replacing time(3) with something that retrieves 
> CLOCK_SECOND shouldn't harm time(3) semantics.  Likewise, keeping 
> CLOCK_REALTIME as is is likely OK -- if an application requests it 
> using clock_gettime(), then it is presumably looking for high 
> accuracy.  It's gettimeofday() that's the troubling one -- it's widely 
> used to query the time in applications, and its API suggests 
> microsecond resolution.
>
> Robert N M Watson
>
>
thread libraries use clock_gettime, this becauses there is
pthread_cond_timedwait and other synchronization objects
like rwlock, and mutex all have a timeout version, I think
pthread_cond_timedwait is mostly used in some applications,
though normally, application is not looking for high accuracy.
they will get benefit from the clock_gettime speed improvement.
Received on Fri Oct 28 2005 - 23:09:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC