Re: Thread safety with background fetching
The only time you're sharing data across threads is via -
performSelectorOnMainThread:... which itself is thread safe.
So the main thing you have to work through is the memory management of
the data which XMLFetcherParser is passing to the -receiveItem: method
on the main thread. The convention is that things are created and
immediately added to the autorelease pool.
For instance, If the worker thread's autorelease pool gets released
right after it passes you the object on the main thread, that object
will become released, and you're left with a dangling pointer.
You might need to adopt a very tight convention that you retain the
object before sending it to the main thread, and once in the main
thread, autorelease it there.
Joe K.
On Jul 31, 2008, at 9:59 AM, Ben wrote:
Hi List,
Having read the Apple documentation and beginner guides on
threading, I am still a little confused about protecting my
variables from access by multiple threads.
A sample of my code is as follows:
@interface Class1 : NSObject
{
XMLFetcherParser *fetcherParser;
}
- (void)doBackgroundFetch;
- (void)receiveItem:(Item *)newItem;
@end
@implementation Class1
- (void)doBackgroundFetch
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
fetcherParser = [[XMLFetcherParser alloc] init];
[fetcherParser doYourThing];
[fetcherParser release];
[pool release];
}
- (void)receiveItem:(Item *)newItem
{
// Add newItem to an array
}
@end
For usage, the summary is that I do:
[NSThread detachNewThreadSelector:@selector(doBackgroundFetch)
toTarget:self withObject:nil];
and then -[XMLFetcherParser doYourThing] repeatedly sends newly
created objects to receiveItem: using the
performSelectorOnMainThread method. Once the spawned thread has done
this, it never uses the sent object again.
My question is how should I protect this code from thread related
problems? Do I just place @synchronized(){} blocks around the code
in receiveItem: and it's counterpart in the spawned thread? Or is
that just plain wrong? Or (likely) am I barking up totally the wrong
tree?
Regards,
Ben
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/joeman%40mac.com
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Thread safety with background fetching
On 31 Jul '08, at 9:59 AM, Ben wrote:
For usage, the summary is that I do:
[NSThread detachNewThreadSelector:@selector(doBackgroundFetch)
toTarget:self withObject:nil];
and then -[XMLFetcherParser doYourThing] repeatedly sends newly
created objects to receiveItem: using the
performSelectorOnMainThread method. Once the spawned thread has done
this, it never uses the sent object again.
My question is how should I protect this code from thread related
problems? Do I just place @synchronized(){} blocks around the code
in receiveItem: and it's counterpart in the spawned thread?
You shouldn't need to. It sounds like -receiveItem: is only called on
the main thread, and if the helper object has finished with each new
object before it sends it to -receiveItem:, those objects won't be
accessed from multiple threads either.
You've basically got an agent-like mechanism, where the threads are
very loosely coupled using queues of messages, and don't need to worry
about synchronization issues. That's the way I like to arrange things
too.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Thread safety with background fetching
On Fri, Aug 1, 2008 at 4:59 AM, Ben [EMAIL PROTECTED] wrote:
and then -[XMLFetcherParser doYourThing] repeatedly sends newly created
objects to receiveItem: using the performSelectorOnMainThread method. Once
the spawned thread has done this, it never uses the sent object again.
My question is how should I protect this code from thread related problems?
Do I just place @synchronized(){} blocks around the code in receiveItem: and
it's counterpart in the spawned thread? Or is that just plain wrong? Or
(likely) am I barking up totally the wrong tree?
Since it doesn't look like you're sharing any ivars or objects between
the threads, I don't think you'll need any @synchronized blocks or
locking. The only thing I can see you'll want to watch out for is the
memory management of the objects that you pass to -receiveItem:.
Phil
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Thread safety with background fetching
Jens response just reminded me to check the docs, and it says of - performSelectorOnMainThread:...: This method retains the receiver and the arg parameter until after the selector is performed So I retract what I said before. So long as, was noted, you do not mess with the passed object in the worker thread AFTER you send it to the main thread, you should be all good. Joe K. On Jul 31, 2008, at 4:14 PM, Joseph Kelly wrote: The only time you're sharing data across threads is via - performSelectorOnMainThread:... which itself is thread safe. So the main thing you have to work through is the memory management of the data which XMLFetcherParser is passing to the -receiveItem: method on the main thread. The convention is that things are created and immediately added to the autorelease pool. For instance, If the worker thread's autorelease pool gets released right after it passes you the object on the main thread, that object will become released, and you're left with a dangling pointer. You might need to adopt a very tight convention that you retain the object before sending it to the main thread, and once in the main thread, autorelease it there. Joe K. On Jul 31, 2008, at 9:59 AM, Ben wrote: ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
