are most RTOS message-based operating systems?

I don't know which is most common, you'd have to count them all up and do the percentages. Most have at least some way of doing process synchronization, almost all of which can be built using any of the others. Ie, message passing can be built on top of semaphores if you've got shared memory. A lot of these things are just variants on others or different names for the same things (a mutex is just a binary semaphore).

My gut feeling is that semaphores/mutexes are the most commonly provided service for this.

-- Darin Johnson

Op Wed, 15 Nov 2006 08:45:30 +0100 schreef John :

Generally speaking, 'classical' OSes are not message-based, and 'modern' OSes, designed after the VME era, are message-based. I know of two purely message-based OSes: OSE (from ENEA) and Sciopta. Most likely Neutrino (from QNX) is also 'modern', but I'm not sure whether it is message-based.

Sadly, many engineers are conservative and/or lazy and/or under influence by conservative engineers, making classical OSes the most common AFAICS.

Yes.

IMHO, that is the best way. It allows tasks to be easily inserted_into and detached_from a system.

These are mostly non-intuitive and error-prone approaches.

I tend to agree with that, although "best" may be a little too general.

I can speak for myself only - I chose to implement both message passing and shared memory, so one can choose - or combine both - during application programming. I tend to use message passing for inter-application communication and a mixture of both when I write an application which runs as multiple, but aware of each other tasks. Typically, the main task sets a non-default common data section (the default would be that of the parent task) and spawns the rest of the application tasks when needed. This gives some programming freedom and can be used to accellerate inter-task communication (I am not sure I have used it for that purpose, though :-). For general system purposes, though, e.g. mouse activities which the system has to signal to the task of interest, I use messages. This makes event queueing both easier and application code controllable, etc. Another way I use is "object specific", but this has to do with the DPS internal object handling system so there is no point discussing it yet (prior to making DPS available for some wider-spread platform, that is, I had two projects stuck at the customer side recently so this will have to wait for another while... ).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Boudewijn Dijkstra wrote:

Some OSes communicate through messages.

The other approach, which is used in Linux for instance, is to have a shared memory, and avoid mutual access by using locks or semaphores.

Both approaches will work. Message passing is an elegant and simple solution to relatively simple problems. Complex problems that require high-performance can often be implemented simpler with shared access and locking.

If you need an example, Google for 'Minix'.

More precisely, tasks communicate through messages. All RTOS I have used for the past twenty years provided this mechanism.

The real problem doesn't lie with the OS but with the application. One issue for instance is whether you allow messages to be queued and processed with a delay or not. Another one is what should you do when a queue is full or when the pool of available buffers is empty.

There are applications such as transmission protocols for which messages are well suited. Others like control are best implemented with periodical tasks and shared variables.

I was actually talking about the OS internal structure. Some have the OS divided into various tasks, and a kernel that is responsible for passing messages from one part to the other. Others are monolithic, but may still allow user/application tasks to communicate with each other through messages. This distinction also applies to the kernel/application boundary. When executing a system call, you can actually send a message to the OS and switch context, or you can have the user process enter the kernel on its own context.

Communication methods are myriad.

Message-based systems, those where most of the operating system is built on top of, and relying upon as a core feature, message passing via queues have an advantage in that they can be more easily scaled across networked processors. If a process needs to pass a message to another, it's not required that the two processes reside on the same system that way, for example, and they don't even need to know that fact so long as there is an addressing scheme that is consistent. This can break down even to the level of function calls so that if calling a procedure is a matter of such messaging, nothing much breaks when that procedure resides somewhere else, for example. The message is forwarded, but the calling application doesn't have to know that. Remote procedure calls are an example. There is a cost to it, in terms of memory footprint, complexity, execution time, latency, turn around time, etc, though. So it depends on application, whether or not it's a better model choice.

In terms of the broader meaning of 'messages,' it is possible to use a very simple, non-queued, non-synchronous method that is little more than a 'register' in the process structure residing on the same system. A message word is written, if desired. If another message word is written before the receiving process gets the prior message, the old message is simply over-written. It's simple and it is effective for many applications. Cost is low, execution time is low, etc. And one can get by with it. And it is 'messaging.'

Other methods would include shared memory, but also depend on what you actually mean by a process. A thread, by this I mean a case where there is shared static data areas but separate stacks, works well in terms of using the shared static area for communication, with some kind of guarding concepts in place (and even that, varies.)

But communication can technically be anything from just finding a way to synchronize two processes to passing encyclopedias back and forth. It can be about only control, only data, or any combination of the two. And probably more than I can think of.

Use your imagination.

Jon

Somewhere there has to be synchronization primitives provided. After that, all else is embellishment. Message-passing is just a somewhat formalized shared memory scheme.

