On Fri, Feb 10, 2012 at 9:52 AM, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
The GC vs reference counting (RC) is the hearth of the matter. With RC every time a variable is allocated or deallocated you need to lock the counter
uh... if you need to lock it for allocation, that is an issue with the malloc, rather than refcounting. And if you need to lock it for deallocation, then your program already has a (possibly threading-race-condition-related) bug. The problem is that you need to lock the memory for writing every time you acquire or release a view of the object, even if you won't be modifying the object. (And this changing of the refcount makes copy-on-write copy too much.) There are plenty of ways around that, mostly by using thread-local (or process-local or machine-local) proxies; the original object only gets one incref/decref from each remote thread; if sharable objects are delegated to a memory-controller thread, even better. Once you have the infrastructure for this, you could also more easily support "permanent" objects like None. The catch is that the overhead of having the refcount+pointer (even without the proxies) instead of just "refcount 4 bytes ahead" turns out to be pretty high, so those forks (and extensions, if I remember pyro http://irmen.home.xs4all.nl/pyro/ correctly) never really caught on. Maybe that will change when the number of cores that aren't already in use for other processes really does skyrocket. -jJ