Deadlock-Free Monitors

Abstract

Monitors constitute one of the common techniques to synchronize threads in multithreaded programs, where calling a wait command on a condition variable suspends the caller thread and notifying a condition variable causes the threads waiting for that condition variable to resume their execution. One potential problem with these programs is that a waiting thread might be suspended forever leading to deadlock, a state where each thread of the program is waiting for a condition variable or a lock. In this paper, a modular verification approach for deadlockfreedom of such programs is presented, ensuring that in any state of the execution of the program if there are some threads suspended then there exists at least one thread running. The main idea behind this approach is to make sure that for any condition variable v for which a thread is waiting there exists a thread obliged to fulfil an obligation for v that only waits for a waitable object whose wait level, an arbitrary number associated with each waitable object, is less than the wait level of v. The relaxed precedence relation introduced in this paper, aiming to avoid cycles, can also benefit some other verification approaches, verifying deadlock-freedom of other synchronization constructs such as channels and semaphores, enabling them to accept a wider range of deadlock-free programs. We encoded the proposed proof rules in the VeriFast program verifier and by defining some appropriate invariants for the locks associated with some condition variables succeeded in verifying some popular use cases of monitors including unbounded/bounded buffer, sleeping barber, barrier, and readers-writers locks. A soundness proof for the presented approach is provided; some of the trickiest lemmas in this proof have been machine-checked with Coq.

Starvation-Free Monitors

“…Hamin et al [6,7,9] introduced a modular approach for verifying absence of deadlock in programs synchronized using condition variables (CVs), where executing a command wait(v, l) on a CV v, which is associated with a lock l, releases l and suspends the running thread, and executing commands notify (v) or notifyAll (v) wake up one or all thread(s) waiting for CV v at which point they will try to reacquire l. This approach ensures absence of deadlock by making sure that for any CV v for which a thread is waiting there is a thread obliged to fulfill an obligation for v which only waits for waitable objects whose levels are lower than the level of v. In this approach when a thread acquires a lock l, the total number of waiting threads, and the total number of obligations of any CV v associated with l, denoted by Wt (v) and Ot(v) respectively, can be mentioned in the proof of that thread. Wt and Ot are actually two bags 4 which keep track of the total number of the waiting threads and the total number of the obligations of the condition variables associated with a lock, respectively.…”

“…To verify deadlock-freedom of the program shown in Figure 1 it is necessary to transfer an obligation of v from the thread running leave to the thread whose ticket number equals to the new value of active, if there exists such a thread. However, it is impossible to verify deadlock-freedom of this program using the proof system introduced by Hamin et al [6,9] due to the following reasons: 1) this approach does not allow obligations to be transferred through broadcasts, because it is not clear which of the waiting threads should receive the transferred obligations, and 2) (even if such a transfer is possible) this approach allows obligations to be transferred through notifications only if there is a thread waiting for that condition variable (0 < Wt(v)), because it ensures that a thread will immediately receive the transferred obligations. Note that in this program there might be a situation where the thread whose ticket number equals the new value of active is not waiting for v but has been already awoken (by a broadcast issued beforehand) and is waiting to reacquire the lock associated with v.…”

“…Recently, Hamin et al [6,7] introduced a modular approach to verify absence of deadlock in monitors. This approach ensures that in any state of the execution there is a thread running, not waiting for a lock or condition variable, until the program terminates.…”

“…This information must ensure the awoken threads that they are approaching the front of the waiting queue (for example, in Figure 1 this information implies that the now serving ticket number has been increased ). Although the approach presented in [6] allows permissions to be transferred through notifyAll, it considers permissions as linear resources, which cannot be in possession of more than one thread at the same time. Consequently, in that approach a notifying thread can transfer a permission p to n number of waiting threads only if it owns n instances of p. Fig.…”

A separation logic to verify termination of busy-waiting for abrupt program exit

“…We start by introducing the programming language in Section 2 and continue in Section 3 with presenting the separation logic and so-called obligations and credits [3,4,11,12], which we use to reason about termination of busywaiting. In Section 4 we present our verification approach in the form of a set of proof rules and illustrate their application.…”