Zum Inhalt
wannacode

Sperren

Kurz gesagt: Ein Lock (Mutex) lässt immer nur einen Thread in den kritischen Abschnitt; in Python ist das threading.Lock mit with, und unter das Lock kommt nur das Wenige, was dorthin muss.

Problem

Wie man die andere Kasse aufhält

In der Lektion „Race Condition“ hat der Verkauf Verkäufe verloren: Zwei Threads machten gleichzeitig „lesen, abziehen, schreiben“, und einer überschrieb den anderen. Die drei Schritte müssen ein Ganzes sein: Solange ein Thread drin ist, muss der andere draußen warten.

Genau das macht ein Lock.

Die Idee

Das Lock

Ein Lock (Mutex, von „mutual exclusion“) ist ein Objekt mit einem Besitzer. Ein Thread nimmt es, erledigt seine Arbeit und gibt es frei. Ein anderer Thread, der es währenddessen verlangt, wartet. Der Code zwischen Nehmen und Freigeben ist der kritische Abschnitt: Höchstens ein Thread ist darin.

In Python ist das Lock threading.Lock(). with self.lock: nimmt es beim Betreten des Blocks und gibt es beim Verlassen frei, auch bei einer Exception. time.sleep(0) bleibt, wo es war: Der andere Thread kann immer noch genau hier ankommen, wartet aber vor dem 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)  # der andere Thread kann hier hereinkommen, wartet aber vor dem Lock
            self.left = seen - 1
Die zwei Kassen aus der letzten Lektion, mit denselben 10.000 Verkäufen je Kasse:
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"Bestellungen: {2 * 10_000}")
print("Verkauft laut Lager:")
print(20_000 - stock.left)
Ausgabe
Bestellungen: 20000
Verkauft laut Lager:
20000

Genau, bei jedem Lauf. Das Lock ist ein Feld, einmal erzeugt: Beide Kassen sperren dasselbe.

Sieh es dir an

Der letzte Artikel, repariert

Die Prüfung „ist einer da“ und das Nehmen liegen im selben kritischen Abschnitt. Wenn jemand drin ist und prüft, kann der andere nicht prüfen, bevor der erste genommen hat:

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  # keiner mehr da: ablehnen
            self.left -= 1    # einer ist da: nehmen
            return True
Schritt für Schritt, in Worten
  1. Es sind noch 3 Stück übrig, und 4 Käufer rufen im selben Moment reserve() auf.
  2. Durch with self.lock kommt nur einer, die anderen drei warten davor. Käufer 1 geht hinein, sieht 3 und nimmt eins: 2 übrig.
  3. Käufer 1 geht hinaus und gibt das Lock frei. Käufer 2 geht hinein, sieht 2 und nimmt eins: 1 übrig.
  4. Käufer 2 geht hinaus und gibt das Lock frei. Käufer 3 geht hinein, sieht 1 und nimmt eins: 0 übrig.
  5. Käufer 4 geht als letzter hinein und sieht 0: abgelehnt. Niemand sah eine Zahl, die ein anderer gerade ändert.
  6. 3 verkauft, 1 abgelehnt, 0 auf Lager: richtig. Der Preis: Die Käufer haben am Drehkreuz aufeinander gewartet.

Vier Käufer, drei Artikel, alle auf einmal:

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"Verkauft: {results.count(True)}")
print(f"Abgelehnt: {results.count(False)}")
print(f"Bestand: {stock.left}")
Ausgabe
Verkauft: 3
Abgelehnt: 1
Bestand: 0

Und hier sind die zwei Käufer aus der letzten Lektion, die den letzten Artikel kauften. Das Belasten der Karte (~100 ms) kommt nach dem Lock: Der Artikel ist reserviert, und die Karte wird belastet, ohne dass der andere wartet:

stock = Stock(1)
bought = []




def buyer():
    if stock.reserve():
        time.sleep(0.1)  # die Karte wird belastet, ~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("Bestand vorher: 1")
print(f"Verkauft: {len(bought)}")
print(f"Abgelehnt: {2 - len(bought)}")
print(f"Bestand: {stock.left}")
Ausgabe
Bestand vorher: 1
Verkauft: 1
Abgelehnt: 1
Bestand: 0

Einer verkauft, einer abgelehnt, 0 auf Lager. Bei jedem Lauf.

Probier es aus

Vergiss die Freigabe nicht

with self.lock: ist die Kurzform für acquire() und release(). Die Freigabe steht in finally, also passiert sie auch bei einer 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()

Was gibt das Lock frei?

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

Probier es aus

Das Lock, das nicht sperrt

Ein Kollege hat ein Lock hinzugefügt, aber die Kassen verlieren trotzdem Verkäufe. Welche Zeile ist falsch?

Wähle die Zeile mit dem Fehler.

Die Idee

Was ein Lock kostet

Ein Lock funktioniert, indem es Threads aufeinander warten lässt. Je länger ein Thread drin bleibt, desto länger warten die anderen. Das ist die Contention (Konkurrenz) um das Lock.

Ein Shop mit 10 Artikeln und vier Bestellungen auf einmal. Jede Bestellung nimmt einen Artikel und sendet eine E-Mail (~200 ms), und Network aus der Lektion „Warum Threads“ zählt die Warterunden:

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


    def call(self, service, answer):
        """Fragt einen Dienst über das Netzwerk: Die Antwort kommt nach ~200 ms."""
        with self.lock:
            if self.in_flight == 0:
                self.rounds += 1  # niemand wartet: eine neue Runde
            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):
        """Schlecht: Die E-Mail geht raus, während das Lock gehalten wird."""
        with self.lock:
            self.left -= 1
            self.net.call("E-Mail", customer)


    def order(self, customer):
        """Gut: Unter dem Lock liegt nur der Bestand."""
        with self.lock:
            self.left -= 1
        self.net.call("E-Mail", customer)
