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

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

[Ignacio García Pérez]

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?

Nacho.

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

[Jan Kiszka]

[-- 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 --]

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

[Ignacio García Pérez]

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

>Typically, timeouts are used here to detect
>errors (someone else failed to signal), and you don't have to detect
>them that precisely - typically.
>  
>
I agree.

>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.
>  
>
Sure you can do it that way, but using a timer seems a bit of an
overhead compared to just having absolute timeout API calls.

I sincerely think it would not break the beauty and simplicity of the
native API.

Nacho.

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

[Jan Kiszka]

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

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

Jan


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

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

[Philippe Gerum]

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.

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

[Philippe Gerum]

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.

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

[Ignacio García Pérez]

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?

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

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

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 :-)

Nacho.

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

[Philippe Gerum]

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.

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

[Ignacio García Pérez]

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

Dunno. My vote goes for "needed flexibility", but it is just my vote.

Oh, and that'r regarding the native skin. Regarding the nucleus, I
definitely think that providing absolute timeouts in a *needed*
flexibility, since other wise a skin that provides absolute timeouts
cannot be properly implemented (at least not without disabling
interrupts and such, which seems quite a kludge). In fact, if what you
want in the nucleus is to retain the maximum flexibility with the
minimal possible API, the way to go is provide *only* absolute timeouts.
The skin implementor can then get relative timeouts by a simple
substraction (and in this case, unexpected preemprion is not a problem
as I discuss in the previous message).

Of course, changing the meaning of the timeout from relative to absolute
in the nucleus now, would be a nightmare to debug.

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

My experience in RT development is small. The only design pattern I know
of is the one I already discussed.

>> 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 :-)
>
> By the way, I just realized that in fact, the wakeup time for threads
>
> 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

