Re: Multithreading

[Wim Oudshoorn]

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

>> There are a few ways out of this:
>>
>> 1 - Ignore the problem.  Because it is quite unlikely to happen
>> 2 - Unlearn the AUTORELEASE (RETAIN ()) trick and put locks
>>     around all getters and setters which need to be thread safe.
>> 3 - Change the DecRef and IncRef count is such a way that
>>     the refcount will be -1 just before deallocating
>>     and let retain return nil if the refcount is -1.
>> 4 - the same as above, but let RETAIN throw an exception.
>>
>> Any thoughts?
>
> Ah ... I thought it was well known that the AUTORELEASE (RETAIN ())
> sequence was not thread safe ... as I recall it being discussed on
> mailing lists (not sure whether it was on gnustep, apple or objc
> lists) some years ago.
>
> This is not simply because of the gap between  decrementing the
> reference count and deallocating, but also because the ASSIGN() and
> RETAIN() are not atomic.

Yes, I realized this after sending my e-mail.  Also, somewhere far back 
in my mind I knew that AUTORELEASE (RETAIN ()) is not really thread safe.  
Fortunately we do not really use this construct that much in our code.
But I will examine these places again.

Besides the multithreading issue.
Might it be wise to check in the function IncRef for the case that 
the refcount has hit zero and dealloc is being or has been called?

I know that this won't really work because it will only catch
the case where the object is still around in memory while
being deallocated or not reclaimed for use in other places.
But it still might catch some bugs in user code. 

Hm but this is a slippery slope.

Also I just noticed this will introduce slightly different behaviour
between REFCNT_LOCAL and not REFCNT_LOCAL.  So that is no good.

But perhaps when added when NSZombies and REFCNT_LOCAL are enabled
warn that a retain happens while release-deallocating?  

It is probably not worth it.  But I am getting quite frustrated
with the multithreading problems, which unfortunately until
now all turned out to be problems in gnustep-base (which 
is much harder for me to debug.) Also the fact that most
of the time when an actual dead lock occurs the stack trace is
garbled does not help.   

Wim Oudshoorn.