Global Interpreter Lock ( GIL ) este o metodă de sincronizare a firelor de execuție utilizată în unele limbaje de programare interpretate , cum ar fi Python și Ruby .
GIL este cel mai simplu mod de a evita conflictele atunci când fire diferite accesează aceeași memorie în același timp [1] . Când un fir îl apucă, GIL, acționând ca un mutex , le blochează pe celelalte. Fără fire paralele - fără conflicte la accesarea obiectelor partajate. Ordinea de execuție a firelor de execuție este determinată de interpret în funcție de implementare, poate apărea comutarea între fire de execuție: atunci când un fir activ încearcă să efectueze I/O , după ce limita de instrucțiuni executate a fost epuizată , sau de un timer [2] .
Principalul dezavantaj al abordării GIL thread -safe este limitarea paralelismului . GIL nu permite obținerea celei mai mari eficiențe de calcul atunci când se lucrează pe sisteme multi-core și multi -procesor [3] . De asemenea, utilizarea mai multor fire de execuție impune o suprasarcină la comutarea lor datorită efectului de dispută (firele „încearcă” să intercepteze GIL-ul). Adică, execuția multi-threaded poate dura mai mult decât execuția secvențială a acelorași sarcini [4] .
Motive pentru a utiliza GIL:
GIL este folosit în CPython , cea mai comună implementare a interpretului Python [5] , iar în Ruby MRI , implementarea de referință a interpretului Ruby , unde se numește Global VM Lock .
Pe net au apărut de mai multe ori petiții și scrisori deschise care le ceru să elimine GIL-ul din Python [6] . Cu toate acestea, creatorul și „ dictatorul generos pe viață ” al proiectului, Guido van Rossum , afirmă că GIL nu este atât de rău și va fi în CPython până când altcineva va introduce o implementare Python fără GIL, cu care scripturile cu un singur thread au funcționat doar la fel de repede [7] [8] .
Implementările interpretului JVM ( Jython , JRuby ) și .NET ( IronPython , IronRuby ) nu folosesc GIL [9] [10] .
Ca parte a proiectului PyPy , se lucrează la implementarea memoriei tranzacționale ( English Software Transactional Memory, STM ). Pentru moment[ ce? ] chiar și în calculele cu mai multe fire, interpretul cu STM funcționează de multe ori mai lent decât cu GIL. Dar datorită JIT , PyPy-STM [11] este încă mai rapid decât CPython [12] .