Concurrent programming Multiple threads working together to achieve - PDF document

Concurrent programming slides T.S. Norvell (c) 2001 Concurrent programming Multiple threads working together to achieve a common goal These threads may share memory • Communication is via shared variables. • Care is required to ensure exclusive access to shared variables Or may not share memory • Communication is via messaging between the treads There are three reasons to solve problems with concurrent programs • Speed. To take advantage of multiple CPUs, we need concurrent programs. • Distribution. Some problems require a distributed solution. E.g. client server systems put the GUI on a client machine and the database on a central server machine. • Ease of programming. Some problems are more naturally solved by concurrent programs. 1

Concurrent programming slides T.S. Norvell (c) 2001 Speed Example: A parallel matrix multiplication (incomplete) const N := 100 type Index : 1..N type Matrix : array Index, Index of real ... W we need to declare something here yet process compute_one_cell( var A,B,C : Matrix, i, j : Index ) var sum := 0.0 for k : Index sum += A(i,k) * B(k,j) end for C(i,j) := sum ... X we need to inform the main thread we are done end compute_one_cell ... 2

Concurrent programming slides T.S. Norvell (c) 2001 var A,B,C : Matrix ... somehow A and B are Þ lled.... %Now we compute C := A*B in parallel ... Y we need something here yet. for i : Index for j : Index fork compute_one_cell( A, B, C, i, j ) end for end for ... Z we have to wait here until all threads are done %Now we can use matrix C We still have the problem of making the main thread wait until all the subsidiary threads are done. We will solve this problem (in two different ways) by Þ lling in W, X, Y, and Z. Note • this algorithm would be good for speeding up computation if we have more than one CPU. • with one CPU we might as well use a single thread. 3

Concurrent programming slides T.S. Norvell (c) 2001 Ease: A Traf Þ c Light Controller process control_one_light( light : Light, north_south_time : Time, east_west_time : Time, orange_time : Time ) loop set( light, Red, EastWest ) set( light, Green, NorthSouth ) wait_for( north_south_time - orange_time ) set( light, Orange, NorthSouth ) wait_for( orange_time ) set( light, Red, NorthSouth ) set( light, Green, EastWest ) wait_for( east_west_time ) set( light, Orange, EastWest ) wait_for( orange_time ) end loop end control_one_light ... fork control_one_light( light1, 30, 20, 5 ) fork control_one_light( light2, 40, 30, 5 ) ... 4

Concurrent programming slides T.S. Norvell (c) 2001 Ease of programming: An Internet server monitor common_data ...we’ll discuss monitors soon... end common_data process handle_one_session( var sock : Socket ) ... code to handle a session with a client... end handle_one_session % Main server algorithm loop ... wait for a client to connect... var sock : Socket ...initialize sock... fork handle_one_session( sock ) end loop 5

Concurrent programming slides T.S. Norvell (c) 2001 Ease: MiniTunis kernel (simpli Þ ed) ...shared data structures and subroutines... process envelope( ... ) loop ...wait for a process to be created... ...initialize process... loop ...run user-level code until it traps... ...deal with system call or other trap... end loop ...clean up after process... end loop end envelope for i : 1 .. State.maxEnvelopes envelope( ... ) end for 6

Concurrent programming slides T.S. Norvell (c) 2001 How does it ease programming? In the traf Þ c-light example • The program must supervise several largely independent activities. In the Internet server • independent sessions can be largely dealt with concurrently In the MiniTunis Kernel • the largely independent user processes can be dealt with independently. • In particular, system calls from different user-level processes can be handled concurrently. 7

Concurrent programming slides T.S. Norvell (c) 2001 Object Oriented Turing Supports • Shared memory between threads (multithreading). ∗ Each thread has its own stack, but static variables are shared. • The Þ ction of an in Þ nite supply of processors. • Message passing can be programmed in. • The process declaration gives the algorithm for one or more threads. • The fork statement creates a new thread. • process — a subroutine, static, compile-time. • thread — an executing instance of a process subroutine, dynamic, run-time. Don’t confuse the process declaration with user-level processes! Don’t confuse OOT’s fork statement with miniTunis’s FORK system call! Confusingly, the OOT literature often calls “threads” “processes”! 8

Concurrent programming slides T.S. Norvell (c) 2001 The need for mutual exclusion Consider the following OOT module module track export increment, decrement, get var current : int := 0 proc increment current := current + 1 end increment proc decrement current := current - 1 end decrement fcn get : int result current end get end track 9

Concurrent programming slides T.S. Norvell (c) 2001 Suppose one thread calls increment while another calls decrement. Suppose current starts at 1 Thread A Thread B current calls increment 0 fetches current to a register 0 increments the register 0 context switch calls decrement 0 fetches current to a register 0 decrements the register 0 stores the register current -1 returns context switch stores the register to current 1 returns So the decrement is effectively lost. Suppose this is a count of how many times a Þ le is needed. Since the decrement is lost the Þ le will not be deleted when it should be. Worse: total corruption of data structures is possible. 10

Concurrent programming slides T.S. Norvell (c) 2001 Monitors to the rescue We require that only one thread be able to execute the code in the module. A monitor is a module with the added property that • A thread “enters” the monitor when it calls an exported routine of the monitor • A thread “exits” the monitor when it returns from an exported routine • A thread is “in” the monitor if it has entered but not exited. • A thread that tries to “enter” will wait until no thread is “in” the monitor. • Hence, at most one thread may be “in” the monitor at any given time. • Note a thread that tries to enter twice without exiting will be stuck! So we Þ x the problem with track like this 6 m 6 o 6 d 6 u 6 l 6 e monitor track 11