A review of the literature has led to a drawback of Interval Temporal Logic (ITL) which is the lack of memory model. Therefore, related suggested memory models such as Framing Variable and Transactional Memory (TM) are investigated in this section in order to diagnose the situation and avoid being trapped by such a limitation.
2.7.1 Memory Models for Interval Temporal Logic (ITL)
One of the most critical issues within the field of parallelism and concurrency of real-time sys- tems is the access to the common shared resource (memory). Due to the importance of this issue, I review some of related work approaches which have been done in order to overcome obstacles which might be encountered in this field. More precisely, approaches such as Framing Variables, and Transactional Memory.
2.7.1.1 Framing Variables
Framed variables remain unchanged at a state, or over an interval, when no assignment is en- countered at that state, or over the interval. Framing Variables is defined as follows [295]:
Definition 7 “Framing a variable x means that the variable x always keeps its old value over an interval if no assignment to x is encountered.”
In temporal logics, no value inherited from a previous state. Alternatively, if a value is needed to be inherited, a repeated assignment of the value should take place at every state. To inherit a value during an interval, I use a formula for each relevant variable such as stable(x). The repeatability of such assignments affects the efficiency of the program and makes it tedious [190, 295]. The application of such a mechanism [196] makes the specification implicit and neat.
The study of framing variables in ITL [190] is initiated by Hale [107]. An investigation of framing variables has also been done by Duan [295]. Projection Temporal Logic (PTL) is an ITL extension with operators for temporal granularities and framing [78, 295]. Subsequently, an executable subset of PTL called Framed Tempura is introduced [295]. Framed Tempura has new operations such as projection operator prj, synchronous communication await, and framing operator frame [295].
However, there are cases where an explicit statement has to be made upon a variable that does not change. Whenever a memory cell has to be updated, it will be a very costly operation. This is called the framing problem. As a solution to this problem is an increase of the speed of the simulator. Instead of updating m memory cells m times, only one statement is needed [49].
2.7.1.2 Transactional Memory
There four attributes which define the transaction notion are Atomicity, Consistency, Isolation, Durability or what is known for short as ACID. Transactional Memory (TM) is defined as follows [82]:
Definition 8 “Transactional Memory (TM) is a promising lock-free technique that enables parts of a program to execute with atomicity and isolation, without regard to other concurrently ex- ecuting tasks. TM allows programs to read and modify disparate primary memory locations atomically as a single operation.”
Atomicity ensures either a commitment of the operations in a transaction completely or abortion of all the operations and leaving no evidence behind [82].
Consistency ensures that the data in the memory is consistent with its corresponding state. Only successful transactions commit their data and permanently store them; otherwise, the old data is restored. Isolation ensures that an execution of a transaction does not affect other concur- rent transactions. In other words, the result of these concurrent executions has to be equivalent like they were executed sequentially. Durability ensures storing the modified data of a successful transaction on a durable media such as a disk.
Transactional Memory (TM) is relatively easy to use, and it does not need locks, as it is lock-free which avoids the occurrence of deadlocks scenario. The performance is boosted due to the increase of parallelism level. However, its application is limited and the debugging is difficult to place a breakpoint within the transaction.
El-kustaban [82] [80] has formalised Transactional Memory (TM) in Interval Temporal Logic (ITL) and verified it using Tempura/AnaTempura. There are still aspects such as nested trans- actions and mechanisms of updating the memory which should be imported to provable abstract TM.
It is challenging to control parallel systems accessing shared resource in order to guarantee correctness property such as consistency of shared resource. In order to avoid having access conflicts, a synchronisation mechanism has to be applied. Techniques have been used to apply synchronisation mechanism such as lock-based, lock-free and wait-free.
Lock-free and wait-free avoid using locks which could cause deadlock. However, they are complex to implement. More precisely, as Transactional Memory (TM) is a lock-free tech- nique, it avoids lock-based problems and offers high-level abstract parallel programming mod- els. However, even though the claim made by Transactional Memory (TM) research community that programming with Transactional Memory (TM) is easier than alternatives such as locks, but evidence is scant [228]. A study was made [228] in which 147 undergraduate students in an op-
erating systems course implemented the same programs using coarse-grain and fine-grain locks, monitors, and Transactional Memory. A survey was made on the students after the assignment and their code was examined to determine the types and frequency of the programming errors for each synchronisation technique. The evaluation shows that students found Transactional Mem- ory (TM) harder to use than coarse-grain locks, but slightly easier to use than fine-grained locks. More reasons why Transactional Memory (TM) is not sufficient enough are space overhead and latency. Transactional Memory (TM) requires significant amounts of global and per-thread meta-data. Transactional Memory (TM) has high single-thread latency, usually two times com- pared to lock-based technique [68]. Generally speaking, Mutual Exclusion (mutex) locks limit concurrency but offers single-thread latency, whereas, Transactional Memory (TM) has higher latency but scales well [68].
2.7.2 Meltdown and Spectre
Meltdown [156] and Spectre [138] are hardware vulnerabilities in modern computers leak pass- words and sensitive data. Meltdown and Spectre take advantage of modern processors critical vulnerabilities. As a consequent of these hardware vulnerabilities, programs get permissions to steal data that has been processed on the computer. Although reading data of programs from other programs is not permitted, a malicious program takes advantage of Meltdown and Spectre to get hold of sensitive personal information stored in the memory of other running programs. Stolen information might be passwords, personal photos, emails, bank card details, etc. Melt- down and Spectre might hit personal computers, mobile devices, and cloud servers. Hitting cloud providers’ infrastructure might cause a steal of data from other customers.
Meltdown breaks the most fundamental isolation between user applications and the operating system. Consequently, programs are allowed to access the memory of other programs and the operating system. Spectre breaks the isolation between different applications. Consequently, error-free programs get tricked by an attacker to leak their secrets. Spectre is harder to exploit
than Meltdown, but it is also harder to mitigate. For more information about Meltdown and Spectre, I refer the reader to [156,138].
These hardware vulnerabilities, Meltdown and Spectre, are my motive of choosing a case study of cache controller of cache memory and its implication on the main memory with respect to their correctness. The case study demonstrates a correctness of such critical systems and par- allel architectures such as multicore architecture to deliver modular, sound, complete, automatic, and an efficient model of the proposed computational model.