Resources
| Depends on | What is an OS |
|---|
An important function of an operating system is resource management. The resources of the system are the things it has or may do, and these need to be managed – and sometimes rationed – amongst the competing demands of users.
Resources may be tangible features (such as a keyboard input) or less material, such as processor time. Here, briefly, are some examples.
Processing time
A computer will have one or more processors which do the actual computing. Every computation takes some amount of time. At a particular moment it is not unusual to want to do more computation than is possible; at other times there may be nothing to do. A typical operating system will share processing time as fairly as it knows how to try to provide a good service for competing demands. This is process scheduling.
Modern systems may have several processor ‘cores’. In addition, there may be other processing resources – such as a GPU – to consider.
Exactly what ‘best’ is may depend on circumstances. In a real-time system – such as flying an aeroplane – response time may be fairly obvious; with an interactive user ‘not obviously slow’ may be good enough; when calculating big computing loads – such as tomorrow’s weather forecast – concentrating on a single job at any time may maximise efficiency.
Memory
Any computer has a certain amount of storage for keeping its programs and data. This must be shared amongst competing demands. There are various techniques which allow the machine to appear to have more memory than it actually does, so the memory resource can be better exploited. This memory management is done by the operating system.
Address space
The space in which your code and variables might be is a related resource but it is slightly different from the memory which is in use. This, too, can be a precious resource. An operating system may allocate address space – the potential to use memory – but not give any real physical memory until and unless it gets used.
Here’s an analogy to illustrate this principle. Imagine you’re playing a computer game where you can explore a planet. In principle you can go anywhere in that space. In practice you will only ever see a small proportion in any detail, so the game only needs to create and store a small fraction of the possible area. Building a whole planet would take rather a long time and probably require a lot of money spent on disk drives!
Files
You have seen and used file systems quite a lot by now. Files are available to different software and sometimes, but not always, different people. Something has to manage this. What happens if two people or programs try to write to the same file at the same time? What if someone tries to delete a file which you’re reading?
This is all managed by the filing system, which is part of the operating system resource management.
Interfaces
A computer is no use unless it has some input and output; this usually involves many different I/O devices, all different. Programming every device in every application would be unrewarding! Usually an operating system tries to make devices look as similar to each other as is sensible which, in turn allows facilities such as redirecting your output from the screen to a file, or a printer with minimal difficulty.
It is also necessary to manage devices. For example a printer is usually a shared resource (printers are quite expensive and spend a lot of their time not printing) but something needs to make sure one job is finished before the next print-job starts.
Keeping track …
Users are often badly behaved; they do things like opening and reading from a file into dynamically allocated memory … and then terminating the process. This could leave the file open – perhaps even locked, preventing other processes from using it – and leak memory such that it was lost for reallocation.
Fortunately in most cases the operating system is allocating the resources and can track who-owns-what. It is then possible to check this information when a process dies and recycle the resources appropriately. This can be a particular issue if the process is terminated abnormally, e.g. via a SIGINT type of exception. (Nevertheless, shutting down processes tidily is encouraged and ought to be given some consideration.)
The sort of resources which can be handled this way include:
- processors/PCB
- memory allocated to this process
- any open files; their buffers may need flushing first
- any hardware devices ‘opened’ by the process; e.g. a particular process may be using a particular serial interface
- locks held by that process need freeing
There are also some resources which are outside the direct ownership of a process and, therefore, cannot be detected this way. If the user does not clear them up then they result in a resource leak. A couple of examples:
- Shared memory (between processes) does not belong to a particular process; it can be left allocated even if there are no processes left using it. In cases where the sharing is managed by the O.S. – such as sharing the same binary code amongst several processes – this can be managed by counting the links and deallocating the memory if the last linked process terminates. If the memory is created by the user process it should also release it before terminating.
- A similar approach may be used with file-system links; the actual file will be deleted when the last link to it disappears.
- Child processes. If a process starts other, cooperating processes then they should all be shut down at the same time. This is an issue, for example, in a windowed system where a user might, arbitrarily, terminate any process at any time. Often, terminating a parent should (first) cause it to terminate its children.
Resources: pre-emptable or not?
Some resources are “pre-emptable” – that is to say even if they have been granted they can be put aside without harm. Two obvious examples are processing time (suspend a process and context switch) and, in some systems, memory (page swap onto secondary store).
“Non-pre-emptable” resources – such as a printer in the middle of a print-job – must not be interrupted and the resource must be requested, locked and subsequently released. Careless use of non-pre-emptable resources is a source of deadlock.
