CST 334 - Week 2

Processes

This week was all about processes (running programs). Programs are just files on a disk and don't actually do anything until they are executed. When that occurs, the operating system allocates memory for the program and loads up its source code and static data (if any exists). The allocated memory must be enough to include not only the program and its data, but also the program's stack and heap. The combination of all these discrete memory locations is called a process. 

A process encapsulates a program and allows it to run securely by isolating its address space from other processes. The process does not know that it is trapped in a bubble and believes that it has full access to system resources. In reality, its reach is limited (which it will discover if it attempts to access a memory location outside of its designated range). Since the operating system has virtualized everything, the process doesn't even know the true size of the memory or that other processes are using the CPU. 

Zombies!

In Unix-like environments, processes can spawn new processes with fork(), which requires a subsequent call to exec() to do anything useful. The way that the fork/exec system works is strange but allows for the running of code in between the forking of a process and the execution of a new program. I also learned that the parent process must call wait() at some point to check if the child process has finished, otherwise a zombie process can exist and waste system resources. 

When a child process terminates, an entry is maintained in its parent's process list until the parent realizes it has finished (through the wait system call). Until that time, the operating system will keep allocating resources for it, hence the term zombie: the process appears to be running but nothing is actually processing. I am not sure why child processes do not notify their parents automatically. It's worth noting here that if a parent process terminates before its children, the child processes will become orphaned and adopted by the init system process.

Scheduling

Finally I want to talk a bit about scheduling. This topic has fascinated me since my data structures and algorithms class. When we were discussing circularly linked lists, my professor briefly described round-robin scheduling. This type of scheduling ensures that all processes in the ready queue are run on the CPU by giving them each an equal amount of execution time before rotating to the next. This week my knowledge of schedulers was expanded, and now I have better insight into some of the challenges faced by different scheduling algorithms (such as turnaround vs response times).

Multilevel queue algorithms use multiple ready queues, each with a different priority level. The individual queues use standard round-robin scheduling, but processes are able to move up or down in priority. These scheduling algorithms offer good turnaround and response times while avoiding starvation of CPU-bound processes, which may occur when a process is unable to move up from a low priority queue and receives little-to-no execution time. Note that processes may be granted a different time quantum (slice of time on the CPU) depending on their priority level.