OOSMOS stands for Object-Oriented State Machine Operating System. It is a new type of operating system where the fundamental contextual unit is the object, not the thread as it is in traditional operating systems.
Because there are no threads, there are no thread stacks, so OOSMOS is ideal for use in memory constrained environments where a traditional thread-based operating system is not a viable option.
Yes, it’s object oriented, but it’s written (or seems to be) with defined states and transitions on top of the OO.
Well the idea is that each “task” is an object that knows how to act on its state and set the next state.
I think the creator is stretching things to say it is completely new. It is of a piece with message oriented and event oriented systems that have been around for a long time.
That being said it is an interesting little system and could be quite useful.
jockm,
I agree, it seems very similar to asynchronous event oriented code. It takes the state machine concept and makes it explicit.
While I’ve merely glanced at this project, I’m actually a proponent of the model in general because it avoids concurrency problems and multitasking deadlocks quite nicely. Not to mention threaded code doesn’t scale as well as state machine code, which is one of the big motivations for asynchronous programming over multithreaded programming.
Many devs prefer solving problems with sequential tasks rather than building state machines though.
Do you even know what asynchronous and event oriented actually mean? Nothing about this task switcher is asynchronous and the only event described is a kernel tick!
You don’t think that state transitions can be considered events?
Micrium actually sells two different RTOSes. A CPU tick event is syncronous and does not respond to external events or interrupts. The architecture described is not new, does not use less resource, and it’s just a task switcher. I did quote you a valid source to read, which you didn’t before you responded.
I did read the article you posted, it doesn’t cite any sources and only pertains to the MIPS4K CPU.
None of which changes the point that you listed a vendor and not a OS. I was just trying to clarify that. You will also notice I didn’t list the roman numeral (II or III) so I could refer to both versions of uC/OS.
It really feels like you want to give and get offense at every oppertunity
Also I didn’t say anything about sync or async, I said that state transitions in this case can be considered events.
Please confine your responses to what I actually say.
Erlang ?
In short, instead of scheduling threads (which boils down to switching stacks) like in a traditional OS, you “schedule” by following state transitions, transforming object state as you go and thus moving the system forwards.
Excellent idea for the intended target: memory-constrainted embedded systems. The fact that they have a system in place for putting state machines on multiple cores (with affinity management) is highly attractive.
This is innovative OS stuff with an actual implementation. I’m rather intrigued.
From what I can see, that loop is called a “Round-Robin scheduler”, and the objects are processes with state.
It is a new type of operating system where the fundamental contextual unit is the object, not the thread as it is in traditional operating systems.
There is nothing new about this cooperatively driven, round robin scheduled, task switcher. It’s basically just running one thread with a queue. Big deal. Any small OS for microcontrollers can do this and much more. This type of round robin scheduling is just like a traditional microcontroller program and can’t provide RTOS-like responsiveness. Nothing intriguing here.
OOSMOS is ideal for use in memory constrained environments where a traditional thread-based operating system is not a viable option.
Like what type of environment? There are multithreaded OS’s that take up just a few K of memory and run on the smallest processors, like FreeRTOS, Micrium and others.
Like micro controllers where every byte counts and every watt spent counts even more.
Multi threaded and OO kernels actually save resources and provide better responsiveness than round robin scheduling. This project is just an incomplete kernel. Like I said you can run many small RTOSes on very small microcontrollers and still have plenty of application space. You don’t even need a kernel to do that type of scheduling.
You have some data to back that up? While I think it is possible that some multi-threaded and/or OO kernels can be better in those regards; I don’t think you can make a blanket statement on the matter.
You obviously don’t understand what you are talking about. With multi threaded systems you can respond to tasks much faster than round Robin and you also don’t have to write scheduling code which eliminates a ton memory consumption in your code. I laugh at you guys willing to accept every concept presented in a technical way as new and novel without questioning what is presented. “It would be so cool to make an OS based on this concept” why? So you would have an unresponsive memory hog?
First off, I asked you for data for your assertion, and what you give me is an argument. Where is your data?
Please point me to where I said anything like that.
All I said it was interesting, and it is. Writing embedded systems as state machines is a well known technique, there is nothing inherently wrong with the idea. Therefore an “os” that is built around that concept could be useful.
Nowhere did I give it a ringing endorsement.
Dano,
Redirecting and discrediting my education…is that really an argument? There is still a good opportunity for a real technical discussion and even debate, lets not drag this down into personal attacks.
Why, technically, do you feel that a state machine is an unresponsive memory hog? Why do you think it’s not event driven?
Edited 2015-09-06 14:44 UTC
Every microcontroller firmware that does not use an RTOS is written round Robin loop so you have written what everyone else has. If you think I criticized your education, you put that on yourself. Read my cited link before commenting again.
Edited 2015-09-06 15:46 UTC
Always a round robin loop? I will accept that most are, but it isn’t always the case. Plenty of embedded app only respond to hardware interrupts and thus aren’t scheduled at all.
Have have written code on resource starved processes that have used other scheduling approaches than simple round robin.
The problem with blanket assertions is that it only takes one exception to prove you wrong.
Even firmware that is completely based on IRQ service routines has a main loop with at least a no-op in it.You guys talk like you are an authority by saying things like “very interesting approach” when any computer scientist can see that what you are saying is completely ridiculous. Like our last conversation, where you try to show people that you know something by trying to incorrectly nit pick details, I’m done here. You can’t teach stupid.
An empty loop is not a round robin scheduler. Maybe this is just a nit to you, but it tells me you are either desperate to be right no matter what, or you don’t know as much about what you are saying as you think you do.
Building an entire OS around a state machine is interesting. You will notice I didn’t claim it was new or innovative, but interesting. Interesting doesn’t have to be useful, interesting doesn’t have to be better, interesting doesn’t have to be practical. It is just interesting.
But I notice you still haven’t provided DATA, just assertions and arguments
jockm,
http://www.osnews.com/thread?594594
Indeed
Dano,
The link discusses embeded processors improving support for multithreading. Although quite dated, that’s wonderful. The multithreading paradigm is popular and it’s great that hardware engineers are working on improving it’s efficiency. While it may look black and white in your head, the truth is that event oriented state machines can be loaded up in parallel to take advantage of these improvements as well.
If you have a specific issue with something being said, then I’d much appreciate it if you could point it out in your own words rather than with a link that doesn’t tell me what your issue is, ok?
Also, can you answer the questions I asked since I think it will reveal exactly where our disagreement lies.
Keep in mind, I specifically agreed this model is not new. I just find it interesting to read and talk about on osnews, that’s all.
Edited 2015-09-06 16:59 UTC
Well put!
You guys are asking me to prove that the existing architecture for every modern embedded system uses more resources than this idea presented as a new idea. The author of this task switcher claims that it uses less resources yet makes no claims or does no studies to support it. I could send you guys links and links about why the current multithreaded architecture is superior but you either wouldn’t understand the basic concepts or would say that the article doesn’t apply to this type of processor or whatever. Just Google articles on your own if you want to know the truth and question original unsubstantiated claims first before asking someone to disprove the claim.
1) I thought you were done
2) I asked for actual data and you didn’t give it to me
3) Please quote my exact words where I said that the “existing architecture for every modern embedded system uses more resources than this idea presented as a new idea.” or for that matter that I said it was a new idea (because my first comment on this post explicitly said it wasn’t)
Dano,
Let’s pretend he was here, what intelligent questions would you ask him?
I need to address this theme that we shouldn’t believe the OOSMOS author without questioning him first. First of all, why shouldn’t I apply this same standard to you by asking you questions before I believe you? Secondly, my opinion about the model is my own based on my own intuition and experience, I’m not blindly taking anybody’s word. I can speak for myself.
I really wanted to have a technical discussion about this. So if it’s at all possible, one last time:
What specifically makes you think the state machine model is an unresponsive memory hog? And what makes you think that it’s not event driven?
These questions are based on your earlier posts, so please answer them meaningfully or retract the assertions. Is that fair enough for you?
Edited 2015-09-06 19:40 UTC
Looks like Dano got found out and has gone into hiding until he figures out how he can dig himself out of his hole.
Well to be fair Dano did say he was done, and I know I have been guilty of saying that and then realizing I had a few more in the barrel.
Dano,
Not speaking for OOSMOS here, but the async state machine approach really shines in matters of scalability over threading. The “C10K” problem is an example of a problem where the multi-threading method scales very poorly.
http://www.kegel.com/c10k.html#threaded
lighttp and nginx can handle high loads because they don’t require more than one worker thread per core. In principal same benefits apply to kernel development.
Low end systems are rarely concerned with this kind of scalability, but another benefit would be reduced memory footprint. Each thread, even if it spends most of it’s lifetime sitting idle waiting for instructions, will require a stack that’s large enough to handle the most memory demanding task that thread will encounter.
I’ll admit that these days these easiest thing to do is to just add ram and/or faster cpus, but IMHO there’s nothing “Dumb” in building this kind of OS. I think it could make for a good choice in something like an IP router where cost drives component choices. Many routers are running so constrained that they don’t even have enough ram to keep track of NAT connections. Highly efficient software design can help.
Edited 2015-09-05 16:45 UTC
This is not an approach, just a single threaded task scheduler. Saying that multithreaded kernels are not as scalable as this system is totally ridiculous because this system can only execute one object for a set amount of time regardless of priority. This is not really an OS at all just a task switcher. Multi threaded systems are way more scalable because threads are scheduled on events and interrupts rather than time slices, which history has proven to be useless.
Edited 2015-09-05 21:28 UTC
Dano,
I haven’t looked at the code and I don’t know the implementation details. However going by the documentation claiming that OOSMOS state machines don’t have threads or stacks, I think you are factually mistaken. A state machine is suspended at any state between transitions. However only threaded code with a stack can be interrupted at specific time slices. Time slice “preemption” only applies to multithreaded code.
As far as priority and events go, state machines are almost always defined as event oriented, I have no idea why you think this is not event oriented, the linked intro itself confirms that it is. Also, there’s no technical reason they can’t implement event priority in the future, if they don’t already.
I quite enjoy discussing these sort of things but I get the distinct impression that your aim is to mock this project rather than discuss it.
Edited 2015-09-06 03:49 UTC
If you don’t understand the implementation details then how can you question the projects claims? A second year computer science student can see the problems with the project immediately.
It’s obvious Dano hasn’t looked at the source either. Having looked at the source, I can’t tell you what it’s doing because the source is completely obfuscated so as to prevent reading the code. Someone will have to reverse the obfuscation before anyone can actually say anything about the actual code.
What’s the point of obfuscating open source?!?! I hate it when programmers do that.
JLF65,
Well, I just downloaded the source and you are right, it’s a complete black box. This isn’t open source at all. How ironic, Dano would have had a much easier time criticizing the project on this basis
Actually, this isn’t open source of any kind… look at the license:
License
1 oosmos.h, oosmos.c, oosmos.cpp
Files oosmos.h, oosmos.c and oosmos.cpp, whether in obfuscated or plain text form, as well as the OOSMOS API, are:
Copyright (c) 2015 OOSMOS, LLC
All Rights Reserved.
He’s even claiming a copyright on the API! Any programmer can tell you that despite the CAFC, APIs are NOT copyrightable! I’d avoid this completely.
Yeah in execution the project has multiple strikes against them:
1) you have to fill out a form to download
2) obfuscated core IP
3) copyright on the API.
Those are some serious strikes against it. The creator has said they are willing to completely open source it if they get a corporate sponsor. I just don’t see how they are going to get one without being completely open source.
3) Not actually doing something new
4) Not actually being the first to open source similar ideas
5) Being an idea that is trivial to code from scratch
In short: nothing interesting even as a thought experiment, nothing new, nothing that can’t already be used.
Threads were first deployed in 1967, so every threaded OS since then wasn’t doing something new. The vast majority of everything isn’t new (open source or not).
But can you point to another OS/Executive that is oriented around state machines? It is unusual if not exactly new
Edited 2015-09-08 17:58 UTC
Megol,
Without the source code, this project is much less useful or informative, which is disappointing. But I think criticizing the underlying ideas as uninteresting is harshly overstating it. Something doesn’t have to be new to be interesting; weren’t you talking about mode13h in another article? Many developers, to say nothing of non-developers, don’t have much experience with this approach, which is all the more reason it should be discussed. At my university all they taught and tested us on was the threaded approach. I learned this model on my own and I do find it both interesting and relevant to scalable software design today.
Anyways I just didn’t want the discussion to end with the conclusion that nobody finds it interesting. I can only speak for myself, but in my opinion, this article was good food for thought, and I hope Thom continues to post more like it.
Edited 2015-09-08 18:23 UTC
Lightweight threads with growable stacks strike a nice balance, I find. Lets you scale while not making you rewrite your sequential code into callback gibberish (if that’s the alternative).
The tough bit is the context switching, but usually lightweight threads are found in languages that require a GC, so the GC safe points give you your ‘in’ to switch.
Micrium is a vendor, not an OS. The RTOS they make is uC/OS.
No stacks? PDP-8
strict cooperative scheduling? PDP-8
low memory requrements? PDP-8 (4K to a maximum of 32K 12 bit words)
Even though we didn’t call the tasks objects, that is what they were – maintaining their own state.
Definitely not new, just using a more modern language.
Edited 2015-09-06 12:47 UTC
http://www.embedded.com/design/mcus-processors-and-socs/4006701/Eff…
It doesn’t cite any sources, and it is only talking about a single processor.
I gave you an article with facts. There are thousands more on the internet. You are believing the author without questioning him first. His way has been done 40 years ago and was retired.
Edited 2015-09-06 17:51 UTC
You are replying to your own post, so who are you addressing.
IF you were addressing me, I never said that I was saying that this approach was better, I said it was interesting, and I said that you can’t make the assertion that multithreaded systems are ALWAYS more efficient.
Why did I say that? Because it depends on how the multithreaded system is implemented, and the particular use case.
The article you pointed to didn’t cite any sources, provide any benchmarks, or any real data. It just explained an approach specific to the MIPS 4K
Kirk: Scotty I need a monolithic kernel in 1 minute or we are all dead.
Scotty: Captain I can not change the laws of open source!
Bones: Its dead Jim.
hackus,
A bit of comic relief is just what the doctor ordered