Philippe Gerum wrote: > On Sun, 2006-09-17 at 13:54 +0200, Jan Kiszka wrote: > > Hi, > > > > reading through timer code of Xenomai I just wondered (again) what our > > official model of TSCs on multiprocessor boxes are: > > > > 1) (practically) perfectly synchronised without offset > > > > 2) synchronised but with (unknown?) offset > > > > 3) unsynchronised > > The current model is unsynchronized. If anything from the codebase is > found relying on the opposite, be it partially or fully, then it's > utterly broken in the SMP case, and I'm likely the one to blame. > IOW, we don't currently provide any guarantee to anyone that a timestamp > could be interpreted anywhere else than the CPU it was read from, and > leave all the related burden to the application developer (e.g. by mean > of managing CPU affinity constraints and the like).
I think xntimer_set_sched assumes some continuity, since it reenqueues on a different CPU a timer whose date has been set up on one cpu. If we wanted strict unsynchronized tsc, we would have to : - compute the difference between the current date and the timer date - enqueue the timer on a migration queue - send an IPI to the distant CPU - on the distant CPU, iterate over the migration queue, recompute the expiration dates and reenqueue the timers. -- Gilles Chanteperdrix. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core