A \emph{language}$\Lang$ consists of a set \textdom{Expr} of \emph{expressions} (metavariable $\expr$), a set \textdom{Val} of \emph{values} (metavariable $\val$), and a set \textdom{State} of \emph{states} (metvariable $\state$) such that\begin{itemize}\item There exist functions $\ofval : \textdom{Val}\to\textdom{Expr}$ and $\toval : \textdom{Expr}\pfn\textdom{val}$ (notice the latter is partial), such that\begin{mathpar}{\All\expr, \val. \toval(\expr) = \val\Ra\ofval(\val) = \expr}\and{\All\val. \toval(\ofval(\val)) = \val}\end{mathpar}

\item There exists a \emph{primitive reduction relation}\[(-,-\step-,-,-)\subseteq\textdom{Expr}\times\textdom{State}\times\textdom{Expr}\times\textdom{State}\times(\cup_n \textdom{Expr}^n)\] A reduction $\expr_1, \state_1\step\expr_2, \state_2, \overline\expr$ indicates that, when $\expr_1$ reduces to $\expr_2$, the new threads in the list $\overline\expr$ is forked off. We will write $\expr_1, \state_1\step\expr_2, \state_2$ for $\expr_1, \state_1\step\expr_2, \state_2, ()$, \ie when no threads are forked off. \\

\end{defn}\begin{defn}[Context] A function $\lctx : \textdom{Expr}\to\textdom{Expr}$ is a \emph{context} if the following conditions are satisfied:\begin{enumerate}[itemsep=0pt]\item$\lctx$ does not turn non-values into values:\\$\All\expr. \toval(\expr)=\bot\Ra\toval(\lctx(\expr))=\bot$\item One can perform reductions below $\lctx$:\\

To introduce invariants into our logic, we will define weakest precondition to explicitly thread through the proof that all the invariants are maintained throughout program execution.However, in order to be able to access invariants, we will also have to provide a way to \emph{temporarily disable} (or ``open'') them.To this end, we use tokens that manage which invariants are currently enabled.We assume to have the following four CMRAs available:\begin{align*}\textmon{State}\eqdef{}&\authm(\exm(\textdom{State})) \\\textmon{Inv}\eqdef{}&\authm(\mathbb N \fpfn\agm(\latert\iPreProp)) \\\textmon{En}\eqdef{}&\pset{\mathbb N}\\\textmon{Dis}\eqdef{}&\finpset{\mathbb N}\end{align*}The last two are the tokens used for managing invariants, $\textmon{Inv}$ is the monoid used to manage the invariants themselves.Finally, $\textmon{State}$ is used to provide the program with a view of the physical state of the machine.Furthermore, we assume that instances named $\gname_{\textmon{State}}$, $\gname_{\textmon{Inv}}$, $\gname_{\textmon{En}}$ and $\gname_{\textmon{Dis}}$ of these CMRAs have been created.(We will discuss later how this assumption is discharged.)

Next, we define \emph{view updates}, which are essentially the same as the resource updates of the base logic ($\Sref{sec:base-logic}$), except that they also have access to world satisfaction and can enable and disable invariants:

We use $\top$ as symbol for the largest possible mask, $\mathbb N$.We will write $\pvs[\mask]\prop$ for $\pvs[\mask][\mask]\prop$.%View updates satisfy the following basic proof rules:\begin{mathpar}\infer[vup-mono]{\prop\proves\propB}{\pvs[\mask_1][\mask_2]\prop\proves\pvs[\mask_1][\mask_2]\propB}\infer[vup-intro-mask]{\mask_2 \subseteq\mask_1}

We further define the notions of \emph{view shifts} and \emph{linear view shifts}:\begin{align*}\prop\vs[\mask_1][\mask_2]\propB\eqdef{}&\always(\prop\Ra\pvs[\mask_1][\mask_2]\propB) \\\prop\vsW[\mask_1][\mask_2]\propB\eqdef{}&\prop\wand\pvs[\mask_1][\mask_2]\propB\end{align*}

