칠판의 숫자가 틀렸다: 경쟁 상태와 Lock

셋째 밤 새벽 두 시, 영업이 끝났습니다. 오늘은 탁 씨의 친구가 하루 도우러 와서 요리사가 넷이었습니다. 셰프는 규칙을 하나 정했습니다. "한 그릇 낼 때마다 칠판 숫자에 1을 더해."

주문서를 세어 보니 넷이 각자 1000그릇씩, 모두 4000그릇입니다. 그런데 칠판에는 1086이 적혀 있습니다.

민호가 머리를 긁습니다. "저 진짜 매번 더했는데요?" 수아도, 탁 씨도 같은 말을 합니다. 셰프가 분필을 집어 듭니다. "다들 거짓말은 안 했어. 넷이 동시에 칠판 앞에 섰을 뿐이지."

3-1. 4000이 1086이 되다 (8분)

칠판에 1을 더하는 일은 사실 세 단계입니다. 칠판을 읽고, 머릿속으로 1을 더하고, 칠판에 쓴다. 이 세 단계를 그대로 코드로 옮겨 보겠습니다.

import threading
import time

board = 0                       # 칠판의 숫자

def cook(times):
    global board
    for _ in range(times):
        seen = board            # 1. 칠판을 읽는다
        time.sleep(0)           # 2. 잠깐 한눈을 판다(다른 요리사에게 차례가 넘어갈 틈)
        board = seen + 1        # 3. 읽은 값에 1을 더해 적는다

threads = [threading.Thread(target=cook, args=(1000,)) for _ in range(4)]
for th in threads:
    th.start()
for th in threads:
    th.join()
print(board)
# 예: 1086  (실행할 때마다 다르다. 4000은 거의 나오지 않는다)

• time.sleep(0)은 "0초 쉬기"인데, 실제로는 지금 차례를 다른 스레드에게 넘겨 주는 효과가 있습니다. 읽기와 쓰기 사이에 다른 요리사가 끼어들 틈을 일부러 만든 것입니다.
• 진짜 프로그램에서는 이 틈이 sleep이 아니라 로그 찍기, 데이터베이스 조회, 함수 호출 같은 평범한 코드입니다. 틈은 늘 어딘가에 있습니다.
• 실행할 때마다 숫자가 다릅니다. 이 PC의 Python 3.14에서는 대략 1000~1200 사이가 나왔습니다.

이렇게 여러 스레드가 같은 값을 읽고 고쳐 쓰는 순서에 따라 결과가 달라지는 것을 경쟁 상태(race condition)라고 합니다. 아래 칠판 실험에서 직접 확인해 보세요. 요리사들은 위의 코드와 똑같이 "읽기 → time.sleep(0) → 쓰기"를 합니다.

• Lock을 끄면 실제 숫자가 기대값보다 한참 작고, 칠 때마다 다릅니다. "잃어버린 주문" 칸이 그 차이입니다.
• 요리사를 1명으로 줄이면 Lock이 없어도 정확히 맞습니다. 경쟁 상태는 둘 이상이 같은 값을 만질 때만 생깁니다.
• Lock을 켜면 몇 명이든 몇 번이든 기대값과 똑같습니다. 그 Lock이 무엇인지가 3-3의 내용입니다.

3-2. 한 단계씩 보는 경쟁 상태 (8분)

칠판이 41일 때, 민호와 수아가 거의 동시에 한 그릇씩 냈다고 해 봅시다. 시간을 한 칸씩 끊어 보면 이렇습니다.

두 사람이 한 그릇씩, 모두 두 그릇을 냈으니 칠판은 43이어야 합니다. 그런데 42입니다. 수아는 민호가 고치기 전의 값을 읽었고, 민호가 쓴 42를 자기 42로 덮어썼습니다. 민호의 한 그릇이 사라졌습니다.

• 문제는 "읽기 → 계산 → 쓰기" 사이에 다른 스레드가 끼어드는 것입니다. 세 단계가 한 덩어리로 실행된다는 보장이 없습니다.
• 네 명이 동시에 읽으면 한 번에 세 그릇이 사라질 수도 있습니다. 넷이 모두 41을 읽고 모두 42를 쓰면, 네 그릇이 한 그릇으로 줄어듭니다. 4000이 1086까지 떨어지는 이유입니다.
• 순서가 운 좋게 맞으면 숫자가 맞기도 합니다. 그래서 경쟁 상태는 테스트에서는 통과하고 손님이 몰린 밤에만 터지는, 가장 찾기 어려운 버그가 됩니다.

3-3. 분필은 하나뿐: Lock (10분)

해법은 단순합니다. 칠판 앞에는 한 번에 한 사람만 서게 합니다. 분필을 하나만 두고, 분필을 쥔 사람만 칠판에 쓸 수 있게 하는 것입니다. 파이썬의 분필은 threading.Lock입니다.

board = 0
chalk = threading.Lock()        # 분필은 하나뿐

def cook(times):
    global board
    for _ in range(times):
        with chalk:             # 분필을 쥔 사람만 칠판 앞에 선다
            seen = board
            time.sleep(0)
            board = seen + 1

threads = [threading.Thread(target=cook, args=(1000,)) for _ in range(4)]
for th in threads:
    th.start()
for th in threads:
    th.join()
print(board)
# 4000

• with chalk: 블록에 들어갈 때 잠금을 잡고(acquire), 나올 때 풉니다(release). 다른 스레드가 이미 잡고 있으면, 풀릴 때까지 그 자리에서 기다립니다.
• 블록 안에서 time.sleep(0)으로 차례를 넘겨도 괜찮습니다. 다른 요리사가 차례를 받아도 분필이 없으니 칠판에 손을 못 댑니다.
• 몇 번을 돌려도 4000입니다. 잠금 안의 "읽기 → 계산 → 쓰기"는 다른 스레드가 끼어들 수 없는 한 덩어리가 됐습니다.

with를 쓰지 않고 직접 잡고 풀 수도 있습니다. 이때는 반드시 try/finally로 감싸서, 중간에 예외가 나도 분필을 내려놓게 합니다.

chalk = threading.Lock()
print(chalk.locked())
chalk.acquire()                 # 분필을 쥔다
try:
    print(chalk.locked())
    print(chalk.acquire(blocking=False))    # 이미 누가 쥐고 있으면 바로 False
    print(chalk.acquire(timeout=0.1))       # 0.1초 기다려 보고 못 쥐면 False
finally:
    chalk.release()             # 무슨 일이 있어도 내려놓는다
print(chalk.locked())
chalk.release()
# False
# True
# False
# False
# False
# RuntimeError: release unlocked lock

잠금 범위는 짧게: 칠판 앞에서만

잠금은 다른 사람을 기다리게 만듭니다. 그러니 꼭 필요한 줄만 감싸야 합니다. 요리까지 분필을 쥔 채로 하면 어떻게 될까요?

board = 0
chalk = threading.Lock()

def cook_wide():
    global board
    with chalk:
        time.sleep(0.1)         # 요리까지 분필을 쥔 채로
        board += 1

def cook_narrow():
    global board
    time.sleep(0.1)             # 요리는 각자
    with chalk:
        board += 1              # 칠판 앞에서만 잠근다

for fn in (cook_wide, cook_narrow):
    board = 0
    threads = [threading.Thread(target=fn) for _ in range(4)]
    start = time.perf_counter()
    for th in threads:
        th.start()
    for th in threads:
        th.join()
    print(fn.__name__, board, f"{time.perf_counter() - start:.2f}s")
# cook_wide 4 0.40s
# cook_narrow 4 0.10s

둘 다 숫자는 정확히 4입니다. 하지만 cook_wide는 분필을 쥔 사람이 요리를 끝낼 때까지 나머지가 줄을 서서, 요리사 넷이 있어도 혼자 하는 것과 같은 0.4초가 걸립니다. 공유하는 값을 만지는 줄만 잠그세요.

3-4. GIL이 있어도 경쟁 상태는 생긴다 (8분)

