3 ms·
It's a great idea and in fact a variation of it is being explored by Python to eliminate the use of the GIL without introducing performance regressions. The va
by Kranar 5y ago
It's a great idea and in fact a variation of it is being explored by Python to eliminate the use of the GIL without introducing performance regressions.
The variation is instead of one count per thread, have two reference counts where one is atomic and the other is not atomic. The heuristic is that at any given time, the majority of writes are performed within a single thread and so that thread has exclusive read/write access to the non-atomic reference count, all other threads share the atomic reference count. There is some work needed to coordinate the atomic and non-atomic reference count so as to test when an object can be deleted, but the overhead of this work is less than the cost of always using an atomic.
http://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf http://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf
- dan-robertson 5y agoIn the case of the original article, the reference count was being updated by all the threads so having an Arc-with-Rc-for-one-thread wouldn’t actually change things, I think. But maybe you just mean for ‘cheaper smart-pointers in general’? The python thing is interesting. I thought there were other reasons for the GIL than ref counts but I guess everything must be addressed.
- Kranar 5y agoYep in this case it might not have helped, but all this to say that some exploration of having multiple reference counts is a great idea. The balance becomes the overhead of coordinating multiple reference counts versus the gains from reduced atomic operations.