This technical overview by veteran real-time lecturer David Kalinsky examines a number of directions in which RTOSs continue to change and mature. Two main directions are alternative task scheduling algorithms, and intertask communication via asynchronous direct message passing. In order to keep at a practical level, the focus is on trends and features that can be expected to appear in RTOSs soon.
Whitepaper: “New Directions in RTOS Kernels”
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
and intertask communication via asynchronous direct message passing.
Just like DragonFly is getting…
“Just like DragonFly is getting…”
i think thats a early effort.
Didn’t read it thoroughly, but some of the things I gleaned from it make it sound a lot like QNX.
Like I said, didn’t read it thoroughly. The only thing that sounds like QNX is the message passing bit. I don’t think a lot of people get just how simple it is.
Is it just a matter of scheduling guarantees that normal OSs don’t necessarily provide?
i think thats a early effort.
Funny that comment. Last time I checked, they had already made excellent progress here (IIRC, they call it CAPS, the userland implementation of their Light Weight Kernel Threading subsystem.).
DragonFly will have a complete implementation of this ages before say, Linux.
I could not QNX stand alone on this.
When oh when will my desktop run on a RTOS. Ode for BeOS, my old friend, we barely knew you.
Linux has already been given RTOS bindings, mind you it’s a specialised distro that costs a tonne of money.
Linux has already been given RTOS bindings, mind you it’s a specialised distro that costs a tonne of money.
Both Linux and the BSDs (well, FreeBSD and DragonFly for sure, probably NetBSD as well) have some real-time capabilities, however, none of them are hard real-time OSes. This article talks about “intertask communication via asynchronous direct message passing,” for a modern approach to hard real-time which, of the OSes I mentioned, only DragonFly currently makes extensive use of (to be fair, they are still working on some of their message passing infrastructure, which is not currently async (system call messages), and they have yet to convert their VFS subsystem over to the new messaging infrastructure.).
And you know that Linus has no plans to make the kinds of massive modifications that the DragonFly folks are currently undertaking.
Oh, and one more thing, like you mentioned, “mind you it’s a specialised distro that costs a tonne of money,” whereas all of the equivelent stuff in DragonFly is in it’s stock, vanilla kernel.
Anybody know what’s up with Amiga lately? They were plannign to use QNX werent they?
Why talking about future when describing the Amiga OS which was selling 19 years ago ?
Why using “rich” words to describe simple things.
Amiga is all what is described, just he had not virtual memory, and just one sheduling type.
The main author of DragonFly is one of the best known Amiga programmers. No doubt he wants to retreive some of the paradise.
About QNX, it is very nice, but just released asynchronous message passing (was synchronous before). Amiga had it from beginning. QNX brought a very nice/simple/powerful concept above the kernel, the resource manager.
Due to the kernel beauty==simplicity, programming Amiga was so easy, so simple, had a so small/coherent API, that i never saw this after.
Its pre-emptive RT OS made immediat responses to the user.
Seeing all the efforts of everybody trying to do complex things to resolve simple problems, I am always tempted to tell them: examine fully the Amiga OS and you’ll have an idea how simplicity can resolve what is big problems for others.
My dream for future is to see Amiga-like systems with as many users as Linux or Windows, so computers will perhaps become a really exciting thing.
I don’t know if it is nostalgy or not that makes you say so, but I do remember that AmigaOS had not memory protection, which means that a bad process could take down the whole OS!
It ‘s simpler yes, but here it was too simple!
Also I wonder what is so special about asynchronous message passing vs other interface?
I’ve used SysV message queues but it isn’t very different than using other interfaces..
“Also I wonder what is so special about asynchronous message passing vs other interface?”
It’s a simpler abstraction that allows one to do more with less coding, and less debugging. For an example, recently there was mention on the FreeBSD mailing lists about how DragonFly’s IPI messaging subsystem could replace roughly a dozen different IPI systems currently employed in FreeBSD 5, and would allow the coders to spend more time adding features instead of spending time hunting down and trying to fix obscure but serious bugs that resulted in the use of a larger number of different, and more complex interfaces.
Also as DragonFly is demonstrating, it (the messaging subsystem) can replace (an estimated) 90% of the situations where mutexes or other locking is used in FreeBSD, resulting in the CPUs doing more useful work in fewer steps, and coders not having to worry about lock order issues, deadlocks, or global contention for shared resourses, among other things.
Of course there’s more to DragonFly than the messaging system (like the serializing tokens, the threading model, etc.), but theres a few answers to your question at any rate.