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

[Philippe Gerum <rpm@xenomai.org>]

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.