[Python-Dev] More on Perl threads

Dan Sugalski dan@sidhe.org
Wed, 15 Aug 2001 18:52:47 -0400


At 01:08 AM 8/14/2001 -0700, Paul Prescod wrote:
>The idea is that there is a function called "share" that you use to
>share a value. Once you do so, the Perl interpreter builds a transparent
>proxy that ensures that it is handled in a thread-safe way. Thus you
>incur a performance price for only the variables you share. On the other
>hand, that price sounds much higher than the price of sharing things
>using the global interpreter lock (both in performance and coding
>complexity). Therefore it is not a good replacement for the GIL but
>perhaps a good alternative for those who need multiprocessor
>performance.

If your interpreters are otherwise disconnected, the proxy lock performance 
will be better than a GIL, if for no other reason then you won't have to 
get locks nearly so often. Other than that there's not much overhead--at 
most a dereference and a mutex get and release. That's not bad. It 
definitely makes a difference on SMP systems to be able to run multiple 
threads simultaneously.

>Here's an interesting late-night idea of mine...could shareability be
>contagious? If you followed a reference from a shared object to an
>"ordinary" object in a different thread, the interpreter could build the
>proxy for you.

Yeah, but you then run the risk of the sharing contagion spreading pretty 
wildly. That risk is probably lower in Python than it is in Perl, though. 
(Store a reference to an interpreter's global symbol table into a shared 
variable and watch the sharing run rampant)

Been there, done that, backed slowly away with my hands in full view. :)


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk