[Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

Ronald Oussoren ronaldoussoren at mac.com
Wed Jul 18 03:21:31 EDT 2018


Op 18 jul. 2018 om 08:02 heeft Barry <barry at barrys-emacs.org> het volgende geschreven:

> 
> 
>>> On 17 Jul 2018, at 21:00, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>>> 
>>> On Tue, Jul 17, 2018 at 1:44 PM Barry <barry at barrys-emacs.org> 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.
> 
> All processors have thread safe ways to inc and dec and test, integers without holding a lock.
> 
> That is the mechanism that locks themselves are built out of. You can use that to avoid holding the GIL until the ref count reaches 0.
> 
> In c++ they built it into the language with std::atomic_int, you would have to find the way to do this C, i don’t have an answer at my finger tips for C.
> 
 Some past attempts at getting rid of the GIL used atomic inc/dec, and that resulted in bad performance because these instructions  aren’t cheap. 

My gut feeling is that you’d have to get rid of refcounts to get high performance when getting rid of the GIL in a single interpreter, which would almost certainly result in breaking the C API.  

Ronald
> Barry
> 
>> 
>>> 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.
>> 
>> -eric
>> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list