Processes

1. Processes CMSC-421 Operating Systems Principles Chapter 2

2. The Process Model • All the runnable software on the computer, including the operating system is organized into a number of sequential processes. • A process is just an executing program, including the current values of the program counter, registers, and variables.

3. Multiprogramming of Four Programs. One program counter A Process Switch B C D

4. Multiprogramming of Four Programs. (II) Four program counters A B C D

5. Multiprogramming of Four Programs. (III) D C B A Time

6. Problem • With the CPU switching back and forth among an unknown number of processes, the rate at which a process performs its computation will not be uniform, and probably not even reproducible. • This causes a problem for real-time processes!

7. Process Hierarchies • Operating systems that support the process concept must provide some way to create all the processes needed. • Init starts all of the necessary processes when the computer is booted. • All subsequent processes can created new processes.

8. Process States • Possible states: • Running • Actually using the CPU at that instant. • Ready • Runnable; temporarily stopped to let another process run. • Blocked • Unable to run until some external event happens.

9. Transition State Diagram 1. Process blocks for input 2. Scheduler picks another process 3. Scheduler picks this process 4. Input becomes available Running 2 1 3 Ready Blocked 4

10. Alternative View ... 0 1 n n - 1 scheduler

11. Scheduler • According to this view, the scheduler not does process scheduling, but also interrupt handling and all the interprocess communication.

12. Implementation of Processes • OS maintains a process table with one entry per process. • Contains process state, pc, stack pointer, memory allocation, status of open files, accounting and scheduling information.

13. Sample Fields Process mgmt Memory mgmt file mgmt Registers Pointer to text seg. UMASK PC Pointer to data seg. Root directory PSW Pointer to bss seg. Working directory Stack pointer Exit status File descriptors Process state Signal status Effective UID Time started PID Effective GID Children CPU time PPID System call Param Time next alarm Real UID Various flag bits Message queue Effective UID Pending signal bits Real GID PID Bit maps for signals Various flag bits Various flag bits

14. Threads • In a traditional process, there is a single thread of control and a single pc in each process. • In some modern OS, support is provided for multiple threads of control within a process.

15. Heavyweight Threads Computer Program Counter Thread Process

16. Lightweight Threads Computer

17. Threads II • An example of when to use threads, is for a server. The server is one single process, but each connection is a separate thread. This allows critical data to be shared in the process global memory and available without special handling. When one connection is not sending data, only that thread is blocked.

18. Threads III • Another example of using threads is in Netscape. One process can have a section of code to manage the internet connections, since there is one logical connection for each image on the screen. • There is one standard thread package, POSIX P-threads.

19. Design Issues • The two alternatives seem equivalent. • Difference is in performance. Switching threads is much faster when thread management is done in user space than when a kernel called needed. • When one thread blocks for I/O, all threads are blocked by the kernel.

20. Design Issues (II) • When the parent (with threads) forks, does the child have threads? • Problems with one thread closing a file that another thread needs! • How is memory allocation coordinated? • How is error reporting handled?

21. Design Issues (III) • How are signals handled, are they thread specific? • How are interrupts handled, are they thread specific? • Which thread gets keyboard input? • How is stack management coordinated?

22. Good News, Bad News • These problems are not insurmountable, but they do show that just introducing threads into an existing system is not going to work at all. • There is also more work currently for the applications programmer!

23. InterProcess Communications • Processes frequently need to communicate with other processes. • One example is the shell pipeline. • There is a need for communications between processes, preferably in a well-structured way, not using interrupts.

24. Three Issues • How one process can pass information to another. • Making sure two or more processes do not get into each other's way when engaging in critical activities. • Proper sequencing when dependencies are present.

25. Race Conditions • One way to sure is with a common resource (main memory, shared file) • One example is the print spooler • one process enters the file name into a special spooler directory. • another process *printer daemon" periodically checks to see if there are any files to print.

26. Race Conditions (II) • directory is capable of a large number of slots. • Two shared variables: • out which points to the next file to be printed • in which is the next free slot in directory.

27. Race Conditions Example • Slots 1-3 are empty • Slots 4-6 are full • Simultaneously, processes A and B decide they want to queue a file for printing. • Both processes thing the next slot is 7.

