1. Concurrency

2. Concurrency Interleaved or overlapped execution
Examples from general purpose digital computing:
Threads
Multiprogramming
Multiprocessing
Examples from computing in nature:
Team projects
Transportation
Food chain
Allows more efficient execution, design flexibility

3. Challenges of concurrency
Cannot predict relative execution speed
Cannot know which process* will run next
Effective allocation of shared resources
Memory (e.g. shared variables)
I/O devices (or associated data structures)
Testing and debugging
Program behaviour cannot be reliably replicated
* In this discussion “process” is used to mean an entity of dispatch

4. Race conditions Final result depends on order of execution
Can happen when two or more processes modify a shared resource
For example …

5. … a threaded mail server
Suppose
Mail server counts the s received each day
s received by any of several worker threads
The assembly language description of the worker threads might include the following:
LOAD MailCount
ADD 1
STORE MailCount

6. A Possible Execution Trace
Thread 1
Load MailCount
Add 1
Store MailCount
Thread 2
Load MailCount
Add 1
Store MailCount

7. Preventing Race Conditions
Restrict access to shared resources
Requires restricting access to code (at some level) that accesses shared resources (“critical section”)
Only when one process has completed execution of the critical section can another process be allowed to begin executing it (“mutual exclusion”)

8. Requirements for a mutual exclusion solution
Only one process at a time is allowed into its critical section (CS)
To prevent race conditions
A process that halts in its non-CS must do so without interfering with other processes.
Definition of critical section
Process waiting for CS must not be delayed indefinitely
To prevent deadlock and starvation
Whenever there is no process in the CS and at least one process waiting to enter the CS, one must be permitted access
To prevent starvation
No assumptions are made about the relative speeds or number of processes
The time that any one process remains inside its critical section is finite
Assumption

9. Four different approaches
Hardware
Turn off interrupts
Special instruction(s)
Software
Application layer
System layer (OS/compiler)

10. 1. Disable interrupts void func() { <non CS>
/* enable interrupts */ }
Satisfies requirements
No interrupts means no mode switches
No mode switches means no process switches
No process switches means no race condition
Simple and efficient
Appropriate for some embedded systems
Insecure
Trusts application to announce exit from critical section
Only applicable on single processor systems

11. 2. Special Instruction(s)
TESTSET X1, X2:
Test X1, and set X2 accordingly
Executes atomically – nothing else executes between test operation and set operation!
For example (assuming X1 and X2 are stored in registers R1 and R2):
If register R1 contains the value 0, store the value 1 in both register R1 and R2
Otherwise, leave R1 unchanged and store the value 0 in register R2.
Pros? Cons?
Example application (busy wait):
int bolt = false;
void main() {
parbegin( P( 0 ),P( 1 )…P( n ) ) }
void P( int j ) {
while( ! TestSet( bolt ) ) {
/* do nothing */
<CS>
bolt = false;
<non-CS>

12. 3. Application layer Relies on hardware support
Typical assumption: machine language instructions cannot concurrently modify a memory location

13. Dekker’s Algorithm (1)
Discussed in Appendix A (Figure A.2, p. 375) for the case of two processes
Global variable indicates next process to receive access to critical section
Processes busy wait (a.k.a. spin wait) while checking the global variable
When a process detects that no other process is in the critical section, it asserts its entry (i.e. updates the global variable)
Issues:
Processes are strictly ordered (coroutines)
Process failure (in or out of critical section)

14. Dekker’s Algorithm (2)
Global variable for each process indicating its presence in critical section
Processes busy wait while checking other processes’ presence
When a process detects that no other process is in the critical section, it asserts its entry (i.e. updates its global variable)
Issues:
Process failure in critical section (this does not violate requirements)
No mutual exclusion (two processes check global variables, then enter critical section)

15. Dekker’s Algorithm (3)
Global variable for each process indicating its presence in critical section
Processes first assert their entry, then busy wait while checking other processes’ presence
Issues:
Process failure in critical section
Deadlock (two processes assert their entry, then busy wait)

16. Dekker’s Algorithm (4)
Global variable for each process indicating its need to enter critical section
Processes first assert their need to enter, then busy wait checking other processes’ need to enter
Unassert their own need
Wait
Assert it again
Issues:
Process failure in critical section
“Livelock” starvation (two processes assert their needs, then unassert them, then sequence repeats indefinitely)

17. Dekker’s Algorithm (Final)
Global variables indicating
Each process’ need to enter critical section
Which process is first in line for the critical section
Processes first assert their need to enter, then busy wait
Check other processes’ need to enter
If they are not first in line
Unassert their own need
Wait
Assert it again
Upon entering critical section, processes update the global variable indicating which process is next
Issue:
Fairness (how to decide which process is next)

18. Peterson’s Algorithm
Discussed in Appendix A (Figure A.3, p. 736) for the case of two processes
More elegant than Dekker’s algorithm
Generalization to n processes left as an exercise for the student