Bei order_slow liegt die E-Mail unter dem Lock:
net = Network()
shop = Shop(net)
orders = [
    threading.Thread(target=shop.order_slow, args=(f"Kunde {c}",))
    for c in range(1, 5)
]
for t in orders:
    t.start()
for t in orders:
    t.join()
print(f"Bestellungen: 4, bestand: {shop.left}")
print(f"Warterunden: {net.rounds}")
Ausgabe
Bestellungen: 4, bestand: 6
Warterunden: 4

Vier Runden: Die E-Mails gehen einzeln raus, und der letzte Kunde wartet etwa 800 ms. Bei order liegt nur der Bestand unter dem Lock:

net = Network()
shop = Shop(net)
orders = [
    threading.Thread(target=shop.order, args=(f"Kunde {c}",))
    for c in range(1, 5)
]
for t in orders:
    t.start()
for t in orders:
    t.join()
print(f"Bestellungen: 4, bestand: {shop.left}")
print(f"Warterunden: {net.rounds}")
Ausgabe
Bestellungen: 4, bestand: 6
Warterunden: 1

Derselbe Bestand, eine Runde. Die Regeln:

  • Nur die gemeinsamen Daten unter das Lock. Rechne, formatiere und warte draußen. Drinnen nur lesen und schreiben.
  • Warte nie unter einem Lock: Netzwerk, Festplatte, Datenbank, sleep. Nimm, was du brauchst, gib das Lock frei und warte dann.
  • Ein Lock für ein Datenstück. Der Bestand und der Umsatz sind getrennt: jedes mit eigenem Lock, damit Kassen, die nur eines von beiden anfassen, nicht aufeinander warten.
Genauer, für Neugierige
  • threading.Lock ist nicht reentrant: Wenn der Thread, der es hält, es erneut verlangt, wartet er für immer auf sich selbst. threading.RLock ist das reentrante.
  • self.lock.acquire(timeout=0.1) nimmt das Lock nur, wenn es innerhalb von 100 ms gelingt, und gibt True oder False zurück.
  • In asyncio ist das Lock asyncio.Lock mit async with: Das ist die Lektion „async ist kein Thread“.

Ein Lock ist nicht der einzige Weg. Für einen Zähler gibt es atomare Operationen, die Threads gar nicht warten lassen, und Daten, die niemand ändert, brauchen kein Lock: die Lektion „Atomare Operationen und unveränderliche Objekte“. Und zwei Locks, die zwei Threads in unterschiedlicher Reihenfolge nehmen, können das Programm für immer anhalten: die Lektion „Deadlock“.

Übung

Der Umsatz und eine Bestellung mit mehreren Artikeln

Löse die Aufgaben in deinem Editor.

Der Umsatz. Repariere die Aufgabe aus der letzten Lektion: zwei Kassen mit je 10.000 Verkäufen zu 3 €, und Revenue schützt total mit einem Lock. Führe das Programm mehrmals aus: Der Umsatz muss jedes Mal derselbe sein.

Erwartet
Kasse 1: 10000 Verkäufe
Kasse 2: 10000 Verkäufe
Umsatz (€):
60000

Eine Bestellung mit mehreren Artikeln. Es sind 5 Artikel auf Lager. Schreibe reserve(count): Wenn mindestens count da sind, nimmt es sie und gibt true zurück, sonst nimmt es nichts und gibt false zurück. Drei Kunden wollen gleichzeitig je 2 Artikel, jeder in seinem eigenen Thread.

Erwartet
Bestellt: 3
Angenommen: 2
Abgelehnt: 1
Bestand: 1

Weitere Aufgaben

  • Der Preis eines Locks. Führe die zwei Kassen mit je 1.000.000 Verkäufen mit und ohne Lock aus und miss die Zeit. Wie viel langsamer ist es mit dem Lock? Und mit 8 Kassen?
  • Zwei Locks. Füge dem Bestand einen Umsatz mit eigenem Lock hinzu. Ein Verkauf zieht vom Bestand ab und addiert zum Umsatz. Bleiben die beiden zusammen, wenn jemand den Bestand und den Umsatz zwischen den beiden Locks liest? - Timeout. Mache einen Verkauf, der mit acquire(timeout=0.05) höchstens 50 ms auf das Lock wartet und bei einem Fehlschlag „Versuch es noch einmal“ zurückgibt.

Test

Teste dich

1. Zwei Threads rufen sell() auf, das left-- unter ein und demselben Lock ausführt. Was passiert, wenn der zweite das Lock erreicht, während der erste drin ist?
2. Die Prüfung „sind Artikel da“ liegt unter dem Lock, und das Abziehen steht in einem eigenen Block unter demselben Lock. Zwei Leute kaufen den letzten Artikel. Was passiert?
3. Unter dem Lock liegen das Abziehen vom Bestand und das Senden einer E-Mail (~200 ms). Vier Bestellungen kommen auf einmal. Wie lange wartet die letzte?
4. Was ist falsch an synchronized (new Object()) { left--; }? (C#: lock (new object()), Python: with threading.Lock())

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·