所以我正在阅读这篇文章,试图从Python解释器中删除全局解释器锁(GIL)以提高多线程性能并看到一些有趣的东西.
事实证明,删除GIL实际上使事情变得更糟的地方之一是内存管理:
使用自由线程,引用计数操作会失去线程安全性.因此,补丁引入了全局引用计数互斥锁以及用于更新计数的原子操作.在Unix上,使用标准的pthread_mutex_t锁(包含在PyMutex结构中)和以下函数实现锁定......
...在Unix上,必须强调的是,简单的引用计数操作已经被不少于三个函数调用替换,加上实际锁定的开销.它的价格要贵得多......
...显然细粒度的引用计数锁定是性能不佳的主要原因,但即使你取消锁定,引用计数性能仍然对任何类型的额外开销(例如,函数调用等)非常敏感. ).在这种情况下,性能仍然是使用GIL的Python的两倍.
然后:
引用计数是一种用于自由线程的非常糟糕的内存管理技术.这已经广为人知,但性能数据更加具体.对于任何尝试使用GIL删除补丁的人来说,这肯定是最具挑战性的问题.
所以问题是,如果引用计数对于线程来说太糟糕了,Objective-C如何做呢？我编写了多线程的Objective-C应用程序,并没有注意到内存管理的大量开销.他们在做别的吗？像某种每个对象锁而不是全局锁？Objective-C的引用计数在线程上实际上在技术上是不安全的吗？我不是一个真正推测的并发专家,但我有兴趣知道.
performance multithreading memory-management reference-counting objective-c