Foreword: In this whitepaper, RTLinux originator Victor Yodaiken gives an overview of synchronization methods for real-time, with special attention to the RTCore (RTLinux) real-time operating system. A glossary, included at the end, provides some useful tutorial material.

Introduction — Real-time software is like an automobile factory

Synchronization operations impose temporal order on a software system by forcing some computations to wait until other computations complete. Waiting and negotiating over which computation should take place next can easily absorb significant fractions of processing power and can cause significant delays.

To compensate, engineers can specify more powerful processors and more resources, maybe even multiple processors — but such things are not free. Even worse, synchronization can easily produce timing failures or deadlocks that may elude testing and this becomes more of a hazard as more complex and sophisticated synchronization operations are employed. It's not uncommon for control system software to spiral in complexity as more hardware is added to provide the compute power needed for synchronization, necessitating more synchronization which requires more resources and also more sophisticated special case software to compensate for hard to find sporadic timing problems and so on.

This paper provides a tutorial on synchronization of real-time software, focused on applications running under the RTCore operating system (RTLinux is RTCore plus Linux). Throughout the design and ongoing development of RTCore, we have tried to solve problems by simplification instead of by adding features.

One of the most brilliant practitioners of this approach to engineering is Taishi Ohno, who helped develop Toyota's manufacturing process. Ohno noticed that large parts inventories in production plants were a significant cost and that they masked ine ciencies. When inventory was reduced and the factory was designed to run, just-in-time problems in quality and reliability were exposed and fixed. The result was greatly increased productivity.

Using up parts inventory and using up slack time “inventory” during synchronization are analogous. If a task is scheduled to start at time t and only starts at time t + w because of delays waiting and negotiating for resources, we have to relax deadlines and build 1 slack time into the system to compensate for w. The slack time is temporal inventory — time we stockpile in order to compensate for resource conflicts, the overhead of arbitration, and other scheduling ineffciencies. We cannot expect to reduce inventory to zero or to do without any synchronization at all, but we can produce cleaner and more reliable software by working to minimize synchronization time.

About the author: Victor Yodaiken, CEO and Co-Founder of FSMLabs, came up with the basic RTLinux technology. Yodaiken began his career in 1983 as one of the chief developers of Auragen's distributed fault-tolerant UNIX and he had an active consulting business before starting FSMLabs. He has also worked in academia, as a professor and department chair at New Mexico Tech, and as a research professor and port-doctoral fellow at the University of Massachussetts in Amherst. Currently he is an adjunct faculty member at the University of New Mexico. Yodaiken is a technical advisor to EMBLIX Japan and is on the board of the Embedded Linux Consortium.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.