Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).

[Philippe Gerum <rpm@xenomai.org>]

Ignacio García Pérez wrote:
> Philippe Gerum wrote:
> 
> 
>>Ignacio García Pérez wrote:
>>
>>
>>>Jan Kiszka wrote:
>>>
>>>
>>>
>>>>Ignacio García Pérez wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>While porting my application, I noticed that all synchronization
>>>>>primitives locking calls take a relative timeout as a parameter,
>>>>>right?
>>>>>
>>>>>Of course, I can get the current time, calculate the timeout
>>>>>interval by
>>>>>substracting the current time from the desired timeout moment, and
>>>>>call
>>>>>the function. But wouldn't something like this be possible?:
>>>>>
>>>>>Suppose I want to wait on a semaphore until t=1000, and now=900.
>>>>>
>>>>>1- I get current time (900).
>>>>>2- I calculate the relative timeout as 1000-900 = 100
>>>>>3- I call rt_sem_p(&mysem, 100);
>>>>>
>>>>>In the best case, no preemption will occur between steps 1 and 3,
>>>>>but my
>>>>>thread will still be sleeping not until t=1000, but until some time
>>>>>later, t=1000+d, where d is the time used by the code in steps 1-3 and
>>>>>into the native skin/nucleus.
>>>>>
>>>>>In the worst case, in addition to that, the thread will be preempted
>>>>>between steps 1 and 3. If it is preempted by another higher priority
>>>>>thread for, say, 50 ticks, and the call in step 3 is actually executed
>>>>>at t=950, the thread will be sleeping until t=1050+d, which may not be
>>>>>acceptable.
>>>>>
>>>>>What do you think?
>>>>> 
>>>>
>>>>
>>>>That's true, having to convert between absolute and relative time (and
>>>>vice versa) in interruptible contexts can cause problems if the
>>>>application is not prepared for it.
>>>>
>>>>The question is: do you really need that precise timeouts for
>>>>synchronisation primitives?
>>>>
>>>
>>>Yes I do. In my application, there is a free-run periodic execution
>>>thread that gets once in a while synchronized to an external event.
>>>
>>>This thread waits on a semaphore with an absolute timeout of t, does its
>>>work, calculates t = t + period and waits again on the semaphore. If the
>>>external event signals the semaphore, the thread wakes up immediately
>>>and does some slightly different stuff.
>>>
>>>The thing is, I want the free-run thread to execute at 2 KHz, this is,
>>>every 5 ms. If I use a relative time, I face the problem I described.
>>>
>>>I guess I could get it working properly using a periodic thread, but I'm
>>>sure it's not as simple (and does not "feel" as natural) as just waiting
>>>on the synchronization primitive using an absolute timeout.
>>>
>>
>>If the need for abs timeout protection is seldom, you could also make
>>the related portion of code interrupt-free, since this is what's going
>>to happen early on within the syscall anyway. e.g.:
>>
>>rthal_lock_irqsave
>><compute-timeout>
>>sem_wait(&s,timeout)
>>rthal_lock_irqrestore
> 
> 
> Mmmm... will sem_wait (=rt_sem_p) properly reenable interrupts?
> 

> I ask, because usually, code that disables interrutps actually do push
> the processor flags and clear the interrupt flag, and code that
> reenables intrrupts just pops the flags, thus allowing nested interrupt
> disabling/enabling. If that's the case, the thread will go to sleep and
> interrupts will remain disabled, locking everything up. Right?
> 

Actually no. When a switch occurs, the incoming task resets its own interrupt 
state, so if it has entered the rescheduling procedure interrupts on, it will 
get back to this state appropriately upon wake up.

> 
>>Ok, I admit that nobody would want to use this on a regular basis, but
>>is this a usual need in the first place?
> 
> 
> Not sure. I guess you're right and it's not an usual need. I'm all
> against polluting the API with every single new kludge that comes to
> mind (I praised the xenomai API in another message), but I sincerely
> think that having two versions of each blocking call with absolute and
> relative timeouts would add a great deal of flexibility while keeping
> the API clean and orthogonal.
> 
> 
>>>I really really think there should be, for each call that takes a
>>>timeout, two version, one that takes a relative timeout and another that
>>>takes an absolute timeout.
>>>
>>>Any chances of this being implemented in the current native API?
>>>
>>>
>>
>>The issue there is really about deciding if we have a proper
>>usefulness / complexity ratio, i.e. how unique, frequently needed and
>>relevant is the feature wrt the cost to implement it and the impact on
>>the core and the API to export it.
> 
> 
> Correct me if I'm wrong, but I suppose implementation should be rather
> trivial. In fact, it should just mean embedding the code snipped you
> wrote above (the interrupt-free relative time calculation) into the API.
> I think that more important than saving the hassle of having the caller
> to write it, is leaving the HAL locking unlocking up to the nucleus,
> where it should be.
> 

Indeed, it's clearly not a matter of implementation, but rather a question of 
adding 8-10 more calls bearing absolute timeouts to the API, which would be 
about a 10% increase of the number of calls. Hence the question: are absolute 
timeouts for each and every single blocking call a _needed_ flexibility, or is 
it "solely" based on the idea of avoiding any exception case among all timed calls?

> 
>>The scenario you presented with a single synchronization allowing to
>>pend for an event and a precisely timed fallback action is not that
>>uncommon, even if it's not a frequent one either.
>>
>>In a first approach, I would suggest an intermediate solution which
>>would provide support for this kind of synchronization constructs,
>>without requiring the whole timeout API to be extended in a somewhat
>>overkill manner (i.e. as Jan already pointed out, in the general case,
>>a timeout associated to a blocking call is by essence a safety belt in
>>case things go weird, not a precision timer).
>>
>>The proposed solution would be to add a single new call to the condvar
>>interface, namely rt_cond_abswait(). Since one can already build any
>>kind of synchro object over the condvar, this would likely provide an
>>adaptable solution.
>>
> 
> That will do. In fact, I'm used to the posix API where the only
> synchronization call thatis timed is pthread_cond_timedwait, and I tend
> to use cond vars more than any other primitive.
> 
> However, as I pointed out above, I think that the implementation should
> be just as easy with other sync primitives as with the cond var, and
> would preserve the orthogonality of the API (*all* locking calls on
> *all* sync primitives would allow both relative and absolute timeouts).
>

Something I would buy as a very good reason to extend the API this way would be 
the existence of some common design pattern that do need such generalized 
absolute timeouts to operate properly and efficiently. So far, I cannot come 
with any obvious illustration of such need; am I missing any of them here?

> By the way, I just realized that in fact, the wakeup time for threads
> must be handled by the scheduler as *absoulte* time, not relative (how
> could it otherwise compare and sort out the earliest waking thread to
> program the timer in oneshot mode?), thus maybe the current
> implementation of relative timeouts is in fact more complex than an
> absolute implementation. I may be wrong, of course I haven't dared to
> delve into the internals of xenomai :-)

Actually, the conversion between relative and absolute dates is handled by a 
couple of lines inside the timer manager code, so it's no big deal using the 
relative timeouts. The decision to use the relative form as the preferred one 
has been made on my perception that most people express their wait limits in 
terms of count of time units, not that often in absolute dates. When we do need 
absolute dates, it's much more likely to express explicit wake up times for 
services that basically do nothing else than putting the caller to sleep.

-- 

Philippe.