파이썬(정확히는 CPython)에는 GIL(Global Interpreter Lock)이라는 큰 잠금이 있습니다. 한 순간에 파이썬 코드를 실행하는 스레드는 하나뿐이라는 규칙입니다. 자세한 건 8교시에 다루는데, 여기서 흔한 오해가 하나 생깁니다. "한 번에 하나만 실행되면 경쟁 상태도 없지 않나?"

아닙니다. GIL은 바이트코드 한 줄 단위로 스레드를 바꿔 줄 뿐, 여러분의 "읽기 → 계산 → 쓰기"를 한 덩어리로 지켜 주지 않습니다. board += 1 한 줄도 안을 열어 보면 여러 단계입니다.

import dis

count = 0

def add():
    global count
    count += 1

dis.dis(add)
# 결과 일부(3.14):
#   LOAD_GLOBAL              0 (count)     ← 읽기
#   LOAD_SMALL_INT           1
#   BINARY_OP               13 (+=)        ← 계산
#   STORE_GLOBAL             0 (count)     ← 쓰기

읽기와 쓰기 사이에 스레드가 바뀌면, 3-2의 표와 똑같은 일이 일어납니다. 스레드를 언제 바꿀지는 인터프리터가 정하고, 그 간격은 sys.getswitchinterval()로 볼 수 있습니다.

import sys
print(sys.getswitchinterval())
# 0.005

기본값은 0.005초입니다. 한 스레드가 계속 돌고 있어도 대략 이 간격마다 다른 스레드에게 차례를 넘기라는 요청이 갑니다. time.sleep이나 I/O처럼 기다리는 일을 만나면 그보다 먼저 넘깁니다.

time.sleep(0) 없이 count += 1만 400만 번 해 보면 어떨까요?

count = 0

def cook(times):
    global count
    for _ in range(times):
        count += 1

threads = [threading.Thread(target=cook, args=(1_000_000,)) for _ in range(4)]
for th in threads:
    th.start()
for th in threads:
    th.join()
print(count, sys._is_gil_enabled())
# Python 3.14:   4000000 True
# Python 3.14t:  예: 1127695 False  (실행할 때마다 다르다)

• 이 PC의 3.14(GIL 있음)에서는 여러 번 돌려도 4000000이 나왔습니다. 하지만 이건 우연히 스레드가 바뀌는 지점이 그 네 단계 사이에 오지 않았을 뿐입니다. 파이썬이 +=를 원자적(쪼개지지 않는 한 덩어리)으로 실행한다고 약속한 적은 없습니다. 버전이 바뀌거나 루프 안에 코드가 한 줄만 늘어도 깨질 수 있습니다.
• GIL이 없는 프리스레딩 빌드 3.14t에서는 스레드가 정말로 동시에 돌기 때문에 400만 중 100만 남짓만 남습니다. GIL 빌드에서 우연히 맞던 코드가 3.14t에서는 바로 틀립니다.
• 3-1의 칠판 코드는 3.14t에서 4000 중 예: 2410이 나왔습니다. 숫자는 달라도 틀리는 건 똑같습니다.
• 결론은 하나입니다. 여러 스레드가 같은 값을 고쳐 쓰면, GIL이 있든 없든 Lock으로 감싸세요. 3.14t로 옮겨 갈 코드라면 더욱 그렇습니다.

3-5. 같은 사람이 또 잠글 때: RLock (6분)

Lock은 누가 잡았는지 신경 쓰지 않습니다. 그래서 이미 분필을 쥔 사람이 분필을 또 집으려 하면, 자기가 내려놓기를 자기가 기다리며 영원히 멈춥니다. 진짜로 멈추면 곤란하니, 0.5초만 기다려 보겠습니다.

def probe(name, lock):
    with lock:                              # 한 번 잠그고
        start = time.perf_counter()
        ok = lock.acquire(timeout=0.5)      # 같은 스레드가 한 번 더
        waited = time.perf_counter() - start
        print(name, ok, f"{waited:.1f}s")
        if ok:
            lock.release()

probe("Lock", threading.Lock())
probe("RLock", threading.RLock())
# Lock False 0.5s
# RLock True 0.0s

