[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*From*: Jay Parlar <parlar@xxxxxxxxx>*Date*: Thu, 2 May 2019 08:58:33 -0700 (PDT)*References*: <1fa1392c-0ec5-4d9e-b339-f7d1617c5117@googlegroups.com> <8147e0fe-bd5c-4653-8523-ef729b528834@googlegroups.com> <af589ad5-3cf3-4899-8be3-0c74d139b1d8@googlegroups.com> <a0489306-2ba7-4dbe-a7f5-ee1be6faaff3@googlegroups.com> <75179b6a-2163-410d-b143-984fafa4533c@googlegroups.com>

I believe I see your misunderstanding:

The temporal-property violating loop occurs under the following steps:

- we start in your initial state

- then we take a `rData` step, pink arrow, wherein `wayBack` becomes <<1>>

- then we take an `aWire` step, green arrow, wherein `endBack` becomes <<1>> and `wayBack` returns to <<>>

- then we take an `sData` step, blue arrow, which brings us back to the initial state

As a reminder, Spec looks like this

`Spec == /\ Init /\ [][Next]_vars /\ WF_vars(Next) /\ SF_vars(ackWire) /\ SF_vars(sData \/ ssd) /\ SF_vars(receiver)`

(I replaced `sender` with `sData \/ ssd`, as that is what `sender` is defined as)

If we look at your initial state in the state graph, we can see that there are two possible exists from it:

- A pink arrow to the right, 'rData', which is the one involved in the infinite loop

- A blue arrow to the left, 'sData', which is the one you _want_ to see eventually taken

Your question roughly is: "Why is an infinite loop allowed, shouldn't strong fairness guarantee that we eventually take that `sData` step out of the initial state?"

Let's recall what strong fairness means:

Let's recall what strong fairness means:

"Strong fairness asserts the a step `A` must occur if `A` is repeatedly enabled, even if it is also repeatedly disabled"

i.e., if some step is repeatedly made possible to take, then we'll eventually take it.

But now let's look at the steps that are taking place in your infinite loop:

rData -> aWire -> sData

Those steps take place over and over. And what's the third step there? An `sData` step! So your strong fairness is satisfied!

We've told the system that if `sData` is repeatedly enabled, then it must eventually be taken. The confusion in your system is that it's enabled _both_ from your initial state, but also after the `aWire` step takes place. It's enabled in two different places along the path of your infinite loop!

So while you personally would like to see that step taken from the initial state, the conditions of strong fairness are perfectly satisfied by that infinite loop. `sData` is repeatedly enabled in that infinite looping behaviour, and the `sData` step is always eventually taken. It always happens to only take the step in one of the two possible places it _could_ take the step, but that doesn't matter to TLA+.

I hope that helps!

Jay P.

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+unsubscribe@xxxxxxxxxxxxxxxx.

To post to this group, send email to tlaplus@xxxxxxxxxxxxxxxx.

Visit this group at https://groups.google.com/group/tlaplus.

For more options, visit https://groups.google.com/d/optout.

**Follow-Ups**:**[tlaplus] Re: problems debugging liveness errors.***From:*Jay Parlar

**References**:**[tlaplus] problems debugging liveness errors.***From:*david streader

**[tlaplus] problems debugging liveness errors.***From:*Jay Parlar

**[tlaplus] Re: problems debugging liveness errors.***From:*david streader

**[tlaplus] Re: problems debugging liveness errors.***From:*Jay Parlar

**[tlaplus] Re: problems debugging liveness errors.***From:*david streader

- Prev by Date:
**Re: [tlaplus] Beginner question: EXCEPT construct** - Next by Date:
**Re: [tlaplus] What does it mean to specify liveness for a "sys implementation"?** - Previous by thread:
**[tlaplus] Re: problems debugging liveness errors.** - Next by thread:
**[tlaplus] Re: problems debugging liveness errors.** - Index(es):