Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

[Paul Rubin]

robert <no-spam at no-spam-no-spam.invalid> writes:
> > I don't want to discourage you but what about reference
> > counting/memory
> > management for shared objects? Doesn't seem fun for me.
> 
> in combination with some simple locking (anyway necessary) I don't
> see a problem in ref-counting.
> If at least any interpreter branch has a pointer to the (root)
> object in question the ref-count is >0. ----
> Question Besides: do concurrent INC/DEC machine OP-commands execute
> atomically on Multi-Cores as they do in Single-Core threads?

Generally speaking, no, the inc/dec instructions are not atomic.  You
can do an atomic increment on the x86 using LOCK XCHG (or maybe LOCK
INC is possible).  The thing is that the locking protocol that
guarantees atomicity is very expensive, like 100x as expensive as an
unlocked instruction on a big multiprocessor.  So yes, of course you
could accomplish reference counting through locks around the ref
counts, but performance suffers terribly.  The solution is to get rid
of the ref counts and manage the entire heap using garbage collection.

For stuff like dictionary access, there are protocols (again based on
LOCK XCHG) that don't require locking for lookups.  Only updates
require locking.  Simon Peyton-Jones has a good paper about how it's
done in Concurrent Haskell:

  http://research.microsoft.com/~simonpj/papers/stm/stm.pdf

This is really cool stuff and has found its way into Perl 6.  I'd like
to see Python get something like it.