(original) (raw)
On 9/13/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
If you look at the article, they have a code sample.
Basically a
global is "owned" by the first thread that touches it. That thread can
do whatever it wants with that global. If another thread wants to touch
the global, it locks everything to do so.
This is a pretty good idea except that in Python there are so
many globals that all threads benefit from having access to. Luckily,
except for their reference counts, they're mostly read-only. Therefore,
if we can work out this reference count, we can probably use a similar
concept.
Justin
Jason Orendorff wrote:
> The clever bit is that SpiderMonkey's per-object
> locking does *not* require a context switch or even an atomic
> instruction, in the usual case where an object is *not* shared among
> threads.
How does it tell whether an object is shared between
threads? That sounds like the really clever bit to me.
If you look at the article, they have a code sample.
Basically a
global is "owned" by the first thread that touches it. That thread can
do whatever it wants with that global. If another thread wants to touch
the global, it locks everything to do so.
This is a pretty good idea except that in Python there are so
many globals that all threads benefit from having access to. Luckily,
except for their reference counts, they're mostly read-only. Therefore,
if we can work out this reference count, we can probably use a similar
concept.
Justin