That means that any sleep will disguise a call's duration to the jiffie, which is a good thing. (If the call's variance is small enough, it may mean that there's no need to figure out how long to sleep.)
Note that caching and branch prediction and the like make "constant time" implementations almost impossible.
No, it will add millisecond-accuracy jitter to the timing of your algorithm. And the attacker will continue to be able to extract microsecond-accuracy data from your timing attack. You need profoundly accurate hardware and a real-time operating system. Your attacker needs… more measurements.
Caching is equally unlikely to play a role. You're probably thinking of DJB's timing attacks on AES (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf), but that attack resolves around the timing of S-box lookups in which the index of the lookup is key-dependent. In the constant-time algorithm proposed by Nate Lawson and others, the only array lookup is the incremented value of a for loop (i.e., constant-time). The other operations are XOR and OR, both of which are constant-time.
Branch prediction doesn't come into play because a constant-time comparison doesn't involve conditionals until all the data has been compared.
A constant-time implementation of AES? Hard. A constant-time implementation of an array comparison? Dead simple.
Note that caching and branch prediction and the like make "constant time" implementations almost impossible.