New Kind of RTOS

New Kind of RTOS

Post by Rabih Chra » Mon, 03 May 2004 00:27:10


Hi,

We have developed a new kind of RTOS based on the concepts of priority
functions and priority objects.

The main goal behind this RTOS is to simplify the programming of embedded
systems, to enable cleaner designs, and to improve performance. The
complexity that arises from the traditional use of "tasks" or "threads" is
partly eliminated.

More details and software can be found at http://www.yqcomputer.com/

Your feedback on this RTOS would be greatly appreciated.

Regards,

Rabih Chrabieh
 
 
 

New Kind of RTOS

Post by eventheli » Mon, 03 May 2004 11:00:13

Looks interesting. Not clear how priority objects would work.

I completely agree that tasks are not important in a real-time and
embedded system environment.

Tasks store their context in stacks while typical embedded system
maintain
their context in a state machine.

Lot of work in embedded system design is "invented" by dividing the
problem
into tasks.

Sandeep
http://www.yqcomputer.com/
EventStudio 2.0 - Real-time and Embedded System Design CASE Tool

 
 
 

New Kind of RTOS

Post by Herman Bru » Mon, 03 May 2004 15:52:07


A first reading suggests to me that your priority functions are very much
like the "tasklets" and "timers" of realtime Linux (RTLinux/GPL and RTAI).
Is this correct?

Herman

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
< http://www.yqcomputer.com/ ~bruyninc> Tel: +32 16 322480
 
 
 

New Kind of RTOS

Post by Rabih Chra » Fri, 14 May 2004 07:59:04

> I'm not sure the example, as shown,

You can find more examples and details in the whitepaper
http://www.yqcomputer.com/



What is ADT?
Remember that semaphores mean priority inversion... something that is far
from clean...
Check this article on the problems of priority inversion:
http://www.yqcomputer.com/

A copy of the object on the stack of the accessor? What if it is a large
structure of data?



Source code example of a modem (layers 1, 2, 3 and more) implemented using
PORTOS can be found at:
http://www.yqcomputer.com/




There is no interrupt poll loop. There is a separate context of execution
similar to what is used by SWI (Software Interrupts) in some RTOSes.

Rabih Chrabieh
 
 
 

New Kind of RTOS

Post by Rabih Chra » Fri, 14 May 2004 08:09:31

> Looks interesting. Not clear how priority objects would work.

In a very simple manner.
A priority object is, for example, a data structure of a modem's layer 2
(L2). You can create multiples instances of this data structures to run
different services. Inside each instance you store the priority level of the
corresponding service. One L2 instance can run at high priority while
another L2 instance can run at low priority.

Any time you call an L2 function (method), you give it the priority level of
the L2 instance. The L2 function (actually a priority function) thus
inherits the priority level of the object. In other words, it asks the
scheduler to run at the required priority level.

All this may sound complicated but is actually really simple. Check out the
source code example in the software
http://www.yqcomputer.com/

Rabih
 
 
 

New Kind of RTOS

Post by Rabih Chra » Sun, 16 May 2004 17:41:36

Herman,

I can see your response on one news server but I can't see it on my
usual news server! I guess my server is not logging all messages! Sorry
for the late reply.

"tasklets" are indeed similar to "priority functions". In some RTOSes
they are called "Software Interrupts". In others "Link Service Routine".
Etc.

What we have done in PORTOS is to generalize the concept and make the
code mainly centered around "priority functions" and "priority objects".
In Linux, tasklets are given little importance while in PORTOS the
"priority functions" are at the heart of the RTOS. For instance,
"tasklets" eventually post a semaphore and the hand is given back to the
"tasks". In PORTOS there are no sempaphores (or are seldom used).

Our claim is that the code will be cleaner and more structured in the
end when avoiding tasks and their complexity. Our idea is that tasks
will only be used by different software applications (not within one
application), in order to achieve time-slicing (if needed), MMU memory
protection, or multi-processing. But within one application running on
one CPU there is usually no need for that. So relying on semaphores,
mailboxes, and priority inversion to write real time code is a killer.
Every sub-process in a real time code has an inherent priority level.

"Priority functions" act like a multi-priority service queues. The
server is the processor, the service provided is the function itself,
and the data is the message or object passed to the function.

Rabih Chrabieh


----
> We have developed a new kind of RTOS based on the concepts of priority
> functions and priority objects.
>
> The main goal behind this RTOS is to simplify the programming of
> embedded systems, to enable cleaner designs, and to improve
> performance. The complexity that arises from the traditional use of
> "tasks" or "threads" is partly eliminated.
>
> More details and software can be found at http://www.yqcomputer.com/
>
> Your feedback on this RTOS would be greatly appreciated.
>
A first reading suggests to me that your priority functions are very
much like the "tasklets" and "timers" of realtime Linux (RTLinux/GPL and
RTAI). Is this correct?

Herman

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
< http://www.yqcomputer.com/ ~bruyninc> Tel: +32 16 322480
 
 
 

New Kind of RTOS

Post by Herman Bru » Sun, 16 May 2004 20:29:29


[...]
SO, why inventing yet another name? This is unnecessarily confusing.


The _importance_ is decided by the application programmer! They exist in
(relatime) Linux, so if you think they are important, just use them :-)

WHy not? Semaphores are one sort of synchronization that is _semantically
needed_. So, an RTOS should have them. Probably, you just use the same
semantic structure somewhere but give it another name? I wouldn't call that
innovative :-)


I beg your pardon...? Ever tried to code a complex machine control
application?

I agree that this approach is sometimes cleaner, but I need no "new" RTOS
to use it. And I don't think you will ever be able to find a "market" for
Portos, because it doesn't _really_ offer something new.

Herman
 
 
 

New Kind of RTOS

Post by Rabih Chra » Mon, 17 May 2004 19:23:26

erman, I still can't get your messages from my usual news server! Sorry for
starting another thread each time.



This is like saying "why invent C when you have Assembly Language". Or why
"C++ when you have C". Or why "Java when you have C++". Or why "Python when
you have Java".

Or why a C "function" is called a "method" in C++?
Or why a C "struct" is called a "class" in C++.

Each programming language serves a particular need. Each language has its
own set of naming convention that fits the sort of things you are trying to
do. A "method" is a more suggestive name for the purpose of object oriented
programming. A "priority function" is a more suggestive name for the purpose
of the RTOS we have developed. It also brings forward the concept of
"priority object".

Note that when we created PORTOS we didn't know about "tasklets" in Linux.
This is the first time I hear of it. I searched the Internet to answer your
email. I am used to the more common terminology "Software Interrupts".



Well, they are probably not exactly the same to start with. Notice that
"within" Linux there are 3 different names for things that essentially do
the same: tasklet, bottom half, and softirq. But they differ in subtle ways.

Also notice that a "task" can be called "thread" sometimes, or "process"
other times. The fundamental concept is again the same. But one can be
light, another can be heavy, etc.

Also, you can write object oriented programming using the C programming
language. But almost no one does it because people are not used to it. The C
language does not clearly provide the tools to do so. Likewise, you can
easily write non-portable, non-upgradeable Real Time code if you are not
very careful with the software architecture. We claim that "priority
functions" and "priority objects" help you write portable and upgradeable
code. If you don't believe us, that is your problem :).


that

We don't have semaphores in PORTOS. This is an important difference between
a task-based architecture and a priority function-based architecture.

Say you receive a new message M1 in the system.
In PORTOS, you just call the priority function (ie, routine) that handles
the message M1.
In the task model first you post a semaphore. The semaphore awakens a task.
The task receives the message M1. It then dispatches the message M1 to the
appropriate sub-task. (Often within one task there are sub-tasks because it
is too heavy to define a task for each sub-task).

Now say that before message M1 is done, a second similar message M2 is
received in the system. And say that M2 has a higher priority than M1.

In PORTOS, you just call the same priority function again to handle M2. You
give it the new priority level it needs. Here's where the concept of
"priority object" is nice. M2 is an object that has a different priority
level than M1. The same priority function will handle both messages, but
each at the requested priority level.

In the task model, you are in trouble. Defining a different priority level
for M2 becomes a headache for the programmer. He needs to define two tasks.
Each will run at a different priority level. Each will need a different
stack. If you create dynamic tasks, this is too slow. If you create
beforehand all the tasks for N possible priority levels, this is too heavy
on memory.

All this and much more is explained in the whitepaper
http://www.portos.org/doc/whitepaper.pdf.

For instanc
 
 
 

New Kind of RTOS

Post by Rabih Chra » Mon, 17 May 2004 19:47:26

Herman, I am reading more on tasklets.
They are pretty different from "priority functions".
Sorry for the confusion.
tasklets don't have specific priority levels! (they run within an interrupt
level).
They run "one at a time in a serial fashion" (on a given CPU).

This is way too different from priority functions.

Softirq in Linux are a bit closer to what I denote by priority functions.
But again, they don't seem to have a specific priority level. They run at
the hardware interrupt level that generated them. Also, there is a total of
32 softirqs. The whole idea behind PORTOS is to have an infinite number of
priority functions, and with almost infinite number of priority levels.

