On Thu, Apr 17, 2008 at 5:30 PM, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote: > > 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.
Thinking more about it: there is a useful use, if the sleep duration is the result of rt_time_tsc2ns. Sleeping indefinitely would be a bit counter-intuitive. -- Gilles _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
