1. CS444/CS544 Operating Systems
Processes
1/22/2007
Prof. Searleman

2. CS444/CS544 Spring 2007 OS Structures (cont.) Processes
Reading assignment:
Chapter 3
HW#2: due Friday,

3. Summary: OS Structures
Protected Mode of Execution (user vs kernel)
System Call (“software interrupts”)
Interrupts (hardware)
Timer
I/O devices
Software “exceptions”
“trap” - request for OS service
“faults” - software errors that transfer control to the OS

4. System Call Illustrated
File.open(“/home/README”)
Resume application with file
opened or error
SystemCall (SYS_OPEN, “/home/README”)
User mode
Kernel mode
Save user registers and mode, lookup
SYS_OPEN in a table of system call procedures,
Change mode bit, jump to the kernelOpen procedure
Restore user mode and application’s registers etc.
kernelOpen(“/home/README”,
this applications access rights)

5. A Day in the Life of the OS
When a machine reboots, the operating system will execute for some time to initialize the state of the machine and to start up certain system processes
Once initialization is complete, the OS only executes when some “event” (e.g. system call, device interrupt) occurs that require its attention
When an event occurs
The current state of the machine is saved
The mode changes to protected mode
An event handler procedure is executed (handlers for all possible events must be specified)

6. Exceptions and Interrupts
Two main types of events
Software Events (often called exceptions)
Normal software requests for OS service are called “traps”
Software errors that transfer control to the OS are called “faults”
Sometimes system calls called software interrupts
Interrupts are caused by hardware (e.g. device notifies CPU that it has completed an I/O request)
Sometimes say “trap to the OS” to handle a hardware interrupt

7. Interrupt Driven I/O
CPU uses special instructions or writes to special memory addresses (memory mapped I/O) to initiate the I/O request
Device will perform the request while the CPU does other work
When the request is complete, the device will send an interrupt signal to the CPU via a shared bus
Interrupt causes control to transfer to the OS (even if an application is in the middle of execution)
Interrupt handler saves the context of the current process and then uses the interrupt type to index into a vector table of routines
Control switches to the procedure registered in the table to handle the specific interrupt

8. Request Processing With Interrupts
To issue a request, OS executes the “top half” initiates request processing
Check if device is available
If so write command, address and data registers
Stores info about the request issued
CPU returns to other processing; device controller gets busy working on request
When request is done, “bottom half” completes request
device controller interrupts the CPU, finds interrupt handler and retrieves info stored about the request
CPU copies data from the device controller registers to main memory if needed
Sets device status to available

9. Interrupting interrupts?
What happens if get another interrupt while processing one? Information about first interrupt could be lost
Disable interrupts while processing an interrupt?
Prioritize interrupts such that interrupts of same or lower priority are disabled
When finished processing an interrupt, check other devices with pending requests for a “done” status

10. Synchronization
When we write a program, we think about adjacent instructions happening in order without interruption
We’ve seen lots of things that can interrupt the execution of a process (timers, I/O request completion, etc.)
Most times this is ok; the state of our process is restored and the illusion is maintained
But sometimes it is really important that two things happen together with no interruption
Specifically if two processes are sharing resources
Example: two processes updating a shared database of account balances; one reads balance and adds $100, one reads balance and removes $100

11. Hardware support for Synchronization
Need a way to guarantee that a sequence of instructions occur at once – at least with respect to other entities that are accessing the same data
Solution 1: Disable Interrupts
Until re-enabled, instruction sequence will run to completion
Would you like to allow applications to do this?
Solution 2: Provide Locks
Acquire lock, perform sequence, release lock
Sequence may be interrupted but interruption not visible to others because they wait to acquire the lock

12. Overlapping I/O and Computation
If we want the OS to be able to efficiently keep the CPU busy, then I/O devices need to be able to operate independently
Even if CPU can do other work while I/O is pending, system is still inefficient if CPU constantly needs to check for I/O completion (polling)
Interrupts
DMA
Buffering