So with respect to Linux I can say that PORTOS is substantially different.
An equivalent to the priority functions "sheduler" does not exist in Linux.
Nor in any RTOS that I know of.

Rabih
 
 
 

New Kind of RTOS

Post by wkara » Wed, 19 May 2004 05:13:20


Can the major selling point of this OS be summarized as "people
often make the mistake of using tasks as way to subdivide a software
system into modules, so, it's a good thing to completely eliminate
tasks"?

Suppose my application was implemented using an event-based design,
and all events with the same maximum latency to handle were processed
by the same task. (That is to say, one task per event priority queue.)
What would be the advantage of switching to this OS? For data
structures manipulated by events of different priorities, what would
be the substitute for mutex semaphores in this OS?
 
 
 

New Kind of RTOS

Post by Rabih Chra » Wed, 19 May 2004 21:19:36

> Can the major selling point of this OS be summarized as "people

Sort of.
But we aren't suggesting to completely remove tasks. Priority functions
"complement" tasks. Sometimes you still want to use tasks. Examples are when
you need time-slicing, MMU memory protection, or multi-processing.


Some advantages of priority functions:
- no stack allocated per task so you save memory.
- no context switching between tasks so you save MIPS.
- no sub-tasks within a task so your design is easier. Each sub-task in
PORTOS is a separate and independent priority function. You can't do that in
a task-based model because you will have too many stacks, context switches,
mailboxes, etc.
- no mailboxes to worry about. No message dispatchers to design. Your
routine is simply called as a priority function (ie, as a function) and any
messages it needs are passed as arguments.

As far as mutex semaphores are concerned, you can't use that in PORTOS (in
theory PORTOS can be upgraded to allow for mutex semphores but this defeats
the original purpose of having a clean design).

Instead of mutex semaphores, you can use one of two methods:
- the priority ceiling mechanism, which is becoming pretty common in modern
RTOSes. In other words, you raise the priority level over the critical
section. This prevents the annoying problem of priority inversion.
- or a dedicated priority function handles a shared global data or resource.
The priority function runs at a fixed priority level. Any modifications to
your shared global data are therefore processed serially by this priority
function. This is fundamentally much cleaner than locking the resource with
a mutex semaphore. The priority function implicitly (and simply) acts like a
queue of requests to modify the shared global data. Note that if you give
this priority function a low priority level, any modifications to your
shared data will occur at a later time when higher priority processing is
done.

If this is unclear please feel free to ask more questions.

Rabih Chrabieh
 
 
 

New Kind of RTOS

Post by Rabih Chra » Wed, 19 May 2004 22:24:18

eply to Les Cargill.

Sorry for the late reply Les. I am again having this problem where I don't
receive some messages on my usual news server. Does anyone know how to fix
the problem?

software interrupts is a
equivalence.

The name "priority function" is not really a new name. It is simply an
extension. A priority function is:

1) a function
2) it has a priority level

A priority function is any C function. We just execute it at the chosen
priority level. So we didn't really invent a new name.
We claim that "priority functions" and "priority objects" help you write
portable and upgradeable code. If you don't believe us, that is your problem
:).

it's better. And "avoiding
serious problem for good designs.

:)

I can summarize the benefits as follows:

- Less stack space.
- No context switches and hence higher performance.
- More modular code because every sub-task is an independent priority
function, while several sub-tasks are grouped into one task in a task-based
model.
- No mailboxes for inter-task communication. Messages are simply the
arguments of the priority function (a priority function is simply a
function).
- No need for message dispatchers between tasks and between sub-tasks.
- Priority functions are equivalent to very lightweight tasks. Very
lightweight means more flexiblity. For instance a timer application running
on top of priority functions is more efficient, simple, and flexible than a
timer application running on top of tasks. Likewise for a user interface
module. Likewise for a host port interface module. Etc.

Assume you want to write a "user interface" module that can call routines in
your embedded application. In a task-based module, routines run inside
tasks. We can refer to routines by sub-tasks. So you have to create messages
to the tasks and sub-tasks. You have to be careful at what level the
routines will run and how they will affect other routines running within the
same task. If you move a routine from one task to another, you have to
rewrite all your messages. Unless you have been careful at designing some
centralized way of messaging. This is not that easy.

In PORTOS, a "user interface" calls the routine directly. As simple as that.
If you upgrade the software, nothing changes as far as that routine is
concerned. There is no interaction between this routine and others.


Exactly.

serialization - I'd have

I am not sure I understand the question. A device driver can run in one (or
several) priority function just like it would run in a task. An ISR can
schedule a priority function. The priority function gets called in its own
context once the ISR is done. Just like a Software Interrupt would get
called. So there is serialization (if I understand your question).

