[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: |
Wed, 06 Sep 2006 19:40:53 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin) |
Richard Frith-Macdonald <richard@tiptree.demon.co.uk> writes:
> On 6 Sep 2006, at 14:31, Wim Oudshoorn wrote:
>
>> So it seems that an NSConnection is deallocated but still exists in
>> the connection_table.
>>
>> Looking at the NSConnection code, a connection is added to this
>> table in the
>> -init... method, and removed in the -invalidate method.
> <snip>
>
>> To me this looks not very thread safe. So I see if garding this
>> with the _refGate works. But because it is so tricky to reproduce
>> (any logging seems to make the bug disappear) it is hard to confirm
>> if the fix is enough.
>
> Thanks ... well spotted.
> I've modified the -release method to protect the check of the retain
> count using the connection table lock as you suggest.
I suggested usiing the refGate, not the connection table lock,
bug using the refGate is horribly wrong and I was quite stupid to suggest that.
Glad you didn't follow my suggestion.
But using the connnection table lock, might not be wise, because:
1 - in order to make the access to the retaincount safe, both
retain and release need to be guarded by the same lock.
2 - the connection_table_gate is a non-recursive lock.
3 - the connection_table_gate should NOT change to a recursive lock
because it guards a hash table.
4 - if in -release the final call holds
the connection_table_gate, it most likely will block on:
either a recursive retain/release or on the invalidate method
who will also try to obtain the lock.
5 - release should hold the lock during the whole release
method because otherwise there is still a chance of
failing to finalize the nsconnection.
Having said this, I am not able to check your fix right now because
I don't have svn on my computer. (Need to install that.)
Also, I tried adding a new lock just for retain and release, but
this seems to make the application hang with a garbled stack trace :-(
Friday I think I will be able to see your diff and test it in our application.
And thank you for looking into this.
Wim Oudshoorn.
P.S.: Did you look at my remark about the win32 message port locking?
- 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 <=
- 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), 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