Messages in this thread | | | Date | Thu, 22 Apr 2010 21:33:06 +0200 | Subject | Re: Considerations on sched APIs under RT patch | From | Primiano Tucci <> |
| |
Hi Peter, It is not in my intents to start a flame, but, as you pointed out yourself, EDF is not so common, particularly in commercial RTOSes as you stated (and xnu, indeed, does not fall into this category).
It is not surprisingly that the citation you found was from Mr Brandenburg and Mr. Anderson from North Carolina University, incidentally I had a copy of their paper (On the Implementation of Global RT Schedulers) at the time of reading your message. I think they're are among the few that concretely and deeply investigated on G-EDF. As you could read by Brandenburg and Anderson, there isn't a standard/reference implementation of Global EDF, but a alot of "variants" are possible (e.g., event-driven / tick driven promotion, dedicated/global interrupt handling, typology of data structures and locking methods ...). My intent is not to make a form of top ten best kernel award, all we are trying to do is investigating on the various facilities offered by the RT operating systems in order to determine how much we can rely on them.
>> It is how it is implemented now, and how it works under VXWorks! > > But that does not, and can not, provide proper isolation and bandwidth > guarantees since there could be runnable tasks outside the scope of the > middleware.
Actually our implementation in VxWorks is based on kernel space tasks that have the maximum priority on the system, even greater of VxWorks system tasks (that have been shifted down after long and fruitful support discussions with windriver) therefore no task (except from interrupt service routines that are accurately weighted under VxWorks) can alter our middleware. Actually it is controlling real world (yet not production stage) manufacturing systems, and it is a bit more than just a play-game.
We are trying to study and understand if, and how, analogous things can be done on other Real Time Operating Systems. We choiced posix threads as a start point on linux kernel to verify the feasibility of the same approach, without intervening too deep on the kernel.
Thanks again for your interventions!
-- Primiano Tucci http://www.primianotucci.com
| |