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

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.

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.

Access to these \emph{non-atomic invariants} is thus guarded by tokens that take the role that masks play for ``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$.

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

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

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

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

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).

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

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

where every pool is a thread.

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

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

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

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.

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

...

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

\paragraph{World Satisfaction.}

\paragraph{World Satisfaction.}

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

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

\begin{align*}

\begin{align*}

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

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

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

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

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

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

\mapComp{\iname}

\mapComp{\iname}

...

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

...

@@ -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).

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.

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.

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 $\mathcal I$ is infinite.

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)}\]

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:

We will overload the notation for invariant assertions for using namespaces instead of names: