In message: <4362CBC2.8050602_at_freebsd.org> David Xu <davidxu_at_freebsd.org> writes: : 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. And unfortuantely, the argument that needs to be passed to abstime is unspecified, at leas tin our man page. Also unfortuantely, CLOCK_REALTIME seems to be what's required here (our man page just says 'if the system time reaches the time specified in abstime'), rather than CLOCK_MONOTONIC so jumps in system time can cause previously short timeouts to become rather large timeouts... This is a flaw in the API. :-( WarnerReceived on Sat Oct 29 2005 - 02:18:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC