are most RTOS message-based operating systems?

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 �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.