From: Sellakumaran Kanagarathnam (sellak_at_windows.microsoft.com)
Date: Wed Jan 07 2004 - 11:43:37 PST
This paper talks about the multiprogramming effort at the Technological
University in Eindhoven. The author gives a high level view of the
design of the system and shares his experiences regarding staffing for
the project, mistakes made during the course of the project and how
testing was simplified by the layered approach to the design. In the
appendix he also describes how mutual synchronization is achieved using
semaphores.
It starts by stating that they had limited human resources, further
worsened by the part-time availability. He explains the issue in
part-time availability and also stresses how highly skilled members are
essential to a project of this scale.
Then the author goes on to clearly state the goals of the effort. To
some extent he also states what the system is not intended to be.
Before going onto the details of the system, the author goes on to give
a progress report. He identifies two major mistakes during the course
of the project. Even though he states that the lack of debugging had no
serious consequences, it is hard to believe that and I tend to think of
it as his first impression. He goes on to say that they were very
careful to prevent nasty bugs from entering construction and they had
found that the logical soundness of the system (that they built) could
be proved and the system would help exhaustive testing. I did not find
detailed explanation of the proof, but he does talk about his testing
strategy. When he says the system is guaranteed to be flawless (even
before testing is complete), though amusing, it speaks of his confidence
in his proofs (which I couldn't explicitly find in his paper).
The author then gives the technical details of his design and he
describes segment variables, different sequential processes in the
system, synchronization. He then explains the different levels of
abstraction in the system: processor allocation, segment controller,
console management, peripheral management, user programs and operator at
the top. These different levels of abstractions had helped the team in
testing. In the design experience he explains the various stages
involved in that project. He concludes by saying how designers should
take into account of testing.
This is a neatly structured paper with lots of ideas which still hold
well. However additional explanations would have helped better
understanding of some of the points made.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 11:43:42 PST