Phillipe and Gilles, thanks for your help, you guys are awesome.
Cheers,
Chris.
> Subject: Re: [Xenomai-help] Xenomai and timers.
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> Date: Fri, 17 Dec 2010 10:09:47 +0100
>
> On Thu, 2010-12-16 at 15:30 -0400, Chris Stone wrote:
> > Thanks for your reply, and I realize that I am now getting off topic
> > for this list, but if the explanation is easy perhaps I could impose
> > on you a little further. How does one fix the POSIX code to deal with
> > this issue? When sem_timedwait() returns with ETIMEDOUT, how does one
> > know that the time was changed by another task and the timeout was not
> > the duration that was asked for?
>
> I'm excluding small time adjustments, NTP-like, which should not be an
> issue, because timeouts are not for accurate timing, but really for
> implementing a safety belt against infinite hangs, so this is coarse
> grained in essence. I'm talking about large arbitrary leaps forward done
> using clock_settime() from an application context.
>
> A possible answer then, is two fold:
>
> - you likely control all the code running on your embedded platform,
> which should include the task(s) issuing clock_settime(). Flagging this
> particular action so that other tasks could detect it later on should be
> possible. It should even be possible to exclude system time updates
> using a rwlock mechanism when other tasks are about to pend on a timed
> sync. Waiters would pick the read side before pending on the sync, the
> task issuing clock_settime() would have to grab the write side before
> changing time. In effect, this might postpone the system time update
> until all waiters have either received the resource or hit a timeout
> condition, but maybe this is acceptable for you.
>
> - upon ETIMEDOUT condition, if the difference between clock_gettime()
> when returning, and clock_gettime() before sleeping is preposterously
> larger than the specified timeout, then the code may assume a system
> time update took place, and act upon accordingly. The cost here is one
> syscall more issued unconditionally before entering the timed wait to
> get the current time, but this may be acceptable as well. The grey area
> is for updates in the range of the typical timeout value, you would
> likely have to rely on something like the previous option instead.
>
> >
> > Chris.
> >
> > > Subject: Re: [Xenomai-help] Xenomai and timers.
> > > From: [email protected]
> > > To: [email protected]
> > > CC: [email protected]
> > > Date: Thu, 16 Dec 2010 19:40:10 +0100
> > >
> > > 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
> > > > [email protected]
> > > > https://mail.gna.org/listinfo/xenomai-help
> > >
> > > --
> > > Philippe.
> > >
> > >
> > _______________________________________________
> > Xenomai-help mailing list
> > [email protected]
> > https://mail.gna.org/listinfo/xenomai-help
>
> --
> Philippe.
>
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
