This paper considers the use of lock-free shared objects within hard real-time systems. As the name suggests, lock-free shared objects are distinguished by the fact that they are not locked. As such, they do not give rise to priority inversions, a key advantage over conventional, lock-based object-sharing approaches. Despite this advantage, it is not immediately apparent that lock-free shared objects can be employed if tasks must adhere to strict timing constraints. In particular, lock-free object implementations permit concurrent operations to interfere with each other, and repeated interferences can cause a given operation to take an arbitrarily long time to complete. The main contribution of this paper is to show that such interferences can be bounded by judicious scheduling. This work pertains to periodic, hard real-time tasks that sharelock-free objects on a uniprocessor. In the first part of the paper, scheduling conditions are derived for such tasks, for both static and dynamic pri...

The authors present a new scheme for implementing shared objects on a real-time system [1]. They assume that the system allocates processor time in discrete quanta, and that the quantum is large compared to the length of an object call. Under these conditions, most object calls are likely to execute without preemption, thus allowing the usage of simpler and more efficient access mechanisms.

We show that previous algorithmic and scheduling work concerning the use of lock-free objects in hard real-time systems can be extended to support real-time transactions on memory-resident data. Using our approach, transactions are not susceptible to priority inversion or deadlock, do not require complicated mechanisms for data-logging or for rolling back aborted transactions, and are implemented as library routines that require no special kernel support. 1 Introduction In most real-time database systems, conventional mechanisms suchaslocks, timestamps, and serialization graphs are used for concurrency control. The main problem when using any of these mechanisms is that of handling con#icting operations. If an operation of a transaction creates a con#ict, then one of two strategies may be used: either that transaction may be blocked, or one or more of the transactions involved in the con- #ict may be aborted. When using con#ict resolution schemes that employ blocking, deadlockisakey ...

Abstract not found