Concurrent Programming Introducing the principles of reentrancy, mutual exclusion and thread-synchronication

Advantages of multithreading For multiprocessor systems (two or more CPUs), there are potential efficiencies in the parallel execution of separate threads (a computing job may be finished sooner) For uniprocessor systems (just one CPU), there are likely software design benefits in dividing a complex job into simpler pieces (easier to debug and maintain -- or reuse)

Some Obstacles Separate tasks need to coordinate actions, share data, and avoid competing for same system resources Management ‘overhead’ could seriously degrade the system’s overall efficiency Examples: –Frequent task-switching is costly in CPU time –Busy-Waiting is wasteful of system resources

Some ‘work-arounds’ Instead of using ‘pipes’ for the exchange of data among separate processes, Linux lets ‘threads’ use the same address-space (reduces ‘overhead’ in context-switching) Instead of requiring one thread to waste time busy-waiting while another finishes some particular action, Linux lets a thread voluntarily give up its control of the CPU

Additional pitfalls Every thread needs some private memory that cannot be ‘trashed’ by another thread (for example, it needs a private stack for handling interrupts, passing arguments to functions, creating local variables, saving CPU register-values temporarily) Each thread needs a way to prevent being interrupted in a ‘critical’ multi-stage action

Example of a ‘critical section’ If interrupt occurs Recall Disk-Drive device-programming (status-register and control-register) Algorithm: –(1) Loop rereads status-register until ‘ready’ –(2) Write drive-command to control-register If an interrupt occurs between these steps, another thread can send its own command

‘mutual exclusion’ To prevent one thread from ‘sabotaging’ the actions of another, some mechanism is needed that allows a thread to temporarily ‘block’ other threads from gaining control of the CPU -- until the first thread has completed its ‘critical’ action Some ways to accomplish this: –Disable interrupts (stops CPU time-sharing) –Use a ‘mutex’ (a mutual exclusion variable) –Put other tasks to sleep (remove from run-queue)

What about ‘cli’? Disabling interrupts will stop ‘time-sharing’ among tasks on a uniprocessor system But it would be ‘unfair’ in to allow this in a multi-user system (monopolize the CPU) So ‘cli’ is a privileged instruction: it cannot normally be executed by user-mode tasks It won’t work on a multiprocessor system

What about a ‘mutex’? A shared global variable acts as a ‘lock’ Initially it’s ‘unlocked’: e.g., int mutex = 1; Before entering a ‘critical section’ of code, a task ‘locks’ the mutex: i.e., mutex = 0; As soon as it leaves its ‘critical section’, it ‘unlocks’ the mutex: i.e., mutex = 1; While the mutex is ‘locked’, no other task can enter the ‘critical section’ of code

Advantages and cautions A mutex can be used in both uniprocessor and multiprocessor systems – provided it is possible for a CPU to ‘lock’ the mutex with a single ‘atomic’ instruction (requires special support by processors’ hardware) Use of a mutex can introduce busy-waiting by tasks trying to enter the ‘critical section’ (thereby severely degrading performance)

Software mechanism The operating system can assist threads needing mutual exclusion, simply by not scheduling other threads that might want to enter the same ‘critical section’ of code Linux accomplishes this by implementing ‘wait-queues’ for those threads that are all contending for access to the same system resource – including ‘critical sections’

Demo programs To show why ‘synchronization’ is needed in multithreaded programs, we wrote the ‘concur1.cpp’ demo-program Here several separate threads will all try to increment a shared ‘counter’ – but without any mechanism for doing synchronization The result is unpredictable – a different total is gotten each time the program runs!

How to employ a ‘mutex’ Declare a global variable: int mutex = 1; Define a pair of shared subroutines – void enter_critical_section( void ); – void leave_critical_section( void ); Insert calls to these subroutines before and after accessing the global ‘counter’

Special x86 instructions We need to use x86 assembly-language (to implement ‘atomic’ mutex-operations) Several instruction-choices are possible, but ‘btr’ and ‘bts’ are simplest to use: –‘btr’ means ‘bit-test-and-reset’ –‘bts’ means ‘bit-test-and’set’ Syntax and semantics: – asm(“ btr $0, mutex “); // acquire the mutex – asm(“ bts $0, mutex “); // release the mutex

The two mutex-functions void enter_critical_section( void ) { asm(“spin: btr $0, mutex “); asm(“ jnc spin “); } void leave_critical_section( void ) { asm(“ bts $0, mutex “); }

Where to use the functions void my_thread( int * data ) { inti, temp; for (i = 0; i < maximum; i++) { enter_critical_section(); temp = counter; temp += 1; counter = temp; leave_critical_section(); }

‘reentrancy’ By the way, we point out as an aside that our ‘my_thread()’ function (on the previous slide) is an example of ‘reentrant’ code More than one process (or processor) can be safely executing it concurrently It needs to obey two cardinal rules: –It contains no ‘self-modifying’ instructions –Access to shared variables is ‘exclusive’

In-class exercise #1 Rewrite the ‘concur1.cpp’ demo-program, as ‘concur2.cpp’, inserting these functions that will implement ‘mutual exclusion’ for our thread’s ‘critical section’ Then try running your ‘concur2.cpp’ on a uniprocessor system (your workstation) Also try running your ‘concur2.cpp’ on a multiprocessor system (e.g., dept server)

The x86 ‘lock’ prefix In order for the ‘btr’ instruction to perform an ‘atomic’ update (when multiple CPUs are using the same bus to access memory simultaneously), it is necessary to insert an x86 ‘lock’ prefix, like this: asm(“ spin: lock btr $0, mutex “); This instruction ‘locks’ the shared system- bus during this instruction execution -- so another CPU cannot intervene

In-class exercise #2 Add the ‘lock’ prefix to your ‘concur2.cpp’ demo, and then try executing it again on the multiprocessor system Use the Linux ‘time’ command to measure how long it takes for your demo to finish Observe the ‘degraded’ performance due to adding the ‘mutex’ functions – penalty for achieving a ‘correct’ parallel program

The ‘nanosleep()’ system-call Your multithreaded demo-program shows poor performance because your threads are doing lots of ‘busy-waiting’ When a thread can’t acquire the mutex, it should voluntarily give up control of the CPU (so another thread can do real work) The Linux ‘nanosleep()’ system-call allows a thread to ‘yield’ its time-slice

In-class exercise #3 Revice your ‘concur3.cpp’ program so that a thread will ‘yield’ if it cannot immediately acquire the mutex (see our ‘yielding.cpp’ demo for header-files and call-syntax) Use the Linux ‘time’ command to compare the performance of ‘concur3’ and ‘concur2’ –On a uniprocessor platform –On a multiprocessor platform