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