EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 127 of 197

i o Global Table local Tables PBO Processes ~=~'.) on the local processor. If the lock can- not be obtained because it is held by another task, then the task spins on the lock. It is guaran teed that the task holding tile global lock is on a differ- e nt processor, and wi ll not be pre- empted, thus it will release the lock shortly. In theory, locking the CPU can lead to possible missed deadlines or priority inversion. However, consider- ing the practical aspects of real-time computers, it is not unusual that a real-time microkernel locks the CPU for up to ] OOps in order to perform system calls such a handling timer interrupts, scheduling, and perform- ing full Global Table: context switches. 117J PBO Processes: ~==~ Locking the global SVAR table The method used to lock the global table and preserve the autonomous execution model of the PBO is based on the assumption that the amount of data communicated via the ports on each cycle of a PBO is relatively small. That is, each INVAR or OUTVAR is only a few tens to a few hundreds of bytes. The exact value of what is meant by "small" depends on a particular con- figuration , and is quantified in an arti- cle that I and others wrote for the JEEE Trans. on Software Engineering.11 91 As a rule of thumb, less than 100 bytes of communication between two objects per cycle is usually sufficiently "small ." For this reason , the frame- work that is su itable for tile control sys- tems domain is not directly applicable to a genel-al communication system with kilobytes or megabytes of data being transferred. The non-preemp- tive framework, however, is sui table even for a high volume of data exchange between objects, because there i no data replication. The global table can be accessed by processes executin g o n different CPUs, making a solution for locking the table that is also suitable for multi- processor environments desirable. The solution used is based on spin- locks.!81 See again my article from the IEEE Tra, ns. on Software Engineering for a discussion of other solutions that were considel-ed but not used-such as the shared memory protocol and priority cei ling protocol-because they al-e impractical for most embedded appli- cations due to their high overhead.!lg! When a task must access the global table, it first locks the processor on which it is executin g. Locking the CPU ensures that the task does not get swapped out while holding the critical global resource. The task then tries to obtain a global lock by performing an atomic read-modifY-write instructio n, which is supported by most processors. If the lock is obtained, the task reads or writes the global table then releases the lock, while remaining locked into the local CPU. lL then releases it lock 126 DECEMBER 2000 Embedded Systems Programming Decomposition of subsystem into components To develop compone nt-based soft- ware, it is necessary to draw clean boundaries between each compone nt. Many attempts at creating component- based software fail because designers have no guidelines to follow when breaking up the appli cation into pieces. In this section, general guide- lines for decomposing tile subsystem into components are presented. It is assumed that the application has already bee n split in to different sub- systems based on functionali ty. A subsystem is defined as part of an application tJlat can be developed and tested independently, and integrated into an application later through sim- FurtJlermore, many RTOSes are creat- ed such that periods and deadlines of processes are rounded to the nearest multiple of tile system clock since more accurate timing is not available to the scheduler. In these systems, if the total time that a CPU is locked to u-ansfer a state variable is mall as com- pared to the resolution of the system clock, then tllere is negligible effect on the predictability of the system due to this mechanism locking the local CPU. When using the non-preemptive version, tllere is no need to lock the global SVAR table.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13