I am trying to determine if Xenomai will help me to solve a problem I am having
with embedded Linux in a real time environment. To set the context of the
problem I am trying to solve, some background is necessary.
Our application area is telecommunications, we build cards for optical
transport applications. We have recently transitioned from using Green Hills
Velocity to embedded Linux as our real time operating system. Our applications
are complex and multi-tasking and they use standard solutions such as
semaphores to serialize access to shared data. In our first port of the Green
Hills Velocity code to embedded Linux we often used sem_timedwait() to wait for
a semaphore for a bounded amount of time. However, Linux appears to have an
issue with timers when a task changes the clock with clock_settime().
The POSIX specification for clock_settime() states that: “Setting the value of
the CLOCK_REALTIME clock via clock_settime() shall have no effect on threads
that are blocked waiting for a relative time service based upon this clock,
including the nanosleep() function; nor on the expiration of relative timers
based upon this clock. Consequently, these time services shall expire when the
requested relative interval elapses, independently of the new or old value of
the clock.”
Additionally, the Linux man page for clock_settime() states that: “All
implementations support the system-wide realtime clock, which is identified by
CLOCK_REALTIME. Its time represents seconds and nanoseconds since the Epoch.
When its time is changed, timers for a relative interval are unaffected, but
timers for an absolute point in time are affected”. This indicates that the
Linux implementation of clock_settime() follows the POSIX specification, as
expected. Also the Linux implementation of nanosleep() uses relative timers, as
expected.
However, almost all Linux API functions use absolute timer intervals. For
instance, the man page for sem_timedwait() states that the timeout is an
absolute interval meaning that it will be affected by clock changes. Thus, if
task A is blocked in a sem_timedwait() call, and task B moves time forward with
clock_settime(), then task A will return from sem_timedwait() with ETIMEOUT
prematurely.
>From my examination of the documentation on Xenomai, it would appear that
>Xenomai does not suffer from this problem, but I would like to confirm my
>impression. My question to this list is, in Xenomai, if one calls rt_sem_p()
>with a timeout, will that timeout be correct even if a task changes the clock
>with clock_settime()?
Additionally, the documentation of the POSIX skin of Xenomai indicates that
sem_timedwait() uses an absolute timeout. So, is the Xenomai version of
sem_timedwait() vulnerable to clock changes? Do I have to use rt_sem_p() in
order to avoid issues with clock changes?
Thanks in advance.
Christopher Stone
Optelian, Inc.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
