## What is a GIL (Global Interpreter Lock)

As the name suggests, the Global Interpreter Lock (GIL) is an interpreter-level mutually exclusive lock. What does that mean 😬? It means that in a Python process, only one thread can execute Python bytecode at any given time. In other words, two threads cannot execute Python code simultaneously within the same process.

So, if the GIL is an interpreter-level lock, can we say that we’ll never face race conditions in a multithreading environment 🤔? As GIL is taking care of and not letting more than one thread run at the same time. The answer is no. Refer to the following code for an explanation.

import threading
counter = 0

def increment_counter():
global counter
for _ in range(1_00_000):
counter += 1


thread1 = threading.Thread(target=increment_counter)
thread2 = threading.Thread(target=increment_counter)

thread1.start()
thread2.start()

thread1.join()
thread2.join()

print(f"Counter value: {counter}")

In the above code, even though the GIL exists, the program may still experience race conditions. If you run the script multiple times, you may get the correct value mostly, but not always. The reason is that the statement counter += 1 is not an atomic operation at the interpreter level 🪢.

Internally, this single line translates into three operations:

1. Retrieve the current value of the counter variable.
2. Increment that value by 1.
3. Store the updated value back into the counter variable.

If the Python interpreter decides to perform a context switch between these operations, both threads might read the same counter value before either one writes it back. As a result, both threads “increment” the same original value, effectively losing one increment — a classic race condition 😟.

So how can we make this code thread-safe and avoid the race condition? The solution is to use an explicit lock provided by the threading library. Refer to the updated code below.

import threading
counter = 0

lock = threading.Lock()

def increment_counter():
global counter
for _ in range(1_00_000):
with lock:
counter += 1


thread1 = threading.Thread(target=increment_counter)
thread2 = threading.Thread(target=increment_counter)

thread1.start()
thread2.start()

thread1.join()
thread2.join()

print(f"Counter value: {counter}")

In the updated code, we use a Lock and acquire it before modifying the shared counter variable. The with lock: statement ensures that only one thread updates the counter at a time. This eliminates the race condition, although it introduces some overhead due to acquiring and releasing the lock for each iteration. The code becomes slightly slower, but much safer 😌.

Feel free to ask any related queries, and Happy Coding 🐍