Giters

stateright / stateright

A model checker for implementing distributed systems.

Home Page:https://docs.rs/stateright

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Leveraging future's state machines

LegNeato opened this issue · comments

commented

Hello! Love this project. I had a thought the other day...Futures are state machines, and stateright explores state space. Rather than having to manually hoist state into the State associated type forActors, would it possible to automatically plug stateright into the generated state machine for futures? Essentially treating futures as actors, where the state is always Poll::Ready(val) or Poll::Pending?

commented

Hi @LegNeato. Thanks for reaching out! For that to work we need two things:

  1. the ability to return to an earlier state (for nondeterminism)
  2. the ability to pass inputs back into each actor

Both could be satisfied by a coroutine library providing the ability to clone a coroutine's state and resume a coroutine from that clone without impacting the original. I looked into that a year or two ago and didn't find any good candidates, but it might just have been a miss on my side, or perhaps someone has fulfilled those requirements in the meantime. Please let me know if you have any ideas/leads.

Alternatively a more invasive change could enable the ergonomic improvement you are suggesting. Stateright is a "stateful model checker" meaning it must be able to access the entire system state (i.e. no system state can be hidden), enabling the checker to know if a state has already been visited. There is a different technique called stateless model checking that does not require access to the internal state, but it comes with some trade-offs:

  1. debugging can be a bit more complex since not all state is necessarily visible
  2. the model checker must replay history for every nondeterministic "branch point," which could be more expensive (although this performance cost could be offset by state space reduction like DPOR as suggested in #7).

I'm on board with the idea; just short on time to implement at the moment. If you'd like to implement or if you have alternative proposals I would very much appreciate it, and we can talk through more details here.

commented

BTW one other difference is that with stateless checking you cannot assert properties on the global state of the system. Instead you would have to embed assertions in each actor or in a test harness that validates the externally observable behaviors (such as linearizability as assessed by a particular client).

commented

Makes sense, thank you for the reply! Let me dwell on this a bit.