Concurrent programming Multiple threads working together to achieve - - PDF document

▶

Sep 14, 2023 262 likes •397 views

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

SLIDE 1

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

SLIDE 2

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

SLIDE 3

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

SLIDE 4

Ease: A TrafÞc Light Controller

process control_one_light( light : Light, north_south_time : Time, east_west_time : Time,

range_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

SLIDE 5

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

SLIDE 6

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

SLIDE 7

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

SLIDE 8

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

SLIDE 9

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

SLIDE 10

Suppose one thread calls increment while another calls

decrement. Suppose current starts at 1

Thread A Thread B current calls increment fetches current to a register increments the register context switch calls decrement fetches current to a register 0 decrements the register stores the register current

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

SLIDE 11

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