---
title: "Story About the Python GIL - its existance and the lack there of - Cheuk Ting Ho"
tags: PyConTW2025, 2025-organize, 2025-共筆
---

# Story About the Python GIL - its existance and the lack there of - Cheuk Ting Ho

{%hackmd L_RLmFdeSD--CldirtUhCw %}

<iframe src=https://app.sli.do/event/arRM45hH2fFrk1YocTsXoB height=450 width=100%></iframe>

:::success
本演講提供 AI 翻譯字幕及摘要，請點選這裡前往 >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=HTVMyWibomme3MrkhD7a)
AI translation subtitles and summaries are available for this talk. Click here to access >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=HTVMyWibomme3MrkhD7a)
:::

> Collaborative writing start from below
> 從這裡開始共筆

## Why Python is "SLOW"
:::info
**Concurrency**
Doing multiple tasks ==seemingly== at the ==same== time.
:::
- Misunderstanind in "Concurrency"
- 2 types of issues:
- I/O bound
- We use `asyncio` and `threading`
- appear concurrent (But not really concurrent)
- considering who is in charge
- true multithreading without the GIL
- CPU bound
- Use `multiprocessing`
- ture concurrency
- side-stepping the GIL
- Each process has its own independent Python interpreter
- Each process has its own GIL
- Different processes can truly execute in parallel on different CPU cores
- issue when sharing data among processes

## GIL
### What
- ensures that data can only be accessed by one thread at a time
- Kind of a lock
- a simple solution for **race condition**

### Why do we use GIL
- Python is old, design when most PCs only had one core
- simplify implementations, no need to consider race condition, memory accessing, easier garbage collection

### Why remove
- Community wants faster execution and ==true concurrency==

## Challenges
- Reference counting
- We assume there's no race conditions with GIL
- non-atomic reference counting does not guarantee thread safety
- atomic reference counting suggers from high overhead
- use biased reference counting, a mixture of both
- Garbage Collection
- The mechanism to collect unused (reference conuting = 0) objects
- Memory allocation
- Current memory allocator assumes GIL protection, not thread-safe
- A new memory allocator is required: faster read access to list and dict
- Compatibility

## Takeaways
- We kind of know python is an OK language
- Fast in terms of implementation, slow in terms of execution / performance

## Atomic reference counting vs. non-atomic reference counting
### Non-atomic reference counting
- Not thread-safe

refcount++;  
// takes 3 steps
// 1. read value refcount
// 2. add 1
// 3. write value refcount

### Atomic reference counting
- Thread-safe
- 10x-100x Slower

// Not able to be interrupted
atomic_increment(&refcount);

### Bias reference counting
Check if the counting only belongs to one thread,
if so, use non-atomic reference counting,
otherwise, use atomic reference counting

## Reference Links
- https://peps.python.org/pep-0703/
- https://cheuk.dev

Below is the part that speaker updated the talk/tutorial after speech
講者於演講後有更新或勘誤投影片的部份