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: 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?




reply via email to

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