Windows NT, CLI and STI (NT and real-time)

M

Michael Griffin

(Originally posted Tue 07/07/1998)
Vladimir E. Zyubin wrote:
<clip>
>At Thu, 2 Jul 1998 00:42:29 -0400, Michael Griffin wrote:
>>For example, consider the following two systems:
>> A) A pneumatically operated pick-and-place.
>> B) A robot driven by electric servo drives.
<clip>
Someone earlier wrote:
>> >Control of the dam gates on a slow moving river may require a
>> >response time no faster than an hour;
<clip>
Vladimir E. Zyubin wrote:
> (?) It seems to me that the first example (dam gates) is
>very close to the case of the system "A" (pneumatically operated
>pick-and-place).

No, I believe that the example of the dam gates is a real time
system, while the pick-and-place is not. The gates are being used to control
the river level in real time. The fact that the response time is very slow
does not affect this fact. If the response from the gates does not meet the
necessary timing criteria, the river level is not controlled. This is
because the river will continue flowing whether the gate control system is
ready for it or not. In this case a late response is just as bad as no
response at all. This is what makes it a real time system.
In the example of the pneumatic pick-and-place, the P&P will sit
there until the control system initiates the next step in the movement
sequence. Control of the P&P does not depend upon meeting certain timing
schedules. Slow or erratic timing of the control will not affect whether the
pick-and-place is able to perform the correct motions. It will only affect
the process cycle time, which is another issue altogether. This is why this
is not a real time system.

