On 17 Jul 2018, at 21:00, Eric Snow
wrote: On Tue, Jul 17, 2018 at 1:44 PM Barry
wrote: The decrement itself is not the problem, that can be made thread safe.
Yeah, by using the GIL. <wink> Otherwise, please elaborate. My understanding is that if the decrement itself were not the problem then we'd have gotten rid of the GIL already.
Let me try a longer answer. The inc+test and dec+test do not require a lock if coded correctly. All OS and run times have solved this to provide locks. All processors provide the instructions that are the building blocks for lock primitives. You cannot mutate a mutable python object that is not protected with the GIL as the change of state involves multiple parts of the object changing. If you know that an object is immutable then you could only do a check on the ref count as you will never change the state of the object beyond its ref count. To access the object you only have to ensure it will not be deleted, which the ref count guarantees. The delete of the immutable object is then the only job that the original interpreter must do.
Do you mean that once the ref reaches 0 you have to make the delete happen on the original interpreter?
Yep. For one thing, GC can trigger __del__, which can do anything, including modifying other objects from the original interpreter (incl. decref'ing them). __del__ should be run under the original interpreter. For another thing, during GC containers often decref their items. Also, separating the GIL between interpreters may mean we'll need an allocator per interpreter. In that case the deallocation must happen relative to the interpreter where the object was allocated.
Yep that I understand. Barry
-eric