[ANNOUNCE] Garbage collection for Python

[Gordon McMillan]

Bjorn Pettersen wrote:

> Helge Hess wrote:

> > Also note that not only the ++ or -- needs to be protected, but the
> > '==0' check as well. Eg:
> > 
> >    [task1]            [task2]
> >    dec(obj);          inc(obj);
> 
> Note that both task 1 and task two must have a reference to the object
> for this to be possible, so the ref count must at least be two. (unless
> you're thinking of sharing names between tasks without locking -- that
> would make rc much more resource intensive...)
> 
> > could be
> >    [task1]            [task2]
> >    obj->rc--;
> >    if (obj->rc==0)
> >      <task-switch>    obj->rc++;
> >      free(obj);       <task-switch>
> >    object-freed       assumes to have a valid obj
> 
> If the reference count was one, adding mutexes wouldn't help:
> 
>     aquire(obj->mutex)
>     obj->rc--;
>     if (obj->rc==0)
>       free(obj);   
>     release(obj->mutex)
> 
>                          aquire(obj->mutex)  // does it crash here
>                          obj->rc++           // or here?

The release would, except the entire scenario is hopelessly 
flawed (how does task2 get ahold of "obj" without either 
holding the lock or having the ref count already increased?).

[interlocked increment & friends]
> The api calls are direct wrappers around the processors
> increment-and-test or test-and-set instructions, and are extremely fast
> compared to a mutex solution (which makes it interesting to see other
> people on this thread claim that it would be _way_ to slow without even
> testing it...).  Our tests showed an order of magnitude difference on
> some tests...

The lightest weight synchronization primitives known to man. 
But a still a whole lot bulkier than a simple increment.

- Gordon