Military Embedded Systems Spring 2005 Volume 1 Number 1

Software
MILITARY EMBEDDED SYSTEMS Resource Guide
For instance, applications conventionally
run in a round robin execution, competing
with each other for a proportion of the
CPU capacity. With an RTOS, however,
you can manipulate the priorities of processes
to have certain activities run preferentially
to others in the system. Applied
judiciously, this priority manipulation can
dramatically improve response in areas
important to the user, without potentially
starving other processes in the system.
The key to ensuring that higher-priority
processes and threads do not starve out
other processes is to be certain of the
limits imposed on their execution. By
pacing the execution, or by throttling it
in response to load, you can limit the proportion
of CPU consumed by these activities
so that user processes get their share
of the CPU.
Priority manipulation can benefit a variety
of applications, including, for example,
media players (MP3, WAV, MPEG-2, and
so on). The operation of a media player
can be tied to the media rate required for
proper playback (44 kHz audio, 30 fps
video). So, within this constraint, a reader
thread and a rendering thread can both be
designed to wake up on a programmable
timer, to buffer or render a single frame,
and then go to sleep until the next timer
trigger. This provides the pacing that
allows the priority to be assigned above
normal user activities, but below critical
system functions.
With well-chosen priorities, playback
will occur consistently at the given
media rate. A well-written media player
will also take into account quality of service,
so that if it doesn’t receive adequate
CPU time, it can reduce its requirements
by selectively dropping samples or follow
an appropriate fallback strategy.
This will then prevent it from starving
other processes as well.
A strategic decision
An RTOS can help make complex applications
both predictable and reliable.
In fact, the precise control over timing
made possible by an RTOS adds a form
of reliability that cannot be achieved with
a GPOS. If a system based on a GPOS
doesn’t behave correctly due to incorrect
timing behavior, then we can justifiably
say that the system is unreliable.
Still, choosing the right RTOS can itself
be a complex task. The underlying architecture
of an RTOS is an important criterion,
but so are other factors. For instance,
does the RTOS support standard APIs,
such as POSIX.1? A flexible choice of
scheduling algorithms? Protocol stacks
such as IPv4, IPv6, and IPsec? What
about support for distributed or symmetric
multiprocessing? Diagnostic tools for
system profiling, memory analysis, and
application profiling? And what of the
RTOS vendor? Do they offer a full range
of engineering services and well-documented
source and customization kits?
How about any direct experience serving
embedded developers?
On one point, there is no question: An
RTOS can play a key role in determining
how reliable a system will run, how well it
will perform, and how easily it will support
new or enhanced functionality. It’s critical,
therefore, to choose an RTOS and an RTOS
vendor that can meet project requirements,
both now and in the future. O
Steve Furr is
senior OS product
manager for QNX
Software Systems
and a coauthor
of the Real-time
Specification for
Java (RTSJ). He
currently serves as a technical member
on several industry forums, including
the Open Group’s Real-time and
Embedded Systems Forum, which is
dedicated to expanding the marketplace
for standardized real-time and embedded
systems. In his 13 years with QNX,
Steve has held various engineering
positions, including software architect.
He holds a Bachelor’s degree in
computer science.
For further information, contact
Steve at:
QNX Software Systems Ltd.
175 Terence Matthews Crescent
Ottawa, Ontario
Canada, K2M 1W8
Tel: 613-591-0931
Fax: 613-591-3579
E-mail: furr@qnx.com
Website: www.qnx.com
40 / 2005 MILITARY EMBEDDED SYSTEMS Resource Guide