I'm not sure I understand entirely what you're saying, but it sounds like
you want multiple reference counts. A reference count per thread might not
be a bad idea, but I can't think of how it would work without locks. If
every object has an array of reference counts, then the GC would need to
lock that array to check to see if they're all 0. That means the
incref/decref operations would need to acquire this lock or risk messing up
the GC.
Perhaps you could have something where you have a reference count per thread
and then a thread count per object. Then you would only need to lock the
thread count for the first and last reference a thread makes to an object.
Once there are no threads referencing and object, its obviously safe for
cleanup. Of course, I'm not convinced atomic ops are really so expensive you
can't have every thread doing it at once, but Adam says that the caches will
be thrashed if we have a bunch of threads continuously updating the same
memory address. I can see the possibility. Perhaps once we have a version
that actually demonstrates this thrashing, we can alleviate it with some
sort of multiple reference count scheme.
Justin
On 9/13/07, Tennessee Leeuwenburg <[EMAIL PROTECTED]> wrote:
>
> Pardon me for talking with no experience in such matters, but...
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> -Tennessee
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/tulloss2%40uiuc.edu
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
