bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another multithreading bug (I think)


From: Wim Oudshoorn
Subject: Re: Another multithreading bug (I think)
Date: Thu, 07 Sep 2006 11:56:47 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin)

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

>> 2 - the connection_table_gate is a non-recursive lock.
>
> Changed to be recursive.
>
>> 3 - the connection_table_gate should NOT change to a recursive lock
>>     because it guards a hash table.
>
> That's not a problem because the table does not retain its contents,
> so removing/adding an object has no side effects.

Hm, well, the connection_table_gate is used to lock access to
the connection_table.  connection_table is a NSHashTable and
if the lock is recursive it can happen that during
enumeration, by having side effects, indirectly a new connection
will/can be added or removed.  
Of course it is a bug if this happens.  Like the +[NSConnection _threadWillExit]
bug I mentioned recently.   So if the lock is recursive such an 
connection_table usage bug will lead to a crash and in the other case to a 
deadlock.
I think the deadlock is slightly easier to debug (if the stacktrace works at 
least.)


> a more elegant solution here would be to scrap the special processing
> in -release and have -dealloc do the work:
>
> 1. lock the connection table lock
> 2. check the current retain count
> 3a. ... if it is greater than 1, then something else has retained the
> object ... so we cancel the dealloc and unlock
> 3b. if it is 1, we remove the connection from the table, unlock, and
> proceed to finalize/deallocate

If it happens in dealloc you could conceivably use the _refGate lock.
This is already recursive and an ivar, so you don't have threads fighting
for the global lock.

> But ... I think this reveals a bug in NSObject ... the -retain and - 
> release implementations are not currently entirely thread-safe.  They
> handle the testing and changing of the reference counts in a thread- 
> safe manner, but during release there is a gap between testing/
> decrementing the reference count and calling the -dealloc method.

Hm I see, yuck.  
>
> I saw the email, but haven't had a chance to reboot in windows and
> look at it properly yet.
> I hope to be able to do that this weekend.

Oh that is fine, if you need some more information let me know.
I won't be able to access a windows machine right now, but 
will do what I can.

Thanks for looking into this.

Wim Oudshoorn.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]