Re: Need advice: Object ownership and threading issue, causing a rare crash.
Re: Need advice: Object ownership and threading issue, causing a rare crash.
- Subject: Re: Need advice: Object ownership and threading issue, causing a rare crash.
- From: Motti Shneor <email@hidden>
- Date: Thu, 02 May 2013 21:33:28 +0300
Hi and thanks Kyle, Fritz, Jens and everyone else....
On 2 במאי 2013, at 20:31, Kyle Sluder <email@hidden> wrote:
> On Wed, May 1, 2013, at 05:10 AM, Motti Shneor wrote:
>> Hello.
>>
>> I have two NSObject subclasses - say MyA and MyB.
>>
>> - Each MyA instance. creates and owns a MyB instance.
>> - MyB instances create an NSThread, and live their asynchronous life,
>> communicating with a remote internet server, and sometimes with their
>> owner (the MyA object) who lives in the main thread.
>
> Dumb question: can you not rely on Cocoa's built-in asynchronous
> networking APIs?
Unfortunately, MyB wraps in Obj-C a (rather weird) 15 year old C++ socket implementation which is nonstandard in many ways, and therefore cannot use the nicer and more modern asynchronous networking APIs.
>
>> What's the best way to get out of this? How can I simply synchronize the
>> "release" calls, without blocking both threads? Maybe I should restrict
>> myself to retaining/releasing in the main thread only? Is there some
>> syntactic Obj-C sugar to ease such things?
>
> In such a circumstance, I would normally require MyA to use a factory
> method to construct instances of MyB, and have that factory method add
> the MyB instances to an object pool. When MyB operations are cancelled,
> they perform their cleanup and message the thread they were created on
> to remove themselves from the pool. Using dispatch queues should
> simplify this quite a bit.
>
That doesn't change the problem much, because now the "object pool" will have the same issues as MyA. The problem is in the multithreaded allocation/deallocation domain.
However, I think I found a good workaround the problem.
If MyB calls [self retain] just BEFORE detaching its thread-function, and then calls [self release] AFTER the thread exits, and the thread-function returns, then all retain and release (hence dealloc) calls happen in the main-thread, and thus --- synchronized.
I think I solved the problem. but now I'll exercise this code heavily, to see it is good.
Last word --- I wonder why it isn't clearly written for every cocoa API (and especially for the very fundamental initialize/alloc/init/release/dealloc methods whether or not they're reentrant! In a multithreaded environment, that's a reasonable requirement from the documentation.
Thanks again!
Motti Shneor, Mac OS X Software Architect & Team Leader
Spectrum Reflections Ltd.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden