# Re: [tlaplus] Checking invariants periods during periods of quiescence

Hi Stephan,

I already check that my system terminates, so I believe the extra reassurance that the predicates are eventually restored is not useful since, when terminated, \A p \in ProcSet : (pc[p] \notin InvocationLabels) will also hold.

Thanks,
Jedd

On Monday, August 31, 2020 at 11:39:11 PM UTC-7 Stephan Merz wrote:
Hi,

the first approach that you describe is the standard way to check that a predicate holds throughout the execution except at certain control points. TLC will help you maintain an appropriate definition of the set of exceptions.

Your second suggestion is complementary: it ensures that the predicates are eventually restored [1]. If you've already checked the first property you can also write

\A p \in ProcSet : []<> ~(pc[p] \notin InvocationLabels)

or perhaps even

\A p \in ProcSet : <>[] ~(pc[p] \notin InvocationLabels)

if violations of the predicate are not recurrent.

Best,
Stephan

[1] Remember that a safety property is true of an algorithm that does nothing. In particular, checking your invariant won't require any fairness assumption, but the liveness property will.

On 1 Sep 2020, at 06:44, Jedd Haberstro <jhabe...@xxxxxxxxx> wrote:

Hi all,

I am modeling a concurrent data structure in PlusCal. There are invariants that may become false during method invocations, but which should become true once all such invocations have completed (during periods of "quiescence", if you will).

Is there a customary way to model check such types of invariants? Two approaches immediately come to mind, but I don't know if better approaches exist.
1. Check the invariant only when all processes' pc variables are equal to a label contained from within the relevant invocations' implementation. e.g. (\A p \in ProcSet : ~(pc[p] \in InvocationLabels)) => QuiescenceInvariant. This is quite a hairy approach because it will be error prone keeping InvocationLabels in sync with the PlusCal code.
2. A liveness property that states that if QuiescenceInvariant is not true, then it will eventually become true. e.g. ~QuiescenceInvariant ~> QuiescenceInvariant. However, this seems too imprecise because I believe it will be trivially satisfied when the algorithm terminates. I could probably add more constraints on this, but I imagine those constraints will just introduce new issues that need new constraints.
Any better ideas? :-)

Thanks,
Jedd

P.S. It's been ~2-3 weeks since I started learning TLA+/PlusCal and already I feel very productive! Kudos to the community for creating such a wonderfully approachable tool. The syntax is simple and readable, the toolbox is proving to be a helpful development environment, and the freely available learning material (e.g. Leslie's books and video course) is top notch. So, thank you all!

--
You received this message because you are subscribed to the Google Groups "tlaplus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+u...@xxxxxxxxxxxxxxxx.