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

["Ignacio García Pérez" <iggarpe@domain.hid>]

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