There are two message-passing schemes: pass-by-value and pass-by-reference. The latter passes a pointer from the sender to the receiver and the sender can't alter the message content until an acknowledgement of the receiver being finished with it is received. The former copies the message body from the sender's area to the receiver's message area thus making the sender's area immediately available for other uses.

shared memory ?? Ah, yes OSE provides semaphores if you mean this by shared memory.

Sciopta --------------- Signals with buffers

Note: OSE and Sciopta use direct message passing, no intermediate mailbox needed.

I liked this one...

So much I tried to paraphrase it into a plausible (pronounceable) acronym for future usage, such as:

SPOCWIACS

(Stinking Pile Of Crap Wrapped In A Candy Shell)

(I was considering using "Steaming" for the first word, but the Candy Shell probably wouldn't hold up)

There must be some good ones out there with a similar theme, seeing how universally applicable the concept is: e.g. political platforms, company benefit packages, Microsoft operating systems, etc...

Most modern RTOS, especially those claiming to be Microkernel based will use some form of Message passing in the OS Kernel somewhere especially if they are the more sophisticated type offering services such as networking and filesystems. Whilst message passing provides good benefits such as maximum configurability and strong preemptivity the overhead in message passing is always noticeable so most of the core services in the microkernels are kept in a Nucleus which use regular calling mechanisms and copyless message passing. I have worked on full unix microkernelised O/S were after serverisation a routine syscall was 300% slower - in general I think that ever faster microprocessor clocking is supposed to soak this kind of impact up allowing for ever sophisticated software design?

I have been working on a set of slides about embedded systems which includes this type of discussion and covers the various linux based approaches I would expect some small fee for them 40$ - if I get enough of a response I could finish them and send them out to requesters.

Cheers. dmctek.googlepages.com

John wrote:

Most modern RTOS, especially those claiming to be Microkernel based will use some form of Message passing in the OS Kernel somewhere especially if they are the more sophisticated type offering services such as networking and filesystems. Whilst message passing provides good benefits such as maximum configurability and strong preemptivity the overhead in message passing is always noticeable so most of the core services in the microkernels are kept in a Nucleus which use regular calling mechanisms and copyless message passing. I have worked on full unix microkernelised O/S were after serverisation a routine syscall was 300% slower - in general I think that ever faster microprocessor clocking is supposed to soak this kind of impact up allowing for ever sophisticated software design?

I have been working on a set of slides about embedded systems which includes this type of discussion and covers the various linux based approaches I would expect some small fee for them 40$ - if I get enough of a response I could finish them and send them out to requesters.

Cheers. dmctek.googlepages.com

John wrote:

Most modern RTOS, especially those claiming to be Microkernel based will use some form of Message passing in the OS Kernel somewhere especially if they are the more sophisticated type offering services such as networking and filesystems. Whilst message passing provides good benefits such as maximum configurability and strong preemptivity the overhead in message passing is always noticeable so most of the core services in the microkernels are kept in a Nucleus which use regular calling mechanisms and copyless message passing. I have worked on full unix microkernelised O/S were after serverisation a routine syscall was 300% slower - in general I think that ever faster microprocessor clocking is supposed to soak this kind of impact up allowing for ever sophisticated software design?

I have been working on a set of slides about embedded systems which includes this type of discussion and covers the various linux based approaches I would expect some small fee for them 40$ - if I get enough of a response I could finish them and send them out to requesters.

Cheers. dmctek.googlepages.com

John wrote:

Actually you do need both "copyless" and "copied" message passing. The former obviously saves overhead, the latter comes handy when the mesage is passed by a task which will get killed possibly prior to its message has been processed by the recipient and (the message) resides in memory which will be deallocated when the task is killed.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

dmctek.googlepages.com wrote:

"you can shellac it and paint it colors, but if you poke at it, you'll find that it's still a turd."

(in fererence to a popular GUI OS)

or you can consider it the senders role to make a copy to send if it needs to maintain an un modified version of the message.

In the case of DPS, it is indeed the sender which does the copying, the copying code being part of the recipient PSCT, though. IOW, the sender does a system call which will transfer the message, and the system takes care of calling the respective code in the recipients program module. Typically, I have two files I link for such purposes, std and qstd, the latter does queue the incoming signals while the former does not (it will time out if the recipient task has not processed the last incoming message for some time; well, so will the qstd as well, but after the queue has been filled up :-). But like I said earlier, this is only one way I use for intertask communication in DPS. I also do a lot of "object specific" exchanges, which are mostly using commonly accessed memory pieces with atomic locks.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

jacko wrote:

Most modern micro kernel based operating systems are message passing based.

VxWorks and Linux are not micro kernel based ...Minix 3.0 and QNX are.

--Armin