Pardon me for talking with no experience in such matters, but...<br><br>Okay, incrementing a reference counter is atomic, therefore the cheapest possible operation. Is it possible to keep reference counting atomic in a multi-thread model?
<br><br>Could you do the following... let's consider two threads, "A" and "B". Each time an object is created, a reference count is created in both "A" and "B". Let's suppose "A" has a real reference and "B" has no reference really. Couldn't the GC check two reference registers for a reference count? The object would then be cleaned up only if both registers were 0.
<br><br>To exploit multiple CPUs, you could have two persistent Python processes on each CPU with its own mini-GIL. Object creation would then involve a call to each process to create the reference and GC would involve checking each process to see what their count is. However, it would mean that within each process, threads could create additional references or remove references in an atomic way.
<br><br>In a single-CPU system, this would be the same cost as currently, since I think that situation would devolve to having just one place to check for references. This seems to mean that it is the case that it would be no more expensive for a single-CPU system.
<br><br>In a two-CPU system, I'm no expertise on the actual call overheads of object creation and garbage collection, but logically it would double the effort of object creation and destruction (all such operations now need to occur on both processes) but would keep reference increments and decrements atomic.
<br><br>Once again, I'm really sorry if I'm completely off-base since I have never done any actual coding in this area, but I thought I'd make the suggestion just in case it happened to have relevance.<br><br>
Thanks,<br>-Tennessee<br>