[Xenomai-help] rt_task_sleep_until question

[Xenomai-help] rt_task_sleep_until question

[Klaas Gadeyne]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 867 bytes --]

Hi,

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?

Thx,

Klaas

[-- Attachment #2: Type: TEXT/x-csrc, Size: 1417 bytes --]

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>

#include <native/task.h>
#include <native/timer.h>

RT_TASK demo_task;
char stop_timer=0;
#define TIMEVAL_MAX ~(RTIME)0

void demo(void *arg)
{
  int ret; 
  int errors = 0;
  do{
    do{
      printf("current_time = %llu\n",rt_timer_read());
      printf("sleep until %llu\n", TIMEVAL_MAX);
    }while ((ret = rt_task_sleep_until(TIMEVAL_MAX)) == 0);
    //		if (ret == -ETIMEDOUT){
    printf("[TIMERLOOP] Total errors = %d, return code = %d\n",++errors,ret);
    // }
  }while (!(stop_timer && ret == -EINTR));
  printf("End of TimerLoop, code %d, Total errors = %d\n",ret,errors);
}

void catch_signal(int sig)
{
  stop_timer = 1;
  rt_task_unblock(&demo_task);
}

int main(int argc, char* argv[])
{
  signal(SIGTERM, catch_signal);
  signal(SIGINT, catch_signal);

  /* Avoids memory swapping for this program */
  mlockall(MCL_CURRENT|MCL_FUTURE);

  /*
   * Arguments: &task,
   *            name,
   *            stack size (0=default),
   *            priority,
   *            mode (FPU, start suspended, ...)
   */
  rt_task_create(&demo_task, "sleeping forever", 0, 50, 0);

  /*
   * Arguments: &task,
   *            task function,
   *            function argument
   */
  rt_task_start(&demo_task, &demo, NULL);

  pause();

  rt_task_delete(&demo_task);
}

Re: [Xenomai-help] rt_task_sleep_until question

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Klaas Gadeyne wrote:
> Hi,
> 
> 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?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] rt_task_sleep_until question

[klaas.gadeyne]

> 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.

More on monday.  Thx!

Klaas

[*]
<http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/timer.c?v=SVN-2.3.x#095>
<http://www.rts.uni-hannover.de/xenomai/lxr/source/include/asm-generic/system.h?v=SVN-2.3.x#174>

Re: [Xenomai-help] rt_task_sleep_until question

[Gilles Chanteperdrix]

klaas.gadeyne@domain.hid 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).

-- 


					    Gilles.

Re: [Xenomai-help] rt_task_sleep_until question

[Klaas Gadeyne]

On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
> klaas.gadeyne@domain.hid 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?

Klaas

[1] http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/native/task.c#921

Re: [Xenomai-help] rt_task_sleep_until question

[Gilles Chanteperdrix]

On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne <klaas.gadeyne@domain.hid> wrote:
>
> On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
>
> > klaas.gadeyne@domain.hid 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

Re: [Xenomai-help] rt_task_sleep_until question

[Gilles Chanteperdrix]

On Thu, Apr 17, 2008 at 5:30 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne <klaas.gadeyne@domain.hid> wrote:
>  >
>  > On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
>  >
>  > > klaas.gadeyne@domain.hid 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

Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Thu, Apr 17, 2008 at 5:30 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne <klaas.gadeyne@domain.hid> wrote:
>>  >
>>  > On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
>>  >
>>  > > klaas.gadeyne@domain.hid 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*.

This behaviour is explicitly stated in the doc, though. So people should not be
surprised.

>>  >
>>  >  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

No way. You don't want to change "magic" values that lightly. This is why they
are magic in the first place.

>>  >
>>  >  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.
> 

Aside of this, the API has to be orthogonal, and having rt_task_sleep behave as
rt_task_suspend is also counter-intuitive. Think about applications doing tick
arithmetics to determine the remaining sleep time; at some point, they might
hang unexpectedly with delay == 0 == TM_INFINITE.

-- 
Philippe.

Re: [Xenomai-help] rt_task_sleep_until question

[Gilles Chanteperdrix]

On Thu, Apr 17, 2008 at 6:07 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>
> Gilles Chanteperdrix wrote:
>  > 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.
>  >
>
>  Aside of this, the API has to be orthogonal, and having rt_task_sleep behave as
>  rt_task_suspend is also counter-intuitive. Think about applications doing tick
>  arithmetics to determine the remaining sleep time; at some point, they might
>  hang unexpectedly with delay == 0 == TM_INFINITE.

We agree, this is what I was trying to say.

-- 
 Gilles

Re: [Xenomai-help] rt_task_sleep_until question

[Klaas Gadeyne]

On Thu, 17 Apr 2008, Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> On Thu, Apr 17, 2008 at 5:30 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne <klaas.gadeyne@domain.hid> wrote:
>>> >
>>> > On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
>>> >
>>> >> klaas.gadeyne@domain.hid 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*.
>
> This behaviour is explicitly stated in the doc, though. So people should not be
> surprised.

That why I added the stuff between the long dashes above :-)  However, if
there's even one thing even better than well documented API's, it's
well documented _and_ intuitive APIs.

>>> >  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
>
> No way. You don't want to change "magic" values that lightly. This is why they
> are magic in the first place.

I know none of them were ideal solutions.  However (AFAIS, that is), 
* from a user point of view, I would find it convenient to be able to
   sleep indefinitely until somebody wakes me up using rt_task_unblock(),
   and this is currently not possible.
* the nucleus _does_ offer this functionality via the
   xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL)
   call, but I cannot access that functionality in the native skin.

So I was wondering if nothing (else) could be done to solve that
problem, the concrete use case being a thread which is woken up every
time a job has to be done, but which can safely sleep "forever" (until 
unblocked) if nothing has to be done.

[For those really interested, I ran into this situation debugging a
CanFestival setup on xenomai, see
<http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.64.0804141120410.11027%40ampere.labo01.fmtc.be&forum_name=canfestival-devel> ]

>>> >  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.
>>
>
> Aside of this, the API has to be orthogonal, and having rt_task_sleep behave as
> rt_task_suspend is also counter-intuitive. Think about applications doing tick
> arithmetics to determine the remaining sleep time; at some point, they might
> hang unexpectedly with delay == 0 == TM_INFINITE.

Didn't I mention "intuitive" somewhere above yet? ;-)

Thx,

Klaas

Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum]

Klaas Gadeyne wrote:
> On Thu, 17 Apr 2008, Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> On Thu, Apr 17, 2008 at 5:30 PM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On Thu, Apr 17, 2008 at 5:23 PM, Klaas Gadeyne
>>>> <klaas.gadeyne@domain.hid> wrote:
>>>> >
>>>> > On Sat, 12 Apr 2008, Gilles Chanteperdrix wrote:
>>>> >
>>>> >> klaas.gadeyne@domain.hid 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*.
>>
>> This behaviour is explicitly stated in the doc, though. So people
>> should not be
>> surprised.
> 
> That why I added the stuff between the long dashes above :-)  However, if
> there's even one thing even better than well documented API's, it's
> well documented _and_ intuitive APIs.
> 
>>>> >  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
>>
>> No way. You don't want to change "magic" values that lightly. This is
>> why they
>> are magic in the first place.
> 
> I know none of them were ideal solutions.  However (AFAIS, that is), *
> from a user point of view, I would find it convenient to be able to
>   sleep indefinitely until somebody wakes me up using rt_task_unblock(),
>   and this is currently not possible.
> * the nucleus _does_ offer this functionality via the
>   xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL)
>   call, but I cannot access that functionality in the native skin.
> 
> So I was wondering if nothing (else) could be done to solve that
> problem, the concrete use case being a thread which is woken up every
> time a job has to be done, but which can safely sleep "forever" (until
> unblocked) if nothing has to be done.
>

What's wrong with rt_task_suspend() ?

> [For those really interested, I ran into this situation debugging a
> CanFestival setup on xenomai, see
> <http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.64.0804141120410.11027%40ampere.labo01.fmtc.be&forum_name=canfestival-devel>
> ]
> 
>>>> >  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.
>>>
>>
>> Aside of this, the API has to be orthogonal, and having rt_task_sleep
>> behave as
>> rt_task_suspend is also counter-intuitive. Think about applications
>> doing tick
>> arithmetics to determine the remaining sleep time; at some point, they
>> might
>> hang unexpectedly with delay == 0 == TM_INFINITE.
> 
> Didn't I mention "intuitive" somewhere above yet? ;-)
> 
> Thx,
> 
> Klaas
> 
> 
> 
> 


-- 
Philippe.

Re: [Xenomai-help] rt_task_sleep_until question

[Klaas Gadeyne]

On Tue, 22 Apr 2008, Philippe Gerum wrote:
> Klaas Gadeyne wrote:

[snipping lots of context]
>>>>>>  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*.
>>>
>>> This behaviour is explicitly stated in the doc, though. So people
>>> should not be
>>> surprised.
>>
>> That why I added the stuff between the long dashes above :-)  However, if
>> there's even one thing even better than well documented API's, it's
>> well documented _and_ intuitive APIs.
>>
>>>>>>  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
>>>
>>> No way. You don't want to change "magic" values that lightly. This is
>>> why they
>>> are magic in the first place.
>>
>> I know none of them were ideal solutions.  However (AFAIS, that is), *
>> from a user point of view, I would find it convenient to be able to
>>   sleep indefinitely until somebody wakes me up using rt_task_unblock(),
>>   and this is currently not possible.
>> * the nucleus _does_ offer this functionality via the
>>   xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL)
>>   call, but I cannot access that functionality in the native skin.
>>
>> So I was wondering if nothing (else) could be done to solve that
>> problem, the concrete use case being a thread which is woken up every
>> time a job has to be done, but which can safely sleep "forever" (until
>> unblocked) if nothing has to be done.
>>
>
> What's wrong with rt_task_suspend() ?

The current loop code is something like

void timerloop_task_proc(void *arg)
{
         int ret;
         int errors = 0;
         do{
                 do{
                         last_occured_alarm = last_alarm_set;
                         EnterMutex();
                         TimeDispatch();
                         LeaveMutex();
                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
                 if (ret == -ETIMEDOUT){
                   printf("[TIMERLOOP] Total errors = %d, return code = %d\n",++errors,ret);
                 }
         }while (!(stop_timer && ret == -EINTR));
         printf("End of TimerLoop, code %d, Total errors = %d\n",ret,errors);
}

I could modify that code and put something like
if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
   rt_task_suspend()
else
   rt_task_sleep_until(last_alarm)

However, the one who wants to wake up this thread (e.g. for asking
this thread to stop) doesn't know in what state the timerthread is.
It seems clumsy to me if that the one who wants to wake up the thread
has to try _unblock() first, and the _resume()?

thx,

Klaas

ps.  Note that the original problem I sketched in this thread was due
to an overflow situation, and that this suggestion to allow to make a
thread *sleep* forever instead of suspending only tackles _my_
concrete problem, and doesn't solve the overflow issue.

Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum]

Klaas Gadeyne wrote:
> On Tue, 22 Apr 2008, Philippe Gerum wrote:
>> Klaas Gadeyne wrote:
> 
> [snipping lots of context]
>>>>>>>  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*.
>>>>
>>>> This behaviour is explicitly stated in the doc, though. So people
>>>> should not be
>>>> surprised.
>>>
>>> That why I added the stuff between the long dashes above :-) 
>>> However, if
>>> there's even one thing even better than well documented API's, it's
>>> well documented _and_ intuitive APIs.
>>>
>>>>>>>  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
>>>>
>>>> No way. You don't want to change "magic" values that lightly. This is
>>>> why they
>>>> are magic in the first place.
>>>
>>> I know none of them were ideal solutions.  However (AFAIS, that is), *
>>> from a user point of view, I would find it convenient to be able to
>>>   sleep indefinitely until somebody wakes me up using rt_task_unblock(),
>>>   and this is currently not possible.
>>> * the nucleus _does_ offer this functionality via the
>>>   xnpod_suspend_thread(thread,XNDELAY,XN_INFINITE,XN_RELATIVE,NULL)
>>>   call, but I cannot access that functionality in the native skin.
>>>
>>> So I was wondering if nothing (else) could be done to solve that
>>> problem, the concrete use case being a thread which is woken up every
>>> time a job has to be done, but which can safely sleep "forever" (until
>>> unblocked) if nothing has to be done.
>>>
>>
>> What's wrong with rt_task_suspend() ?
> 
> The current loop code is something like
> 
> void timerloop_task_proc(void *arg)
> {
>         int ret;
>         int errors = 0;
>         do{
>                 do{
>                         last_occured_alarm = last_alarm_set;
>                         EnterMutex();
>                         TimeDispatch();
>                         LeaveMutex();
>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>                 if (ret == -ETIMEDOUT){
>                   printf("[TIMERLOOP] Total errors = %d, return code =
> %d\n",++errors,ret);
>                 }
>         }while (!(stop_timer && ret == -EINTR));
>         printf("End of TimerLoop, code %d, Total errors =
> %d\n",ret,errors);
> }
> 
> I could modify that code and put something like
> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>   rt_task_suspend()
> else
>   rt_task_sleep_until(last_alarm)
> 
> However, the one who wants to wake up this thread (e.g. for asking
> this thread to stop) doesn't know in what state the timerthread is.
> It seems clumsy to me if that the one who wants to wake up the thread
> has to try _unblock() first, and the _resume()?
> 

There has been a fair amount of misunderstanding. Past mails were apparently
aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay etc.), but
you actually care for rt_task_sleep_until, which is a totally different story
(the subject line was right though).

Handling the special TM_INFINITE value as a valid timeout value for
rt_task_sleep_until would not introduce the flaws I was concerned about
regarding rt_task_sleep. We would just change the behaviour when receiving what
used to be an utterly bugous date spec in the current implementation, and make
it valid, which is ok -- i.e. I'm not particularly concerned by maintaining
backward compatible behaviours when receiving utterly insane data specs like "0"
for an absolute date.

If your loop was truly periodic, you could probably use rt_task_wait_period(),
but I suspect last_alarm may not try to enforce a strictly periodic timeline, right?

The fact that we don't have any other blocking calls with absolute date specs is
bothering me actually, and 2.5 will probably see some extensions like
rt_sem_p_until(), in order to address patterns of this kind.

But well, back to rt_task_sleep_until, I see no reason not to handle the corner
case you described a bit more gracefully. So let's try the Klaas Amendment to
the native API. Does the following work for you?

--- ksrc/skins/native/task.c	(revision 3713)
+++ ksrc/skins/native/task.c	(working copy)
@@ -958,8 +958,10 @@
  * reached.
  *
  * @param date The absolute date in clock ticks to wait before
- * resuming the task (see note). Passing an already elapsed date
- * causes the task to return immediately with no delay.
+ * resuming the task (see note). As a special case, TM_INFINITE is an
+ * acceptable value that makes the caller block indefinitely, until
+ * rt_task_unblock() is called against it. Otherwise, any wake up date
+ * in the past causes the task to return immediately with no delay.
  *
  * @return 0 is returned upon success. Otherwise:
  *
@@ -968,7 +970,8 @@
  *
  * - -ETIMEDOUT is returned if @a date has already elapsed.
  *
- * - -EWOULDBLOCK is returned if the system timer is inactive.
+ * - -EWOULDBLOCK is returned if the system timer is inactive, and
+ *    @date is valid but different from TM_INFINITE.
  *
  * - -EPERM is returned if this service was called from a context
  * which cannot sleep (e.g. interrupt, non-realtime or scheduler
@@ -990,8 +993,8 @@

 int rt_task_sleep_until(RTIME date)
 {
+	int err = 0, mode = XN_REALTIME;
 	xnthread_t *self;
-	int err = 0;
 	spl_t s;

 	if (xnpod_unblockable_p())
@@ -999,22 +1002,30 @@

 	self = xnpod_current_thread();

-	if (!xnthread_timed_p(self))
-		return -EWOULDBLOCK;
-
 	xnlock_get_irqsave(&nklock, s);

-	/* Calling the suspension service on behalf of the current task
-	   implicitely calls the rescheduling procedure. */
+	if (date == TM_INFINITE)
+		/* i.e. will resume only upon rt_task_unblock(). */
+		mode = XN_RELATIVE;
+	else if (date <= xntbase_get_time(__native_tbase)) {
+		err = -ETIMEDOUT;
+		goto unlock_and_exit;
+	} else if (!xnthread_timed_p(self)) {
+		err = -EWOULDBLOCK;
+		goto unlock_and_exit;
+	}

-	if (date > xntbase_get_time(__native_tbase)) {
-		xnpod_suspend_thread(self, XNDELAY, date, XN_REALTIME, NULL);
+	/*
+	 * Calling the suspension service on behalf of the current
+	 * task implicitely calls the rescheduling procedure.
+	 */
+	xnpod_suspend_thread(self, XNDELAY, date, mode, NULL);

-		if (xnthread_test_info(self, XNBREAK))
-			err = -EINTR;
-	} else
-		err = -ETIMEDOUT;
+	if (xnthread_test_info(self, XNBREAK))
+		err = -EINTR;

+ unlock_and_exit:
+
 	xnlock_put_irqrestore(&nklock, s);

 	return err;

-- 
Philippe.

Re: [Xenomai-help] rt_task_sleep_until question

[Klaas Gadeyne]

On Tue, 22 Apr 2008, Philippe Gerum wrote:

[snipping even more context]

>>> What's wrong with rt_task_suspend() ?
>>
>> The current loop code is something like
>>
>> void timerloop_task_proc(void *arg)
>> {
>>         int ret;
>>         int errors = 0;
>>         do{
>>                 do{
>>                         last_occured_alarm = last_alarm_set;
>>                         EnterMutex();
>>                         TimeDispatch();
>>                         LeaveMutex();
>>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>>                 if (ret == -ETIMEDOUT){
>>                   printf("[TIMERLOOP] Total errors = %d, return code =
>> %d\n",++errors,ret);
>>                 }
>>         }while (!(stop_timer && ret == -EINTR));
>>         printf("End of TimerLoop, code %d, Total errors =
>> %d\n",ret,errors);
>> }
>>
>> I could modify that code and put something like
>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>>   rt_task_suspend()
>> else
>>   rt_task_sleep_until(last_alarm)
>>
>> However, the one who wants to wake up this thread (e.g. for asking
>> this thread to stop) doesn't know in what state the timerthread is.
>> It seems clumsy to me if that the one who wants to wake up the thread
>> has to try _unblock() first, and the _resume()?
>>
>
> There has been a fair amount of misunderstanding. Past mails were apparently
> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay etc.), but
> you actually care for rt_task_sleep_until, which is a totally different story
> (the subject line was right though).

Sorry about that, during the debugging I ended up playing around with
rt_task_sleep() to check if the overflow issues did occur there too.

> Handling the special TM_INFINITE value as a valid timeout value for
> rt_task_sleep_until would not introduce the flaws I was concerned about
> regarding rt_task_sleep. We would just change the behaviour when receiving what
> used to be an utterly bugous date spec in the current implementation, and make
> it valid, which is ok -- i.e. I'm not particularly concerned by maintaining
> backward compatible behaviours when receiving utterly insane data specs like "0"
> for an absolute date.
>
> If your loop was truly periodic, you could probably use rt_task_wait_period(),
> but I suspect last_alarm may not try to enforce a strictly periodic timeline, right?
>
> The fact that we don't have any other blocking calls with absolute date specs is
> bothering me actually, and 2.5 will probably see some extensions like
> rt_sem_p_until(), in order to address patterns of this kind.
>
> But well, back to rt_task_sleep_until, I see no reason not to handle the corner
> case you described a bit more gracefully. So let's try the Klaas Amendment to
> the native API.

I *really* like the way that sounds ;-)

> Does the following work for you?

[snipped patch]

It does!  Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03 kernel.
Any chance this could still be merged in the 2.4 series?

Thx for your patience!

Klaas

Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum]

Klaas Gadeyne wrote:
> On Tue, 22 Apr 2008, Philippe Gerum wrote:
> 
> [snipping even more context]
> 
>>>> What's wrong with rt_task_suspend() ?
>>>
>>> The current loop code is something like
>>>
>>> void timerloop_task_proc(void *arg)
>>> {
>>>         int ret;
>>>         int errors = 0;
>>>         do{
>>>                 do{
>>>                         last_occured_alarm = last_alarm_set;
>>>                         EnterMutex();
>>>                         TimeDispatch();
>>>                         LeaveMutex();
>>>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>>>                 if (ret == -ETIMEDOUT){
>>>                   printf("[TIMERLOOP] Total errors = %d, return code =
>>> %d\n",++errors,ret);
>>>                 }
>>>         }while (!(stop_timer && ret == -EINTR));
>>>         printf("End of TimerLoop, code %d, Total errors =
>>> %d\n",ret,errors);
>>> }
>>>
>>> I could modify that code and put something like
>>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>>>   rt_task_suspend()
>>> else
>>>   rt_task_sleep_until(last_alarm)
>>>
>>> However, the one who wants to wake up this thread (e.g. for asking
>>> this thread to stop) doesn't know in what state the timerthread is.
>>> It seems clumsy to me if that the one who wants to wake up the thread
>>> has to try _unblock() first, and the _resume()?
>>>
>>
>> There has been a fair amount of misunderstanding. Past mails were
>> apparently
>> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay
>> etc.), but
>> you actually care for rt_task_sleep_until, which is a totally
>> different story
>> (the subject line was right though).
> 
> Sorry about that, during the debugging I ended up playing around with
> rt_task_sleep() to check if the overflow issues did occur there too.
> 
>> Handling the special TM_INFINITE value as a valid timeout value for
>> rt_task_sleep_until would not introduce the flaws I was concerned about
>> regarding rt_task_sleep. We would just change the behaviour when
>> receiving what
>> used to be an utterly bugous date spec in the current implementation,
>> and make
>> it valid, which is ok -- i.e. I'm not particularly concerned by
>> maintaining
>> backward compatible behaviours when receiving utterly insane data
>> specs like "0"
>> for an absolute date.
>>
>> If your loop was truly periodic, you could probably use
>> rt_task_wait_period(),
>> but I suspect last_alarm may not try to enforce a strictly periodic
>> timeline, right?
>>
>> The fact that we don't have any other blocking calls with absolute
>> date specs is
>> bothering me actually, and 2.5 will probably see some extensions like
>> rt_sem_p_until(), in order to address patterns of this kind.
>>
>> But well, back to rt_task_sleep_until, I see no reason not to handle
>> the corner
>> case you described a bit more gracefully. So let's try the Klaas
>> Amendment to
>> the native API.
> 
> I *really* like the way that sounds ;-)
> 
>> Does the following work for you?
> 
> [snipped patch]
> 
> It does!  Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03 kernel.
> Any chance this could still be merged in the 2.4 series?
> 

Since this does not change the behaviour of documented and valid use cases, I
will merge that patch into 2.4.4.

> Thx for your patience!
>

You are welcome.

> Klaas
> 
> 


-- 
Philippe.

Re: [Xenomai-help] rt_task_sleep_until question

[Bosko Radivojevic]

Are there any differences (in performance point of view) between using
rt_task_sleep_until (TM_INFINITE) + rt_task_unblock() and
rt_task_suspend() + rt_task_resume() ? I'm writting some kind of task
manager and I'm using suspend + resume combination.

On Wed, Apr 23, 2008 at 1:37 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>
> Klaas Gadeyne wrote:
>  > On Tue, 22 Apr 2008, Philippe Gerum wrote:
>  >
>  > [snipping even more context]
>  >
>  >>>> What's wrong with rt_task_suspend() ?
>  >>>
>  >>> The current loop code is something like
>  >>>
>  >>> void timerloop_task_proc(void *arg)
>  >>> {
>  >>>         int ret;
>  >>>         int errors = 0;
>  >>>         do{
>  >>>                 do{
>  >>>                         last_occured_alarm = last_alarm_set;
>  >>>                         EnterMutex();
>  >>>                         TimeDispatch();
>  >>>                         LeaveMutex();
>  >>>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>  >>>                 if (ret == -ETIMEDOUT){
>  >>>                   printf("[TIMERLOOP] Total errors = %d, return code =
>  >>> %d\n",++errors,ret);
>  >>>                 }
>  >>>         }while (!(stop_timer && ret == -EINTR));
>  >>>         printf("End of TimerLoop, code %d, Total errors =
>  >>> %d\n",ret,errors);
>  >>> }
>  >>>
>  >>> I could modify that code and put something like
>  >>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>  >>>   rt_task_suspend()
>  >>> else
>  >>>   rt_task_sleep_until(last_alarm)
>  >>>
>  >>> However, the one who wants to wake up this thread (e.g. for asking
>  >>> this thread to stop) doesn't know in what state the timerthread is.
>  >>> It seems clumsy to me if that the one who wants to wake up the thread
>  >>> has to try _unblock() first, and the _resume()?
>  >>>
>  >>
>  >> There has been a fair amount of misunderstanding. Past mails were
>  >> apparently
>  >> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay
>  >> etc.), but
>  >> you actually care for rt_task_sleep_until, which is a totally
>  >> different story
>  >> (the subject line was right though).
>  >
>  > Sorry about that, during the debugging I ended up playing around with
>  > rt_task_sleep() to check if the overflow issues did occur there too.
>  >
>  >> Handling the special TM_INFINITE value as a valid timeout value for
>  >> rt_task_sleep_until would not introduce the flaws I was concerned about
>  >> regarding rt_task_sleep. We would just change the behaviour when
>  >> receiving what
>  >> used to be an utterly bugous date spec in the current implementation,
>  >> and make
>  >> it valid, which is ok -- i.e. I'm not particularly concerned by
>  >> maintaining
>  >> backward compatible behaviours when receiving utterly insane data
>  >> specs like "0"
>  >> for an absolute date.
>  >>
>  >> If your loop was truly periodic, you could probably use
>  >> rt_task_wait_period(),
>  >> but I suspect last_alarm may not try to enforce a strictly periodic
>  >> timeline, right?
>  >>
>  >> The fact that we don't have any other blocking calls with absolute
>  >> date specs is
>  >> bothering me actually, and 2.5 will probably see some extensions like
>  >> rt_sem_p_until(), in order to address patterns of this kind.
>  >>
>  >> But well, back to rt_task_sleep_until, I see no reason not to handle
>  >> the corner
>  >> case you described a bit more gracefully. So let's try the Klaas
>  >> Amendment to
>  >> the native API.
>  >
>  > I *really* like the way that sounds ;-)
>  >
>  >> Does the following work for you?
>  >
>  > [snipped patch]
>  >
>  > It does!  Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03 kernel.
>  > Any chance this could still be merged in the 2.4 series?
>  >
>
>  Since this does not change the behaviour of documented and valid use cases, I
>  will merge that patch into 2.4.4.
>
>  > Thx for your patience!
>  >
>
>  You are welcome.
>
>  > Klaas
>  >
>  >
>
>
>  --
>  Philippe.
>
>
>
>  _______________________________________________
>  Xenomai-help mailing list
>  Xenomai-help@domain.hid
>  https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum]

Bosko Radivojevic wrote:
> Are there any differences (in performance point of view) between using
> rt_task_sleep_until (TM_INFINITE) + rt_task_unblock() and
> rt_task_suspend() + rt_task_resume() ? I'm writting some kind of task
> manager and I'm using suspend + resume combination.
>

Internally, this boils down to running the same code.

> On Wed, Apr 23, 2008 at 1:37 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Klaas Gadeyne wrote:
>>  > On Tue, 22 Apr 2008, Philippe Gerum wrote:
>>  >
>>  > [snipping even more context]
>>  >
>>  >>>> What's wrong with rt_task_suspend() ?
>>  >>>
>>  >>> The current loop code is something like
>>  >>>
>>  >>> void timerloop_task_proc(void *arg)
>>  >>> {
>>  >>>         int ret;
>>  >>>         int errors = 0;
>>  >>>         do{
>>  >>>                 do{
>>  >>>                         last_occured_alarm = last_alarm_set;
>>  >>>                         EnterMutex();
>>  >>>                         TimeDispatch();
>>  >>>                         LeaveMutex();
>>  >>>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>>  >>>                 if (ret == -ETIMEDOUT){
>>  >>>                   printf("[TIMERLOOP] Total errors = %d, return code =
>>  >>> %d\n",++errors,ret);
>>  >>>                 }
>>  >>>         }while (!(stop_timer && ret == -EINTR));
>>  >>>         printf("End of TimerLoop, code %d, Total errors =
>>  >>> %d\n",ret,errors);
>>  >>> }
>>  >>>
>>  >>> I could modify that code and put something like
>>  >>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>>  >>>   rt_task_suspend()
>>  >>> else
>>  >>>   rt_task_sleep_until(last_alarm)
>>  >>>
>>  >>> However, the one who wants to wake up this thread (e.g. for asking
>>  >>> this thread to stop) doesn't know in what state the timerthread is.
>>  >>> It seems clumsy to me if that the one who wants to wake up the thread
>>  >>> has to try _unblock() first, and the _resume()?
>>  >>>
>>  >>
>>  >> There has been a fair amount of misunderstanding. Past mails were
>>  >> apparently
>>  >> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay
>>  >> etc.), but
>>  >> you actually care for rt_task_sleep_until, which is a totally
>>  >> different story
>>  >> (the subject line was right though).
>>  >
>>  > Sorry about that, during the debugging I ended up playing around with
>>  > rt_task_sleep() to check if the overflow issues did occur there too.
>>  >
>>  >> Handling the special TM_INFINITE value as a valid timeout value for
>>  >> rt_task_sleep_until would not introduce the flaws I was concerned about
>>  >> regarding rt_task_sleep. We would just change the behaviour when
>>  >> receiving what
>>  >> used to be an utterly bugous date spec in the current implementation,
>>  >> and make
>>  >> it valid, which is ok -- i.e. I'm not particularly concerned by
>>  >> maintaining
>>  >> backward compatible behaviours when receiving utterly insane data
>>  >> specs like "0"
>>  >> for an absolute date.
>>  >>
>>  >> If your loop was truly periodic, you could probably use
>>  >> rt_task_wait_period(),
>>  >> but I suspect last_alarm may not try to enforce a strictly periodic
>>  >> timeline, right?
>>  >>
>>  >> The fact that we don't have any other blocking calls with absolute
>>  >> date specs is
>>  >> bothering me actually, and 2.5 will probably see some extensions like
>>  >> rt_sem_p_until(), in order to address patterns of this kind.
>>  >>
>>  >> But well, back to rt_task_sleep_until, I see no reason not to handle
>>  >> the corner
>>  >> case you described a bit more gracefully. So let's try the Klaas
>>  >> Amendment to
>>  >> the native API.
>>  >
>>  > I *really* like the way that sounds ;-)
>>  >
>>  >> Does the following work for you?
>>  >
>>  > [snipped patch]
>>  >
>>  > It does!  Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03 kernel.
>>  > Any chance this could still be merged in the 2.4 series?
>>  >
>>
>>  Since this does not change the behaviour of documented and valid use cases, I
>>  will merge that patch into 2.4.4.
>>
>>  > Thx for your patience!
>>  >
>>
>>  You are welcome.
>>
>>  > Klaas
>>  >
>>  >
>>
>>
>>  --
>>  Philippe.
>>
>>
>>
>>  _______________________________________________
>>  Xenomai-help mailing list
>>  Xenomai-help@domain.hid
>>  https://mail.gna.org/listinfo/xenomai-help
>>
> 


-- 
Philippe.

[Xenomai-help] Recurring Interrupts

[Henry Bausley]

How do I setup xenomai so that my ISR can be re-entered even if I am 
currently in it.

I have an external edge interrupt wired and it occurs every 250usec.  There 
are instances
when the interrupt can occur while I am currently in my ISR.

If another interrupt occurs while I am currently in my ISR I want my ISR to 
be called again
so I can flag that the condition occurred then exit the re-entered ISR and 
continue executing
the originally called ISR.


I am using a board based off the AMCC 440EP Yosemite and a Denx Kit with 
2.6.24 and Xenomai 2.4.2
This something I did with previously with RT Linux.  I have converted a 
large project from FSM RT Linux
to Xenomai and everything is functioning except this last item.

Re: [Xenomai-help] Recurring Interrupts

[Philippe Gerum]

Henry Bausley wrote:
> How do I setup xenomai so that my ISR can be re-entered even if I am 
> currently in it.
>

Try this:

int your_isr(xnintr_t *intr)
{
	unsigned long flags;

	xnlock_clear_irqon(&nklock);

	... your code ...

	xnlock_get_irqsave(&nklock, flags); /* must re-lock on exit */
}

We do take a per-IRQ lock internally as well, but this is a no-brainer for the
issue at stake.

NOTE: this solution is only valid in uniprocessor mode. SMP would run into
deadlocks; we would need to provide internal support to allow this.

> I have an external edge interrupt wired and it occurs every 250usec.  There 
> are instances
> when the interrupt can occur while I am currently in my ISR.
> 
> If another interrupt occurs while I am currently in my ISR I want my ISR to 
> be called again
> so I can flag that the condition occurred then exit the re-entered ISR and 
> continue executing
> the originally called ISR.
> 
> 
> I am using a board based off the AMCC 440EP Yosemite and a Denx Kit with 
> 2.6.24 and Xenomai 2.4.2
> This something I did with previously with RT Linux.  I have converted a 
> large project from FSM RT Linux
> to Xenomai and everything is functioning except this last item.
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
Philippe.

Re: [Xenomai-help] Recurring Interrupts

[Philippe Gerum]

Philippe Gerum wrote:
> Henry Bausley wrote:
>> How do I setup xenomai so that my ISR can be re-entered even if I am 
>> currently in it.
>>
> 
> Try this:
> 

The following is needed to allow the same interrupt to recurse as well.

> int your_isr(xnintr_t *intr)
> {
> 	unsigned long flags;
>

+	xnintr_enable(intr);

> 	xnlock_clear_irqon(&nklock);
> 
> 	... your code ...
> 
> 	xnlock_get_irqsave(&nklock, flags); /* must re-lock on exit */

+	return XN_ISR_HANDLED | XN_ISR_NOENABLE;
> }

> 
> We do take a per-IRQ lock internally as well, but this is a no-brainer for the
> issue at stake.
> 
> NOTE: this solution is only valid in uniprocessor mode. SMP would run into
> deadlocks; we would need to provide internal support to allow this.
> 
>> I have an external edge interrupt wired and it occurs every 250usec.  There 
>> are instances
>> when the interrupt can occur while I am currently in my ISR.
>>
>> If another interrupt occurs while I am currently in my ISR I want my ISR to 
>> be called again
>> so I can flag that the condition occurred then exit the re-entered ISR and 
>> continue executing
>> the originally called ISR.
>>
>>
>> I am using a board based off the AMCC 440EP Yosemite and a Denx Kit with 
>> 2.6.24 and Xenomai 2.4.2
>> This something I did with previously with RT Linux.  I have converted a 
>> large project from FSM RT Linux
>> to Xenomai and everything is functioning except this last item.
>>
>>
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
> 
> 


-- 
Philippe.