28. Race Conditions Example (II) out = 4 4 5 6 7 8 in = 7 A B

29. Critical Sections • The key to preventing trouble here and in other situations involving shared resources is to find some way to prohibit more than one process from reading and writing the shared data at the same time

30. Mutual Exclusion • Making sure that if one process is using a shared resource, the other processes will be excluded from doing the same thing. • Choice of primitive operation is a major design issue in any operating system.

31. Solution • Part of the time, a process is busy doing internal computations and other things that do not lead to race conditions. • The part of the program where the shared memory is accessed in called the critical region or critical section. • No two processes can be in their critical region at the same time.

32. Four Conditions • No two processes may be simultaneously inside their critical regions. (Mutual exclusion) • No assumptions may be made about speeds or the number of CPUs (Timing) • No process running outside its critical region may block other processes. (Progress) • No process should have to wait forever to enter its critical region. (Bounded waiting)

33. Mutual Exclusion with Busy Waiting • Disabling Interrupts after entering critical region and re-enable them just before leaving • Simplest solution. • No clock interrupts can occur. • Very vulnerable • Does not work if multiple processors are involved

34. Lock Variables • Variable initially set to 0 • First process to enter critical section changes the lock variable to 1. • Any other process checks the lock variable to see if it is 0. If it is not, it must wait until the lock becomes 0 again.

35. Lock Variables Faults • This is like the spooler problem. If two processes read the variable when the variable is set to zero, both will enter the critical region. • Violates Mutual Exclusion!

36. Strict Alternation While (TRUE) { while ( turn != 0) ; critical_region(); turn = 1; noncritical_region(); } Process A While (TRUE) { while ( turn != 1) ; critical_region(); turn = 0; noncritical_region(); } Process B

37. Strict Alternation Faults • Continually testing a variable for some state is called busy waiting. Should be avoided, since it wastes CPU time. • Can end up blocking and violating Progress.

38. Peterson's Solution #define FALSE 0 #define TRUE 1 #define N 2 int turn; int interested[N];

39. Peterson's Solution (II) void enter_region( int process ) { int other; other = 1 - process; interested[process] = TRUE; turn = process; while ( turn == process && interested[ other ] == TRUE ) ; }

40. Peterson's Solution (III) void leave_region( int process ) { interested[process ] = FALSE; }

41. TSL Instruction • Hardware instruction that is especially important for computers with multiple processors is TSLTest and Set Lock • Solves problems with Strict Alternation, because there is no chance of two processes reading the variable and getting the same value.

42. TSL enter_region: tsl register, lock cmp register, #0 jne enter_region ret leave_region: move lock, #0 ret

43. Peterson's Solution & TSL Instruction Fault • Both are correct. • But require busy waiting.

44. Priority Inversion Problem • Two processes: • H, with high priority, to run whenever it is in a ready state. • L, with low priority • If L is in critical region and H becomes ready, L never gets scheduled so it can leave it critical region, so H can run.

45. SLEEP & WAKEUP • SLEEP is a system call that causes the caller to be blocked until something wakes it up. • WAKEUP has one parameter, the process to wakeup.

46. Producer-Consumer Problem • Also known as the bounded buffer problem. • One process puts data into a buffer. • Another takes it out.

47. Buffer Problems • Producer wants to put a new item into full buffer. • Producer goes to sleep until consumer empties queue. • Consumer wants to to remove an item when buffer is empty • Consumer goes to sleep until producers adds to queue.

48. Fatal Race Condition #define N 100 int count = 0; void producer( void ) { while ( TRUE ) { produce_item(); if ( count == N ) sleep ( ); enter_item( ); count = count + 1; if (count == 1 ) wakeup(consumer ); } }

49. Fatal Race Condition (II) void consumer( void ) { while ( TRUE ) { if ( count == 0 ) sleep ( ); remove_item( ); count = count - 1; if ( count == N - 1 ) wakeup ( producer ); consume_item( ); } }

50. Fatal Race Condition (III) • Because access to count is unconstrained, problems occur. • Consumer sees count is zero, but gets suspended. • Producer adds, gives wakeup call. • Consumer misses call, gets resumed and goes to sleep. • Producer goes to sleep.