An operating system is a - usually extensive - collection of computer software which makes a raw computer more or less usable by people. To most people who use computers, the operating system is indistinguishable from the hardware; they never experience the machine by itself. It is the operating system's job to communicate with the people who use it, to look after their files, to do sensible things when they do silly things, and generally to look after all the jobs that must be done but which are too complicated conveniently to be built into the hardware.
The operating system is the link between the people who use the system, and the machinery which it comprises. In discussing the system, we can begin from either end. The traditional approach ( which you will find in almost all textbooks ) is from the hardware end, beginning with a treatment of how to get a lot of work done on a single processor, and working through memory management, disc organisation, device control, and so on. This approach works well if you can choose a particular model of a computer system, preferably one familiar to all those taking the course, and typical of most organisations' computing practices. It seems to us that it is less satisfactory now, when we have to deal with a large and growing variety of different types and sizes of computers, and where widely divergent modes of use of the machines are rapidly developing.
In this course, therefore, we start at the other end. We begin by asking what people want to do with computers, and how their needs can be met. The material of the course is much the same as you will find in the textbooks : we have changed the order of presentation, and we have taken a top-down rather than a bottom-up view. We believe that the more general "high level" considerations will prove more durable than details of specific techniques and methods, so should be of more use in the rapidly changing world of computers.
The recommended text ( A. Silberschatz, P.B. Galvin : Operating system concepts ( Addison-Wesley, fourth edition, 1994, or fifth edition, 1998 ) ) is a good book, with lots of detail which fills out the material presented in the lectures and in the distributed notes. It complements the course rather than reproduces it; we shall treat the topics of the textbook, but not in the same order. This is partly because we deal with the topics in an unusual order ( see above ), but it is valuable anyway because you get two rather different views of operating systems rather than just one.
Because we don't work directly from the textbook, it really doesn't matter which edition you use. We used the fourth edition last year ( obvious, really, if you look at the publication dates ), and second-hand copies will therefore be fourth editions, but new copies are likely to be fifth editions.
The textbook we used before the recommended text ( M.G. Lane, J.D. Mooney : A practical approach to operating systems ( Boyd and Fraser, 1988 ) ) fitted the course rather better than the current text, but it's out of print. You might like to look at that occasionally - it's in the library - for some topics which aren't treated very thoroughly in the recommended text.
The textbook is particularly good for examples of features implemented in real systems. The notes emphasise principles much more than examples, because, being principles, they're more important - but that doesn't mean that we think examples are unimportant. ( It does mean that we're very unlikely to ask you questions which require detailed knowledge of what happens in any individual operating system, unless we've stressed that particular example in the notes or in the lectures. ) We strongly recommend that you look up examples in the textbooks, or elsewhere, while you're studying your notes, because they can help a lot in understanding just how the ideas fit into a practical system.
An overwhelming quantity of literature is available for your entertainment, or even study. The types are listed below. At this very moment, it's all 1997 material, but the notes will be transformed into 1998 versions as time goes by.
( Yes, you've heard it all before, but don't say we didn't tell you. )
KEEP UP TO DATE.
Don't leave everything until the week before the examinations; try to make sense of the material covered in the course as it comes along. Look at the notes we distribute; notice what we present in the lectures, which may expand on the notes, or add to them, or provide examples; read the relevant parts of the textbook; discuss the material with friends ( or anybody ). It's a good idea to look at another textbook too if you can, to get a different viewpoint; there are several good texts in the library.
Another resource is available : 340 tests and examination papers for many years past, with full answers and comments. Don't just print them all at once, for there's a lot of repetition; spend some time browsing to work out which bits you want. You will find that the comments contain quite a lot of information about common mistakes, and expand on many details to a degree impossible in the notes.
If you do all that, you will probably discover that the field of operating systems is not consistent. Do not be concerned; that's realistic. There is no single right way to build an operating system, and many different approaches are possible. Different people use different terminology, many questions have several answers. That doesn't mean that some of the answers are wrong - different answers may be appropriate for different circumstances, or in some cases we just don't know. In such cases, you have to form your own opinions. It's good exercise to try to see the points of view which lead to the conflicting positions; there is usually some sense in all of them.
The course is about operating systems; you have all used operating systems, and will use more during the year. Think about what you're doing - as you learn about operating systems, ask how what you are learning applies to what you are doing. If it doesn't apply, ask why not, and decide whether it could usefully be added in some way. Don't be satisfied until you are sure that you would be able to implement whatever it is. ( It doesn't much matter whether you really can or not; the important thing is to get a good understanding of how the bits of the operating system must fit together. )
If you have tried hard to understand something and, after trying the various approaches we've discussed in the previous paragraphs, you still can't understand, please do ask one of us about it. You can come to visit us, or write us letters, but the most effective way is to use the electronic mail system; you don't have to wait for us to turn up, and it's easy for us to reply. Usually, we'll answer within a day or so at the worst; if we think your question is sufficiently complicated to warrant a meeting, we'll tell you so, and suggest some times. We haven't yet bitten any students, particularly through electronic mail, so you will be quite safe. The best way is first to try to work out a few fairly specific questions which you would like to discuss, and then ask about them - but if you can't do that, ask anyway. And ask fairly soon; if you misunderstand chunks of the course, you are quite likely to misunderstand later chunks which depend on them.
DO NOT WORRY that we might think your questions stupid, and form a bad impression of you; we are more likely to be favourably impressed by the evidence that you're really doing some work for 340. Experience also shows that, in almost all cases, people who come along and say "This may be a silly question, but ..." either ask quite sensible questions, or do ask silly questions which we clear up on the spot, enjoy the joke together, then forget. It might help you if you remember that, despite appearances, we're quite human too, and we have asked ( and still do ask ) plenty of silly questions of our own.
If you work only a forty-hour week ( which is reasonable if you are not interested in your subjects, but in that case why are you doing them ? ), then, taking seven points as a full-time course at stage 3, you owe 340 something like twelve hours every week. We repeat : every week. If you come to the lectures, that's three hours; if you don't, you have even more time for private study. We don't expect you to spend more than four or five hours per week on assignments, and we do try to get the assignments to you so that you can spread out the work over several weeks. That leaves you with at least four or five hours to work on the course material every week. Do so. Notice that this argument is quite independent of anything happening in any other course; if someone else sets a hard assignment, then make sure that you don't let it exceed the twelve hours due to that course - or, if you do, regard it as overtime, and don't let it interfere with the 340 time. If our assignments exceed the time we've suggested averaged over the whole period of the assignment, let us know.
Alan Creak and Robert Sheehan,
July, 1998.
Go to Alan;
Go to Robert;
Go to the 340 course page;
Go to Computer Science.