You are required to read and agree to the below before accessing a full-text version of an article in the IDE article repository.
The full-text document you are about to access is subject to national and international copyright laws. In most cases (but not necessarily all) the consequence is that personal use is allowed given that the copyright owner is duly acknowledged and respected. All other use (typically) require an explicit permission (often in writing) by the copyright owner.
For the reports in this repository we specifically note that
- the use of articles under IEEE copyright is governed by the IEEE copyright policy (available at http://www.ieee.org/web/publications/rights/copyrightpolicy.html)
- the use of articles under ACM copyright is governed by the ACM copyright policy (available at http://www.acm.org/pubs/copyright_policy/)
- technical reports and other articles issued by M‰lardalen University is free for personal use. For other use, the explicit consent of the authors is required
- in other cases, please contact the copyright owner for detailed information
By accepting I agree to acknowledge and respect the rights of the copyright owner of the document I am about to access.
If you are in doubt, feel free to contact webmaster@ide.mdh.se
Interprocess Communication Utilising Special Purpose Hardware
Publication Type:
Licentiate Thesis
Publisher:
Mälardalen University Press and Department of Information Technology, Uppsala University
Abstract
Real-time systems are computer systems with constraints on the timing of
actions. To ease the development and maintenance of application software,
real-time systems often make use of a real-time operating system (RTOS).
Its main task is management and scheduling of application processes
(tasks). Other functions are interprocess communication, interrupt
handling, memory management etc.Sometimes it is hard (or even impossible) to meet the time constraints
specified for a real-time system, resulting in an incorrectly functioning
application. A possible remedy is to redesign the system by upgrading the
processor and/or remove functionality. An alternative approach is to use a
special purpose hardware RTOS accelerator. The aim of such an accelerator
is to speedup RTOS functions that impose big overhead i.e. to reduce the
RTOS overhead by offloading the application processor. Accordingly, the
processor gets more time for executing application software, and hopefully
the time constraints can be met. The main drawback is the cost of extra
hardware.This thesis presents results from implementing RTOS functions in hardware,
especially interprocess communication (IPC) functions. The types of systems
considered are uniprocessor and shared memory multiprocessor real-time
systems.IPC is used in systems with co-operating processes. The real-time operating
systems on the market support a large variation of IPC mechanisms. We will
here present and evaluate three different IPC implementations. The first is
an extended message queue mechanism that is used in commercial robot
control applications. The second is the signal mechanism in OSE, a
commercial RTOS predominantly used in telecommunication control
applications, and the third is the semaphore and message queue mechanisms
supported by the leading commercial RTOS VxWorks. All the implementations
are based on a pre-emptive priority-based hardware real-time operating
system accelerator.We show that it is not optimal, practical or desirable to implement every
RTOS function in hardware, regarding systems in the scope of this thesis.
However, an accelerator allows new functionality to be implemented. We
illustrate this by implementing a message queue mechanism that supports
priority inheritance for message arrival in hardware, which is too
expensive to implement in software. Also, we show that substantial speedups
are possible, and that a crucial mechanism in achieving speedup is the
realisation of the communication between the accelerator and the processor.
We further note that application speedups are possible, even in cases with
an IPC-mechanism slow-down. The main reasons for this is that the
accelerator can off-load the processor by handling the RTOS timing
mechanism (clock-ticks), reducing the RTOS code to be executed on the
processor, and handling interrupts.
Bibtex
@misc{Furunas-Akesson302,
author = {Johan Furun{\"a}s-{\AA}kesson},
title = {Interprocess Communication Utilising Special Purpose Hardware},
number = {01/42},
month = {December},
year = {2001},
publisher = {M{\"a}lardalen University Press and Department of Information Technology, Uppsala University},
url = {http://www.ipr.mdu.se/publications/302-}
}