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?
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
