IPC Timeouts

Kevin Elphinstone kevine at cse.unsw.edu.au
Wed Feb 23 23:31:31 CET 2005

Just for your info, I don't have time to really get into the debate, our current thinking is that timeouts (besides poll and block forever) should go away and be replaced with a time service (implemented in a user-level server or the kernel depending on the granularity required and architecture, the API can remain the same for both).

Our reasons:

* Can (help) control the propagation of time in case where it is desirable to restrict it.

* The only design patterns that emerged for timeouts were used for where for generating timer events. Even for pagefault timeouts, most systems architected themselves such that zero or infintite could be used.

* No method emerged (even ideas?) that took advantage of finite timeouts in combination with IPC, the required analysis was always put in the too hard basket, and even given it, it may not scale beyond very simple systems. There still might be an opportunity for someone clever here, but it is not on anyones agenda we are aware of.

* The loose timekeeping in L4 combined with the way timeouts are specified means they are unusable in practice for precise timing. You can't specify a timeout (both absolute or relative) due to the potential for a pathological case delaying the IPC (registering of the event) such that the timeout becomes incorrect, or that given a timeout, that time being usurped by a burst of interrupt handling. I have yet to see the analysis that demonstrates it can't happen (implying the no identification of the requirements to avoid it), and such an analysis probably won't scale beyond simple systems.

The previous two points basically agree with shap's comment of lack of a robust method to set finite time, even with it, L4 does not appropriate accounting to give you the time you specify. 

Summary: I'd argue strongly for absolute time events specified absolutely, not relative to some current time. There is obvious motivation for absolute wall clock events, but there may be cases for "absolute" events on a process virtual time scale. There maybe cases for relative time events on a process virtual time scale, but I think relative events based on wall clock (what we have now) is unusable where . The combination with IPC seems unwarranted.



Ronald Aigner <> scribbled on Thursday, 24 February 2005 4:29 AM:

> (Background:) I am working with L4 in Dresden on real-time systems, which
> become fairly complex lately.  One of the questions, which began to bother
> me more and more, is: What is the use of finite IPC timeouts?

More information about the l4-hackers mailing list