On Fri, 2006-07-21 at 15:39 +0200, ROSSIER Daniel wrote: > > -----Message d'origine----- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > > la part de Philippe Gerum > > Envoyé : vendredi, 21. juillet 2006 15:16 > > À : Daniel Simon > > Cc : [email protected] > > Objet : Re: [Xenomai-help] Priority inversion > > > > On Fri, 2006-07-21 at 14:51 +0200, Daniel Simon wrote: > > > On Fri, 21 Jul 2006 14:12:47 +0200 > > > "ROSSIER Daniel" <[EMAIL PROTECTED]> wrote: > > > > > > > but it might be at the spin() level. > > > > > > I have observed that the behaviour of rt_timer_spin() does not fit with > > > the expected behaviour as described in the doxygened comment: its actual > > > awakening time do not increase when it is preempted. > > > > > > According to the code in timer.c (using 2.1.2) the wakening time seems > > > to be computed once for all at the beginning of the function call. > > > > > > Am I right? > > > > > > > Yes. But nothing is said in the documentation about the determination of > > the end spinning time, so the doc is right; what it says is that your > > task is going to wait for a certain count of nanoseconds, as seen from > > its own POV, it does not say that only cycles spent in actual spinning > > wait on behalf of the caller should be accounted for. Fact is that the > > task will have waited for a certain amount of time before returning, > > what has occurred in the rest of the system during that period is > > irrelevant to the purpose of rt_task_spin(). > > > > I guess that your interpretation of the behaviour of your application > > has been wrong due to the non-cumulative aspect of rt_timer_spin(), i.e. > > a first spinning interrupted by a second one will exit immediately upon > > return if the initial end time has been reached, because of the second > > spin time. But in any case, this is an expected behaviour. > > Yes, that's definitively the point; and again, sorry for the mishap with the > mutex/sema, which actually perfectly works :-) > > Back to rt_timer_spin(), in other words, does it mean that there is a kind of > global counter used by this function that evolves over the different tasks > when rt_timer_spin() is used, or something like this (no notion of virtual > task time)? >
rt_task_spin() relies on the free running counter provided by the hw platform, e.g. the TSC on x86. Therefore, on x86 this value is local to the current CPU, but global to any thread executed by this CPU. rt_task_spin() is basically aimed at providing fine grained and short delays for synchronizing with hardware ops without involving any rescheduling. Xenomai only use real time references, never virtual ones. However, runtime accounting data are available since v2.2, giving the percentage of CPU used by any given task (see /proc/xenomai/stat), which is the only virtual time information available so far, but never used to specify timings though. > > > > > Daniel > > > > > -- > > Philippe. > > > > > > > > _______________________________________________ > > Xenomai-help mailing list > > [email protected] > > https://mail.gna.org/listinfo/xenomai-help -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
