On Fri, 2005-Oct-28 00:35:24 +0200, Poul-Henning Kamp wrote: > * Does threads have to return ordered timestamps ? > > Consider: > > CPU1 CPU2 > > gettimeofday(t1) > gettimeofday(t2) > gettimeofday(t3) ... > > [t1 <= t2 <= t3] If this reflects kernel threads, unless there's some sort of explicit synchronization between the two threads, there's no need to guarantee anything better than t1 <[=] t3. If the threads are explicitly synchronised, then we should guarantee t1 <= t2 <= t3. On Thu, 2005-Oct-27 19:50:45 -0400, Chuck Swiger wrote: >I believe Darwin keeps the timecounters of the system exposed on a common >page mapped via the System framework (their libc+libm), which gets mapped >in once by init, and then shared with all of it's children copy-on-write. >They are using the PowerPC timebase registers according to a thread on the >darwin-kernel list. SunOS 4.x (I'm not sure about SunOS 5.x) did this as well. As Poul pointed out, this is much easier with sane hardware. FreeBSD already supports a variety of different timecounters with different levels of accuracy/performance/guarantees. One problem is that this is a system-wide knob whereas different applications may have different requirements. Whilst it's reasonable for MySQL to gather performance statistics, it only needs to measure short time periods and doesn't require extreme accuracy - the TSC would probably be good enough on a UP system (if there was a quick way to measure the current TSC tick rate). I don't think there's any way on i386 to quickly access a timecounter that returns a synchronised time across multiple CPUs. -- Peter JeremyReceived on Fri Oct 28 2005 - 07:34:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC