A Note About Learning
We have been going through the class the past few weeks in a teaching and learning mode that highlights an important lifelong learning skill—the acquired capacity to recognize from a presentation important points and issues that may not be specifically written down.
In our current age we have a number of technologies that are intended to (or by default do) aid in the learning process, including
- traditional hardcopy textbooks
- the web
- search engines
- specific web resources, such as Wikipedia, course management systems (e.g, Moodle), course websites, and online textbooks.
- often detailed course notes posted by instructors in one of the above manners
In this milieu we find ourselves often with so much readily available information that we neglect the important skill of learning by identifying important points in a lecture, taking notes on these, and then assimilating the results.
So, although we, too, will make use of a number of these technologies and opportunities, a focus of the course will be that students learn to identify important issues, take notes on them, and acquire understanding from this style of learning.
Example
In recent lectures it has been mentioned a number of times that exceptions are caused by the decoding and/or execution of an instruction, whereas interrupts are posted by hardware external to the IFE cycle circuits. It was also mentioned that this distinction between interrupts and exceptions is not universally made in the literature, which means that you must be aware of how a term is used in context. Thus, the use of these terms in class will have a specific meaning that may not show up at all in the textbook and/or have a different connotation in literature or web sources.
Processes
We delved into processes more deeply.
- a process is started when a user requests (through a running process that is awaiting user requests for programs to be run, such as the Windows Desktop) that a program be executed.
- That process (e.g., the Windows Desktop) identifies the program to be executed and does the appropriate supervisor call to the OS to have the program started.
- the program, which is just a file of machine language instructions on a drive, is turned into an executable process by the OS in two parts:
- a virtual image with the executable code retrieved from disk along with virtual memory environment that generally includes a run-time stack for managing function calls and a heap for managing dynamic data, such as object instantiation and release
- a process control block (PCB) for that process that contains all of the information needed to start, stop, and restart the process over time, as well as maintain statistics about the process.
- the OS finally puts the PCB into the OS's queue of ready-to-run processes, so that this process can be managed.
- as the process is allowed to run by the OS it will, through supervisor calls to the OS and interrupts from external hardware, occasionally be stopped from running by the OS. The OS manages a number of queues other than the ready-to-run queue that processes may be in when not running, such as a queue awaiting an interrupt from a hard drive signaling that a read request made by the OS on behalf of the process is now done, so the process can be restarted now that the read data is available.
As can be guessed, the managing of processes and the information needed to be kept in a process's PCB can be quite complex. Nonetheless there is one important point to be made:
An OS is a program, and like all other programs you have written, it has data structures and code to operate on those data structures (or objects and methods, if you prefer) to carry out its objectives. Thus, the data structures, algorithms, programming techniques, and virtually all other aspects of your undergraduate CS education come into play in the design and implementation of an OS.