On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne <[EMAIL PROTECTED]> wrote: > > On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote: > > > [EMAIL PROTECTED] wrote: > > > > Klaas Gadeyne wrote: > > > >> I've noticed that threads which, in my ignorant opinion, are supposed > > > >> to be sleeping, get woken up much earlier than I expect them to be. > > > >> > > > >> Please find attached a modified version of the trivial-periodic.c > > > >> application, which creates a RT_TASK that should sleep as long as > > > >> possible (i.e. until unblocked by a signal handler). However, the > > > >> task gets woken up much earlier (and many times) _before_ that time > it > > > >> seems. > > > >> > > > >> head /tmp/app.txt > > > >> current_time = 1207928393295939429 > > > >> sleep until 18446744073709551615 > > > >> [TIMERLOOP] Total errors = 1, return code = -110 > > > >> current_time = 1207928393296000379 > > > >> sleep until 18446744073709551615 > > > >> [TIMERLOOP] Total errors = 2, return code = -110 > > > >> current_time = 1207928393296005409 > > > >> sleep until 18446744073709551615 > > > >> [TIMERLOOP] Total errors = 3, return code = -110 > > > >> current_time = 1207928393296009604 > > > >> > > > >> What did I overlook here? > > > > > > > > Probably an overflow issue: (RTIME)~0 will be converted to TSCs, and > if > > > > your box runs at > 1GHZ, the result of this conversion will by > something > > > > < (RTIME)~0 due to the overflow. And this can result in an absolute > > > > timeout date (in TSC units) before the current date -> ETIMEDOUT. Can > > > > you confirm this? > > > > > > I have no linux box at hand, but I noticed that [*] > > > xntimer_do_start_aperiodic() passes its xnticks_t interval argument > (which > > > is an unsigned long long) to xnarch_ns_to_tsc, and that one expects a > > > (signed) long long. > > > > > > If I did not make any calculation errors (a very small chance...) in > "my" > > > case "interval" > LLONG_MAX so there's already an overflow there. > > > > The problem is that we can not change xnarch_ns_to_tsc to use > > xnarch_ullimd instead of xnarch_llimd: xnarch_ns_to_tsc may be used to > > convert negative differences. Anyway, I do not think there is an > > overflow in llimd, otherwise you would get a processor exception, not a > > silent truncation (at least on x86). To solve this issue, we should > > probably switch to saturation arithmetic, but it would probably have a > > huge impact on performance (and on code also, since we would have to use > > xnarch_saturated_add(foo, bar) instead of foo + bar). > > > > I see. > > I noticed that xnpod_suspend_thread offers the possibility to suspend > a thread "indefinitely" (until unblocked) via the (in the 2.4.x API, > that is) > > xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL) > > call. > However, since TM_INFINITE (and XN_INFINITE) are both defined as being > zero, calls to rt_task_sleep(TM_INFINITE), are intercepted in the > implementation of rt_task_sleep [1]. So in the latter case (which I > would naively---i.e. without looking at API docs--- read as "sleep for > an infinite amount of time), rt_task_sleep() returns *immediately*. > > Would it make sense to change the current behaviour of > rt_task_sleep(TM_INFINITE) and call > xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL) > instead of returning 0? > > One could either do that by > - altering rt_task_sleep()'s behaviour (not returning zero if delay is > zero) > - redefining TM_INFINITE > > Both changes might "break" existing applications however. > > Any thoughts?
Well, I do not see how applications could find a useful use of the "rt_task_sleep(0) returns 0 immediately" behaviour. Another useful use of rt_task_sleep(0) could have been to yield processor, like vxworks does, but there is already an rt_task_yield() service for this. -- Gilles _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