>Moreover, I bet that a response time of 1 hour
>is not acceptable for the end user of the system "A", i.e., as
>well as in the case of the system "B", it means a loss of money.
>For the system "A" it means waste of energy. For the system "B" --
>waste of a half-finished product (or rather producing of
>goods we may, but don't agree to use :).
<clip>
We should not confuse the profitability of a production process
(which depends upon many things) with whether or not it is a real time
system. Several people have mentioned economic issues and I wish to state
that this is very much a red herring as far as whether or not something is a
real time system.

To add another twist to this discussion, if I were to use a computer
which had a "real time operating system" (e.g. QNX), and wrote software to
control the above mentioned pick-and-place, this does not suddenly make the
P&P a real time system. An RTOS is something which *may* be used as part of
a control for a real time system, but the mere presense of an RTOS (and
appropriate control software) does not automatically make the system it is
controlling a real time system.

Michael Griffin
London, Ont. Canada
 
(Originally posted Tue 07/07/1998)
Mike,
My apologies. I didn't mean to insult your intelligence. I just find
your style of questioning objectionable. To your questions:

Windows (95, NT, 3.51, etc.) and DOS in all forms are just Disk
Operating Systems. Windows makes the multitasking easier than invoking a
new COMMAND sequence that was necessary in DOS. It also provides easier
to use memory management to take advantage of Extended Memory that is
necessary due to the handicap of the x86 architecture. If you care to
write a program to use low level timers, you may create an entire
real-time environment yourself using DOS or any form of Windows, but the
O/S does not help you in any way. Therefore, IMHO, Windows is NOT a
real-time O/S. I don't know about WinCE 3.0 which Microsoft says will
have at least fast context switching, but there has been no information
on time-based scheduling or task synchronization.

My definition: a real-time O/S provides the services to
deterministically schedule tasks based on time or external events, and
provides the services to synchronize task execution in a multitasking
environment.

Mike, you may be an ace programmer and find real-time routines in some
class-library. That doesn't help most people working on applications
who expect these services to be provided by the O/S. If you care to
follow some obscure references, I was one of the editors of the
Real-Time Extensions to FORTRAN prepared in the 1970's and which became
ANS/ISA S61.1. These were implemented by Modcomp and DEC (and maybe
others) for their FORTRAN compilers. These same extensions were
prepared for PL/I and added to the subset of that language which became
an ANSI standard, but I don't have that reference.

Please note that "real-time" does not in any way define response time
requirements. It only implies that the O/S provides services needed by
tasks to respond in a deterministic way. A genuine RTOS provides the
enforcement that library scheduler routines cannot.

Dick Caro
 
M
(Originally posted Tue 07/07/1998)
Your apology is accepted, and fully reciprocated with respect to my
style of questioning should you consider it objectionable. It is not
intended to be so.

Moving on to the question of Windows, I think it is important to make a
distinction between the different members of that family, as they are
all rather different in the areas we are discussing...

With Windows 3.1, the OS that most people see (ie. the GUI) is about as
far from anyone's definition of an RTOS as you could ever get.
Underlying that, though, is the virtual machine manager (VMM) used to
schedule between DOS virtual machines. One of these VMs is running the
GUI, and the others may run anything you like. I would argue that the
VMM meets you definition of an RTOS, in that you can schedule the VMs
according to interrupt events, be they from the timer or from other
external sources. Any attempt to implement a real-time application in
this way is hampered, though, by two things. Firstly, the calls into the
this "operating system under an operating system" can only be made from
virtual device drivers -- which were still most evil at that stage of
Window's evolution -- and, secondly, your entire I/O system is based
upon DOS, with all its non-re-entrant nastiness.

With Windows NT, it is a different kettle of fish altogether. It surely
meets your definition of an RTOS, and it surely does "help you" by
provide flexible scheduling, task and thread synchronisation services,
asynchronous procedure calls, and all manner of fun things. Whether or
not it is responsive enough in terms of latencies to be a true RTOS by
some people's definition is another question, but it is precisely that
quantitative nature of the definition that makes me want to throw the
term away altogether.

With Windows 95, you've got an in-between situation. It provides pretty
much all of the task stuff that you require of an RTOS, but elements of
its I/O system are still less re-entrant and responsive than Windows NT,
and large elements of its GUI are likewise single threaded. But then
again, we're not talking about graphical real-time operating systems
(GRTOS???) so perhaps this isn't relevant.

From all of this, I draw two conclusions. Firstly, all of the Windows
family have some form of scheduler which would meet *some* definition of
an RTOS, even if the latencies didn't meet other people's expectations.
Secondly, those members of the family that have weakness actually have
them in the areas of their I/O systems and their task protection
mechanisms. This fits in with my "what's the big deal" comment --
writing an RT scheduler is trivial; writing an RT I/O system is much
more complex. Even then, though, the concept of RT-ness is a sliding
scale, such that no-one can draw a line in the sand and say where RT
begins, and where it ends. As such, it does not strike me as a useful
term when used in this context.

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk
 
A

A. V. Pawlowski

(Originally posted Tue 07/07/1998)
I think I would have to agree with Mike Granby that the term "RTOS" just
does not have much value anymore.

It used to mean (for me) a small, embedable kernel which was optimized
for computer hardware support of automation/control applications. Today
though, many of the scheduling, I/O and sychronization features that
were typically provided by that class of product are now provided (to
greater and lessor extent) by general purpose OS's, the difference being
largely speed and size.

In fact, many "real time" applications are now being successfully
supported by general purpose OS's. For better, or worse, the difference
between these classes has decreased greatly.
 
A

Armin Steinhoff

(Originally posted Tue 07/07/1998)
At 09:10 07.07.98 +0100, Mike Granby wrote:
>Dick,
>
[ ... ]
> ...... and why I still maintain my assertion that the term "real time"
is not precisely defined when applied to operating systems when compared
to the exact definition that exists when it is applied to applications.

Mike ... what is the exact definition of real-time "when it is applied to
applications" ??

Here is my set of ATTRIBUTES which a real-time system must have ... when I
call it a real-time system.


ATTRIBUTES of REAL-TIME systems.

REAL-TIME Systems in general (minimum requirements)

HARDWARE
- supports at least one interrupt level
- CPU reacts to interrupts
- CPU supports context switching

SOFTWARE
- event driven management of system resources
- deterministic response times to events with a predictable jitter
- deadlines for the processing of events are met with a
predictable jitter
- supports priority levels for task processing
- supports fast context switching of tasks


HARD REAL-TIME Systems

HARDWARE
- supports different interrupt levels (priorities)
- allows nesting of interrupts
- CPU reacts fast to interrupts in the range of nanoseconds
- CPU supports fast context switching in the range to nanoseconds

SOFTWARE
- event driven management of all system resources
- priority levels for interrupt processing
- supports nesting of interrupts

- deterministic response times to events with a worst case
predictable jitter in the maximal range of 10 microseconds

- deadlines for the processing of events are met with a worst case
predictable jitter in a maximal range of 10 microsecond

- supports priority levels for task processing ( 256 at bests ...)
- supports fast context switching of tasks in the range of
microseconds
- supports different scheduling policies (POSIX)


SOFT REAL-TIME Systems

HARDWARE
- support of different interrupt levels (priorities)
is not coercive required
- nesting of interrupts is not coercive required
- CPU reacts to interrupts in the range of 100 miroseconds
- CPU supports context switching in the range to 100 microseconds

SOFTWARE
- management of system resources is not 100% bound to external events
(print and wait ...:)

- priority levels for interrupt processing
- support of nested interrupts is not coercive required

- deterministic response times to events with a predictable jitter
in the maximal range of 100 microsecond

- deadlines for the processing of events are met with a predictable
jitter in a maximal range of 10 millisecond

- supports priority levels for task processing
- supports of context switching of tasks in the range of milliseconds
- support of different scheduling policies is not coercive required

Armin Steinhoff

<http://www.dachs.net/>
 
D

Donald W. Carr

(Originally posted Tue 07/07/1998)
RTOS is still a valuable term. Many slow, non-critical real-time
applications can be run on a general purpose OS with at least some extra
work from the programmer. There are also real-time packages written for
general purpose operating systems that to some degree make up for what is
lacking in the OS. There is a big difference though between, say, QNX and
Windows 95 in terms of OS support for real-time applications. When I here
the term RTOS it may need some qualification, but I instantly know that
there are at least some features commonly needed by real-time applications
built into the OS. By the way, the term operating system itself is not very
precise either. What features are necessary before you can call it an
operating system? If you ask 10 different people you will get 10 different
answers, but that does not mean the term operating system has no value. And
which general purpose operating systems do you refer to that are just as
good as any RTOS for implementing time critical real-time applications
where failures could result in result in injury and/or large financial losses.

Don.
 
(Originally posted Wed 07/08/1998)
Subject: SOFT: "Real-Time Debate"

In my younger days we referred to this type of debate as "Catching the
mice, but letting the elephants free."

At the risk of getting further embroiled, I would like to offer the
following solution:

Why not use the "official" definition given in IEEE Std 100-1992 (at
least thru the 5th edition)?.

Phil Corso,
TRIP-A-LARM CORP.
 
(Originally posted Tue 07/07/1998)
Answered in context below:
> Moving on to the question of Windows, I think it is important
> to make a
> distinction between the different members of that family, as they are
> all rather different in the areas we are discussing...
>
> With Windows 3.1, the OS that most people see (ie. the GUI)
> is about as
> far from anyone's definition of an RTOS as you could ever get.
> Underlying that, though, is the virtual machine manager (VMM) used to
> schedule between DOS virtual machines. One of these VMs is running the
> GUI, and the others may run anything you like. I would argue that the
> VMM meets you definition of an RTOS, in that you can schedule the VMs
> according to interrupt events, be they from the timer or from other
> external sources. Any attempt to implement a real-time application in
> this way is hampered, though, by two things. Firstly, the
> calls into the
> this "operating system under an operating system" can only be
> made from
> virtual device drivers -- which were still most evil at that stage of
> Window's evolution -- and, secondly, your entire I/O system is based
> upon DOS, with all its non-re-entrant nastiness.

Win3.1 is only DOS with an ugly GUI and a single threaded multitasking
system. It needed to be run as a slave OS under a real RTOS which most
of the HMI vendors did.

>
> With Windows NT, it is a different kettle of fish altogether.
> It surely
> meets your definition of an RTOS, and it surely does "help you" by
> provide flexible scheduling, task and thread synchronisation services,
> asynchronous procedure calls, and all manner of fun things. Whether or
> not it is responsive enough in terms of latencies to be a true RTOS by
> some people's definition is another question, but it is precisely that
> quantitative nature of the definition that makes me want to throw the
> term away altogether.

Everything you say is correct except that I did not refer to thread
synchronization but for independent tasks (processes) spawned by the
timer. In a real RTOS, it is not necessary to keep a scheduling task
alive as it is in WinNT. Also, WinNT has no means, unless you write the
code, to support deadline scheduling, common in RTOS. The missing factor
is that the OS must enforce the time schedule unless blocked by higher
priority tasks. I guess that you can do all that in WinNT if you write
the code. If I specify an RTOS, I ask that the RTOS enforce these
features. You raise all the same questions that the PL/I designers
raised in 1976 about the need for Real-Time extensions to their favorite
language. It's all about a small matter of programming. Without the
enforcement of the schedule and the synchronization by the OS, it cannot
be considered as Real-Time. Ergo, WinNT, without modification cannot be
considered a RTOS.

> With Windows 95, you've got an in-between situation. It
> provides pretty
> much all of the task stuff that you require of an RTOS, but
> elements of
> its I/O system are still less re-entrant and responsive than
> Windows NT,
..clip ... and therefore less RT.
>
> >From all of this, I draw two conclusions. Firstly, all of the Windows
> family have some form of scheduler which would meet *some*
> definition of
> an RTOS, even if the latencies didn't meet other people's
> expectations.
> Secondly, those members of the family that have weakness actually have
> them in the areas of their I/O systems and their task protection
> mechanisms. This fits in with my "what's the big deal" comment --
> writing an RT scheduler is trivial; writing an RT I/O system is much
> more complex. Even then, though, the concept of RT-ness is a sliding
> scale, such that no-one can draw a line in the sand and say where RT
> begins, and where it ends. As such, it does not strike me as a useful
> term when used in this context.

Easy for you to say, Mike ace programmer. Not easy for an application
programmer to write multithreaded tasks to run real-time. Even harder
to write the OS administrative code to enforce clock synchronization
should task execution run over the allocated time gap. It all boils down
to one issue: how much real-time code must the programmer create to
enforce the real-time scheduling and synchronization tasks required to
implement the application. I say that RTOS like PSOS and Lynx or the
older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
easy, but I cannot even conceive of the complexity of doing the same
jobs in WinNT.
 
M
(Originally posted Wed 07/08/1998)
> "What is the exact definition of real-time [applications]?"

It was contained in an earlier post. In short, my definition of a
real-time application is one where input data is processed as it
arrives, and output data is provided as it is needed. It is the opposite
of old-style batch or off-line processing. All control systems are by
definition real time applications, or they'd be unable to control
things.

> HARDWARE
> [1] supports at least one interrupt level
> [2] CPU reacts to interrupts
> [3] CPU supports context switching

I agree about [1] and [2], but then again these are hardly onerous
requirements. As for the CPU supporting context switching, if this means
via hardware (ie. a single instruction to swap the entire execution
context) then you're knocking-out many self-proclaimed RTOS's that run
on processors that do not support this sort of thing. If you mean via
software, then virtually any processor is capable of doing this via
stack operations.

> SOFTWARE
> [1] event driven management of system resources
> [2] deterministic response times to events with a predictable jitter
> [3] deadlines for the processing of events are met with a predictable
jitter
> [4] supports priority levels for task processing
> [5] supports fast context switching of tasks

I don't understand "management of system resources" in [1], so I cannot
comment further on that issue. Point [2] requires deterministic response
times to events, but these responses can only be determined in the
context of the application, as the processor can only do one thing at
once. This is thus a property of the application / OS system and not of
the OS itself. The same surely applies to point [3]. I accept point [4]
without argument, while point [5] is quantitative in nature and thus not
a useful part of a solid definition.

The million dollar question: Is WinNT an RTOS under this definition?

> HARD REAL-TIME SYSTEMS

I won't go into these in detail, as most as just tighter version of the
above, although I accept that there are also some unique properties not
included in the non-hard RT definition. Overall, though, I am still left
with the feeling that most of the supposed properties of an RTOS fall
into two categories...

1/ Those properties which are defined in a quantitative way. For
example, an RTOS must meet such-and-such a context switching time, and
must be able to scheduling tasks with an accuracy of so-many
milliseconds. These values of properties are self-evidently defined by
the application in question, and so to my mind cannot form part of a
definition. While you or I might be happy with responses in
milliseconds, some people will need them in microseconds, and some
people might be happy to wait a second or two.

2/ Those properties which are easy to define in a simple system, but
which in a real application are determined just as much by the
application context than by the OS. For example, it has been said that
an RTOS must be able to guarantee that a task can be run by a given
deadline. And yet the RTOS cannot do that if the application has a
higher priority task running at that point. In other words, the response
of the system to the real world is determined as much by the application
as by the OS. Determinism at the OS level is thus only part of it -- the
really important determinism is that of the application-OS system as a
whole.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk
 
(Originally posted Wed 07/08/1998)
I was hoping to not get embroiled, but the answer to your question is:

Page 1083 of the aforementioned IEEE standard.

Phil Corso,
Trip-A-Larm Corp


Mike Granby wrote:

>Sounds like a good idea. What is it?
 
S

Simon Martin

(Originally posted Tue 07/07/1998)
Hey Armin,

The definitions here have absolutely NO meaning, as you do not specify the
system this is being inserted into. The numbers you quote could be
ridiculous (too fast or too slow) depending on the system you are
controlling. As for requiring multiple interrupts levels, this is *not* a
requirement, e.g. if I destine a processor, microcontroller, ASIC, FPGA,
abacus, pocket calculator, etc. (depending on the selected technology) to
handle each event, I do not require multiple interrupt levels, I do not even
need interrupts, as I can run a polling system, which if it handles all
events "predictably given the systems time constraints" then what's the
problem?

As I said before *if you don't specify the system, real-time has no
meaning*. If a general purpose quantitative measure is required then it
should be something along the lines of:

REAL-TIME System:
A system that is guaranteed to handle all events within the time constraints
dictated by the physical system with which it is connected.

HARD REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed primordially by its physical configuration.

SOFT REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed by a combination of its physical and logical configurations.

This is a first stab, anyone want to improve on it?

Simon Martin
mailto:[email protected]
 
L

Lester R. Shields

(Originally posted Tue 07/07/1998)
On Tuesday, July 07, 1998 3:45 PM, Dick Caro wrote:
> I say that RTOS like PSOS and Lynx or the
> older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
> easy, but I cannot even conceive of the complexity of doing the same
> jobs in WinNT.

As a long time user of the PDP-11, I often wonder why someone doesn't
rewrite RSX to run on Intel. While it didn't always make everything
easy, it did have most of the features a real-time programmer needs.
Even the features it didn't have could usually be added or synthesized.

Les
 
M
(Originally posted Wed 07/08/1998)
YOU SAID: "Everything you say is correct except that I did not refer to
thread synchronisation but for independent tasks (processes) spawned by
the timer."

Most self-proclaimed RT operating systems I have looked at only support
threads, and only a few support self-contained processes with separate
address spaces. By a thread, I mean a unit of execution which shares the
same code and data space as a number of similar units of execution.

YOU SAID: "Also, WinNT has no means, unless you write the code, to
support deadline scheduling, common in RTOS. The missing factor is that
the OS must enforce the time schedule unless blocked by higher priority
tasks."

So now you are adding dealing scheduling to the definition of an RTOS?
There is plenty of evidence against this assertion. Let us consider AMX
-- the first RTOS that I used in an industrial application. This does
not provide deadline scheduling. Further, let us consider PSOS -- the
RTOS that you suggested I study. The description of the PSOS scheduler
that I found on a Phillips web site is remarkably similar to that of
Windows NT, and of many other priority-based schedulers. There is
absolutely no mention of deadline scheduling. Further, let us consider
the July 1998 version of the comp.realtime FAQ which includes in its
definition of an RTOS the requirement that "The notion of thread
priority has to exist as there is for the moment no deadline driven OS."

In other words, the commonly used definition of an RTOS does not include
the notion of deadline scheduling. Rather, it includes the
priority-based scheduling that Windows NT (and indeed Windows 95)
implements. You may still feel that neither of these operating systems
is an RTOS, but the fact remains that BY YOUR DEFINITION -- less the
recently added requirement for deadline scheduling -- they are precisely
that.

YOU SAID: "Easy for you to say, Mike ace programmer."

Oh, stop it.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk
 
(Originally posted Wed 07/08/1998)
Great idea. Unfortunately, the PDP-11 hardware did a lot of the work.
It had 16 levels of priority interrupt and automatic context switching
in interrupt response. One way to do important stuff (like incrementing
a flow integrator) was to do it in the interrupt level. Pentium has
only 4 hardware interrupt levels, but is much faster than the PDP-11 in
any form.

Dick Caro
 
A

A. V. Pawlowski

(Originally posted Wed 07/08/1998)
>RTOS is still a valuable term. ...............<

I will take your word that it is still valuable for you. It probably has
some for me too. But, for me, it would be hard to attach much
preciseness to it.

> ............And which general purpose operating systems do you
refer to that are just as
good as any RTOS for implementing time critical real-time
applications
where failures could result in result in injury and/or large
financial losses.....................<

I don't think I have ever said that general purpose OS's are better at
real time applications than some other
designed-for-real-time-applications OS. I did say that some successful
real time applications have been installed that run on general purpose
OS's. There is a big difference. Certainly, different OS's have
differering strengths and weaknesses.
 
(Originally posted Wed 07/08/1998)
Not to prolong the issue, but I still insist that to qualify as a RTOS I
ask for the following:

1. Ability to schedule an independent task to execute at some future
time increment (from now). This can also be a delay in task thread
execution. The schedule cannot be masked by execution of a lower
priority task/thread.

2. Ability to schedule an independent task to cyclically execute at a
precise time interval. I am not sure how I do this with an execution
thread.

3. Ability to queue a task execution (or resume a program thread) when
an external event occurs. External event may be a program (shared
memory) semaphore, or it may be a bit in a register of a scanned I/O
database.

I look for being able to do these operations for independent tasks by
configuration of queuing tables, not by programming. At very worst,
the scheduling task is very small.

I don't find these functions as part of the Windows NT specifications.
I am sure that it is possible to write the queuing tasks and to create a
queue manager with some reasonable high level of performance on say a
P400 processor, but it isn't part of NT.

In short, if the OS doesn't have Real-Time features, how can it be a
RTOS?

Dick Caro
 
M
(Originally posted Thu 07/09/1998)
1. Spawn a high-priority thread which sleeps for N ms and then wakes
your other thread. Okay, so you need a bit of code, but we're talking
about ten lines or so to create the framework, and a single line to
invoke it each time.

2. Similar idea to above, but use a waitable timer within the helper
thread. If you're not running Windows NT 4.0 and so don't have a
waitable timer available, then you're okay as long as the time taken to
wake a thread is less than a system tick. This is pretty much the case
on any system built within the last few years.

3. I/O database triggered resumes need a scanning task, but is easy to
do and I've not seen a single RTOS that does this out-of-the-box. Having
a task resume from a semaphore is part of Windows NT, and thus requires
no extra effort. This can be done between threads, or across processes.

The first point is thus that you can get Windows NT to do all these
things, albeit with some user-mode coding. The more important point,
however, is that many many operating systems which claim to be RTOS's
require exactly the same amount of coding as Windows NT. You thus appear
to have two choices: Admit that Windows NT is (by a commonly used
definition) an RTOS, or admit that the term has no value! :)

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk
 
