are most RTOS message-based operating systems?

This will be helpful to you.
OSE              ---------------         Signals with buffers, shared memory



OSEK-VDK  --------------         Messages, Shared Memory



LynxOS        ---------------        Message queues, pipes, Sockets, Shared
memory



uITRON        ---------------------        Mailboxes, Data queues



QNX             ---------------------        Messages, pipes, queues,
Sockets



RTAI            ----------------------        FIFOs, Shared Memory



VRTX           ----------------------        Message queues, pipes, sockets,
shared memory



VxWorks      ----------------------        Message queues, pipes, sockets,
shared memory, RPC



--Hare



"Boudewijn Dijkstra" <boudewijn@indes.com> wrote in message
news:op.ti1ze1kuy6p7a2@ragnarok.lan...
> 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/

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.
> 
> 
The most toweringly bad system I ever had the misfortune to work on 
relied exclusively on message passing when it should have just written 
values to command registers (atomically, of course).  The software 
(well, the whole product, actually) was very much like a stinking pile 
of dog doo wrapped in a tasty candy shell -- if you didn't push it hard 
it seemed like a good thing, but if you tried to actually _use_ it you 
ended up with a very bad taste in your mouth.

Queue up messages if each message matters.  If the only thing that 
matters is the latest value of the command, then just write it to a 
shared memory location and be happy that you haven't screwed things up.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Thu, 16 Nov 2006 11:32:56 +0530, "Harsha" <sriharshab@gmail.com>
wrote:

>This will be helpful to you.
>OSE              ---------------         Signals with buffers, shared memory
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.


-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:TZSdndF5SfpHksHYnZ2dnUVZ_uGdnZ2d@web-ster.com...
> ... The software (well, the whole product, actually) was very much like a 
> stinking pile of dog doo wrapped in a tasty candy shell ...

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:

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

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:

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

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:

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

> ....are kept in a Nucleus which use
> regular calling mechanisms and copyless message passing.

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

http://www.tgi-sci.com
------------------------------------------------------


dmctek.googlepages.com 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:
>
> > 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...

>> ... The software (well, the whole product, actually) was very much like a 
>> stinking pile of dog doo wrapped in a tasty candy shell ...

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


"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)


-- 
	mac the na�f

Didi wrote:
> > ....are kept in a Nucleus which use
> > regular calling mechanisms and copyless message passing.
>
> 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
>

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.