Re: Another multithreading bug (I think)

[Wim Oudshoorn]

Richard Frith-Macdonald <richard@tiptree.demon.co.uk> writes:

> I've committed a change which moves the call to -gcFinalise into - 
> dealloc and replaces the implementation of -release with:
>
> {
>    M_LOCK(connection_table_gate);
>    if (NSDecrementExtraRefCountWasZero(self))
>      {
>        NSHashRemove(connection_table, self);
>        M_UNLOCK(connection_table_gate);
>        [self dealloc];
>      }
>    else
>      {
>        M_UNLOCK(connection_table_gate);
>      }
> }

I have tested this fix and it seems to work well.
I also understand now why my quick fix did not work.  
The reason is that I introduced, naively, a new lock to guard the whole 
release/dealloc
sequence.   This will not work.

It should happen as above, the decrementing and testing of the refcount and 
removal
from the hashtable should happen together inside a region locked by the 
connection_table_gate.

Oh and the lock should be recursive, as I mentioned before.  Because there are 
calls to the
delegate in protected regions, and preventing release being called in the 
delegate 
(even on another connection) is a little bit harsh.

Next week, debugging the next annoying multithreading bug :-(

Wim Oudshoorn