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

incorporating modules into other modules when model checking



Hello

Stephen Merz provided some nice examples of communication primitives a while back: LossyQueue, AsyncInterleavingQueue, SyncInterleavingQueue. For example, the LossyQueue looked like this:

----------------------------- MODULE LossyQueue ---------------------------
EXTENDS Sequences
VARIABLES i,o,q

vars == <<o,q>>

LQInit == /\ q = <<>>
          /\ i = o
                    
LQEnq == /\ q' = Append(q,i')
         /\ o' = o

LQDeq == /\ q # <<>>
         /\ o' = Head(q) 
         /\ q' = Tail(q)
         /\ i' = i
                  
LQNext == LQEnq \/ LQDeq

LQLive == WF_vars(LQDeq)                               
LQSpec == LQInit /\ [][LQNext]_vars /\ LQLive

=======================================================================

I want to use a LossyQueue in a larger module to model a queue. And I also want to model check some correctness properties of the larger module which makes use of this LossyQueue. For example, let's say the larger module represents a system composed of a producer, a consumer and the lossy queue and I want to check whether or not messages enq'd by the producer are deq'd by the consumer. Let's say it's called ProducerConsumer.

I expect modules are there to provide reuse, but it isn't clear to me how this LossyQueue module could be reused in ProducerConsumer to model an instance of a lossy queue, nor is it clear to me how the LQSpec defined in this module could or would be incorporated into the model checking of ProducerConsumer. Am I way off track?

What I do at present is to define operations like Enq(q,i) and Deq(q) which operate on a sequence called q to append and remove elements and so behave like a queue. These macros can even be put in their own module, but any underlying sequences which the macros operate on appear in the large module. Is this the only approach I have for incorporating such data structures into my larger modules?