These two are useful when writing down specifications, but for reasoning, it is typically easier to just work directly with view updates.Still, just to give an idea of what view shifts ``are'', here are some proof rules for them:\begin{mathparpagebreakable}\inferH{vs-update}{\melt\mupd\meltsB}{\ownGhost\gname{\melt}\vs\exists\meltB\in\meltsB.\;\ownGhost\gname{\meltB}}\and\inferH{vs-trans}{\prop\vs[\mask_1][\mask_2]\propB\and\propB\vs[\mask_2][\mask_3]\propC}{\prop\vs[\mask_1][\mask_3]\propC}\and\inferH{vs-imp}{\always{(\prop\Ra\propB)}}{\prop\vs[\emptyset]\propB}\and\inferH{vs-mask-frame}{\prop\vs[\mask_1][\mask_2]\propB}{\prop\vs[\mask_1 \uplus \mask'][\mask_2 \uplus \mask']\propB}\and\inferH{vs-frame}{\prop\vs[\mask_1][\mask_2]\propB}{\prop * \propC\vs[\mask_1][\mask_2]\propB * \propC}\and\inferH{vs-timeless}{\timeless{\prop}}{\later\prop\vs\prop}

We assume that everything making up the definition of the language, \ie values, expressions, states, the conversion functions, reduction relation and all their properties, are suitably reflected into the logic (\ie they are part of the signature $\Sig$).\begin{align*}

This ties the authoritative part of \textmon{State} to the actual physical state of the reduction witnessed by the weakest precondition.The fragment will then be available to the user of the logic, as their way of talking about the physical state:\[\ownPhys\state\eqdef\ownGhost{\gname_{\textmon{State}}}{\authfrag\state}\]

Furthermore, the following adequacy statement shows that our weakest preconditions imply that the execution never gets \emph{stuck}: Every expression in the thread pool either is a value, or can reduce further.\begin{align*}&\All\mask, \expr, \state, \melt, \state', \tpool'.\\&(\All n. \melt\in\mval_n) \Ra