fire coherent and

Again I am not sure I understand the question. Accessing a critical section
from interrupt is a problem for both PORTOS and task-based RTOSes. One
solution is to lock interrupts. Another solution is to:

- in a task-based RTOS: post a message to a task that accesses the critical
section.
- in PORTOS: schedule a priority function that accesses the critical
section.

The neat thing in PORTOS is that scheduling a priority function doesn't cost
much in terms of performance nor in terms of amount of code to write. In a
task-based model, posting a message results in several context switches
(waking up tasks and sleeping others), and plenty of code to wri
 
 
 

New Kind of RTOS

Post by Tom Sheppa » Wed, 19 May 2004 23:17:36

In article <c8cv19$ioo$ XXXX@XXXXX.COM >,



I haven't had time to read through this entire thread or to review your
web site in detail but the above line caught me eye.

These priority functions sound like the shared procedures I wrote into a
custom RTOS in the late 1970s. I think my work was based on another
commercial RTOS whose name escapes me. As such, I wouldn't call priority
functions a new idea.

I used a shared procedure to control an old AMD math chip that couldn't
be preempted in the middle of a calculation because its complete state
could not be saved during a task switch. Each calculation was sent as a
list of commands and conditionals that was executed in series in the
shared procedure. The procedure ran to completion under the context of
the task whose code called the procedure.

Presumably there's more about your RTOS than priority functions that
makes it a new kind of RTOS.

On your web site I noticed this line, "When writing a function or a
software module, the programmer can forget about the rest of the
system." I trust you mean with regards to logic only, not execution
time, memory consumption, system calls or other resources that are used.
Any programmer that deliberately ignores the rest of the system when
designing and coding wouldn't last long in the places I've worked.

I'll try and get time to take a closer look to get a better context for
your statements.

...Tom

--
Tom Sheppard
Real-Time Fundamentals instructor-led and web-based training courses
http://www.yqcomputer.com/
 
 
 

New Kind of RTOS

Post by wkara » Thu, 20 May 2004 03:33:16

Rabih Chrabieh" < XXXX@XXXXX.COM > wrote in message news:<c8cv19$ioo$ XXXX@XXXXX.COM >...

Is a priority function any different from a regular function that saves
the current priority in a local variable, sets a higher priority, then
restores the saved priority on exit? (In C++, this priority save-and-
restore could be accomplished by a single line declaring an instance of
a "Pri_save_restore" class at the top of the function.)

Suppose you had three tasks: A (lowest priority), B (middle priority)
and C (highest priority). Suppose that A and C need mutually exclusive
access to a shared data structure. If mutual exclusion is done by
raising A's priority to the level of C's (either explicity or implicitly
by calling a priority function to access the data structure), the result
is an undesirable priority inversion between A and B. It seems clearly
better for A and C to use a mutex semaphore with priority inheritance.

Can you give a quick example of a case were you'd want to call a priority
function as opposed to a regular function, other than as a (seemingly
inferior) way to do mutual exclusion?
 
 
 

New Kind of RTOS

Post by Rabih Chra » Thu, 20 May 2004 07:32:23

> Is a priority function any different from a regular function that saves

I haven't heard of this C++ priority class. I am not sure what's this about.
In any case, you need a relatively complex scheduler to handle priority
levels so I don't think it is as simple as creating a class that saves and
restores priority levels. For instance, what if the priority level is lower
than the current priority? Then a database has to store the function call in
order to call it later. You also need hardware interrupts for all this to
work. Hardware interrupts create the (virtual) priority levels.


I think what you've said is incorrect (unless I misunderstood you). A mutex
semaphore results in a similar behavior. Just like a priority function or a
priority ceiling (that modern RTOSes recommend) would, a mutex sempahore
implicitly raises the priority level of task A.

And priority functions are "superior" because they can do more. Instead of
raising the priority level of A, they could decrease the priority level of
C. This means that the shared data can be processed at a lower priority
level (sometimes this is the desired behavior). You can achieve the same
with tasks but it is too costly with tasks. With priority functions it comes
for free, effortlessly.


As mentioned above, priority functions are actually superior, not inferior.
They can do more, not less.

Priority functions are not only used for mutual exclusion! They are used
whenever a task or sub-task is used. E.g., you can run layer 1 of a modem at
priority level 1. Layer 2 at priority level 2. Layer 3 at priority level 3.
You can also run a user interface at priority level 4 (e.g., printf).

If you call all functions directly instead of calling them (or some of them)
as priority functions, then all your code runs at a fixed priority level.
This means one printf could delay an urgent layer 1 demodulation.

Rabih Chrabieh