Real-Time Resources
An important facet to working in real-time is how resources can be used. Resources include both software, such as the runtime library functions, and computer hardware. In MS-DOS, resource allocation may requires extra consideration since both MS-DOS and the typical compiler libraries were not designed for sharing. There is often little specific documentation provided concerning the multi-tasking of applications. Most C compilers do provide interrupt programming capabilities, so some documentation exists concerning their use for that purpose.
Real-time systems essentially operate as sophisticated interrupts. Those functions and activities that are available for use inside interrupts should be usable without restrictions. Those that cannot be used inside interrupts must only be used in a restricted fashion.
The term reentrant is used to describe those functions that may be used without restriction. A reentrant function is one that may be run, during an interrupt for example, while the processor was already running the function in the main program. The basic criterion for reentrancy is whether or not a function affects something that is shared. Functions that modify hardware or variables with a scope beyond the function should be automatically suspect. Both Microsoft and Borland provide lists of reentrant routines, or those that can be made reentrant by compiler switches.
There are several ways to work around sharing problems. The simplest is to keep all activities of a particular type within one task level. Another technique is to disable interrupts during small sections of nonreentrant code. Flags can be used to control program flow in order to avoid problems. Overall program design also provides you with the ability to work around problem areas.
Your code will also contain sections that are not reentrant. Manipulation of timers and task flags is not reentrant, so the provided functions disable interrupts during the time while they are doing the manipulation.
Any variable that can change in an interrupt or higher priority task may need protection for both reading and writing during lower priority tasks. Variables modified in more than one task can cause problems when a lower priority task is interrupted between the reading and writing of a variable which is then modified during the higher priority task. The modification done in the higher priority task will be overwritten by the lower priority. For variables that require more than one machine language instruction to read, it is possible to end up with halves of two different numbers if the variable is changed by a higher priority task.
Errors causes by these problems can be severe. They may also occur on an infrequent basis and never be observed during development and testing.
