Operating Systems (OS)
The computer is physically composed by hardware, i.e. CPU, Hard Drive, Memory, Graphics Card, Printer, Keyboard, Mouse, the Network Board and several other devices that we can connect via USB ports, Firewire, PCIe, PCI, etc.., according to what we have seen when we analyzed the Mother Board. Therefore, a developer, when he is developing a program must know the characteristics of all the devices of the computer where it will work, so that his program can interact with all them: the keyboard, the mouse, the printer, the monitor and all the others from the specific computer where it will work.
Under this perspective the developer activity would be frustrating, don’t you think so?
This is one of the Operating Systems (OS) tasks, the management of input/output devices. For this purpose the different devices manufacturers provide for each OS a small program called Driver, whose purpose is teaching that OS how to handle the device it refers to. The developer only has to write instructions that have to do with its overall intent, i.e. print, put on the screen, save to disk, read from the keyboard, etc.. It’s the OS that translates those overall instructions into the necessary ones for the developer instruction to be executed on the device that fulfills that task in the computer.
How good it is to plug that sophisticated Gamepad we owned in order we can better play with that game we love so much and realize that a few moments later the gamepad is working with all its buttons configured and ready to interact with the game. The game does even know the gamepad name and characteristics, but its developer didn’t know about its existence when he developed the game.
Broadly, the OS is an interface between the Hardware the Software and the User, including in this definition such tasks as:
- The I/O devices management.
- The HDD management, what it does through its File System.
- The Process management.
- The Virtual Memory management
- And many others.
When Mary decides to do an orange cake, she goes to her cookbook and collects the orange cake recipe. It’s like going to the HDD seeking for the Orange Cake file that contains the program (or recipe) to do an orange cake. It’s a simple recipe, or a program. But when Mary starts executing the recipe, she starts using the available resources in her kitchen (bowls, pyrex, whisks, oven, dishwasher, etc.) and the program will slowly become what’s its purpose, the orange cake. Well, from the recipe (program) execution start to the cake completion, we are precisely in the orange cake confection Process.
During the confection process, the language used to write the recipe doesn’t matter (Portuguese, English, Mandarin, or other) as well as the type, characteristics, brand or model of the devices that execute it. Only matter the ingredients, their quantities, how they are mixed and the cooking time and temperature.
Therefore, the process is the abstraction which executes the program purpose, unrelated to the language in which the program was written and to the machine where it runs. Address space, Stack, Heap and others are concepts connected with Process that we’ll develop during this Chapter.
Several processes can run simultaneously in Mary’s kitchen, what’s named as multiprocessing. Mary realized this quickly since she noticed that while the confection processes were on the stove or in the oven she was not doing anything (maybe crochet, but not recipes) and that she could use that time to go ahead with other recipes in different areas with unused devices. This way, the stove and the oven themselves began to be used much more. Mary was very pleased, because she realized that with the same devices she could execute more receipts in less time, therefore producing more, processing more recipes simultaneously. The problem is that the crochet was getting delayed. But crisis is crisis and crochet doesn’t fill the belly.
Mary was multi cooking (multiprocessing) several recipes in her kitchen, or was executing concurrently several recipes in the same kitchen. Mary was the OS of her kitchen. Her kitchen is the CPU which uses the other devices. When a process was long communication with a device (e.g. the oven) Mary (the OS) withdrew this process (the implementation of the recipe) from the kitchen (the CPU), kept it in a waiting state registering its cooking process state when it was withdrawn from the kitchen and placed another recipe (another cooking process) in the kitchen being processed with unused devices. When the oven sounded “Plimm”, it was calling Mary’s attention (the OS) to the fact that the process that was running in this device was ready and needed her attention (the OS). Then Mary (the OS) suspended the other recipe that was running in the kitchen (the CPU) and continued with the first, restarting it exactly in the state it was when withdrawn, which she had registered in her memory.
The same applies in a real system, for example when a process needs to access the HDD to pick elements that it doesn’t have in memory.
During this Chapter, along with multiprocessing we’ll talk in process switching, process state, interrupts and exceptions and we’ll also discuss an OS organization.
It is also the OS that is responsible for managing a Multitasking implementation. Mary will also be named to the understanding of this process, but for now we’ll leave her quiet.
Multitasking is the division of a process into different tasks that can be executed in parallel, all competing for the same purpose.
Multitasking programming is developers responsibility. The OS makes available to the developers special tools for monitoring the competition between tasks and the access to processes critical regions, such as global variables for example.
These tools include the mutex and the semaphores, which we’ll try to introduce through an imaginary game where the teams in competition will be confronted with situations in which they will need to use these tools in order to be able to increase their score without running into data inconsistency.
A program can be running simultaneously with others. So, how does the developer or the compiler to assign memory address spaces for instructions and data to his program knowing that it will not be coincident with those of the other programs?
Yes that’s a problem. The developers run the risk of assigning coincident address spaces in memory to different programs. This way, when the program removed from the CPU is back to execution, everything is a mess in its address space.
Having this in mind the developers shall organize frequent covenants between them to agree together the memory address spaces each one will use. Preferably in good hotels and popular tourist regions, to offset the boring that will be the participation into a discussion only possible in the imaginary context, facing an indescribable confusion from which any solution will never arise.
As a solution to this issue, the OS has taken the place of these covenants and created for that purpose something called Virtual Memory, which has an address space with the size of the CPU registers:
- For 32 bits CPU and 32 bits OS the virtual address space is limited to 32 bits what corresponds to 4 GB.
- For 64 bits CPU and 64 bits OS the virtual address space is limited to 64 bits what corresponds to 16 Exabytes, although the several OS can impose lower limits.
In this Chapter we will talk about Virtual Memory, pages, paging memory, page tables, the Pagefile or Swappfile, Cache paging or TLB (Translation Lookaside Buffer), the way it’s actually made the access to memory by the CPU, which knows only virtual addresses that have to be translated into physical addresses. But the best is reading the chapter as this summary is already going long.
To finish we will see how the memory access is made by a core i7 Nehalem CPU, with presentation of access latencies according to different levels of fetch, as the address fetch sought to find a translation page in TLB or not, as the translated address is or is not in the Cache, or in a page in main memory or in a page on Pagefile.
See the global synopsis of this work
We introduce here the table of contents of the Paper Book to describe the themes approached in this Chapter