**[PS4 Assessment](https://docs.google.com/forms/d/1_MONt8V99KtucMRswC2L6yUtXlKYK9CY3wB9Ubf_MFY/viewform)** due after your demo (by tomorrow at the latest)
**[Project Idea](https://docs.google.com/forms/d/1Sxg5aJuhEWPVpVzUzEBrTsChRsn2wtJogsd7ycSjcTk/viewform)** due by **11:59pm Thursday (tonight)**.
# Projects/Hackathon Update
# Mutual Exclusion
**Requirements:**
1. Only one thread may be in the critical section at any time.
2. Each must eventually be able to enter its critical section.
3. Must be symmetrical (all run same program, cannot introduce static priority).
4. Cannot make any assumptions about speed of threads.
What's "wrong" with this solution?
```python
loop {
if turn == i:
critical_section;
turn = i + 1;
}
```
What's "wrong" with this solution?
```python
loop {
if not lock:
lock = true;
critical_section;
lock = false;
}
```
## Test and Set
Atomic instruction that:
- returns current value of _v_
- sets value of _v_ to true
How can you implement mutual exclusion using _test-and-set_?
## ARM's Exclusion Instructions
**LDREX** _dest_ _location_
_dest_ = _location_
Sets monitor on _location_ in Exclusive state
**STREX** _success_ _value_ _location_
Conditionally store into exclusive .
If permitted, = 1 and = .
If not, = 0 and value unchanged.
Context switch clears monitor (Open) state.
[_ARM Synchronization Primitives_](http://infocenter.arm.com/help/topic/com.arm.doc.dht0008a/DHT0008A_arm_synchronization_primitives.pdf)
```
lock_mutex(lock):
try_again:
LDREX R2, [lock]
if R2 goto try_again
STREX R2, 1, [lock]
if not R2 goto try_again
unlock_mutex(lock):
STR [lock], 0
```
Why don't we need to use **STREX** in unlock?
How should this be different if we care about energy?
# Dijkstra's Solution
```python
loop {
b[i] := false
L1: if k != i
c[i] := true
if b[k]:
k := i
goto L1
else:
c[i] := false
for j in [1, ..., N]:
if j != i and not c[j]:
goto L1
critical section;
c[i] := true
b[i] := true
}
```
Why is this guaranteed to provide mutual exclusion?