• Lock은 0.5초를 꼬박 기다리고 False입니다. timeout이 없었다면 이 스레드는 여기서 영원히 멈췄을 것입니다.
• RLock(재진입 잠금, reentrant lock)은 잡은 스레드가 누구인지 기억합니다. 같은 스레드는 몇 번이든 다시 잡을 수 있고, 잡은 횟수만큼 풀어야 완전히 풀립니다. 다른 스레드는 평소처럼 기다립니다.

이런 일은 잠그는 메서드가 다른 잠그는 메서드를 부를 때 자주 생깁니다.

class Board:
    def __init__(self):
        self.lock = threading.RLock()
        self.count = 0

    def add(self):
        with self.lock:
            self.count += 1

    def add_table(self, dishes):
        with self.lock:             # 테이블 하나는 통째로
            for _ in range(dishes):
                self.add()          # 안에서 같은 잠금을 또 잡는다

board = Board()
threads = [threading.Thread(target=board.add_table, args=(250,)) for _ in range(4)]
for th in threads:
    th.start()
for th in threads:
    th.join()
print(board.count)
# 1000

self.lock이 Lock이었다면 add_table이 add를 부르는 순간 멈췄을 것입니다. RLock은 조금 더 무겁고, 잠금이 몇 겹인지 헷갈리게 만들기도 합니다. 설계를 바꿔 "잠그지 않는 내부 메서드"(_add)를 따로 두는 것도 좋은 방법입니다.

영업 마감 (10분)

오늘 밤의 목표는 요리사가 몇 명이든 칠판 숫자가 정확히 맞고, 주방은 느려지지 않는 것이었습니다. 칠판을 클래스로 만들고, 칠판을 고치는 줄만 잠급니다. 요리(time.sleep)는 잠금 밖에서 각자 합니다.

class Chalkboard:
    def __init__(self):
        self._lock = threading.Lock()
        self.count = 0

    def add(self, n=1):
        with self._lock:            # 칠판 앞에서만
            self.count += n

board = Chalkboard()

def cook(dishes):
    for _ in range(dishes):
        time.sleep(0.001)           # 요리는 잠금 밖에서
        board.add()

threads = [threading.Thread(target=cook, args=(100,)) for _ in range(4)]
start = time.perf_counter()
for th in threads:
    th.start()
for th in threads:
    th.join()
print(board.count, f"{time.perf_counter() - start:.2f}s")
# 예: 400 0.15s  (숫자는 늘 400, 시간은 대략)

• 요리사 넷이 100그릇씩, 칠판은 언제나 400입니다. 3.14t에서 돌려도 400입니다.
• 시간은 한 사람이 100그릇을 하는 시간(이 PC에서 약 0.11초)보다 조금 더 걸리는 정도입니다. 넷이 요리는 함께 하고, 칠판 앞에서만 잠깐씩 줄을 서기 때문입니다.
• 칠판(count)을 고치는 길은 add() 하나뿐입니다. 잠금을 클래스 안에 숨겨 두면, 누가 실수로 분필 없이 쓰는 일이 줄어듭니다.

셰프가 칠판을 지우고 400을 다시 적습니다. "칠판은 한 명씩이면 돼. 그런데 내일 화구는 셋이고 요리사는 여섯이야. 한 명씩만 들여보내면 화구 둘이 논다. 세 명까지 들여보내는 분필은 없을까?"

실습 과제

1. 칠판 실험에서 Lock을 끄고, 요리사 2명 × 2000번과 8명 × 500번을 비교해 보세요. 총 횟수는 4000으로 같은데 잃어버린 주문은 어느 쪽이 많나요? 왜 그럴까요?
2. 3-1의 코드에서 time.sleep(0)을 지우고 다시 돌려 보세요. 숫자가 맞게 나와도 왜 안전하다고 할 수 없는지 3-4를 근거로 설명해 보세요.
3. 3-5의 Board를 Lock으로 바꾸고, 잠그지 않는 내부 메서드 _add()를 두어 add()와 add_table()이 둘 다 멈추지 않게 고쳐 보세요.