@@ -177,15 +177,15 @@ This linearization point being atomic, it allows the opening of invariants just
\begin{mathpar}
%
\infer{%
\lahoare{\Forall x. P}{e}{Q}
\lahoare<x> {P}{e}{Q}
}{%
\Forall x. \hoare{P}{e}{Q}
}
\infer{%
\lahoare{\Forall x. I \isep P}{e}{I \isep Q}
\lahoare<x> {I \isep P}{e}{I \isep Q}
}{%
\knowInv{}{I}\vdash\lahoare{\Forall x. P}{e}{Q}
\knowInv{}{I}\vdash\lahoare<x> {P}{e}{Q}
}
%
\end{mathpar}
...
...
@@ -201,8 +201,7 @@ in~\fref{fig:queue:specsc}.
It closely resembles that of the sequential setting (\fref{fig:queue:specseq}).
The first difference that can be seen is the use of angle brackets $\anglebracket{\ldots}$ denoting logically atomic triples instead of curly brackets $\curlybracket{\ldots}$ for ordinary Hoare triples.
Another difference is the presence of embedded universal quantifiers ($\forall\nbelems, \elemList*[]{.}$) in the syntax of logically atomic triples.
% TODO: in Iris literature the binder is simply denoted as "x." with no ∀ symbol.
Another difference is the presence of embedded universal quantifiers ($\lahoarebinder{\nbelems, \elemList*[]}$) in the syntax of logically atomic triples.
These additional bindings address a subtlety of logical atomicity: indeed, recall that the precondition and the postcondition are to be interpreted at the linearization point.
However, the state of the shared queue is not known in advance by the client when calling the functions $\enqueue$ and $\dequeue$: instead, both the preconditions and the postconditions need to be parameterized by said shared state.
Said otherwise, since we do not know in advance when executing a program fragment the state of the shared resource at the linearization point, a logically atomic triple provides a \emph{familly} of pre/postcondition pairs covering all the possible shared states at the linearization point.
