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

*From*: 钱晨 <allenhandora@xxxxxxxxx>*Date*: Tue, 28 Jun 2022 19:52:29 -0700 (PDT)*References*: <9e859fd3-6d18-43f6-81b0-ed329f780047n@googlegroups.com> <2C070E7E-A900-4476-B102-808738D0A34A@gmail.com> <6d08a54c-e7eb-47ed-a8d2-5e551c4cac09n@googlegroups.com> <556DE16C-105F-46E9-B580-5BC5DD4C274D@gmail.com> <09eb6219-9a8b-4f35-ad5a-e522cf160e05n@googlegroups.com> <05BAD015-F2FC-4FAD-939C-F470AF363410@gmail.com>

I add the following condition into the fairness formulas, while it still reports the error for the liveness problem.

```

/\ \A rm \in RM:

SF_vars(TMRcvAborted(rm) /\ tmConfirmed' = RM)

```It still appears that `tmReboot` occurred repeatedly before `tmConfirmed` is fully collected, so it loops infinitely and violates the liveness property.

I do not understand what will happen if I declare a formula in liveness except formulas that already occurred in `Next`.

Will it be evaluated as an action or it will do something else?

Will it be evaluated as an action or it will do something else?

Stephan Merz 在 2022年6月29日 星期三凌晨12:37:45 [UTC+8] 的信中寫道：

It seems to me that you can express this condition by writingSF_vars(TMRcvAborted /\ tmConfirmed' = RM)But I don't understand your specification well enough to know if this is a reasonable fairness condition, and why you really need this variant rather thanWF/SF_vars(TMRcvAborted)which requires TMRcvAborted to occur eventually when it is enabled, eventually ensuring that tmConfirmed = RM.Given that no action appears to be in conflict with TMRcvAborted, there should be no difference between weak and strong fairness for this action.StephanOn 28 Jun 2022, at 18:28, 钱晨 <allenh...@xxxxxxxxx> wrote:Thanks for your nice explanation.I have another question I want to ask. When I run the case after solving the problem of 'tautology', it happens to be a case that violates the liveness check like below1. We have [a, b, c] as RM

2. ....3. TM is in 'aborted' state and all rms are in 'TombstoneNo' (* means forget the result, and 2pc will use Presumed Abort to answer the TM)4. TM receives one of the abort responses and fills in it in tmConfirmed(* like tmConfirmed = [a] *)5. Tm occurred tmReboot(* and tmConfirmed will be empty again(* like tmConfirmed = [] *)Then 4 and 5 will loop forever and cause a liveness problemI solve the problem by adding the following formulas into the `fairness`(I also add another one that involves "committed" state), and it finally pass the liveness check```/\ SF_vars(

/\ tmState = "aborted"

/\ tmConfirmed /= RM

/\ \A rm \in RM:

/\ [type |-> "RMABORTED", rm |-> rm] \in msgs

/\ tmConfirmed' = RM

/\

UNCHANGED<<rmState, tmState, tmParticipants, tmPrepared, msgs>>)

```It seems we must collect all responses before advancing to the next stage and cannot reboot during the process. In my way, we must write a completely new formula to achieve the goal. Does it exist another better writing style that can achieve the same goal or just use the original formula like `TMRcvAborted`?Stephan Merz 在 2022年6月28日 星期二晚上11:55:48 [UTC+8] 的信中寫道：> One more question, you say "When I comment out this useless fairness condition, TLC throws an exception that appears to indicate that some internal tables become too big.". I also encounter the problem, and I want to know what is meant by "some internal tables become too big". Does it mean that some data structures in TLC can not support the size of the action in the `Next`?

It's not the next-state relation that's the problem but the fairness conditions: TLC has to monitor for each fairness condition at which state the underlying action is enabled and which transitions correspond to the action being taken. I do not know how TLC represents this information, but apparently it is not meant to handle a lot of fairness conditions (remember that you have to multiply the RM actions by the number of resource managers in the model).

Stephan--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/09eb6219-9a8b-4f35-ad5a-e522cf160e05n%40googlegroups.com.

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 view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/259333f8-21cc-4d18-8fe8-9c4ed15ea3b3n%40googlegroups.com.

**References**:**[tlaplus] Question about "Temporal formula is a tautology" in fairness***From:*钱晨

**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness***From:*Stephan Merz

**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness***From:*Stephan Merz

**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness***From:*钱晨

**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness***From:*Stephan Merz

- Prev by Date:
**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness** - Next by Date:
**[tlaplus] How can I speed up model checking for this revised TLA+ spec of Raft?** - Previous by thread:
**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness** - Next by thread:
**Re: [tlaplus] Question about "Temporal formula is a tautology" in fairness** - Index(es):