eXtremeDB/rt: Adjustable to RTOS Scheduling for Temporal Data Consistency

Real-time operating systems use various techniques to achieve deterministic behavior and to complete tasks within predefined time windows. The eXtremeDB/rt transaction managers adapt to the underlying operating systems schedulers, yet do not make any assumptions about transactions patterns and/or the applications’ data flow. The schedulers can handle periodic and aperiodic transactions and do not require any execution-time estimates to enforce transaction deadlines. Consider, for example, ASTERIOS® which statically allocates execution time slices, and a CPU budget and defines the order for each running task at compile time. Then there is DEOS™ for which a thread is statically assigned a period of execution and the CPU budget (a predefined time slice within each period). Thread scheduling is dynamic though — a thread that attempts to exceed its CPU budget is (generally) preempted. Lastly, consider RTLinux, an extension to the Linux kernel that merely assists real-time tasks (tasks that must run with minimal latency and jitter) to finish within their assigned deadlines. Regardless of the approach, the RTOS interrupts the running task when it runs out of its allotted time slice. If the activities performed by the task were atomic, that would not present a problem for the application’s logic. In real life, though, there can be multiple logically related yet independent activities performed within a time slice. For example, the application could read a sensor value and then store that value in the database. Non-real time database systems can’t be used in this scenario because the database internals can be left in an inconsistent state if the time allotted to the task expires prior to the sensor value being fully committed to the database. eXtremeDB/rt, on the other hand, is able to adjust its transaction deadline to the operating system’s time slice so that the entire operation — the sensor access and the database access either succeeds or is rejected as one (i.e., is atomic). In either case, the system retains temporal data consistency.

Dynamically assigned transaction deadlines example

Let’s consider the following example for a task running under DEOS operating system. The task performs some activities unrelated to the database and then creates a transaction with the database in an infinite loop. Each iteration must fit into single time slice in order to guarantee transaction completion within a thread’s CPU budget. In order to achieve that, the developer of an eXtremeDB/rt application would specify a deadline value when starting a transaction. This value must also account for the estimated transaction rollback time. If a thread’s CPU budget is 50 ms, and non-database activities (e.g. accessing hardware, reading sensor data, etc.) take 10 ms, then the eXtremeDB/rt operations are left with 40 ms. A portion of this 40 ms slice is reserved for the transaction rollback time, which is roughly zero for read-only transactions, and up to 100% of the transaction’s execution time for read-write transactions. Thus, in our example, a conservative estimate for the deadline value would be 20 ms if read-write transactions are used. If a transaction attempts to overrun the 20 ms deadline, it is interrupted, and the remaining 20 ms of the CPU budget will be used to perform a safe rollback without compromising data integrity.

Click to enlarge

The eXtremeDB/rt allows setting the transaction deadline value individually just prior to the start of the transaction. The deadline value can be chosen based on the application’s current state. If necessary, the transaction is interrupted by the eXtremeDB/rt runtime and the deadline is guaranteed to be satisfied. The transaction deadline mechanism allows using RTOS time slices accurately and effectively to store and retrieve applications’ data.