방금 해커 뉴스에 this section of Unladen Swallow's documentation이 표시되었습니다. 기본적으로 Google 엔지니어는 GIL 제거에 대해 낙관하지 않는다고 말합니다. 그러나 GIL에 관한이 이야기에 산재 해있는 가비지 컬렉터에 대한 논의가있는 것처럼 보입니다. 누군가 나에 대한 관계를 설명 할 수 있을까요?파이썬의 GIL은 가비지 컬렉터와 어떤 관련이 있습니까?
정말 짧은 버전은 현재 참조 계산 + 표시 & 스위프 사이클 수집기 스키마 (처리량 대신)에 최적화 된 메모리를 관리한다는 것입니다.
이것은 하나의 돌연변이 스레드 만있는 경우 모두 괜찮지 만 멀티 스레드 시스템에서는 refcounts를 수정하는 모든 시간을 동기화해야합니다. 그렇지 않으면 값이 "균열을 넘어"있습니다. 동기화 프리미티브는 현대 하드웨어에서 상당히 비쌉니다.
refcounts가 자주 변경되지 않으면 문제가되지 않지만 cpython에서 수행하는 거의 모든 작업이 refcount를 어딘가에서 변경할 수 있으므로 옵션은 GIL, 일부는 refcounts 일종의 동기화 (그리고 문자 그대로 동기화에 거의 모든 시간을 보냅니다), 또는 실제 가비지 컬렉터의 일종에 대한 참조 계산 시스템을 버리십시오.
참치 물고기의 대답은 기본적으로 그것을 다룹니다. http://mail.python.org/pipermail/python-ideas/2009-October/006264.html
해당 링크의 제안은 순진합니다. 참조 카운팅을 위해 비교 및 교체를 사용하는 것이 너무 느립니다. –
난 그냥 여기에이 주제에 다른 관점을 발견 : 당신이 더 많은 정보를 원하는 경우, GIL 너무 기준에 많은 효과을 을 가지고 여기에 계산하지 않고 제거 할 수있는 방법에 대한 논의가 있었다 http://renesd.blogspot.com/2009/12/python-gil-unladen-swallow-reference.html
글쎄, GIL에 대해 읽어보십시오. http://wiki.python.org/moin/GlobalInterpreterLock 보시다시피이 모든 것은 메모리 관리에 관한 것입니다. –