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

Fulltext:


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.es.mdu.se/publications/302-}
}