db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{Welch90,
  title =        "{M}ulti-priority scheduling for transputer-based real-time control",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Welch, Peter H.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Zedan,  Hussein S. M.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "198--214",
  booktitle=     "{OUG}-13: {R}eal-{T}ime {S}ystems with {T}ransputers",
  isbn=          "90 5199 041 3",
  year=          "1990",
  month=         "sep",
  abstract=      "A major requirement of real-time control applications is a
     set of cyclic processes — one for each
     \&amp;quot;control-law\&amp;quot;. Each process must be
     managed so that it completes each cycle within a fixed time.
     The rate at which each process cycles will be constant, but
     will generally be different for different processes.Current
     transputer hardware provides very fast pre-emptive
     scheduling for two static priority levels, with
     \&amp;quot;round-robin\&amp;quot; management within each
     level. This is not sufficient to manage securely more than
     one such control-law per transputer — even at very low
     processor loadings. Efficient classical solutions (e.g.
     \&amp;quot;rate-monotonic\&amp;quot; or
     \&amp;quot;deadline\&amp;quot; scheduling) require multiple
     and time-varying priorities.This paper shows how to
     implement such solutions simply, and with an acceptable
     level of overhead, on the existing (and future) generation
     of transputer. Other promising scheduling methods are
     discussed. All solutions are expressed in occam with no
     assembler inserts and no security rules violated — the
     intended applications are safety-critical! Real performance
     figures are reported.Finally, a method of proving (or
     dis-proving) the security of any particular set of process
     loadings, operating under any particular scheduling
     algorithm, is described."
}