13. Intel Architecture’s PIC
Programmable Interrupt Controller (PIC) is a chip that offloads some interrupt processing from the main CPU
Serves a referee to prioritize interrupt signals and allows devices to prevent conflicts
Device interrupts go to the PIC; PIC determines which device raised the interrupt; Sends interrupt to the CPU with a value indicating the interrupt service routine to invoke
If multiple interrupts, PIC will buffer them and send them one at a time to the CPU
Treated by the main CPU as a peripheral

14. DMA
Still if we want to transfer large chunks of data, CPU will still need to be very involved
For each small chunk of data, CPU must write a command to the command and address registers and transfer data to/from the data register
Very regular pattern
DMA or Direct Memory Access automates this process and provides even greater overlap of computation and I/O
Tell device controller with DMA: Starting memory address and length and it will get each piece directly from memory as it needs it
Scatter/gather list: don’t limit it to single start/length

15. Buffering Still more can be done to overlap computation and I/O
What if I/O is slow enough and requested frequently enough, all processes may be waiting for I/O
I/O bound vs compute bound jobs
For writes, copy data to a buffer and then allow process to continue while data is written from buffer to device
If system crashes?
For reads, read data ahead in anticipation of demand

16. Memory Mapped I/O
For each device, set aside a range of memory that will be mapped to the registers of the device
The CPU thinks it is reading/writing memory locations (same instructions, same addressing scheme)
Without memory mapped I/O, CPU needs a way to name each register on each device controller
Special instructions? Device/register addresses?
Required knowledge of number and type of devices at design time

17. Programmers/users demand functionality
Operating systems provide commonly needed functionality
Programmers want stable storage, want to be able to share contents with other apps => file system with naming scheme shared by all processes
Programmers don’t want to deal with paging their own code and data in and out of limited physical memory (and want protection/isolation from other processes) => virtual memory
Programmers want running processes to be able to communicate (not complete protection and isolation) => shared memory regions, pipes, sockets, events
Users don’t want a single task to be able to monopolize the CPU => preemptive scheduling
Users want to be able to designate high and low priority processes => priority scheduling
…….

18. Application demands exceed OS functionality?
Not all applications are happy with the operating system’s services
Many things an operating system does, application programmers could do on their own if they were sufficiently motivated
Examples:
Databases traditionally ask for a raw disk partition and manage it themselves (who needs the FS?)
User-level thread libraries can be more efficient than kernel level threads

19. Application Moves Into the OS
If a computer system is going to be used for one application, can avoid overhead of crossing user/kernel protection boundary by putting the application in the kernel

20. Driving forces for OS development?
Many times platform implies operating system; system hardware usually marketed more than OS
Choice of OS for the PC platform is not the norm
Even on PC platform, what drives OS development
Application mix, stability, politics bigger factors than OS features?
OS features driven by stability and ease of porting/writing apps
All this implies OS you use every day doesn’t follow the bleeding edge like hardware

21. Programs vs Processes A program is passive A process is active
Sequence of commands waiting to be run
A process is active
An instance of program being executed
There may be many processes running the same program
Also called job or task

22. What makes up a process? Address space Code Data
Stack (nesting of procedure calls made)
Register values (including the PC)
Resources allocated to the process
Memory, open files, network connections

23. Address Space Map Sometimes Reserved for Stack Biggest OS Virtual
(Space for local variables etc.
For each nested procedure call)
Heap
(Space for memory dynamically
allocated e.g. with malloc)
Statically declared variables
(Global variables)
Code
(Text Segment)
Stack Pointer PC
Ox0000
Sometimes
Reserved for
Error Catching

24. How is a process represented?
Usually a process or task object
Process Control Block
When not running how does the OS remember everything needed to start this job running again
Registers, Statistics, Working directory, Open files, User who owns process, Timers, Parent Process and sibling process ids
In Linux, task_struct defined in include/linux/sched.h

