GIL with dict

Java HashMap, HashTable, ConcurrentHashMap 을 찾아보다가 간단히 정리

Java의 HashMap & Python dict

Java에서 HashMap의 대표적인 특성은 두 가지로 요약됨.

1. synchronized 처리가 안 된다 → 멀티스레드 환경에서 thread-safe 하지 않음.
2. key와 value에 null을 허용됨

Python의 dict 역시 이 두 특성과 매우 유사하다.

• 파이썬의 dict도 key/value에 None을 자유롭게 넣을 수 있음
• 멀티스레드 환경에서 안정성을 보장하지 않는다.(안전하게 쓰고 싶으면 직접 Lock을 써야 한다.)

이때 다음과 같은 질문이 나올 수 있다.

 

“파이썬에는 GIL이 있는데, 멀티스레드 안정성 문제는 의미 없는 거 아닌가?”

결론부터 말하면 아니다.
GIL은 thread-safe를 보장하지 않는다.

 

GIL이 하는 일

GIL(Global Interpreter Lock)은 다음 한 가지를 보장한다.

→ 한 순간에 하나의 스레드만 Python 바이트코드를 실행한다.

→ bytecode 들이 atomic 하지 않다면 thread-safe 에서 문제가 생긴다는 뜻

 

import threading

d = {"count": 0}

def worker():
    for _ in range(5000):
        d["count"] += 1  

threads = [threading.Thread(target=worker) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()

print(d["count"])

 

이거를 실행시키면 20000이 나오질 못한다.

왜냐하면 d["count"]+=1 의 바이트코드가 다음과 같기 때문이다. (CPython기준)

LOAD d["count"]
BINARY_ADD
STORE d["count"]

 

읽기 -> 더하기 -> 저장하는 3개의 별도 동작하게 된다. 

중간에 GIL이 다른 스레드한테 넘어가면 바로 원자성이 깨지는 그런 구조 (=lost update)

 

실제로 dis 로 더 자세히 확인해보자

import dis

def f():
    d["count"] += 1

dis.dis(f)

 

  3           0 RESUME                   0

  4           2 LOAD_GLOBAL              0 (d)
             12 LOAD_CONST               1 ('count')
             14 COPY                     2
             16 COPY                     2
             18 BINARY_SUBSCR
             22 LOAD_CONST               2 (1)
             24 BINARY_OP               13 (+=)
             28 SWAP                     3
             30 SWAP                     2
             32 STORE_SUBSCR
             36 RETURN_CONST             0 (None)

 

이걸 고치려면? 그때 threading.Lock 을 with 구문과 함께 쓰면 된다

import threading

d = {"count": 0}
lock = threading.Lock()

def worker():
    for _ in range(5000):
        with lock:
            d["count"] += 1