For more infomation about this bug, visit

Peter Soetens
<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|--- |1.6.0

--- Comment #6 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-06-06 16:22:07 ---
Fixed on trunk/rtt

$ svn ci src/os/gnulinux/fosi.h src/os/gnulinux/fosi_internal.cpp -m"Fix bug
#565: Periodicity of thread not guaranteed under (preempt-rt) gnulinux
> Applied patch for using clock_nanosleep()
> "
Sending src/os/gnulinux/fosi.h
Sending src/os/gnulinux/fosi_internal.cpp
Transmitting file data ..
Committed revision 29372.

For more infomation about this bug, visit

--- Comment #5 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-06-06 10:44:58 ---
(In reply to comment #4)
>
> Could you agree that each thread stores a RTOS_TASK* and uses that with
> rtos_wait_period()?

Yes, the thread may only pass its own RTOS_TASK to rtos_task_wait_period().

>
> Asuming this, one thread can't call rtos_wait_period() with some other thread's
> RTOS_TASK*. This makes rtos_wait_period() reentrant as far the RTOS_TASK*
> argument is concerned. In other words: rtos_wait_period() can be interrupted by
> an other thread but the RTOS_TASK* _will be_ different.

This is how it is implemented and will stay as such.

Peter

For more infomation about this bug, visit

--- Comment #4 from sander <sander [dot] vandenbroucke [..] ...> 2008-06-06 10:01:40 ---
(In reply to comment #3)
> Because we need to support different OS APIs, we need to pass the OS-specific
> RTOS_TASK struct to this function such that it can extract itself the necessary
> data. For example, RTAI will use no data at all and just use the preprogrammed
> period in rt_task_period_wait(void). Others, like gnulinux, store the period in
> this RTOS_TASK struct and use a nanosleep.
> In both cases, the calling thread is suspended though.
> Peter

Ok, I see.

Could you agree that each thread stores a RTOS_TASK* and uses that with
rtos_wait_period()?

Asuming this, one thread can't call rtos_wait_period() with some other thread's
RTOS_TASK*. This makes rtos_wait_period() reentrant as far the RTOS_TASK*
argument is concerned. In other words: rtos_wait_period() can be interrupted by
an other thread but the RTOS_TASK* _will be_ different.

Sander.

For more infomation about this bug, visit

--- Comment #3 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-06-06 09:47:26 ---
(In reply to comment #2)
> An other thought: What is rtos_task_wait_period() supposed to do anyway?
> Is it supposed to suspend the thread represented by 'RTOS_TASK* task' or is it
> to suspend the calling thread?
>
> It seems to be the second so I wonder if
> int rtos_task_wait_period( NANO_TIME period )
> is a better definition to cover the function's semantics?

Because we need to support different OS APIs, we need to pass the OS-specific
RTOS_TASK struct to this function such that it can extract itself the necessary
data. For example, RTAI will use no data at all and just use the preprogrammed
period in rt_task_period_wait(void). Others, like gnulinux, store the period in
this RTOS_TASK struct and use a nanosleep.

In both cases, the calling thread is suspended though.

Peter

For more infomation about this bug, visit

sander <sander [dot] vandenbroucke [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |sander.vandenbroucke@vandewi
| |ele.be

--- Comment #2 from sander <sander [dot] vandenbroucke [..] ...> 2008-06-06 08:44:09 ---
An other thought: What is rtos_task_wait_period() supposed to do anyway?
Is it supposed to suspend the thread represented by 'RTOS_TASK* task' or is it
to suspend the calling thread?

It seems to be the second so I wonder if
int rtos_task_wait_period( NANO_TIME period )
is a better definition to cover the function's semantics?

Sander.

For more infomation about this bug, visit

--- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-06-05 15:13:04 ---
Created an attachment (id=317)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=317)
Now we're talking !

As suggested on the mailinglist, clock_nanosleep() is just what we need. Also,
used CLOCK_MONOTONIC to avoid time running backwards in some reported cases...

How does this fit into MacOSX ?

On Jun 5, 2008, at 05:26 , Peter Soetens wrote:

> For more infomation about this bug, visit > >
> Summary: Periodicity of thread not guaranteed under
> (preempt-rt)
> gnulinux
> Product: RTT
> Version: 1.4.0
> Platform: All
> OS/Version: GNU/Linux
> Status: NEW
> Severity: major
> Priority: P2
> Component: Operating System Abstraction - Portability
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [dot] soetens [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
> The following code in gnulinux/fosi_internal.cpp contains a race
> condition,
> which disturbs deterministic periodic execution, even under PREEMPT-
> RT.
>
> INTERNAL_QUAL int rtos_task_wait_period( RTOS_TASK* task )
> {
> if ( task->period == 0 )
> return 0;
>
> //rtos_printf("Time is %lld nsec, Mark is %lld
> nsec.\n",rtos_get_time_ns(), task->periodMark );
> // CALCULATE in nsecs
> NANO_TIME timeRemaining = task->periodMark -
> rtos_get_time_ns();
> // set next wake-up time :
> task->periodMark += task->period;
>
> // XXX Racecondition bug:
> // if interrupted by another thread here, we will nanosleep
> to long !
> // is there a better Linux API??
>
> if ( timeRemaining > 0 ) {
> //rtos_printf("Waiting for %lld nsec\n",timeRemaining);
> TIME_SPEC ts( ticks2timespec( timeRemaining ) );
> // see nanosleep man page for this construct:
> while ( rtos_nanosleep( &ts , &ts ) == -1 && errno ==
> EINTR ) {
> errno = 0;
> }
> return 0;
> }
>
> return 0;
> }
>
> And I don't want any signals as these are per-process and not per-
> thread.

Would clock_nanosleep(..., TIMER_ABS, ...) help?
S

[...]
> And I don't want any signals as these are per-process and not per-thread.

Out of interest: Can you elaborate on what's the exact problem you
have with signals?

Klaas