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

[Jan Kiszka <kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

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? Typically, timeouts are used here to detect
errors (someone else failed to signal), and you don't have to detect
them that precisely - typically.

An exception is when you want to maintain a single timeout across
multiple blocking calls. Then you could create a timer instead that
unblocks your infinitely waiting task when being triggered. Just as
timing out, unblocking also gives you an error when returning from the
blocking call.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]