25. struct task_struct *next_run, *prev_run;
/* these are hardcoded - don't touch */
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
long counter;
long priority;
unsigned long signal;
unsigned long blocked; /* bitmap of masked signals */
unsigned long flags; /* per process flags, defined below */
int errno;
long debugreg[8]; /* Hardware debugging registers */
struct exec_domain *exec_domain; /* various fields */
struct linux_binfmt *binfmt;
struct task_struct *next_task, *prev_task;
struct task_struct *next_run, *prev_run;
unsigned long saved_kernel_stack;
unsigned long kernel_stack_page;
int exit_code, exit_signal; /* ??? */
unsigned long personality;
int dumpable:1;
int did_exec:1; /* shouldn't this be pid_t? */
int pid;
int pgrp; int tty_old_pgrp;
int session; /* boolean value for session group leader */
int leader; int groups[NGROUPS];
/* pointers to parent process, youngest child,
younger sibling, * older sibling, respectively.
(p->father can be replaced with
*p->p_pptr->pid) */
struct task_struct *p_opptr, *p_pptr, *p_cptr,
*p_ysptr, *p_osptr;
struct wait_queue *wait_chldexit; /* for wait4() */
unsigned short uid,euid,suid,fsuid;
unsigned short gid,egid,sgid,fsgid;
unsigned long timeout, policy, rt_priority;
unsigned long it_real_value, it_prof_value, it_virt_value;
unsigned long it_real_incr, it_prof_incr, it_virt_incr;
struct timer_list real_timer;
long utime, stime, cutime, cstime, start_time;
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
int swappable:1;
unsigned long swap_address;
unsigned long old_maj_flt; /* old value of maj_flt */
unsigned long dec_flt; /* page fault count of the last time */
unsigned long swap_cnt; /* number of pages to swap on next pass */
/* limits */
struct rlimit rlim[RLIM_NLIMITS];
unsigned short used_math;
char comm[16];
/* file system info */
int link_count;
struct tty_struct *tty; /* NULL if no tty */
/* ipc stuff */
struct sem_undo *semundo; struct sem_queue *semsleeping;
/* ldt for this task - used by Wine. If NULL, default_ldt is used */
struct desc_struct *ldt;
/* tss for this task */
struct thread_struct tss;
/* filesystem information */
struct fs_struct *fs;
/* open file information */
struct files_struct *files;
/* memory management info */
struct mm_struct *mm;
/* signal handlers */
struct signal_struct *sig;
#ifdef __SMP__
int processor;
int last_processor;
int lock_depth; /* Lock depth. We can context switch in and out of holding a syscall kernel lock... */
#endif };

26. Management of PCBs
PCBs are data structures (just like you are used to at user level)
Space for them may be dynamically allocated as needed or perhaps a fixed sized array of PCBs for the maximum number of possible processes is allocated at init time
As process is created, a PCB is assigned and initialized for it
Often process id is an offset into an array of PCBs
After process terminates, PCB is freed (sometimes kept around for parent to retrieve its exit status)

27. Process States
During their lifetime, processes move between various states
New – just created
Ready – waiting for a turn to use the CPU
Running – currently executing on the CPU
How many processes can be in this state? 
Waiting – Unable to use the CPU because blocked waiting for an event
Terminated/Zombie – Finished executing but state maintained until parent process retrieves state

28. Process State Transitions
New
Ready
Running
Terminated
Waiting
Schedule/ Unschedule
Grant Resource
Request Resource or Service

29. UNIX process creation fork() system call
Creates a new PCB and a new address space
Initializes the new address space with a *copy* of the parent’s address space
Initializes many other resources to copies of the parents (e.g. same open files)
Places new process on the queue of runnable processes
fork() gives two processes exactly alike
fork() returns twice: to parent and child
Returns child’s process ID to the parent
Returns 0 to the child

30. Example Code Snippet int main (int argc, char **argv) { int childPid;
childPid = fork();
if (childPid == 0){
printf(“Child running\n”);
} else {
printf(“Parent running: my child is %d\n”,
childPid); }

31. Output
%./tryfork
Parent running: my child is 707
Child running %