Reclamation breaks Ownership

Thread-modular analyses [Berdine et al. 2008; Jones 1983; Owicki and Gries 1976] verify each thread individually. On the one hand, this yields an efficient analysis for programs with a fixed number of threads as it avoids an explicit cross-product of all threads. On the other hand, it makes verification for an arbitrary number of threads possible. The downside of thread-modularity is its imprecision in computing thread interferences. Since threads are verified individually, the relation among thread-local information gets lost. We discuss this problem and why its common solution does not apply for manual memory management.

As we have seen in Chapter 4, thread-modular analyses abstract program configurations into sets of views which capture a thread’s perception of the configuration. To compute the effect that an interfering thread has on a victim thread, the views for the two threads are combined, the interfering thread takes a step in the resulting view, which is then projected to the victim thread. Combining two views is more problematic than one might think. As already noted, views

Section 6.1 Reclamation breaks Ownership 55

abstract away the relation among the interfering and victim threads. For an analysis to be sound, it has to consider all possible relations among those two threads. This introduces imprecision and may ultimately lead to false alarms. We illustrate the problem on an example.

Example 6.1.Consider the views from Figure 6.2 which arise during a thread-modular analysis of Michael&Scott’s queue. The threads captured by views𝜐₁and𝜐₂from Figure 6.2a are𝑡₁and𝑡₂, respectively. Thread𝑡₁is executing^enqueue. It has already allocated a new node𝑏, referenced by its local pointer variable𝑡₁∶^node, and is about to execute the^CASfrom Line 315 in order to insert the new node after^Tail. Thread𝑡₂is executing^dequeue. It has removed node𝑐, referenced by𝑡₂∶^head. Its next step is to retire𝑐.¹

Let us consider the interference𝑡₁is exposed to due to the actions of𝑡₂. The goal is to compute a new view for𝑡₁which captures the effect of𝑡₂performing the insertion. To that end, we combine the two views from Figure 6.2a. The result is given in Figure 6.2b. View𝜐₃ is the expected one:𝑡₁∶^nodepoints to𝑏and𝑡₂∶^headpoints to𝑐with𝑏≠𝑐—the threads hold pointers to distinct nodes. In𝜐₄, however, both threads alias the exact same node. Although peculiar, we have to consider view𝜐₄as well to guarantee soundness of the overall analysis, that is, guarantee that all possible views are explored. Indeed, just from inspecting𝜐₁and𝜐₂we cannot conclude that the memory layout of𝜐₄ is spurious in the sense that it does not occur in any execution of Michael&Scott’s queue. Unfortunately, the spurious view will lead to a false alarm.

To see why view𝜐₄is problematic, we continue to compute the inference. To that end, we let𝑡₂ execute its next command in𝜐₄. The result is view𝜐₄^′ from Figure 6.2c. In𝜐^′₄, node𝑏has been retired. Here, we assume that the retirement is followed immediately by a^free(𝑏). Next, we project away thread𝑡₂ from𝜐₄^′ and let𝑡₁execute its next command. In the resulting view,𝜐^′′₄ from Figure 6.2c, the deleted node𝑏has become the new^Tail, breaking the shape invariant of the queue. Subsequent^enqueueoperations can now reallocate𝑏and update it. The updates lead to unintended updates of the overall queue, changing the queue’s content or losing elements if the next field of𝑏is modified. This constitutes a linearizability violation, verification fails.

A well-known and common technique to avoid such spurious views during thread-modular analyses isownershipreasoning [Castegren and Wrigstad 2017; Dietl and Müller 2013; Gotsman et al. 2007; O’Hearn 2004; Vafeiadis and Parkinson 2007]. The allocation of a new node grants the allocating thread ownership over the new node. Ownership is removed as soon as the new node is published, that is, made accessible to other threads. Typically, this happens when a pointer to a node is written to a shared pointer variable or to a pointer field of another node that is reachable from the shared variables. (We refrain from a formal definition of ownership at this point.) Then, we exploit ownership to avoid spurious views and increase the precision

1The attentive reader of Chapter 2 might observe that, unlike presented in Figure 6.2 here, the next field𝑐 .next

of the removed but not yet retired node𝑐is never^NULLin Michael&Scott’s queue. To obtain such a view where𝑐 ._nextis^NULL, we require a preceding interference step which suffers from the same imprecision as the interference step presented here. For simplicity, we stick with𝑐 .nextbeing^NULLin this example.

56 ^{Chapter 6} Ownership and Reclamation

Figure 6.2:Views encountered during a thread-modular analysis of Michael&Scott’s queue.

Imprecision in interference steps leads to spurious verification failure.

(a)Two views the interference among which is computed. View𝜐₁captures thread𝑡₁which has allocated a new node𝑏and is about to append it to the^Tailof the queue via the^CASfrom Line 315.

View𝜐₂captures thread𝑡₂which has removed node𝑐from the queue and is about to retire it, Line 339.

⋯ 𝑎

(b)Possible combinations of views𝜐₁and𝜐₂. Judging from the view abstraction alone, a vanilla thread-modular analysis cannot know whether nodes𝑏and𝑐coincide in the actual program configuration the views abstract from. Interference has to consider both𝜐₃and𝜐₄, although𝜐₄spurious.

