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

Re: [tlaplus] Protocol specification liveness


modeling a real-world protocol means choosing what to include in the model and what not. Your decision to exclude some irrelevant communication exchanges sounds reasonable. The deadlock that you see can be a symptom of two issues: either some relevant action (i.e., taking place after the omitted messages) has a precondition that would be established by the omitted actions, or it represents termination of your protocol. Inspecting the deadlock state should help you decide which is the case. In the first case, you need to fix your model. In the second case, assuming that all relevant liveness properties are verified (unchecking the box for checking deadlock), you may conclude that liveness holds *at the level at which the model is written*.


On 15 May 2017, at 06:20, Wan Azlan <wear...@xxxxxxxxx> wrote:

Hello TLA+ experts,

I recently wrote a peer-to-peer protocol specification for an industrial protocol. In order to simplify the number of states, I purposely left out from the specification message exchanges between the client and server when the communication line is in idle state. However, the specification goes into deadlock. When I include the idle state message exchange, I have a state space explosion until the JVM heap ran out of memory.

In your opinion, without specifying the idle message exchange, can I still argue that the specification meets its liveness property even though it goes into deadlock. 

Thank you

- Wan -       

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 post to this group, send email to tla...@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/tlaplus.
For more options, visit https://groups.google.com/d/optout.