Re: Host Time epoch
Re: Host Time epoch
- Subject: Re: Host Time epoch
- From: Jeff Moore <email@hidden>
- Date: Thu, 10 Feb 2005 15:42:17 -0800
The bug that Mr. Checkoway reported had nothing to do with the number
of CPUs. It was easy enough to demonstrate the bug on a single CPU
system with the program he provided in his previous email (Thanks, it
helped a lot when tracking down the bug!). Nor does it have anything to
do with the CPU clock.
Rather, the bug was caused by Murphy's Law of Pre-emption: "Whatever
can be pre-empted will be pre-empted at the worst possible moment." It
struck the HAL's code that tracks the sample clock of the hardware
against the CPU clock. Basically, the problem was that the IO thread
was pre-empting the thread that was retrieving the current time.
Because the IO thread was updating the clock, the thread retrieving the
current time would get an inconsistent set of values from the clock
with which to compute the current sample time. The most common
expression of this bug was that the sample time would jump backward by
driver ring buffer's worth of samples, and then jump back forward the
next time AudioDeviceGetCurrentTime() is called. However, I also saw
other odd things happen from time to time that led to other odd sample
times, in some case making the sample time jump ahead.
Mr. Checkoway's program is the worst case scenario for triggering this
bug. It sits and spins in a loop calling AudioDeviceGetCurrentTime().
This makes it pretty likely that the IO thread will eventually pre-empt
the call to AudioDevicegetCurrentTime() and trigger the bug. Since
applications generally don't do this sort of thing, the probability of
experiencing this bug in the real world is actually quite small.
That said, apps looking for the widest compatibility should be prepared
for this circumstance and deal with it appropriately. Note that if you
are not careful, the obvious work around to the bug, keeping the last
good returned time stamp and returning that if the new one is off in
the weeds, will fail. The circumstance that will cause it to
potentially fail is if multiple threads are accessing and updating this
"shadow" value. Indeed, this would actually result in a variant of the
bug in the HAL.
Since there are several parts to the time stamp, it can't be
manipulated atomically in it's entirety. So, there's a window of
opportunity for Murphy's Law of Pre-emption to strike and cause other
threads to see a mixed set of values (that is some old and some new).
You'd need to either keep a shadow per thread or use a mutex to make it
work properly.
If you don't mind the occasional potentially slightly stale value, you
can also use an array of time stamps to hold the sahdow values and
atomically manipulate the pointer into the array that other threads use
to get the "current" shadow value. You'll also want to use a memory
barrier with this technique to properly sequence the stores in an
multi-processing environment.
On Feb 10, 2005, at 3:10 PM, Herbie Robinson wrote:
At 12:38 PM -0800 2/10/05, Steve Checkoway wrote:
On Feb 10, 2005, at 12:21 PM, John Iversen wrote:
Sorry, I'm not aware of this issue, but it's of interest to me, and
is rather fundamental. Would you mind elaborating? What is the
nature of the non-monotonicity--I can't imagine you mean actual
reversals in the host time, I hope. Instead, do you mean that the
rate of increase of the HostTime is variable, so it drifts away
from 'real time'? How large is the effect in your experience?
Oh no. I mean non-monotonicity. Time does indeed move backward. I
filed a bug report quite a while ago and I was told (eventually)
that it was fixed in some later version of the OS.
Was this on a dual processor system?
This is just a guess, but the clock is probably a hardware register
in the CPUs; therefore, it is probably per cpu. With most hardware,
it's nearly impossible to reset the clocks to zero simultaneously;
so, there will almost always be a slight offset between the clocks on
different CPUs.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden