[Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

Hi,

I've compiled a previously 100% working application under the new 2.4.0 
release and found the following issues:


1- rt_task_set_periodic does not work sometimes?

In this application I have a periodic task (250ms period) which is used 
to blink some lights. The blinking is occasionally resynchronized to 
some external event, and this is what I do:

In the periodic task:

blink_count = 0;
rt_task_set_periodic();
for (;;) {
    whatever();
    blink_count = (blink_count + 1) & 3;
    rt_task_wait_period();
}

Some somewhere else, when I want to synchronize the blinking:

    blink_count = 0;
    rt_task_set_periodic();

This has worked perfectly until version 2.4.0. It seems that further 
calls to rt_task_set_periodic (from a different task) break the 
periodicity (the periodic task enters rt_task_wait_period() and never 
leaves again).

Any clues?



2- ENOBUFS error in rt_pipe_read upon userland close of the pipe.

This is weird and I still have to investigate it further. When the 
userland program closes the pipe, the RT kernel module gets a ENOBUFS 
error from rt_pipe_read.

Any clues?



Thanks.

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

Ignacio García Pérez escribió:

Ok, replying myself with further findings:

It turns out that the following code miserably fails to set the thread 
periodic:

rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250));

Where this actually works:

rt_task_set_periodic(&_blink_thread, TM_NOW, mili2count(250));

Which makes me think that rt_task_set_periodic() fails when the passed 
idate is in the past.

And you may say: why the hell do you use rt_timer_read() when you can 
use TM_NOW ???

Well, I think that rt_task_set_periodic should word (AND DID) both ways, 
but actually I have a very good reason to (sometimes) use an idate in 
the past: I want the blinking synchronized to the "event" as closely as 
possible. If there is a delay D from my recorded time for the event to 
the actual call to rt_task_set_periodic, I can:

a) Use rt_task_set_periodic(TM_NOD)

b) Use rt_task_set_periodic(recorded_time)

In the first case there will be a delay of D from every period to the 
"event", while in the second case that delay will be only in the FIRST 
execution of the periodic task.

Anyway, something is truly screwed up when 
rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250)) 
fails to make the task periodic...

> Hi,
>
> I've compiled a previously 100% working application under the new 2.4.0 
> release and found the following issues:
>
>
> 1- rt_task_set_periodic does not work sometimes?
>
> In this application I have a periodic task (250ms period) which is used 
> to blink some lights. The blinking is occasionally resynchronized to 
> some external event, and this is what I do:
>
> In the periodic task:
>
> blink_count = 0;
> rt_task_set_periodic();
> for (;;) {
>     whatever();
>     blink_count = (blink_count + 1) & 3;
>     rt_task_wait_period();
> }
>
> Some somewhere else, when I want to synchronize the blinking:
>
>     blink_count = 0;
>     rt_task_set_periodic();
>
> This has worked perfectly until version 2.4.0. It seems that further 
> calls to rt_task_set_periodic (from a different task) break the 
> periodicity (the periodic task enters rt_task_wait_period() and never 
> leaves again).
>
> Any clues?
>   

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Jan Kiszka]

Ignacio García Pérez wrote:
> Ignacio García Pérez escribió:
> 
> Ok, replying myself with further findings:
> 
> It turns out that the following code miserably fails to set the thread 
> periodic:
> 
> rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250));
> 
> Where this actually works:
> 
> rt_task_set_periodic(&_blink_thread, TM_NOW, mili2count(250));
> 
> Which makes me think that rt_task_set_periodic() fails when the passed 
> idate is in the past.
> 
> And you may say: why the hell do you use rt_timer_read() when you can 
> use TM_NOW ???
> 
> Well, I think that rt_task_set_periodic should word (AND DID) both ways, 
> but actually I have a very good reason to (sometimes) use an idate in 
> the past: I want the blinking synchronized to the "event" as closely as 
> possible. If there is a delay D from my recorded time for the event to 
> the actual call to rt_task_set_periodic, I can:
> 
> a) Use rt_task_set_periodic(TM_NOD)
> 
> b) Use rt_task_set_periodic(recorded_time)
> 
> In the first case there will be a delay of D from every period to the 
> "event", while in the second case that delay will be only in the FIRST 
> execution of the periodic task.
> 
> Anyway, something is truly screwed up when 
> rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250)) 
> fails to make the task periodic...

That's due to the reworked timer subsystem: Starting timers (like the
periodic task timer) in the past is reported as error - up to the
application in this case. One may discuss if this case can be considered
as an undocumented API change (I haven't re-read the docs in this regard
yet).

However, what about this to resolve your issue:

while start_date < now()
	start_date += period

Of course you can write this more smartly than using a loop (e.g. if you
know that already start_date + period > now()).

Jan


-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

>> Anyway, something is truly screwed up when 
>> rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250)) 
>> fails to make the task periodic...
>>     
>
> That's due to the reworked timer subsystem: Starting timers (like the
> periodic task timer) in the past is reported as error - up to the
> application in this case. One may discuss if this case can be considered
> as an undocumented API change (I haven't re-read the docs in this regard
> yet).
>   
At least the rt_task_set_periodic documenations says nothing about it.

I don't know about the timer subsystem, but from the native API point of 
view, the behaviour that makes most sense is the old, that is, if I set 
a task periodic with a start time in the past, it should be scheduled 
immediately.

I hope there is a very good reason for this behaviour change, because I 
bet it is going to cause a lot of headaches to a lot of people.

For example, in a code like this:

rt_task_set_periodic(&mytask, some_time_in_the_near_future, mili2count(100))

There is always a chance that "some_time_in_the_future" is in the past 
by the time the call to rt_task_set_periodic is called (due to this task 
being delayed by some higher priority task).

WHAT am I supposed to do, check the result of each an every 
rt_task_set_periodic call???

It is clearly a case of "*better later than never*". I'd rather have the 
periodic task start scheduled a bit late than not scheduled at all.

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

Jan Kiszka escribió:
> That's due to the reworked timer subsystem: Starting timers (like the
> periodic task timer) in the past is reported as error - up to the
> application in this case. One may discuss if this case can be considered
> as an undocumented API change (I haven't re-read the docs in this regard
> yet).
>   
I correct myself. The API actually states that the -ETIMEDOUT error code 
will be return if passed idate is in the past. But that is true for the 
2.3.x series and for the new 2.4.0 version.

Which means that the true difference between 2.3.x and 2.4.0 is that:

2.3.x: returns -ETIMEDOUT but schedules the task for immediate execution.

2.4.0: returns -ETIMEDOUT and *does not* schedule the task for immediate 
execution.

The more I think about it the mode I think this is a bug.

I just can't think of a situation in which idate is in the past and it 
makes sense *not scheduling* the task for immediate execution...

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Gilles Chanteperdrix]

On Dec 11, 2007 2:16 PM, Ignacio García Pérez <iggarpe@domain.hid> wrote:
> Jan Kiszka escribió:
> > That's due to the reworked timer subsystem: Starting timers (like the
> > periodic task timer) in the past is reported as error - up to the
> > application in this case. One may discuss if this case can be considered
> > as an undocumented API change (I haven't re-read the docs in this regard
> > yet).
> >
> I correct myself. The API actually states that the -ETIMEDOUT error code
> will be return if passed idate is in the past. But that is true for the
> 2.3.x series and for the new 2.4.0 version.
>
> Which means that the true difference between 2.3.x and 2.4.0 is that:
>
> 2.3.x: returns -ETIMEDOUT but schedules the task for immediate execution.
>
> 2.4.0: returns -ETIMEDOUT and *does not* schedule the task for immediate
> execution.
>
> The more I think about it the mode I think this is a bug.
>
> I just can't think of a situation in which idate is in the past and it
> makes sense *not scheduling* the task for immediate execution...

Why not passing TM_NOW as an initial date if you want the task to be
scheduled immediately instead of passing a date in the past ? It has
always worked and still works with Xenomai 2.4.0.


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

>> 2.3.x: returns -ETIMEDOUT but schedules the task for immediate execution.
>>
>> 2.4.0: returns -ETIMEDOUT and *does not* schedule the task for immediate
>> execution.
>>
>> The more I think about it the mode I think this is a bug.
>>
>> I just can't think of a situation in which idate is in the past and it
>> makes sense *not scheduling* the task for immediate execution...
>>     
>
> Why not passing TM_NOW as an initial date if you want the task to be
> scheduled immediately instead of passing a date in the past ? It has
> always worked and still works with Xenomai 2.4.0.
>   
Let's suppose some event happens at time T0 which is recorded. Then, 
after some processing I'm reading to call rt_task_set_periodic, but a 
little delay has passed. If I use:

rt_task_set_periodic(&mytask, TM_NOW, period)

The periodic thread will be executed at:

T0+D    T0+D+period    T0+D+period*2    T0+D+period*3    ...

However, if I use rt_task_set_periodic(&mytask, recorded_time, period):

T0+D    T0+period    T0+period*2    T0+period*3

That is, only the first execution is affected by the delay D. I think 
this option is clearly superior.

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Gilles Chanteperdrix]

On Dec 11, 2007 4:17 PM, Ignacio García Pérez <iggarpe@domain.hid> wrote:
>
> >> 2.3.x: returns -ETIMEDOUT but schedules the task for immediate execution.
> >>
> >> 2.4.0: returns -ETIMEDOUT and *does not* schedule the task for immediate
> >> execution.
> >>
> >> The more I think about it the mode I think this is a bug.
> >>
> >> I just can't think of a situation in which idate is in the past and it
> >> makes sense *not scheduling* the task for immediate execution...
> >>
> >
> > Why not passing TM_NOW as an initial date if you want the task to be
> > scheduled immediately instead of passing a date in the past ? It has
> > always worked and still works with Xenomai 2.4.0.
> >
> Let's suppose some event happens at time T0 which is recorded. Then,
> after some processing I'm reading to call rt_task_set_periodic, but a
> little delay has passed. If I use:
>
> rt_task_set_periodic(&mytask, TM_NOW, period)
>
> The periodic thread will be executed at:
>
> T0+D    T0+D+period    T0+D+period*2    T0+D+period*3    ...
>
> However, if I use rt_task_set_periodic(&mytask, recorded_time, period):
>
> T0+D    T0+period    T0+period*2    T0+period*3
>
> That is, only the first execution is affected by the delay D. I think
> this option is clearly superior.

After checking the sources, it appears that Xenomai never worked the
way you think: xnpod_set_thread_periodic returns -ETIMEDOUT if the
initial date is in the past. So maybe it worked for you because you
are using a periodic timer ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Gilles Chanteperdrix]

On Dec 14, 2007 10:01 AM, Ignacio García Pérez <iggarpe@domain.hid> wrote:
>
> > After checking the sources, it appears that Xenomai never worked the
> > way you think: xnpod_set_thread_periodic returns -ETIMEDOUT if the
> > initial date is in the past. So maybe it worked for you because you
> > are using a periodic timer ?
> >
> >
> I'm using oneshot mode. The application that got broken wasn't
> unmodified. It worked in 2.3.4 and didn't work in 2.4.0 unchanged.
>
> The problem seems not to be the return value of rt_task_set_periodic,
> which returns -ETIMEDOUT for start dates in the past both in 2.3.4 and
> 2.4.0, but in the fact that in 2.3.4 the task is anyway scheduled for
> immediate execution while in 2.4.0 it is not.

I do not see this in 2.3.4 code, but let's admit it is true: then
v2.3.4 code is broken, and so is your application. Really, no RTOS
allows starting timers with dates in the past, you can check the
various Xenomai skins implementation or the posix spec. So, our advice
is to fix your application.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Ignacio García Pérez]

[-- Attachment #1: Type: text/html, Size: 2754 bytes --]

Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

[Gilles Chanteperdrix]

Ignacio García Pérez wrote:
 > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 > <html>
 > <head>
 >   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
 > </head>
 > <body bgcolor="#ffffff" text="#000000">
 > <br>
 > <blockquote
 >  cite="mid:2ff1a98a0712140146o2a3c5761i8a97d67921fedecd@domain.hid"
 >  type="cite">
 >   <blockquote type="cite">
 >     <pre wrap="">immediate execution while in 2.4.0 it is not.
 >     </pre>
 >   </blockquote>
 >   <pre wrap=""><!---->
 > I do not see this in 2.3.4 code, but let's admit it is true: then
 > v2.3.4 code is broken, and so is your application. Really, no RTOS
 > allows starting timers with dates in the past, you can check the
 > various Xenomai skins implementation or the posix spec. So, our advice
 > is to fix your application.
 > 
 >   </pre>
 > </blockquote>
 > <br>
 > I agree it makes no sense to start a timer in the past, but we are not
 > talking about a timer, but about a <b>task</b>.<br>
 > <br>

Yeah, but guess what ? the rt_task_set_periodic starts a timer, so what
you are basically asking is the ability to start a timer with a date in
the past.

 > The discussion is: I want to make a task periodic starting a "little
 > while" ago, what should the rt_task_set_periodic do:<br>
 > <br>
 > a) Fail and do nothing about the task (actually it will <b>stop</b> it
 > if it was already periodic !!!).<br>
 > <br>
 > b) Fail, but schedule the task for immediate execution and set it
 > periodic starting at the specified date plus a period multiple such
 > that the result is in the future.<br>
 > <br>

This is a bad idea, a service which fails should have as little effect
as possible, precisely because it... failed.

 > Not only it seems to me that (b) makes more sense and does something
 > actually useful, but also <b>I think there is no way I can do the
 > equivalent in an atomic way in the application code</b> (I mean without
 > resorting to non-native API functions).<br>
 > <br>
 > I might be wrong, and if so, I'll really appreciate an example of how
 > do to that. Atomically. Meanwhile this is the only thing I could come
 > up with:<br>
 > <br>
 > while ((r = rt_task_set_periodic(&amp;mytask, start, period)) ==
 > -ETIMEDOUT) {<br>
 > &nbsp;&nbsp;&nbsp; count++; start += period;<br>
 > }<br>
 > if (count &gt; 0) rt_task_resume(&amp;mytask);<br>
 > <br>

The rt_task_resume call will only cause a spurious wakeup. Remove it,
and you have a working solution.

 > That code, would however have a non-desirable effect under certain
 > circumstances: let's assume that I want a task A executed, rather than
 > every T milliseconds, N times per second. If the "master" if both tasks
 > are prevented from executing by some other task with higher priority
 > for a large amount of time larger than several periods, several
 > executions would be skipped, which may not be the best solution (maybe
 > I'd rather have the task A execute its processing loop severan times
 > nonstop until it "cathes up" with the total expected number of
 > executions).<br>
 > <br>
 > And now that I think about it, &iquest;what happens to a periodic task when it
 > is prevented from executing by some other higher priority task for an
 > interval equivalent to several periods?<br>

This is called an overrun, and this is what is returned by the calls to
rt_task_wait_period, if you do not pass a null pointer.

 > <br>
 > Regards.<br>
 > <br>
 > Nacho.<br>
 > <br>
 > <br>
 > <br>
 > <br>
 > </body>
 > </html>


-- 


					    Gilles Chanteperdrix.