Operating Systems - Process Management

Process management

This is handled by the process manager of the OS (see here)

First a little history..

• In early computers, only one program could be executed at a time. This is much different from now. Right now as I type this, I am running Finder, Safari, Chrome, iTunes, iChat, RSS, Tweetie, Spotify, Pages and Last.fm (This has nothing to do with the post, I just wanted to show off all my cool apps)


• Eventually time sharing came. This meant that firmer control was needed along with more compartmentalisation


• Even with all these developments, a computer still has one CPU and one program counter


• A process is an executing program, with a virtual CPU


• The real CPU switches back and forth between processes

Processes (redux)

So a process is a program in execution. The first three letters of program and process are the same, this is probably a clue or something.

Think of a process as this:

An abstraction of the sequence of instructions executed by the processor, because the processor may need to service hardware devices or other processes when time sharing by executing their device drivers in between the instructions of the process.

Yeah...that makes hardly any sense, but you'll understand processes a bit more after reading this.

A process contains:

• Flow of control


• Address space


• Register values


• External interfaces (this lets the process open files, the network, etc)

A really important thing to remember is that a process isn't a program on the disk, because that would just be a file. Imagine you have a recipe for a cake. This may help you visualise it. Now the cake recipe is the instructions for making the cake, which is like the program on the disk. The actual activity of making the cake is the process.

The thing to take away from this section is that an OS is a collection of processes. The OS can make the computer more productive by switching the CPU between processes.

Creating processes

The things that normally cause a process to be created are:

• System initialising


• A system call that creates a process is called by a running process


• A user requests for a new process to be created

The system call that creates processes is known as 'fork()' and 'execve()' in Unix, and in Windows it is 'CreateProcess'.

These processes can be called by one process to create another. This is known as a parent process creating a child process.

Ending (terminating) processes

There are several reasons a process may be terminated:

• Exit normally due to the task being completed


• Error exit


• Fatal error


• Killed by another process
  
  
  
  • In Unix there is a system call called 'kill', and it is known as 'TerminateProcess' in Windows
  
  
  
  

Process states

Transitioning between the states

• New → Ready: Admitted


• Ready → Running: Scheduler dispatch


• Running → Ready: Interrupt / Time slice expired / Relinquish processor


• Running → Blocked: Block


• Blocked → Ready: Ready


• Running → Terminated: Exit

Things that could become an issue:

• Context switch: When the CPU switches from one process to another, the state of the current process must be saved, and then the state of the next process must be loaded


• Scheduling: How does the CPU know which ready process to choose for execution?

Process Control Block (PCB)

The OS has a table, with one entry per process. Each entry is known as a PCB. Each entry has:

• Process ID


• Process state


• Saved registers:
  
  
  
  • Program counter
  
  
  • Stack pointer
  
  
  • General registers
  
  
  • and more!
  
  
  
  


• CPU scheduling info (is it high priority etc)


• Memory management info


• File and IO management info
  
  
  
  • list of open files
  
  
  • network connections
  
  
  
  


• accounting info (CPU time used etc)


• Parent process id


• More..

The basic thing to learn here is that the PCB has all the info needed so that if a process is stopped it can be restarted.

Process switching

Note: This diagram is taken from the source material for this post, available here on slide 10. All rights reserved.



The diagram is fairly simple. You can see how when the actual switching of processes is happening that neither process is executing, as the CPU cannot perform any processing when it is in the middle of switching.

The actual switching time can vary from around 1 to 1000 microseconds (that's 1×10^-6 seconds to 1 millisecond)

Multiple flows

The concepts for processing we've used so far have assumed that a single address space is being used for every process, and that there is a single thread of control.

But why not have multiple threads within one process? It's possible, think of it this way: You can have multiple processes sharing one computer, so why not have multiple threads sharing a process?

This would be useful for a web browser for example, as you can have one thread receiving data from the network while another displays text.

With a web browser, you could have one thread that is getting input from the user, while another thread is autosaving. Imagine if your word processor was single threaded: You wouldn't be able to type anything while it's autosaving. (Note: On my version of powerpoint I can't type anything while it's autosaving. It's annoying.)

Threads

You might hear something called a lightweight process. This is just another way of saying thread.

So threads are multiple flows of control sharing one address space. Each one needs it's own program counter, register values, stack. Remember that all threads that are in the same process will share the same code section, global variables, network connections and open files.

You may have heard of multithreading. This is when multiple threads share a process.

Benefits of using threads

Programs become more responsive, and resources are shared better. If part of a program is blocked it can keep running. As the IO and CPU use is shared between threads of the same process, performance is usually better too.

It's more economical: There is a lot of cost associated with making a process. Memory and resources need to be allocated. Creating a thread can be up to 100x faster.

There are some concerns though: I mentioned before that two threads share the same data. Therefore one thread might read from a location while another is writing to it, so you need to take care to stop problems like this.

Making threading happen!

In the user space

Implementing threading is fast when done in the user space. However, the OS isn't aware of this, meaning that if a user level thread gets blocked, the whole process is blocked.

In the kernel

This is useful when support for multiprocessors (dual core) is available. This was the OS schedules individual threads. However, it is slow as it requires a system call.

That's all.

Slightly more detailed notes available at http://intranet.cs.man.ac.uk/Study_subweb/courses/COMP20051/2009-10/lect06.pdf