| Follow @jessejiryudavis
New York
I’m a staff engineer at MongoDB in New York City. I wrote Motor, the async MongoDB Python driver, and I’m the lead developer of the MongoDB C Driver. I contribute to PyMongo, asyncio, Python and Tornado. I study at the International Center for Photography and practice at the Village Zendo.
Authored Comments
Hi! Nothing prevents a thread from preemptively dropping the GIL while it holds a lock. Let's call that Thread A, and let's say there's also a Thread B. If Thread A holds a lock and gets preempted, then maybe Thread B could run instead of Thread A.
If Thread B is waiting for the lock that Thread A is holding, then Thread B is *not* waiting for the GIL. In that case Thread A reacquires the GIL immediately after dropping it, and Thread A continues.
If Thread B is not waiting for the lock that Thread A is holding, then Thread B might acquire the GIL and run.
My point about coarse locks, however, is this: no two threads can ever execute Python in parallel, because of the GIL. So using fine-grained locks doesn't improve throughput. This is in contrast to a language like Java or C, where fine-grained locks allow greater parallelism, and therefore greater throughput.
Hi Louie, yes, please do translate it!
I chose 2.7 because its implementation of the GIL is simpler and easier to understand the Python 3's. I have no plan to change the example.