Journal/Paper.thy
changeset 154 9756a51f2223
parent 152 15f4481bc0c9
child 155 eae86cba8b89
equal deleted inserted replaced
153:8a9767ab6415 154:9756a51f2223
  1520 end
  1520 end
  1521 (*>*)
  1521 (*>*)
  1522 
  1522 
  1523 section {* A Finite Bound on Priority Inversion *}
  1523 section {* A Finite Bound on Priority Inversion *}
  1524 
  1524 
       
  1525 (*<*)
       
  1526 context extend_highest_gen
       
  1527 begin
       
  1528 (*>*)
  1525 text {*
  1529 text {*
  1526 
  1530 
  1527   Like in the argument by Sha et al.~our result does not
  1531   Like in the argument by Sha et al.~our result does not yet guarantee
  1528   yet guarantee absence of indefinite Priority Inversion. For this we
  1532   absence of indefinite Priority Inversion. For this we further have
  1529   further have to assume that every thread gives up its resources
  1533   to assume that every thread gives up its resources after a finite
  1530   after a finite amount of time. We found that this assumption is not
  1534   amount of time. We found that this assumption is not so
  1531   so straightforward to formalise in our model. There are mainly two
  1535   straightforward to formalise in our model. There are mainly two
  1532   reasons for this: First, we do not specify what ``running'' the code
  1536   reasons for this: First, we do not specify what ``running'' the code
  1533   of a thread means, for example by giving an operational semantics
  1537   of a thread means, for example by giving an operational semantics
  1534   for machine instructions. Therefore we cannot characterise what are
  1538   for machine instructions. Therefore we cannot characterise what are
  1535   ``good'' programs that contain for every looking request also a
  1539   ``good'' programs that contain for every looking request also a
  1536   corresponding unlocking request for a resource. Second, we would
  1540   corresponding unlocking request for a resource.  Second, we can
  1537   need to specify a kind of global clock that tracks the time how long
  1541   distinghish between a thread that ``just'' locks a resource for a
  1538   a thread locks a resource. But this seems difficult, because how do
  1542   finite amount of time (even if it is very long) and one that locks
  1539   we conveniently distinguish between a thread that ``just'' locks a
  1543   it forever. But this seems difficut.
  1540   resource for a very long time and one that locks it forever.
       
  1541 
  1544 
  1542   Therefore we decided in our earlier paper \cite{ZhangUrbanWu12} to
  1545   Therefore we decided in our earlier paper \cite{ZhangUrbanWu12} to
  1543   leave out this property and let the programmer assume the
  1546   leave out this property and let the programmer assume the
  1544   responsibility to program threads in such a benign manner (in
  1547   responsibility to program threads in such a benign manner (in
  1545   addition to causing no circularity in the RAG). However, in this
  1548   addition to causing no circularity in the RAG). However, in this
  1546   paper we can make an improvement: 
  1549   paper we can make an improvement: we can look at the \emph{events}
  1547 
  1550   that are happening once a Priority Inversion occurs. The events can
  1548 In this detail, we
  1551   be seen as a rough abstraction of the ``runtime behaviour'' of
  1549   do not make any progress in comparison with the work by Sha et al.
  1552   threads and also as an abstract notion for ``time''.  We can then
  1550   However, we are able to combine their two separate bounds into a
  1553   prove a more direct result for the absence of indefinite Priority
  1551   single theorem improving their bound. We can characterise a 
  1554   Inversion. For this let us introduce the following definition:
  1552   program
  1555 
       
  1556   \begin{isabelle}\ \ \ \ \ %%%
       
  1557   @{thm blockers_def}
       
  1558   \end{isabelle}
       
  1559 
       
  1560   \noindent This set contains all treads that can potentially block
       
  1561   @{text th} after state @{text s}.
       
  1562 
  1553 
  1563 
  1554 *}
  1564 *}
  1555 
  1565 (*<*)
       
  1566 end
       
  1567 (*>*)
  1556 
  1568 
  1557 section {* Properties for an Implementation\label{implement} *}
  1569 section {* Properties for an Implementation\label{implement} *}
  1558 
  1570 
  1559 text {*
  1571 text {*
  1560   While our formalised proof gives us confidence about the correctness of our model of PIP, 
  1572   While our formalised proof gives us confidence about the correctness of our model of PIP,