\\&\cfg{\state}{[\expr]}\step^\ast\cfg{\state'}{\tpool'}\Ra\\&\All\expr'\in\tpool'. \toval(\expr') \neq\bot\lor\red(\expr', \state')\end{align*}Notice that this is stronger than saying that the thread pool can reduce; we actually assert that \emph{every} non-finished thread can take a step.

\paragraph{Hoare triples.}It turns out that weakest precondition is actually quite convenient to work with, in particular when perfoming these proofs in Coq.Still, for a more traditional presentation, we can easily derive the notion of a Hoare triple:\[\hoare{\prop}{\expr}{\Ret\val.\propB}[\mask]\eqdef\always{(\prop\Ra\wpre{\expr}[\mask]{\Ret\val.\propB})}\]

\subsection{Invariant Namespaces}\label{sec:namespaces}In \Sref{sec:invariants}, we defined an assertion $\knowInv\iname\prop$ expressing knowledge (\ie the assertion is persistent) that $\prop$ is maintained as invariant with name $\iname$.The concrete name $\iname$ is picked when the invariant is allocated, so it cannot possibly be statically known -- it will always be a variable that's threaded through everything.However, we hardly care about the actual, concrete name.All we need to know is that this name is \emph{different} from the names of other invariants that we want to open at the same time.Keeping track of the $n^2$ mutual inequalities that arise with $n$ invariants quickly gets in the way of the actual proof.To solve this issue, instead of remembering the exact name picked for an invariant, we will keep track of the \emph{namespace} the invariant was allocated in.Namesapces are sets of invariants, following a tree-like structure:Think of the name of an invariant as a sequence of identifiers, much like a fully qualified Java class name.A \emph{namespace}$\namesp$ then is like a Java package: it is a sequence of identifiers that we think of as \emph{containing} all invariant names that begin with this sequence. For example, \texttt{org.mpi-sws.iris} is a namespace containing the invariant name \texttt{org.mpi-sws.iris.heap}.The crux is that all namespaces contain infinitely many invariants, and hence we can \emph{freely pick} the namespace an invariant is allocated in -- no further, unpredictable choice has to be made.Furthermore, we will often know that namespaces are \emph{disjoint} just by looking at them.The namespaces $\namesp.\texttt{iris}$ and $\namesp.\texttt{gps}$ are disjoint no matter the choice of $\namesp$.As a result, there is often no need to track disjointness of namespaces, we just have to pick the namespaces that we allocate our invariants in accordingly.Formally speaking, let $\namesp\in\textlog{InvNamesp}\eqdef\textlog{list}(\mathbb N)$ be the type of \emph{invariant namespaces}.We use the notation $\namesp.\iname$ for the namespace $[\iname]\dplus\namesp$.(In other words, the list is ``backwards''. This is because cons-ing to the list, like the dot does above, is easier to deal with in Coq than appending at the end.)The elements of a namespaces are \emph{structured invariant names} (think: Java fully qualified class name).They, too, are lists of $\mathbb N$, the same type as namespaces.In order to connect this up to the definitions of \Sref{sec:invariants}, we need a way to map structued invariant names to $\mathbb N$, the type of ``plain'' invariant names.Any injective mapping $\textlog{namesp\_inj}$ will do; and such a mapping has to exist because $\textlog{list}(\mathbb N)$ is countable.Whenever needed, we (usually implicitly) coerce $\namesp$ to its encoded suffix-closure, \ie to the set of encoded structured invariant names contained in the namespace: \[\namecl\namesp\eqdef\setComp{\iname}{\Exists\namesp'. \iname=\textlog{namesp\_inj}(\namesp' \dplus\namesp)}\]We will overload the notation for invariant assertions for using namespaces instead of names:\[\knowInv\namesp\prop\eqdef\Exists\iname\in\namecl\namesp. \knowInv\iname{\prop}\]We can now derive the following rules (this involves unfolding the definition of view updates):\begin{mathpar}\axiomH{inv-persist}{\knowInv\namesp\prop\proves\always\knowInv\namesp\prop}

\subsection{Accessors}The two rules \ruleref{inv-open} and \ruleref{inv-open-timeless} above may look a little surprising, in the sense that it is not clear on first sight how they would be applied.The rules are the first \emph{accessors} that show up in this document.Accessors are assertions of the form\[\prop\vs[\mask_1][\mask_2]\Exists\var. \propB*(\All\varB. \propB' \vsW[\mask_2][\mask_1]\propC)\]One way to think about such assertions is as follows:Given some accessor, if during our verification we have the assertion $\prop$ and the mask $\mask_1$ available, we can use the accessor to \emph{access}$\propB$ and obtain the witness $\var$.We call this \emph{opening} the accessor, and it changes the mask to $\mask_2$.Additionally, opening the accessor provides us with $\All\varB. \propB' \vsW[\mask_2][\mask_1]\propC$, a \emph{linear view shift} (\ie a view shift that can only be used once).This linear view shift tells us that in order to \emph{close} the accessor again and go back to mask $\mask_1$, we have to pick some $\varB$ and establish the corresponding $\propB'$.After closing, we will obtain $\propC$.Using \ruleref{vs-trans} and \ruleref{Ht-atomic} (or the correspond proof rules for view updates and weakest preconditions), we can show that it is possible to open an accessor around any view shift and any \emph{atomic} expression.Furthermore, in the special case that $\mask_1=\mask_2$, the accessor can be opened around \emph{any} expression.For this reason, we also call such accessors \emph{non-atomic}.The reasons accessors are useful is that they let us talk about ``opening X'' (\eg ``opening invariants'') without having to care what X is opened around.Furthermore, as we construct more sophisticated and more interesting things that can be opened (\eg invariants that can be ``cancelled'', or STSs), accessors become a useful interface that allows us to mix and match different abstractions in arbitrary ways.\ralf{This would be much more convincing if we had forward references here to sections describing canellable invariants and STSs.}