robert <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