⋯ 𝑎

(c)Continuing the interference computation for𝜐₄, we let thread𝑡₂take a step and retire𝑏, Line 339.

The result is𝜐^′₄where the retirement of𝑏has immediately freed it (marked with †). Next, we project away𝑡₂and let𝑡₁execute Line 315. The result is𝜐^′′₄where the freed node𝑏has been inserted into the queue. Subsequent reallocations of𝑏may thus change the queue’s content unknowingly, leading to verification failure. Note that the verification failure is spurious since it is a result of the spurious𝜐₄.

⋯ 𝑎

of thread-modular analyses. To that end, we extend views to track ownership information and prevent combinations of views where an owned node is referenced by another non-owning thread. That is, we ensure that the access exclusivity granted by ownership is respected. For the above example, this means that thread𝑡₂cannot have a pointer to𝑏. Hence, we can rule out view𝜐₄as a combination of𝜐₁and𝜐₂because𝑏=𝑐is guarantee to be no longer possible.

While ownership reasoning is elegantly simple and yet effective, we cannot use it in our setting.

The above approach is sound only under garbage collection, when nodes are neither reused nor reclaimed, but unsound otherwise. We demonstrate this with an example. Thereafter, in Section 6.2, we introduce a new variant of ownership that applies to our setting.

Example 6.3.To see why traditional ownership reasoning breaks when memory is reclaimed and reused, consider the configurations of Micheal&Scott’s queue with hazard pointers depicted in Figure 6.4a. Configurationcfgcorresponds to the scenario where node𝑏used to be the^Tailof the queue, however, it has subsequently been removed from the queue, reclaimed, and reallocated.

The reallocating thread and owner of𝑏is𝑡₁. Thread𝑡₂started its operation while𝑏was still the^Tailand acquired a pointer to it,𝑡₂∶^tail. Node𝑏was removed and reallocated before𝑡₂ could protect it. Hence,𝑡₂∶^tailis a dangling pointer to the now𝑡₁-owned𝑏. The view abstraction ofcfgis the expected one: views𝜐₁and𝜐₂from Figure 6.4b. To make explicit that we lose any relation among threads in the abstraction, we renamed node𝑏to𝑐in𝜐₂(in practice, memory abstractions are unlikely to maintain the addresses explicitly [Chang et al. 2020]).

If we let thread𝑡₁continue its execution incfg, it appends𝑏to the end of the queue and then swings^Tailto the newly added node. The result iscfg^′from Figure 6.4a. For an analysis to be sound, interference has to produce from𝜐₁and𝜐₂a new view for𝑡₂that captures the effect of𝑡₁’s actions. The first step of interference is to combine𝜐₁ and𝜐₂. Intuitively, we expect the combined view to correspond tocfg. The fact that𝑡₁owns𝑏, however, makes traditional ownership reasoning ignore the relevant case𝑏 = 𝑐. That is,𝜐₁ and𝜐₂ do not producecfg although they were obtained from it. Consequently, it is not guaranteed that a view for𝑡₂ is explored which reflectscfg^′. This compromises soundness.

It is worth pointing out that under GC the same problem does not arise. Node𝑏would have not

been reclaimed due to𝑡₂∶^tailpointing to it.

To overcome the problem of an unsound analysis, we introduce a variant of ownership that allows for both soundness and precision in the presence of memory reclamation and reuse.

58 ^{Chapter 6} Ownership and Reclamation

Figure 6.4:Reallocation scenario from Michael&Scott’s queue with hazard pointers where traditional ownership reasoning, as done under garbage collection, is unsound.

(a)Program configurations without view abstraction. Incfg, thread𝑡₁owns node𝑏while𝑡₂holds a dangling pointer to it. The scenario arises if𝑏is reclaimed and subsequently reallocated in-between𝑡₂ acquiring and protecting pointer𝑡₂∶^tail. Next,𝑡₁inserts𝑏into the queue. The result iscfg^′.

owned(𝑡₁)

⋯ 𝑎

Tail

𝑏 𝑡₁∶^node

𝑡₂∶^tail

Configuration cfg 𝑡₁∶pc=Line 315 𝑡₂∶pc=Line 308

⋯ 𝑎

Tail

𝑏 𝑡₁∶^node

𝑡₂∶^tail

Configuration cfg^′ 𝑡₁∶pc=Line 317 𝑡₂∶pc=Line 308

(b)View abstraction forcfggives views𝜐₁and𝜐₂. Applying traditional ownership reasoning prevents a combined view where nodes𝑏and𝑐coincide, because𝑏is owned. Hence, configurationcfg^′is not guaranteed to be covered by any view. The analysis is unsound.

owned(𝑡₁)

⋯ 𝑎

Tail

𝑏 𝑡₁∶^node

View𝜐₁ 𝑡₁∶pc=Line 315

⋯ 𝑎

Tail

𝑐 𝑡₂∶^tail

View𝜐₂ 𝑡₂∶pc=Line 308

Section 6.1 Reclamation breaks Ownership 59