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
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to