Global Interpreter Lock ( GIL ) är en trådsynkroniseringsmetod som används i vissa tolkade programmeringsspråk , som Python och Ruby .
GIL är det enklaste sättet att undvika konflikter när olika trådar kommer åt samma minne samtidigt [1] . När en tråd tar tag i den, blockerar GIL, som fungerar som en mutex , de andra. Inga parallella trådar - inga konflikter vid åtkomst till delade objekt. Ordningen för exekvering av trådar bestäms av tolken beroende på implementeringen, växling mellan trådar kan ske: när en aktiv tråd försöker utföra I/O , efter att gränsen för utförda instruktioner har förbrukats , eller av en timer [2] .
Den största nackdelen med GIL - trådssäkra tillvägagångssätt är begränsningen av parallellism . GIL tillåter inte att uppnå den största beräkningseffektiviteten när man arbetar på system med flera kärnor och flera processorer [3] . Användningen av flera trådar medför också overhead på deras växling på grund av effekten av konflikt (trådar "försöker" att fånga upp GIL). Det vill säga, multitrådad exekvering kan ta längre tid än sekventiell exekvering av samma uppgifter [4] .
Skäl att använda GIL:
GIL används i CPython , den vanligaste implementeringen av Python- tolken [5] , och i Ruby MRI , referensimplementeringen av Ruby -tolken , där den kallas Global VM Lock .
Framställningar och öppna brev har dykt upp på nätet mer än en gång och bett dem att ta bort GIL från Python [6] . Men skaparen och den " generösa livslånga diktatorn " av projektet, Guido van Rossum , säger att GIL inte är så dåligt och kommer att finnas i CPython tills någon annan introducerar en Python-implementation utan GIL, med vilken enkeltrådade skript fungerade precis lika snabbt [7] [8] .
JVM ( Jython , JRuby ) och .NET ( IronPython , IronRuby ) tolkimplementeringarna använder inte GIL [9] [10] .
Som en del av PyPy- projektet pågår arbete med att implementera transaktionsminne ( engelsk Software Transactional Memory, STM ). Just nu[ vad? ] även vid flertrådiga beräkningar arbetar tolken med STM många gånger långsammare än med GIL. Men på grund av JIT är PyPy-STM [11] fortfarande snabbare än CPython [12] .