Real-time functionality is essential for developing many consumer, industrial, and systems devices. While the C/C++ programming language is most often used in the creation of real-time software, the Java language, with its simple and familiar object-oriented programming model, offers many advantages.

Over current real-time practices. Concurrent and Real-Time Programming in Java covers the motivations for, and semantics of, the extensions and modifications to the Java programming environment that enable the Java platform (Virtual Machine) to meet the requirements and constraints of real-time development. Key aspects of concurrent and real-time programming and how they are implemented in Java are discussed, such as concurrency, memory management, real-time scheduling, and real-time resource sharing.

A hard real-time task or system is one where an activity simply must be completed—always—by a specified deadline. The deadline may be a particular time or time interval, or may be the arrival of some event. Hard real-time tasks fail, by definition, if they miss such a deadline. Notice this definition makes no assumptions about the frequency or period of the tasks. It could be a microsecond or a week—if missing the deadline induces failure, and then the task has hard real-time requirements. Soft real time, though, has a definition as weak as its name. By convention, it's those systems that aren't hard real-time, though generally some sort of timeliness requirements exist. If missing a deadline won't compromise the integrity of the system, and if generally getting the output in a timely manner is acceptable, then the application's real-time requirements are “soft.” Sometimes-soft real-time systems are those where multi-valued timeliness is acceptable: bad, better, and best responses are all within the scope of possible system operation.

Interrupts are inexorably linked with real-time systems, as only the interrupt bypasses the time-consuming tedium of polling multiple asynchronous inputs. Yet a surprising number of very fast applications are crippled by the overhead associated with servicing interrupts. Though chip vendors specify interrupt latency in terms of the time the hardware needs to recognize the external event, to firmware folks a more useful measure is time-from-input to the time we're doing something useful, which may be many dozens of clock cycles. The multiple levels of vectoring needed by the average processor, plus important housekeeping like context pushing, are all ultimately overhead incurred before the code starts doing something useful. Similarly, the real-time operating system (RTOS) is one of the most important and common tools in the real-time arsenal. Yet the RTOS also provides no guarantee of real-time response. The first rule of real-time design is to know the worst-case performance requirements of each activity—and only then select the right implementation (CPU, hardware design, and firmware organization). Thinking in the time domain, as well as in that of the conventional procedural, is crucial.

SRF Fabrication Unit