| 关注 @jessejiryudavis
纽约
我是纽约市 MongoDB 的一名 Staff Engineer。我编写了 Motor，即异步 MongoDB Python 驱动程序，并且我是 MongoDB C 驱动程序的首席开发人员。我为 PyMongo、asyncio、Python 和 Tornado 做出贡献。我在国际摄影中心学习，并在 Village Zendo 练习。
A. Jesse
我是纽约市 MongoDB 的一名 Staff Engineer。我编写了 Motor，即异步 MongoDB Python 驱动程序，并且我是 MongoDB C 驱动程序的首席开发人员。我为 PyMongo、asyncio、Python 和 Tornado 做出贡献。我在国际摄影中心学习，并在 Village Zendo 练习。
发表的评论
您好！没有什么可以阻止线程在持有锁时抢先释放 GIL。我们称之为线程 A，假设还有线程 B。如果线程 A 持有锁并被抢占，那么线程 B 可能会代替线程 A 运行。
如果线程 B 正在等待线程 A 持有的锁，那么线程 B *不是* 在等待 GIL。在这种情况下，线程 A 在释放 GIL 后立即重新获取 GIL，线程 A 继续运行。
如果线程 B 没有等待线程 A 持有的锁，那么线程 B 可能会获取 GIL 并运行。
然而，我关于粗粒度锁的观点是：由于 GIL 的存在，任何两个线程都永远无法并行执行 Python。因此，使用细粒度锁并不能提高吞吐量。这与 Java 或 C 等语言形成对比，在 Java 或 C 等语言中，细粒度锁允许更高的并行性，从而更高的吞吐量。
嗨 Louie，是的，请翻译它！
我选择 2.7 是因为它对 GIL 的实现更简单，并且更容易理解 Python 3 的实现。我没有计划更改示例。