At least in my designgs (again, I'm nowhere near being an RT guru),
whenever I need to execute code along a very well defined timeline (ie
at t, t+1000, t+1200, t+1600 and t+2400), I *need* to use absolute
timeouts. I don't say it's *convenient*, I say I *need* to use absolute
timeouts.

IMHO, the fact that some design pattern cannot be properly implemented
with relative timeouts, no matter how rarely it is used, is reason
enough to at least provide the absolute time capability.

So far, implementing absolute timeouts is both easy and convenient, and
the *only* drawback is that we are adding some API calls (and you'll
agree that it's not the same adding N new functions that are alter egos
of existing functions than adding just N heterogeneous and unrelated new
functions, the level of perceived complexity added is much lower in the
first case).

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

Agree. But I insist that the point is not how rare a design pattern
requiring absolute timeouts is, but that if it is required, it cannot be
properly implemented with the current native API (or even the nucleus
API, which I believe is not intended to be exposed to RT application
developers but to skip developers).

I'm seriously thinking of implementing native API absolute time calls
(and BTW, sayng that after just one hour of examination of the internals
of xenomai, is the best praise I could pay to the quality of the code).
I understand your position and it is OK if you don't implement those
calls. However, in order to keep the modifications to the source
*minimal*, I would need some changes in the xenomai code. I think they
would all be totally transparent and impactless, but let me know what
you think:

I would modify the following functions (not a complete list, just the
ones I came across when tracing the timeout parameter in the
rt_mutex_lock call), such that they take an extra boolean parameter
after the timeout that specifies whether it is realtive or absolute. The
modifications would be MINIMAL, meaning that for all functions but the
last two they will just pass the bool along with the timeout. In the
last two, again the modification is minimal, taking into account the
value of the bool when updating the xntimer_t.date field.

xnsync_sleep_on()
xnpod_suspend_thread()
xntimer_start()
xntimer_do_start_periodic();
xntimer_do_start_aperiodic();


Since otherwise I would be breaking the nucleus API, I would change the
name of the functions to something else, like:

xnsync_sleep_on_absrel()
xnpod_suspend_thread_absrel()
xntimer_start_absrel()
xntimer_do_start_periodic_absrel();
xntimer_do_start_aperiodic_absrel();


(Yeah, horrible naming, but could not think of anything better)


And then add inline functions that would just call the _absrel functions
with the bool parameter set to indicate relative timeout.


What do you think?


Nacho.

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

[Ignacio García Pérez]

Ok, so I took the time to delve a bit into the xenomai code to check out
by myself how complex would it be to implement absolute timeouts. This
is from a 1 hour walk around the code, so I'll post my thoughts so those
truly knowledgeable can correct me.

(BTW, here goes another praise: nice, readable, structured,
understandable code, you know what's my reference for comparison)

All synchronization primitive's blocking calls that take a timeout end
up using

xnsync_sleep_on()

to suspend (delay, actually) the current thread. That function takes a
relative timeout, just as passed to the blocking synchronization
primitive call. After some magic, xsync_sleep_on() ends up calling

xnpod_suspend_thread()

again passign the timeout as a relative value. Eventually, the timeout
is again passed in a call to:

xntimer_start()

which in turn calls xntimer_do_start_periodic() or
xntimer_do_start_aperiodic() depending on the current timer operation
mode. In xntimer_do_start_(a)periodic(), one can see, finally how the
wakeup time (xntimer_t.date) is calculated from the current time and the
requested sleep interval.

So, we timeout trail is:

rt_mutex_lock() --> xsync_sleep_on() ---> xnpod_suspend_thread() --->
xntimer_start() ---> xntimer_do_start_(a)periodic()

And my assumption that internally the scheduler works with absolute
timeouts for delayed threads is true.

Now suppose that I want to implement absolute timeouts. There are two
alternatives:

1- Write an absolute timeout alter ego of every "public" function in the
native skin AND in the nucleus, except maybe for
xntimer_do_start_(a)periodic.

2- Add a parmeter to every "public" function in the native skin AND in
the nucleus which specifies if the timeout is absolute or relative.

3- Write an absolute timeout alter ego of every synchronization call in
the native skin, and add a parameter in the nucleus calls to specify
absolute/relative timeout.

4- Rewrite all functions that use a relatime timeout to use an absolute
timeout.

(1) Would mean copy&paste of code. Definitely a no-no.

(2) Is very easy to implement. One downside is that, for example, the
locking of a mutex requires three parameters when most of the time one
would do (just the mutex). Another important downside is that it breaks
the API of applications written over the native API.

(3) Best IMHO. Would keep the native API intact while providing all the
absolute/relatime timeout flexibility in the nucleus.

(4) Worst IMHO. Would break the whole API, would be a nightmare to
debug. However, I have to point out that this would probably have been
my initial design choice. Work always with absolute timeouts, if the
user wants a relative timeout, he should calculate it from current time.
I cannot imagine a situation in which a preemption in between getting
current time and issuing the blocking call would be undesirable. I'll
explain:

With the relatime timeout API, if I want this thread to wake up at
t=1000, I must calculate delay as d = 1000 - current_time and then call
rt_sem_p (or whatever). If the thread is preempted between getting
current time and calling rt_sem_p, it will sleep for longer than desired
and will end up waking up after t=1000, which is what I wanted exactly.

In the absolute timeout scenatio, suppose that I want this thread to
wake up in 100 ns. In 100 ns since when?... since current time?... then
use the absolute timeout and you're done. Since some other operation
like setting a digital output?, then there is anyway nothing you can do
to prevent the possibility of being preempted in between the I/O
operation and the actual rt_sem_p call, so why worry about that
preemption happening in between getting current time and issuing the call?

Nacho.

P.S: Not to be a purist, but I think that functions like
xntimer_do_start_aperiodic and xntimer_do_start_periodic should be
declared static, since they are only to be accessed through their
pointers in the nktimer structure.

P.S: As a side note, wouldn't be a good practice to expand tabs to
spaces in all the code?

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

[Jan Kiszka]

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

Ignacio García Pérez wrote:
> ...
> P.S: As a side note, wouldn't be a good practice to expand tabs to
> spaces in all the code?

My opinion is yes - but it's a nasty work. Would you provide such
patches...?

Jan


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

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

[Ignacio García Pérez]

Jan Kiszka wrote:

>Ignacio García Pérez wrote:
>  
>
>>...
>>P.S: As a side note, wouldn't be a good practice to expand tabs to
>>spaces in all the code?
>>    
>>
>
>My opinion is yes - but it's a nasty work. Would you provide such
>patches...?
>
>Jan
>
>  
>
Assuming everybody is using the 8 space tab (I saw it in all the files I
examined today), something like this would do:

texp () {
    TMPFILE=$(mktemp tmp.XXXXXX)
    expand -t 8 $1 > $TMPFILE
    mv -f $TMPFILE $1
}

for i in $(find -name "*.c"); do texp $i; done
for i in $(find -name "*.h"); do texp $i; done



However, this is of no help if developers don't configure their editors
to expand spaces by default, which I think is quite difiicult to achieve.

Would be a good idea too to enforce this tab expansion policy with a SVN
submit filter, but that's beyond by knowledge.

Nacho.

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

[Philippe Gerum]

Jan Kiszka wrote:
> Ignacio García Pérez wrote:
> 
>>...
>>P.S: As a side note, wouldn't be a good practice to expand tabs to
>>spaces in all the code?
> 
> 
> My opinion is yes - but it's a nasty work. Would you provide such
> patches...?
> 

Actually, there is a more general problem with the current coding style used 
throughout the code base: it's mine, it's not that standard, and now that more 
people are contributing to it, I'm pondering whether we should just adopt the 
conventional kernel coding style, without the ludicrous 8-space tabs, that is.

-- 

Philippe.

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

[Philippe Gerum]

Ignacio García Pérez wrote:
> Ok, so I took the time to delve a bit into the xenomai code to check out
> by myself how complex would it be to implement absolute timeouts. This
> is from a 1 hour walk around the code, so I'll post my thoughts so those
> truly knowledgeable can correct me.
> 
> (BTW, here goes another praise: nice, readable, structured,
> understandable code, you know what's my reference for comparison)
> 
> All synchronization primitive's blocking calls that take a timeout end
> up using
> 
> xnsync_sleep_on()
> 
> to suspend (delay, actually) the current thread. That function takes a
> relative timeout, just as passed to the blocking synchronization
> primitive call. After some magic, xsync_sleep_on() ends up calling
> 
> xnpod_suspend_thread()
> 
> again passign the timeout as a relative value. Eventually, the timeout
> is again passed in a call to:
> 
> xntimer_start()
> 
> which in turn calls xntimer_do_start_periodic() or
> xntimer_do_start_aperiodic() depending on the current timer operation
> mode. In xntimer_do_start_(a)periodic(), one can see, finally how the
> wakeup time (xntimer_t.date) is calculated from the current time and the
> requested sleep interval.
> 
> So, we timeout trail is:
> 
> rt_mutex_lock() --> xsync_sleep_on() ---> xnpod_suspend_thread() --->
> xntimer_start() ---> xntimer_do_start_(a)periodic()
> 
> And my assumption that internally the scheduler works with absolute
> timeouts for delayed threads is true.
>

Yes.

> Now suppose that I want to implement absolute timeouts. There are two
> alternatives:
> 
> 1- Write an absolute timeout alter ego of every "public" function in the
> native skin AND in the nucleus, except maybe for
> xntimer_do_start_(a)periodic.
> 
> 2- Add a parmeter to every "public" function in the native skin AND in
> the nucleus which specifies if the timeout is absolute or relative.
> 
> 3- Write an absolute timeout alter ego of every synchronization call in
> the native skin, and add a parameter in the nucleus calls to specify
> absolute/relative timeout.
> 
> 4- Rewrite all functions that use a relatime timeout to use an absolute
> timeout.
> 
> (1) Would mean copy&paste of code. Definitely a no-no.
> 

Indeed.

> (2) Is very easy to implement. One downside is that, for example, the
> locking of a mutex requires three parameters when most of the time one
> would do (just the mutex). Another important downside is that it breaks
> the API of applications written over the native API.
>

No-go.

> (3) Best IMHO. Would keep the native API intact while providing all the
> absolute/relatime timeout flexibility in the nucleus.
> 

Again, the nucleus internals are not the issue here. Actually, Xenomai 1.x 
worked with both rel/abs timing modes on demand; the feature was removed because 
no clear sign of usefulness went backing the decision to keep this duality at 
that time. So let's keep this aside, there would be no problem adding the 
feature at this level.

The real issue is only about extending the absolute timeout support to _all_ 
blocking primitives from the native API, or only to a single one for which there 
exists a clear POSIX counterpart (i.e. rt_cond_wait -> pthread_cond_timedwait). 
I'd like we focus on this issue instead. IOW, would rt_sem_p_abs() or 
rt_queue_recv_abs() be of any use?

> (4) Worst IMHO. Would break the whole API, would be a nightmare to
> debug. However, I have to point out that this would probably have been
> my initial design choice. Work always with absolute timeouts, if the
> user wants a relative timeout, he should calculate it from current time.
> I cannot imagine a situation in which a preemption in between getting
> current time and issuing the blocking call would be undesirable. I'll
> explain:
> 
> With the relatime timeout API, if I want this thread to wake up at
> t=1000, I must calculate delay as d = 1000 - current_time and then call
> rt_sem_p (or whatever). If the thread is preempted between getting
> current time and calling rt_sem_p, it will sleep for longer than desired
> and will end up waking up after t=1000, which is what I wanted exactly.
> 
> In the absolute timeout scenatio, suppose that I want this thread to
> wake up in 100 ns. In 100 ns since when?... since current time?... then
> use the absolute timeout and you're done. Since some other operation
> like setting a digital output?, then there is anyway nothing you can do
> to prevent the possibility of being preempted in between the I/O
> operation and the actual rt_sem_p call, so why worry about that
> preemption happening in between getting current time and issuing the call?
> 

In any case, changing the semantics of existing calls now is the last thing we 
should do.

> Nacho.
> 
> P.S: Not to be a purist, but I think that functions like
> xntimer_do_start_aperiodic and xntimer_do_start_periodic should be
> declared static, since they are only to be accessed through their
> pointers in the nktimer structure.
>

Indeed, they should.

> P.S: As a side note, wouldn't be a good practice to expand tabs to
> spaces in all the code?
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

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

[Ignacio García Pérez]

>
> The real issue is only about extending the absolute timeout support to
> _all_ blocking primitives from the native API, or only to a single one
> for which there exists a clear POSIX counterpart (i.e. rt_cond_wait ->
> pthread_cond_timedwait). I'd like we focus on this issue instead. IOW,
> would rt_sem_p_abs() or rt_queue_recv_abs() be of any use?

Don't think so. Just liked the idea of an "orthogonal" API. Sometimes
it's simply easier to remember that wherever you specify a timeout you
can do it abs/rel than to remember that some sync primitives allow abs
and other don't.

Nacho.

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

[Ignacio García Pérez]

In my previous (long) message I forgot something. I think that without
support for abolute timeouts in the nucleus, the RTAI skin cannot be
accurately implemented (*_until and *_timed calls).

Nacho.

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

[Jan Kiszka]

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

Ignacio García Pérez wrote:
> In my previous (long) message I forgot something. I think that without
> support for abolute timeouts in the nucleus, the RTAI skin cannot be
> accurately implemented (*_until and *_timed calls).
> 

Then something must be wrong, e.g. here: ;)

http://www.rts.uni-hannover.de/xenomai/lxr/source/skins/rtdm/drvlib.c?v=SVN#L280
(other skins do it similar but have to deal with more complexity)

I does work as you can see, it just takes some locking. :)

Well, it's not that accurate as it could be at best, that's true, but
the short time you "loose" between the conversions in the skin and the
nucleus is not significant compared to the overall jitter you always
face on an OS.

Jan


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

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

[Ignacio García Pérez]

Jan Kiszka wrote:

>Ignacio García Pérez wrote:
>  
>
>>In my previous (long) message I forgot something. I think that without
>>support for abolute timeouts in the nucleus, the RTAI skin cannot be
>>accurately implemented (*_until and *_timed calls).
>>
>>    
>>
>
>Then something must be wrong, e.g. here: ;)
>
>http://www.rts.uni-hannover.de/xenomai/lxr/source/skins/rtdm/drvlib.c?v=SVN#L280
>(other skins do it similar but have to deal with more complexity)
>
>I does work as you can see, it just takes some locking. :)
>  
>
Um. I meant it cannot be properly done in a user application.

