prio/Paper/Paper.thy
changeset 316 0423e4d7c77b
parent 315 f05f6aeb32f4
child 317 2d268a0afc07
equal deleted inserted replaced
315:f05f6aeb32f4 316:0423e4d7c77b
  1158   PIP on top of PINTOS, a small operating system for teaching
  1158   PIP on top of PINTOS, a small operating system for teaching
  1159   purposes. A byproduct of our formalisation effort is that nearly all
  1159   purposes. A byproduct of our formalisation effort is that nearly all
  1160   design choices for the PIP scheduler are backed up with a proved
  1160   design choices for the PIP scheduler are backed up with a proved
  1161   lemma. We were also able to prove the property that the choice of
  1161   lemma. We were also able to prove the property that the choice of
  1162   the next thread taking over a lock is irrelevant for the correctness
  1162   the next thread taking over a lock is irrelevant for the correctness
  1163   of PIP. Earlier model checking techniques
  1163   of PIP. Earlier model checking approaches to verifying the
  1164   \cite{Faria08,Jahier09,Wellings07} were not able to provided this
  1164   correctness of PIP \cite{Faria08,Jahier09,Wellings07} were not able
  1165   kind of ``deep understanding'' into PIP.
  1165   to provide this kind of ``deep understanding'' about PIP.
  1166 
  1166 
  1167   PIP is a scheduling algorithm for single-processor systems. We are
  1167   PIP is a scheduling algorithm for single-processor systems. We are
  1168   now living in a multi-processor world. So the question naturally arises 
  1168   now living in a multi-processor world. So the question naturally
  1169   whether PIP has nowadays any relevance beyond teaching. 
  1169   arises whether PIP has any relevance nowadays beyond
  1170   
  1170   teaching. Priority inversion certainly occurs also in
  1171    The work in this paper only deals with single CPU configurations. The
  1171   multi-processor systems.  The surprising answer, according to
  1172   "one CPU" assumption is essential for our formalisation, because the
  1172   \cite{Steinberg10}, is that except for one unsatisfactory proposal
  1173   main lemma fails in multi-CPU configuration. The lemma says that any
  1173   nobody seems to have any good idea how PIP shoud be modified to work
  1174   runing thead must be the one with the highest prioirty or already held
  1174   correctly on multi-processor systems. The obstacles become clear
  1175   some resource when the highest priority thread was initiated. When
  1175   when considering that locking and releasing a resource always
  1176   there are multiple CPUs, it may well be the case that a threads did
  1176   requires some small time span. If processes are independent, then a
  1177   not hold any resource when the highest priority thread was initiated,
  1177   low priority process can always ``steal'' a the lock for such a
  1178   but that thread still runs after that moment on a separate CPU. In
  1178   resource from a high-priority process that should have run next. In
  1179   this way, the main lemma does not hold anymore.
  1179   effect, we have again the problem of Priority Inversions. It seems 
  1180 
  1180   difficult to design an algorithm with a meaningful property from
  1181 
  1181   PIP.  We can imagine PIP can be of use in a situation where
  1182   There are some works deals with priority inversion in multi-CPU
  1182   processes are not independent, but coordinated such that a master
  1183   configurations[???], but none of them have given a formal correctness
  1183   process distributes the work over some slave processes. However a
  1184   proof. The extension of our formal proof to deal with multi-CPU
  1184   formal investigation of this is beyond the scope of this paper.
  1185   configurations is not obvious. One possibility, as suggested in paper
       
  1186   [???], is change our formal model (the defiintion of "schs") to give
       
  1187   the released resource to the thread with the highest prioirty. In this
       
  1188   way, indefinite prioirty inversion can be avoided, but for a quite
       
  1189   different reason from the one formalized in this paper (because the
       
  1190   "mail lemma" will be different). This means a formal correctness proof
       
  1191   for milt-CPU configuration would be quite different from the one given
       
  1192   in this paper. The solution of prioirty inversion problem in mult-CPU
       
  1193   configurations is a different problem which needs different solutions
       
  1194   which is outside the scope of this paper.
       
  1195 
       
  1196   no clue about multi-processor case according to \cite{Steinberg10} 
       
  1197 
  1185 
  1198  
  1186  
  1199 
  1187 
  1200 *}
  1188 *}
  1201 
       
  1202 section {* An overview of priority inversion and priority inheritance \label{overview} *}
       
  1203 
       
  1204 text {*
       
  1205 
       
  1206   Priority inversion refers to the phenomenon when a thread with high priority is blocked 
       
  1207   by a thread with low priority. Priority happens when the high priority thread requests 
       
  1208   for some critical resource already taken by the low priority thread. Since the high 
       
  1209   priority thread has to wait for the low priority thread to complete, it is said to be 
       
  1210   blocked by the low priority thread. Priority inversion might prevent high priority 
       
  1211   thread from fulfill its task in time if the duration of priority inversion is indefinite 
       
  1212   and unpredictable. Indefinite priority inversion happens when indefinite number 
       
  1213   of threads with medium priorities is activated during the period when the high 
       
  1214   priority thread is blocked by the low priority thread. Although these medium 
       
  1215   priority threads can not preempt the high priority thread directly, they are able 
       
  1216   to preempt the low priority threads and cause it to stay in critical section for 
       
  1217   an indefinite long duration. In this way, the high priority thread may be blocked indefinitely. 
       
  1218   
       
  1219   Priority inheritance is one protocol proposed to avoid indefinite priority inversion. 
       
  1220   The basic idea is to let the high priority thread donate its priority to the low priority 
       
  1221   thread holding the critical resource, so that it will not be preempted by medium priority 
       
  1222   threads. The thread with highest priority will not be blocked unless it is requesting 
       
  1223   some critical resource already taken by other threads. Viewed from a different angle, 
       
  1224   any thread which is able to block the highest priority threads must already hold some 
       
  1225   critical resource. Further more, it must have hold some critical resource at the 
       
  1226   moment the highest priority is created, otherwise, it may never get change to run and 
       
  1227   get hold. Since the number of such resource holding lower priority threads is finite, 
       
  1228   if every one of them finishes with its own critical section in a definite duration, 
       
  1229   the duration the highest priority thread is blocked is definite as well. The key to 
       
  1230   guarantee lower priority threads to finish in definite is to donate them the highest 
       
  1231   priority. In such cases, the lower priority threads is said to have inherited the 
       
  1232   highest priority. And this explains the name of the protocol: 
       
  1233   {\em Priority Inheritance} and how Priority Inheritance prevents indefinite delay.
       
  1234 
       
  1235   The objectives of this paper are:
       
  1236   \begin{enumerate}
       
  1237   \item Build the above mentioned idea into formal model and prove a series of properties 
       
  1238     until we are convinced that the formal model does fulfill the original idea. 
       
  1239   \item Show how formally derived properties can be used as guidelines for correct 
       
  1240     and efficient implementation.
       
  1241   \end{enumerate}
       
  1242   The proof is totally formal in the sense that every detail is reduced to the 
       
  1243   very first principles of Higher Order Logic. The nature of interactive theorem 
       
  1244   proving is for the human user to persuade computer program to accept its arguments. 
       
  1245   A clear and simple understanding of the problem at hand is both a prerequisite and a 
       
  1246   byproduct of such an effort, because everything has finally be reduced to the very 
       
  1247   first principle to be checked mechanically. The former intuitive explanation of 
       
  1248   Priority Inheritance is just such a byproduct. 
       
  1249   *}
       
  1250 
       
  1251 section {* General properties of Priority Inheritance \label{general} *}
       
  1252 
       
  1253 text {*
       
  1254  
       
  1255   *}
       
  1256 
  1189 
  1257 section {* Key properties \label{extension} *}
  1190 section {* Key properties \label{extension} *}
  1258 
  1191 
  1259 (*<*)
  1192 (*<*)
  1260 context extend_highest_gen
  1193 context extend_highest_gen
  1414 
  1347 
  1415   {\em Examples of inaccurate specification of the protocol ???}.
  1348   {\em Examples of inaccurate specification of the protocol ???}.
  1416 
  1349 
  1417 *}
  1350 *}
  1418 
  1351 
  1419 section {* Conclusions \label{conclusion} *}
       
  1420 
       
  1421 text {*
       
  1422  
       
  1423 
       
  1424 *}
       
  1425 
  1352 
  1426 (*<*)
  1353 (*<*)
  1427 end
  1354 end
  1428 (*>*)
  1355 (*>*)