Re: [Xenomai-help] Xenomai and timers.

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2010-12-16 at 13:55 -0400, Chris Stone wrote:
> 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?


Well, the POSIX behavior just makes sense, the kernel does not have to
figure out that in fact, your code is not immune to system time updates
so as to eventually consider absolute timeout specs as being relative
ones in disguise.

Therefore I would not speak about vulnerability here, it is just how
POSIX works, because absolute timeouts do have an advantage over
relative timeouts. Since Xenomai's POSIX skin wants to comply with the
standard, it does resume outstanding timers which end up having a
trigger date in the past due to a clock_settime() request.

The native Xenomai skin - which rt_sem_p is part of - has both relative
and absolute timeout forms. The relative form won't be sensitive to
system time updates, whilst the absolute form will. So you may want to
switch skins, or fix your POSIX code to explicitly deal with this issue.
YMMV. (I would probably fix my code actually).

> 
> Thanks in advance.
> Christopher Stone
> Optelian, Inc.
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.