Answer all questions. Each question is worth 10 marks, giving a total of 50 marks for the test.
I do not want long answers to read. A complete list of relevant points will get you full marks.
a) The introduction of SPOOLing meant that one computer could efficiently process the input and output requirements of jobs as well as the main processing. What technical developments were needed in order to make SPOOLing possible?
(3 marks)
b) It was common for batch systems to provide the user with several queues to submit jobs to the system. What purpose did the queues have? Give an example.
(2 marks)
c) Briefly describe why batch systems generally keep CPUs busier than interactive time-sharing systems do.
(5 marks)
a) The Macintosh user interface has one menu bar at the top of the display. The Windows user interface has one menu bar per application (you can have more than one application visible on the display at once). List advantages of each method.
(5 marks)
b) The original Oberon user interface allowed any visible string of text to be treated as a command (by clicking on it with the right mouse button). Explain how you could use this to provide your own menus and then discuss the advantages and disadvantages this has over a more traditional menu bar system.
(5 marks)
Here is part of an access control matrix:
(2 marks)
(2 marks)
(4 marks)
d) Describe some of the problems or inconveniences with access control lists.
(2 marks)
a) Describe one problem with allocating file blocks contiguously on disk.
(2 marks)
b) Describe one problem with allocating file blocks via a linked method with the links stored in the file blocks themselves.
(2 marks)
Some systems have attempted to make a compromise between these two methods. Firstly a certain amount of contiguous space is allocated for a file. If that space gets used up another contiguous space is found and the first is linked to it and so on.
c) Describe the information which needs to be stored in each of the contiguous sections of the file in order for this scheme to work. Should this information be stored at the beginning or end of each section (or somewhere else), give a reason.
(4 marks)
d) Show how this system deals with the problems you mentioned in parts a) and b). If it doesn't solve a problem, say why it doesn't.
(2 marks)
With both paged and segmented memory systems it is possible to share memory between two or more processes, by sharing pages or segments. Each process has an entry leading to the shared memory in its page or segment table.
a) Explain how it is possible for one process to be able to read and write to the shared memory and restrict another process to reading only.
(2 marks)
b) Sharing data between processes in this manner is straightforward. Similarly sharing the code for a program is straightforward. Things get more complicated when it comes to sharing library routines which are attached to the process when it is loaded. The difficulty is caused by shared library routines which refer to code positions within themselves. Explain what the difficulty is (Hint: Think of the addresses.). Provide two different solutions to the difficulty and give a reason why one is better than the other.
(8 marks)
Sections in italics were added after marking the test.
a) Disk drives and interrupt handling.
The importance of large disk drives can not be overemphasised. The data has to be transferred from slow sources of input to somewhere else, at the other end it has to be put somewhere quickly by the running process and then later transferred to the slow output devices. The only way this can work is with a random access device such as a disk (memory could also be used, but this was even more expensive).
b) Different queues signified different resource limitations. e.g. The amount of CPU time allocated to the job, the number of lines of printer output, the number of tapes required to be loaded to run …
The question states "It was common for batch systems to provide the user with several queues…". A lot of people ignored this when answering. They spoke about the FIFO operation of queues and said that it was the job of queues to hold tasks until they could run. The question was about the queues the user was given, not why were there queues in the operating system.
c) Batch systems are designed to use the hardware efficiently. The scheduler selects jobs according to their resource requirements and the currently available resources in the system. The idea is to always have a job ready to run. Interactive systems must keep a certain number of resource available to handle new requests from users. They cannot foretell the resource requirements of new jobs.
Some people said that interactive systems have to wait for i/o and that batch systems don't. Please think about this. Can any computer system work without i/o? Another related comment about interactive i/o being slower than i/o from a batch system is true, but it doesn't directly explain anything about the usage of the CPU. Too many people thought that when a process was waiting for i/o the CPU was waiting as well. Operating systems are not that badly designed..
a) Advantages for the Macintosh:
The user always knows where to look to find the menu bar.
It is much easier to position the pointer at the top of the display than on a narrow band. The pointer is prevented from moving past the top of the display. Studies have shown this speeds up menu selection time.
Also mentioned:
It takes up less room on the screen.
Advantages for Windows:
More menus can be shown on the display at once.
As screens get larger the pointer has less distance to travel to get to the menu bar of a specific application, rather than having to move all the way to the top of the display.
Also mentioned:
Users are less likely to select a menu item with the wrong program being the active one.
It was interesting how many people thought that the Macintosh only allowed one program to be visible on the screen at a time. After three years of using Macintoshes I thought you must know you can have many windows from many programs on the screen simultaneously.
Even though the question provided all the information you needed to think about the answer (I was only interested in the differences in the placement of the menu in the two interfaces) people made up extra information which they thought was relevant such as: Windows allows menus to have custom commands whereas the Mac doesn't; Windows programs don't have consistent menu items, the Mac is easier for the novice and Windows is better for the professional. All of these are wrong.
Only a handful of people mentioned the operational aspects of the different approaches, i.e. how the user has to move the pointer differently to get to the different menus.
b) A simple list of commands automatically becomes a menu.
Advantages:
The users can easily create their own menus.
Menus can be placed anywhere on the display.
Menus can have explanatory text around them.
Disadvantages:
Menus are not in consistent places.
There is no requirement for standard menu items (or menus themselves for that matter, such as File, Edit …).
Surprisingly this part of the question was done far better than the Mac, Windows part. Not many mentioned inconsistency of menu items as a potential problem.
This question was done well.
a) "Switch" means that a process running in this domain can switch to running in another domain. In the example a process running in D2 can switch to run in D3.
"Control" means that a process running in the original domain can change any access right in the controlled domain. In the example a process running in D2 can alter any elements in the D4 row.
b) D4 can switch to D1. D1 can switch to D2. D2 can print.
c) Access control lists are lists of pairs <domain,rights> over a particular object. They are usually thought of as being information belonging to the object. They correspond to columns in the matrix.
Capability lists are lists of pairs <object, rights> a particular domain has over the object. They are usually thought of as information belonging to the domain (or a process running in that domain). They correspond to the rows of the matrix.
d) They can be rather long. E.g. A file which can be read by everyone. This can be solved with default access rights.
Each access should be checked against the access control list, rather than caching the right somewhere (more like a capability).
It is difficult to work out what rights a process has in a particular domain because the rights are scattered throughout all the objects of the system.
This question was done very well.
a) It is difficult to add more information if there are no empty blocks following the contiguous area.
b) It is difficult to randomly access a point in the file. The links have to be traversed, with lots of blocks read. Another problem is that if any of the links get corrupted, the remaining data may be lost.
c) Each section needs to have its allocated length, its used length and the link to the next section. It is more efficient to store the information at the beginning of the section for ease of finding.
The used length could be worked out from the overall length of the file stored in a file attribute section, but the length of the sections themselves must be stored somewhere. The question doesn't state that the contiguous sections are all of the same size, if you assumed this in your answer you must state your assumption.
d) More information can be added by allocating another contiguous area. It doesn't solve the problems of random access, but it will minimise the problem because less reads are necessary. Similarly it minimises the problem of corrupt links since there are less of them.
This question was done poorly. People didn't understand the question in b).
a) The protection bits on the page or segment table entry can be different in each process.
Discussing locking memory or worse yet, locking files was not what I was looking for.
b) The difficulty is the addresses the shared library uses to refer to itself. If the address is an absolute address then the page or segment must be at the same absolute address (same page or segment table entry) in both processes.
Solutions include:
Reserving page table and segment table entries for each shared library. This can either be permanent or performed as the library is loaded the first time.
Only allowing self references in shared libraries to be via offsets into the library, e.g. as displacements or via a segment register.
The first solution is better than the second from the point of view of flexibility of the code generated by the compiler. This can possibly lead to faster code.
However the second solution is much better overall as we don't have to keep track of all the shared libraries and give them unique page or segment numbers.
Also see page 289 of the textbook.
Copying rather than sharing the libraries didn't seem a worthwhile solution to me.