Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Host Time epoch

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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

This email sent to email@hidden
References: 
 >Host Time epoch (From: Geoff Schmidt <email@hidden>)
 >Re: Host Time epoch (From: Jeff Moore <email@hidden>)
 >Re: Host Time epoch (From: Steve Checkoway <email@hidden>)
 >Re: Host Time epoch (From: John Iversen <email@hidden>)
 >Re: Host Time epoch (From: Steve Checkoway <email@hidden>)
 >Re: Host Time epoch (From: Herbie Robinson <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.