Forums

are most RTOS message-based operating systems?

Started by John November 15, 2006
Are most modern RTOS message-based operating systems? For example,
VxWorks, or embedded linux OS? I try to understand how tasks
communicate with each other? My understanding is that tasks can
communicate via messages, or mails? Any other approaches?

please advice. thanks...

John wrote:
> Are most modern RTOS message-based operating systems? For example, > VxWorks, or embedded linux OS? I try to understand how tasks > communicate with each other?
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 <javacc1@gmail.com>:
> Are most modern RTOS message-based operating systems? For example, > VxWorks, or embedded linux OS?
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.
> I try to understand how tasks > communicate with each other?
Yes.
> My understanding is that tasks can > communicate via messages, or mails?
IMHO, that is the best way. It allows tasks to be easily inserted_into and detached_from a system.
> Any other approaches?
These are mostly non-intuitive and error-prone approaches. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
> > My understanding is that tasks can > > communicate via messages, or mails? > > IMHO, that is the best way. It allows tasks to be easily inserted_into > and detached_from a system.
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 http://www.tgi-sci.com ------------------------------------------------------ Boudewijn Dijkstra wrote:
> Op Wed, 15 Nov 2006 08:45:30 +0100 schreef John <javacc1@gmail.com>: > > Are most modern RTOS message-based operating systems? For example, > > VxWorks, or embedded linux OS? > > 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. > > > I try to understand how tasks > > communicate with each other? > > Yes. > > > My understanding is that tasks can > > communicate via messages, or mails? > > IMHO, that is the best way. It allows tasks to be easily inserted_into > and detached_from a system. > > > Any other approaches? > > These are mostly non-intuitive and error-prone approaches. > > > -- > Gemaakt met Opera's revolutionaire e-mailprogramma: > http://www.opera.com/mail/
John wrote:

> Are most modern RTOS message-based operating systems? For example, > VxWorks, or embedded linux OS? I try to understand how tasks > communicate with each other? My understanding is that tasks can > communicate via messages, or mails? Any other approaches?
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.
John wrote:
> Are most modern RTOS message-based operating systems? For example, > VxWorks, or embedded linux OS? I try to understand how tasks > communicate with each other? My understanding is that tasks can > communicate via messages, or mails? Any other approaches? > > please advice. thanks... >
If you need an example, Google for 'Minix'. -- Tauno Voipio tauno voipio (at) iki fi
Arlet a &#2013265929;crit :
> John wrote: > >> Are most modern RTOS message-based operating systems? For example, >> VxWorks, or embedded linux OS? I try to understand how tasks >> communicate with each other? My understanding is that tasks can >> communicate via messages, or mails? Any other approaches? > > Some OSes communicate through messages.
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.
Lanarcam wrote:

> >> Are most modern RTOS message-based operating systems? For example, > >> VxWorks, or embedded linux OS? I try to understand how tasks > >> communicate with each other? My understanding is that tasks can > >> communicate via messages, or mails? Any other approaches? > > > > Some OSes communicate through messages. > > More precisely, tasks communicate through messages. All RTOS I have > used for the past twenty years provided this mechanism.
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.
On 14 Nov 2006 23:45:30 -0800, "John" <javacc1@gmail.com> wrote:

>Are most modern RTOS message-based operating systems? For example, >VxWorks, or embedded linux OS? I try to understand how tasks >communicate with each other? My understanding is that tasks can >communicate via messages, or mails? Any other approaches?
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
"Darin Johnson" <darin@usa.net> writes:
> John wrote: > > Are most modern RTOS message-based operating systems? For example, > > VxWorks, or embedded linux OS? I try to understand how tasks > > communicate with each other? > > 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.
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.