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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4