Skip to content
wannacode

Locking

In short: A lock (mutex) lets only one thread at a time into the critical section; in Python this is threading.Lock with with, and only the little that must be there goes under it.

Problem

How to stop the other till

In the lesson "Race condition" the sale lost sales: two threads did "read, subtract, write" at once and one overwrote the other. The three steps have to be one whole: while one thread is inside, the other has to wait outside.

That is exactly what a lock does.

The idea

The lock

A lock (mutex, from "mutual exclusion") is an object with one owner. A thread takes it, does its work and releases it. Another thread that asks for it in the meantime waits. The code between taking and releasing is the critical section: at most one thread is in it.

In Python the lock is threading.Lock(). with self.lock: takes it when entering the block and releases it when leaving, even with an exception. time.sleep(0) stays where it was: the other thread can still arrive exactly here, but it waits in front of the lock.
class Stock:
    def __init__(self, left):
        self.left = left
        self.lock = threading.Lock()


    def sell(self):
        with self.lock:
            seen = self.left
            time.sleep(0)  # the other thread may get in here, but waits at the lock
            self.left = seen - 1
The two tills from the last lesson, with the same 10,000 sales each:
stock = Stock(20_000)




def checkout():
    for _ in range(10_000):
        stock.sell()




a = threading.Thread(target=checkout)
b = threading.Thread(target=checkout)
a.start()
b.start()
a.join()
b.join()
print(f"Orders: {2 * 10_000}")
print("Sold according to the stock:")
print(20_000 - stock.left)
Output
Orders: 20000
Sold according to the stock:
20000

Exact, on every run. The lock is a field created once: both tills lock the same one.

See it

The last item, fixed

The check "is there one" and taking it are in one and the same critical section. If someone is inside checking, the other cannot check before the first has taken:

class Stock:
    def __init__(self, left):
        self.left = left
        self.lock = threading.Lock()


    def reserve(self):
        with self.lock:
            if self.left == 0:
                return False  # none left: refuse
            self.left -= 1    # there is one: take it
            return True
Step by step, in words
  1. 3 items are left, and 4 buyers call reserve() at the same moment.
  2. Only one gets through with self.lock; the other three wait in front of it. Buyer 1 goes in, sees 3 and takes one: 2 left.
  3. Buyer 1 leaves and releases the lock. Buyer 2 goes in, sees 2 and takes one: 1 left.
  4. Buyer 2 leaves and releases the lock. Buyer 3 goes in, sees 1 and takes one: 0 left.
  5. Buyer 4 goes in last and sees 0: refused. No one saw a number that someone else was in the middle of changing.
  6. 3 sold, 1 refused, 0 in stock: correct. The price: the buyers waited for each other at the turnstile.

Four buyers, three items, all at once:

stock = Stock(3)
results = []




def buyer():
    results.append(stock.reserve())




buyers = [threading.Thread(target=buyer) for _ in range(4)]
for t in buyers:
    t.start()
for t in buyers:
    t.join()
print(f"Sold: {results.count(True)}")
print(f"Refused: {results.count(False)}")
print(f"In stock: {stock.left}")
Output
Sold: 3
Refused: 1
In stock: 0

And here are the two buyers from the last lesson who were buying the last item. Charging the card (~100 ms) is after the lock: the item is reserved, and the card is charged without the other one waiting:

stock = Stock(1)
bought = []




def buyer():
    if stock.reserve():
        time.sleep(0.1)  # charging the card, ~100 ms
        bought.append(True)




buyers = [threading.Thread(target=buyer) for _ in range(2)]
for t in buyers:
    t.start()
for t in buyers:
    t.join()
print("In stock before: 1")
print(f"Sold: {len(bought)}")
print(f"Refused: {2 - len(bought)}")
print(f"In stock: {stock.left}")
Output
In stock before: 1
Sold: 1
Refused: 1
In stock: 0

One sold, one refused, 0 in stock. On every run.

Try it

Don't forget to release

with self.lock: is short for acquire() and release(). The release is in finally, so it happens even with an exception:
class Stock:
    def __init__(self, left):
        self.left = left
        self.lock = threading.Lock()


    def sell(self):
        self.lock.acquire()
        try:
            seen = self.left
            time.sleep(0)
            self.left = seen - 1
        finally:
            self.lock.release()

What releases the lock?

def sell(self):
    self.lock.acquire()
    try:
        seen = self.left
        time.sleep(0)
        self.left = seen - 1
    finally:

Try it

The lock that does not lock

A colleague added a lock, but the tills still lose sales. Which line is wrong?

Pick the line with the bug.

The idea

What a lock costs

A lock works by making threads wait for each other. The longer one thread stays inside, the longer the others wait. That is contention for the lock.

A shop with 10 items and four orders at once. Each order takes an item and sends an e-mail (~200 ms), and Network from the lesson "Why threads" counts the rounds of waiting:

class Network:
    def __init__(self):
        self.lock = threading.Lock()
        self.in_flight = 0
        self.rounds = 0


    def call(self, service, answer):
        """Asks a service over the network: the answer comes after ~200 ms."""
        with self.lock:
            if self.in_flight == 0:
                self.rounds += 1  # nobody is waiting: a new round
            self.in_flight += 1
        time.sleep(0.2)
        with self.lock:
            self.in_flight -= 1
        return f"{service}: {answer}"
class Shop:
    def __init__(self, net):
        self.net = net
        self.left = 10
        self.lock = threading.Lock()


    def order_slow(self, customer):
        """Bad: the e-mail goes out while the lock is held."""
        with self.lock:
            self.left -= 1
            self.net.call("e-mail", customer)


    def order(self, customer):
        """Good: only the stock is under the lock."""
        with self.lock:
            self.left -= 1
        self.net.call("e-mail", customer)
With order_slow the e-mail is under the lock:
net = Network()
shop = Shop(net)
orders = [
    threading.Thread(target=shop.order_slow, args=(f"customer {c}",))
    for c in range(1, 5)
]
for t in orders:
    t.start()
for t in orders:
    t.join()
print(f"Orders: 4, in stock: {shop.left}")
print(f"Rounds of waiting: {net.rounds}")
Output
Orders: 4, in stock: 6
Rounds of waiting: 4

Four rounds: the e-mails go out one by one, and the last customer waits about 800 ms. With order only the stock is under the lock:

net = Network()
shop = Shop(net)
orders = [
    threading.Thread(target=shop.order, args=(f"customer {c}",))
    for c in range(1, 5)
]
for t in orders:
    t.start()
for t in orders:
    t.join()
print(f"Orders: 4, in stock: {shop.left}")
print(f"Rounds of waiting: {net.rounds}")
Output
Orders: 4, in stock: 6
Rounds of waiting: 1

The same stock, one round. The rules:

  • Only the shared data under the lock. Compute, format and wait outside. Inside, only read and write.
  • Never wait under a lock: network, disk, database, sleep. Take what you need, release the lock and then wait.
  • One lock for one piece of data. The stock and the revenue are separate: each with its own lock, so that tills touching only one of them do not wait for each other.
More precisely, if you are curious
  • threading.Lock is not reentrant: if the thread that holds it asks for it again, it waits for itself forever. threading.RLock is the reentrant one.
  • self.lock.acquire(timeout=0.1) takes the lock only if it manages within 100 ms and returns True or False.
  • In asyncio the lock is asyncio.Lock with async with: that is the lesson "async is not a thread".

A lock is not the only way. For one counter there are atomic operations, which do not make threads wait at all, and data that nobody changes needs no lock: the lesson "Atomic operations and immutable objects". And two locks that two threads take in a different order can stop the program forever: the lesson "Deadlock".

Exercise

The revenue and an order of several items

Solve the tasks in your editor.

The revenue. Fix the task from the last lesson: two tills with 10,000 sales each at €3, and Revenue protects total with a lock. Run the program several times: the revenue has to be the same every time.

Expect
Till 1: 10000 sales
Till 2: 10000 sales
Revenue (€):
60000

An order of several items. There are 5 items in stock. Write reserve(count): if there are at least count, it takes them and returns true, otherwise it takes nothing and returns false. Three customers want 2 items each at once, each in their own thread.

Expect
Ordered: 3
Accepted: 2
Refused: 1
In stock: 1

More tasks

  • The price of a lock. Run the two tills with 1,000,000 sales each, with and without the lock, and time them. How much slower is it with the lock? And with 8 tills?
  • Two locks. Add revenue to the stock, with its own lock. A sale subtracts from the stock and adds to the revenue. Do the two stay together if someone reads the stock and the revenue between the two locks? - Timeout. Make a sale that waits for the lock at most 50 ms with acquire(timeout=0.05), and if it fails, returns "try again".

Test

Test yourself

1. Two threads call sell(), which does left-- under one and the same lock. What happens when the second reaches the lock while the first is inside?
2. The check "are there items" is under the lock, and the subtraction is in a separate block under the same lock. Two people buy the last item. What happens?
3. Under the lock are the stock subtraction and sending an e-mail (~200 ms). Four orders come at once. How long does the last one wait?
4. What is wrong with synchronized (new Object()) { left--; }? (C#: lock (new object()), Python: with threading.Lock())

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·