Journal/Paper.thy
changeset 143 c5a65d98191a
parent 142 10c16b85a839
child 144 e4d151d761c4
equal deleted inserted replaced
142:10c16b85a839 143:c5a65d98191a
   307 text {*
   307 text {*
   308   The Priority Inheritance Protocol, short PIP, is a scheduling
   308   The Priority Inheritance Protocol, short PIP, is a scheduling
   309   algorithm for a single-processor system.\footnote{We shall come back
   309   algorithm for a single-processor system.\footnote{We shall come back
   310   later to the case of PIP on multi-processor systems.} 
   310   later to the case of PIP on multi-processor systems.} 
   311   Following good experience in earlier work \cite{Wang09},  
   311   Following good experience in earlier work \cite{Wang09},  
   312   our model of PIP is based on Paulson's inductive approach to protocol
   312   our model of PIP is based on Paulson's inductive approach for protocol
   313   verification \cite{Paulson98}. In this approach a \emph{state} of a system is
   313   verification \cite{Paulson98}. In this approach a \emph{state} of a system is
   314   given by a list of events that happened so far (with new events prepended to the list). 
   314   given by a list of events that happened so far (with new events prepended to the list). 
   315   \emph{Events} of PIP fall
   315   \emph{Events} of PIP fall
   316   into five categories defined as the datatype:
   316   into five categories defined as the datatype:
   317 
   317 
   526 
   526 
   527   \noindent
   527   \noindent
   528   If there is no cycle, then every RAG can be pictured as a forrest of trees, as
   528   If there is no cycle, then every RAG can be pictured as a forrest of trees, as
   529   for example in Figure~\ref{RAGgraph}.
   529   for example in Figure~\ref{RAGgraph}.
   530 
   530 
       
   531   Because of the RAGs, we will need to formalise some results about graphs.
   531   While there are few formalisations for graphs already implemented in
   532   While there are few formalisations for graphs already implemented in
   532   Isabelle, we choose to introduce our own library of graphs for
   533   Isabelle, we choose to introduce our own library of graphs for
   533   PIP. The reason for this is that we wanted to be able to reason with
   534   PIP. The reason for this is that we wanted to be able to reason with
   534   potentially infinite graphs (in the sense of infinitely branching
   535   potentially infinite graphs (in the sense of infinitely branching
   535   and infinite size): the property that our RAGs are actually forrests
   536   and infinite size): the property that our RAGs are actually forrests
   536   of finitely branching trees having only an finite depth should be a
   537   of finitely branching trees having only an finite depth should be 
   537   something we can \emph{prove} for our model of PIP---it should not
   538   something we can \emph{prove} for our model of PIP---it should not
   538   be an assumption we build already into our model. It seemed for our
   539   be an assumption we build already into our model. It seemed for our
   539   purposes the most convenient represeantation of graphs are binary
   540   purposes the most convenient represeantation of graphs are binary
   540   relations given by sets of pairs from \eqref{pairs}. The pairs stand for the edges in
   541   relations given by sets of pairs from \eqref{pairs}. The pairs stand for the edges in
   541   graphs. This relation-based representation is convenient since we
   542   graphs. This relation-based representation is convenient since we
   562   @{thm subtree_def[where ?r="rel" and ?x="node", THEN eq_reflection]}\\
   563   @{thm subtree_def[where ?r="rel" and ?x="node", THEN eq_reflection]}\\
   563   @{thm ancestors_def[where ?r="rel" and ?x="node", THEN eq_reflection]}\\
   564   @{thm ancestors_def[where ?r="rel" and ?x="node", THEN eq_reflection]}\\
   564   \end{tabular}
   565   \end{tabular}
   565   \end{isabelle}
   566   \end{isabelle}
   566   
   567   
   567   \noindent Note that forests can have trees with infinte depth and
   568   \noindent Note that forrests can have trees with infinte depth and
   568   containing nodes with infinitely many children.  A \emph{finite
   569   containing nodes with infinitely many children.  A \emph{finite
   569   forrest} is a forest which is well-founded and every node has 
   570   forrest} is a forrest which is well-founded and every node has 
   570   finitely many children (is only finitely branching).
   571   finitely many children (is only finitely branching).
   571 
   572 
   572   \endnote{
   573   \endnote{
   573   \begin{isabelle}\ \ \ \ \ %%%
   574   \begin{isabelle}\ \ \ \ \ %%%
   574   @{thm rtrancl_path.intros}
   575   @{thm rtrancl_path.intros}
   579   \end{isabelle}}
   580   \end{isabelle}}
   580 
   581 
   581 
   582 
   582   \endnote{{\bf Lemma about overlapping paths}}
   583   \endnote{{\bf Lemma about overlapping paths}}
   583   
   584   
   584 
   585   The locking mechanism of PIP ensures that for each thread node,
   585   We will design our PIP-scheduler  
   586   there can be many incoming holding edges in the RAG, but at most one
   586   so that every thread can be in the possession of several resources, that is 
   587   out going waiting edge.  The reason is that when a thread asks for
   587   it has potentially several incoming holding edges in the RAG, but has at most one outgoing  
   588   resource that is locked already, then the thread is blocked and
   588   waiting edge. The reason is that when a thread asks for resource that is locked
   589   cannot ask for another resource.  Clearly, also every resource can
   589   already, then the thread is blocked and cannot ask for another resource.
   590   only have at most one outgoing holding edge---indicating that the
   590   Clearly, also every resource can only have at most one outgoing holding edge---indicating
   591   resource is locked. So if the @{text "RAG"} is well-founded and
   591   that the resource is locked. In this way we can always start at a thread waiting for a 
   592   finite, we can always start at a thread waiting for a resource and
   592   resource and ``chase'' outgoing arrows leading to a single root of a tree. 
   593   ``chase'' outgoing arrows leading to a single root of a tree.
   593   
   594   
   594   The use of relations for representing RAGs allows us to conveniently define
   595   The use of relations for representing RAGs allows us to conveniently define
   595   the notion of the \emph{dependants} of a thread using the transitive closure
   596   the notion of the \emph{dependants} of a thread using the transitive closure
   596   operation for relations, written ~@{term "trancl DUMMY"}. This gives
   597   operation for relations, written ~@{term "trancl DUMMY"}. This gives
   597 
   598 
   609   which in turn needs to wait for @{text "th\<^sub>0"} to finish). If
   610   which in turn needs to wait for @{text "th\<^sub>0"} to finish). If
   610   there is a circle of dependencies in a RAG, then clearly we have a
   611   there is a circle of dependencies in a RAG, then clearly we have a
   611   deadlock. Therefore when a thread requests a resource, we must
   612   deadlock. Therefore when a thread requests a resource, we must
   612   ensure that the resulting RAG is not circular. In practice, the
   613   ensure that the resulting RAG is not circular. In practice, the
   613   programmer has to ensure this. Our model will assume that critical 
   614   programmer has to ensure this. Our model will assume that critical 
   614   reseources can only be requested provided no circularity can arise.
   615   resources can only be requested provided no circularity can arise.
   615 
   616 
   616   Next we introduce the notion of the \emph{current precedence} of a thread @{text th} in a 
   617   Next we introduce the notion of the \emph{current precedence} of a thread @{text th} in a 
   617   state @{text s}. It is defined as
   618   state @{text s}. It is defined as
   618 
   619 
   619   \begin{isabelle}\ \ \ \ \ %%%
   620   \begin{isabelle}\ \ \ \ \ %%%