[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.
- Another multithreading bug (I think), Wim Oudshoorn, 2006/09/06
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/06
- Re: Another multithreading bug (I think), Wim Oudshoorn, 2006/09/06
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/07
- Re: Another multithreading bug (I think),
Wim Oudshoorn <=
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/07
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/07
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/07
- Re: Another multithreading bug (I think), Wim Oudshoorn, 2006/09/07
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/07
- Re: Another multithreading bug (I think), David Ayers, 2006/09/08
- Re: Another multithreading bug (I think), Richard Frith-Macdonald, 2006/09/08
- Multithreading, Wim Oudshoorn, 2006/09/08
- Re: Multithreading, Richard Frith-Macdonald, 2006/09/09
- Re: Multithreading, Wim Oudshoorn, 2006/09/09