A

Armin Steinhoff

(Originally posted Thu 07/09/1998)
At 18:34 06.07.98 +0100, Mike Granby wrote:
>[1] Dick made the point that semaphores were a more-or-less defining
>feature of RTOS, or at least that most of them supported such a thing.

Yes ... semaphores are neccessary for the management of shared resources in
a real-time system, because the usage of a shared resource is event driven.

>The point I was making was that such things are not related to the
>"real-time-ness" of the operating system. If they were a defining
>property, then one would be able to convert a non-RTOS into an RTOS by
>writing a very simple bit of user-mode code. This would surely reduce
>the definition of an RTOS to something so non-fundamental as to be
>useless.

Yes ...the existence of semaphores doesn't mean that there are shared
resources which are requested by real-time events.

>[2] Indeed not. So I guess the definition of an RTOS is claimed to be
>one which helps you write real time applications. But the definition of
>a "real time" is not tied down without knowing what the particular
>application is. Since the RTOS must exist independent of its
>applications, I would still assert that the first two letters of that
>abbreviation are woefully ill-defined compared to when they are used in
>other contexts.

IMHO ... RTOS means an OS that can handle most physical time
constrains of any application.

>[3] Ah, so it comes down to what an operating system is *intended* to
>do. In other words, it is more likely to be a badge used in marketing a
>product than a real, definable property which can be measured according
>to some standard.

