Sometimes it is necessary to maintain invariants that we need to open non-atomically.

Clearly, for this mechanism to be sound we need something that prevents us from opening the same invariant twice.

Access to these \emph{non-atomic invariants} is thus guarded by tokens that take the role that masks play for ``normal'', atomic invariants.

One way to think about them is as ``thread-local invariants''.

For every thread, we have a set of \emph{tokens}.

By giving up a token, you can obtain the invariant, and vice versa.

Such invariants can only be opened by their respective thread, and as a consequence they can be kept open around any sequence of expressions (\ie there is no restriction to atomic expressions).

To tie the threads and the tokens together, every thread is assigned a \emph{thread ID}.

Note that these thread IDs are completely fictional, there is no operational aspect to them.

In principle, the tokens could move between threads; that's not an issue at all.

Clearly, for this mechanism to be sound we need something that prevents us from opening the same invariant twice, something like the masks that avoid reentrancy on the ``normal'', atomic invariants.

The idea is to use tokens\footnote{Very much like the tokens that are used to encode ``normal'', atomic invariants} that guard access to non-atomic invariants.

Having the token $\NaTokE\pid\mask$ indicates that we can open all invariants in $\mask$.

The $\pid$ here is the name of the \emph{invariant pool}.

This mechanism allows us to have multiple, independent pools of invariants that all have their own namespaces.

One way to think about non-atomic invariants is as ``thread-local invariants'',

where every pool is a thread.

Every thread thus has its own, independent set of invariants.

Every thread threads through all the tokens for its own pool, so that each invariant can only be opened in the thread it belongs to.

As a consequence, they can be kept open around any sequence of expressions (\ie there is no restriction to atomic expressions) -- after all, there cannot be any races with other threads.

The last two are the tokens used for managing invariants, $\textmon{Inv}$ is the monoid used to manage the invariants themselves.

...

...

@@ -126,7 +126,7 @@ We assume that at the beginning of the verification, instances named $\gname_{\t

\paragraph{World Satisfaction.}

We can now define the assertion $W$ (\emph{world satisfaction}) which ensures that the enabled invariants are actually maintained:

\begin{align*}

W \eqdef{}&\Exists I : \mathcal I\fpfn\Prop.

W \eqdef{}&\Exists I : \InvName\fpfn\Prop.

\begin{array}[t]{@{} l}

\ownGhost{\gname_{\textmon{Inv}}}{\authfull

\mapComp{\iname}

...

...

@@ -471,8 +471,8 @@ We use the notation $\namesp.\iname$ for the namespace $[\iname] \dplus \namesp$

The elements of a namespaces are \emph{structured invariant names} (think: Java fully qualified class name).

They, too, are lists of $\nat$, 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 $\mathcal I$, the type of ``plain'' invariant names.

Any injective mapping $\textlog{namesp\_inj}$ will do; and such a mapping has to exist because $\List(\nat)$ is countable and $\mathcal I$ is infinite.

In order to connect this up to the definitions of \Sref{sec:invariants}, we need a way to map structued invariant names to $\InvName$, the type of ``plain'' invariant names.

Any injective mapping $\textlog{namesp\_inj}$ will do; and such a mapping has to exist because $\List(\nat)$ is countable and $\InvName$ is infinite.

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: