Thread Synchronization with Lock

The problem: race conditions

A race condition happens when two threads update shared state at the same time.

Example: incrementing a shared counter.

race_condition.py

import threading
 
counter = 0
 
 
def inc():
    global counter
    for _ in range(100_000):
        counter += 1
 
 
t1 = threading.Thread(target=inc)
t2 = threading.Thread(target=inc)
 
t1.start(); t2.start()
t1.join(); t2.join()
 
print("counter:", counter)

You might expect 200000, but results can vary.

Fix with Lock

lock_fix.py

import threading
 
counter = 0
lock = threading.Lock()
 
 
def inc():
    global counter
    for _ in range(100_000):
        with lock:
            counter += 1
 
 
t1 = threading.Thread(target=inc)
t2 = threading.Thread(target=inc)
 
t1.start(); t2.start()
t1.join(); t2.join()
 
print("counter:", counter)

Best practices

• Keep locked sections small.
• Prefer with lock: so you don’t forget to release.
• Avoid deadlocks (don’t acquire multiple locks in random order).

diagram a lock turns a read-modify-write back into one step mermaid

  flowchart TD
  A["counter += 1"] --> B["read counter"]
  B --> C["add 1"]
  C --> D["write counter"]
  B -.->|"another thread can run HERE"| E["it reads the SAME old value"]
  E --> F["both write the same result"]
  F --> G["one increment is lost"]
  H["with lock:"] --> I["read, add, write -- uninterrupted by other threads"]
  I --> J["the invariant holds"]

The unsafe version reads, is interrupted, and writes back a value computed from a stale read -- so one increment disappears. Holding a lock across the whole sequence means no other thread can interleave with it, which is what makes the operation atomic with respect to the others.

sketch Where the increment goes missing, and what the lock removes p5.js Pause Restart

Two threads running read-add-write on one counter. Without a lock the second thread reads before the first has written, so both compute the same result and one increment vanishes. With the lock the second thread waits at the door instead. The counter at the bottom is what each version actually produces.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. Why can `counter += 1` lose updates across threads?

   A Integers are not thread-safe B It is a read-modify-write, and another thread can run between the read and the write C The GIL is released mid-instruction D Addition is not atomic in C
   pch.quizShowAnswer

   B — It is a read-modify-write, and another thread can run between the read and the write — Both threads read the same old value, compute the same result, and write it. The second write does not add anything — it repeats the first.

2. An exception is raised inside `with lock:`. What happens to the lock?

   A It stays held B It is released — that is what the context manager guarantees C It is released only if you catch the exception D The thread dies holding it
   pch.quizShowAnswer

   B — It is released — that is what the context manager guarantees — Verified. A manual `acquire()` with no `try`/`finally` left the lock HELD after an exception, and the next thread to ask for it would wait forever.

3. The same thread calls `acquire()` twice on a plain `threading.Lock`. What happens?

   A It succeeds — locks are re-entrant B It deadlocks against itself C It raises RuntimeError D The second call is ignored
   pch.quizShowAnswer

   B — It deadlocks against itself — Measured: the second `acquire(timeout=0.2)` returned False. `RLock` records its owner and a count, so the owner may re-enter — and must release the same number of times.

4. When do you NOT need a lock?

   A When there is only one writer B When the shared state is only ever read C When the operations are short D When using a daemon thread
   pch.quizShowAnswer

   B — When the shared state is only ever read — Reads alone cannot tear a value. The moment anything writes, a read-modify-write needs protection — and 'only one writer' is not enough if readers can observe a half-updated structure.

🧪 Try It Yourself

Exercise 1 – Basic Lock Usage

pch.exerciseTag pch.exerciseTitle

Exercise 2 – Lock as Context Manager

pch.exerciseTag pch.exerciseTitle

Exercise 3 – Detect Locked State

pch.exerciseTag pch.exerciseTitle