Each technology has its marketing :)

Armin Steinhoff

http://www.DACHS.net
 
A

Armin Steinhoff

(Originally posted Thu 07/09/1998)
Hi Martin,

At 17:54 07.07.98 -0400, you wrote:
>Hey Armin,
>
>The definitions here have absolutely NO meaning, as you do not specify the
>system this is being inserted into.

It has absolutely a meaning for the concrete "technological" reqirements
... for the real existing classes of real-time systems.

> The numbers you quote could be ridiculous (too fast or too slow)
depending on the system you are controlling.

Yes ... of cause :). But you must define limits for differentiations ...
and these limits are always in question.

>As for requiring multiple interrupts levels, this is *not* a requirement,

A realtime system must respond to external events ... at least to manage
the most important resource - the CPU - . This must also be possible when
the CPU handels an event triggered by an hardware interrupt ... so you need
an interrupt with a higher hardware priority to serve immediately the more
important external event.

> e.g. if I destine a processor, microcontroller, ASIC, FPGA,
>abacus, pocket calculator, etc. (depending on the selected technology) to
>handle each event, I do not require multiple interrupt levels, I do not even
>need interrupts,

Interesting theory ... how do you control the different polling loops ??
How would you assign the CPU to the polling loops ???

> as I can run a polling system, which if it handles all
>events "predictably given the systems time constraints" then what's the
>problem?