One of the best things of xenomai is the neat layered design. In theory
(again, correct this newbie if he's wrong),* the application developer
should use only the API provided by the skin he chooses. The nucleus
services should be used only by skin developers.*

So, it's perfectly ok that the RTDM developer uses the locking mechanism
provided by the nucleus.

But I think that I, as an application developer using the native skin,
should not need to resort to the nucleus to implement a certain basic RT
functionality (and yes, I agree it is a quite rare design pattern, but
it's there).

As I discuss in another message, I think the best (and easy!) solution
from the design standpoint would be to modify all nucleus calls that
take a timeout argument and add a boolean argument to specify whether
the timeout is realtive or absolute. Would be almost trivial to
implement, however:

- Would break the nucleus API, THOUGH the required updates in the skins
would be TRIVIAL (just add a zero/one after the timeout). Later, some
calls like the RTDM one you mention could be further optimized by using
the absolute timeout nucleus call instead of the locking.

- Would require modifications of the documentation. Since it's generated
with doxygen, and the code changes are trivial, this would be probably
the largest job.

The nucleus API would suffer a minimal change (no new calls, just a new
parameter in ones) and would provide quite a large amount of
flexibility. Extending the native skip API would be the next step, and
if the project leader decides not to do it, that would be OK because I
could do it only for myself via a tiny patch.

>Well, it's not that accurate as it could be at best, that's true, but
>the short time you "loose" between the conversions in the skin and the
>nucleus is not significant compared to the overall jitter you always
>face on an OS.
>
>Jan
>
>  
>

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

[Philippe Gerum]

Ignacio García Pérez wrote:
> In my previous (long) message I forgot something. I think that without
> support for abolute timeouts in the nucleus, the RTAI skin cannot be
> accurately implemented (*_until and *_timed calls).
> 

There is no problem for any skin to enclose the timeout computation and the 
actual suspension call within an interrupt-free section, and as a matter of 
fact, some skins already do this. What's not that handy, is for _user_ level 
code to do the same, this is true. In that case, the issue is not with the 
nucleus, but with the skin.

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


-- 

Philippe.