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

[Philippe Gerum <rpm@xenomai.org>]

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

Ok, I admit that nobody would want to use this on a regular basis, but is this a 
usual need in the first place?

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

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.

-- 

Philippe.