Yes ... it works just for a specific class of application. But what happens
when the whole polling process takes 20ms ... and you have to respond
predictably in the time range of 50 us ... to meet the deadline of the
processing of an external event e.g. in the time range of 1ms ???

>As I said before *if you don't specify the system, real-time has no meaning*.

I talked about ATTRIBUTES of 'real-time' computer systems based on the
existing technology ... so there is a clear meaning.

> If a general purpose quantitative measure is required then it
>should be something along the lines of:
>
>REAL-TIME System:
>A system that is guaranteed to handle all events within the time constraints
>dictated by the physical system with which it is connected.

Good general definition .... as long as "time constrains" means "meeting of
all
deadlines" .

( In the real world you have to define a predictable worst case variation
in meeting of deadlines ...)

>HARD REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed primordially by its physical configuration.

Too general ... I don't see any differences to the definition of REAL-TIME !

>SOFT REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed by a combination of its physical and logical configurations.

This definition is not from (and for) this world ... guaranteed :)

Armin Steinhoff

http://www.DACHS.net
 
A

Armin Steinhoff

(Originally posted Thu 07/09/1998)
>I think I would have to agree with Mike Granby that the term "RTOS" just
>does not have much value anymore.

That means the upcoming RTOS version of WinCE has no additional values
compared to the existent versions ??

No value ? ... ask Microsoft how much this development cost :)

>It used to mean (for me) a small, embedable kernel which was optimized
>for computer hardware support of automation/control applications. Today
>though, many of the scheduling, I/O and sychronization features that
>were typically provided by that class of product are now provided (to
>greater and lessor extent) by general purpose OS's,

Would be nice ... but this is not the reality.

> the difference being largely speed and size.

There are other important attributes ...

>In fact, many "real time" applications are now being successfully
>supported by general purpose OS's. For better, or worse, the difference
>between these classes has decreased greatly.

It depends on your definition of real-time applications ...

Armin Steinhoff

http://www.DACHS.net
 
Top