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

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka 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.
> 
> 
> I see.
> 
> 
>>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?
>>
> 
> 
> In kernel mode, you can already implement such version on your own. Take
> a look at the RTDM_EXECUTE_ATOMICALLY() macro (see RTDM->Driver
> Development API->Synchronisation Services - or rtdm_driver.h). It should
> demonstrate how to run the relative timeout calculation and the rt_sem_p
> call atomically (i.e. by taking the global nucleus lock already before
> the service calls).
> 

One would only need local IRQ masking in Ignacio's case, using the SMP lock 
would be overkill.

> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.