[Python] Global Interpreter Lock(GIL)은 왜 도입됐고, 어떤 특징이 있나요?

Global Interpreter Lock(GIL)?

GIL은 문자 그대로 인터프리터에 대한 Lock이다.

Lock은 인터프리터가 여러 스레드를 병렬적으로(Parallel) 실행하지 않도록 막는다.

 

파이썬엔 GIL이 있기 때문에, 인터프리터가 매 순간 1개의 쓰레드만 실행할 수 있다.

결국 파이썬의 멀티 스레딩은 병렬적(Parallel)으로 실행되는 대신, 동시적으로(Concurrent) 실행된다.

Python의 멀티 스레딩 : GIL에 의해 Concurrent 함

이때 여러 스레드 중 실행 될 1개의 스레드를 정하려면, 스레드 스케줄러가 필요하다.

하지만 파이썬은 자체적인 스케줄러가 없어서, OS의 스레드 스케줄링을 그대로 활용한다.

 

그래서 I/O Block이 발생할 경우 GIL도 마찬가지로 Release된다. 따라서 I/O Bound 작업의 경우, 멀티 스레딩으로 병렬 처리(Parallel)는 못해도 동시적(Concurrent)으로는 처리할 수 있다.

 

왜 도입?

GIL의 설명을 보면 뭔가 불편해보이고, 굉장히 이상해보인다.

'스레드 여러 개 그냥 동시에 쓰면 안되나?'라는 생각도 든다.

Thread : 메모리 영역(Heap, Static, Code)을 공유한다.

파이썬이 GIL를 도입한 이유는 멀티 스레드 환경에서 발생할 수 있는 Race Condition(경쟁 상태)를 방지하기 위함이다. 그래서 GIL을 경쟁 상태를 방지하기 위해 도입된 Lock이라고 생각하면 된다.

 

다른 언어에도 발생할 수 있는 스레드 경쟁 상태를, 인터프리터를 Lock 할 정도로 극단적으로 처리하는 이유는, 파이썬의 메모리 관리 방법 때문이다.

 

파이썬은 Reference Counting(RC)을 통해 자동으로 메모리를 관리한다.

Java 자료지만 RC 역할 자체는 동일하니 참고!

RC는 객체를 참조하는 것이 아무 것도 없는 경우, 자동으로 객체의 메모리 할당을 해제한다.

자동화가 가능한 이유는 파이썬의 모든 것이 객체(Heap 영역의 객체를 참조하는 것)이기 때문이다.

이러한 RC는 메모리 영역이 공유되지 않는 경우엔 잘 동작한다.

 

하지만 메모리 영역이 공유되는 멀티 스레딩 환경에선, 자원(객체)을 동시에 접근하는 경쟁 상태가 발생할 수 밖에 없다. 이 경우 당연하게도 RC 실행에 문제가 생긴다. 삭제 돼야 할 객체가 그대로 있을 수도, 있어야 할 객체가 없어질 수도 있는 그런 혼란스러운 상황이 발생한다.

 

문제를 방지하려면, 자원 공유가 불가능 하도록 Mutex(뮤텍스)와 같은 Lock을 도입해야 한다.

하지만 파이썬의 모든 것은 객체(Heap 영역이라 공유 됨)이기에, 모두 Lock 하여 관리하는 것은 굉장히 비효율적이다. 그래서 파이썬은 객체 단위 Lock 대신, 인터프리터 단위 Lock을 도입했고 그것이 바로 GIL이다. 

 

GIL 우회?

C/C ++ extentions는 GIL과 상관 없이 동작될 수 있다.

GIL은 파이썬 인터프리터 단위의 Lock 이다.

그래서 만약 인터프리터에만 안 걸리면(?) 스레드를 잠시 동안 병렬적(Parallel)으로 활용할 수 있다.

파이썬의 작업 속도를 올리기 위해 활용되는 C/C++ extentions 들이 이러한 특성을 활용한다.

 

하지만 extentions도 영원히 병렬적(Parallel)으로 실행될 수는 없다.

파이썬 객체나 인터프리터와 관련된 작업들을 수행하는 순간 다시 GIL에 묶이게 된다.

그래서 extentions의 실행 과정은 GIL을 우회하고, 또 GIL에 묶이고 하는 과정의 반복이다.

---

참고

Understanding the Python GIL

• 좋은 내용이 많다. 엄청난 파이썬 고수이다.

[Python] GIL (Global Interpreter Lock) 이해하기

• 한글로 작성된 자료 중엔 제일 이해하기 쉽게 작성 됐다고 느꼈다.