Subj : Re: NPTL, linuxthreads, and posix periodic timers (time shift) To : comp.programming.threads From : David Schwartz Date : Wed Jan 05 2005 09:46 am "stéphane SARAGAGLIA" wrote in message news:41dbc1b0$0$27146$8fcfb975@news.wanadoo.fr... > David Schwartz wrote: > >>>I would like to use NPTL, but the results displayed by DISPLAY2 are >>>alarming me... >>>I have tried using 2.6.7 and 2.6.9 kernels, and I obtain the same >>>results... >> >> I think you're trying to rely on something that's not guaranteed. >> >>>Why such a difference between 2.6 and 2.4 kernel ? >> >> Because you're relying on something that's not guaranteed, so nobody >> cares if it changes. > > Ok. So what is guaranteed ? The fact that the timer event will occur AT > LEAST AFTER the it_interval value specified ? Never less than it_interval > value ? I believe so. However, it would be sensible to tolerate slightly less if possible. It may be that all that's guarantee is best effort, and the implementation may be allowed to get closer to the requested time by firing the timer first. >>>Are posix timers not suitable to my needs ? >> >> They are not suitable as they are coded. You should wrap them with >> code that provides the precise guarantees that you require. > > I am surprised there is no easy way to set up a periodic timer whose goal > is to be consistent to start tick. > How would you wrap posix timers ? By starting a one shot timer, then > reading the overrun time and starting another one shorter ? When a timer fires, compute how long until the next timer should fire (based upon a suitable clock) and set the timer for that long. The problem is, what clock is suitable? What do you want to happen if the system clock jumps ahead 3 seconds? You probably don't totally realize it yet, but you've stumbled on a very complex question. And different applications have different timing requirements. POSIX doesn't know what you want and it can't provide it without knowing. So you'll have to code exactly what you want based upon the requirements that you have. You may want to use a thread to fire every so often and double-check the system clock. If it remains sane and stable, continue to use it as the base for your timer calculations. If it jumps forward or backward, set a flag and then reset your timer logic. Or you can just bracket it each time -- if you want a timer every 300 milliseconds, and you compute 2900 milliseconds to the next timer, probably just make it 300, but if it's between 100 and 600, it's probably right. It really depends upon your precise requirements. For example, some people care a lot that over a very long term the right number of timers fire. This may require reducing the firing interval if you discover that over the last time interval, too few timers fired. If the time jumps forward a minute and you missed many timers, do you want to fire them all at once? Or do you want to speed up the timers to catch up? Or do you just want to forget them? You would want to forget them if it's important that the timers have the interval right (say because they're commanding an external device) rather than that there is the right number of them. DS .