On Dec 14, 2009, at 9:59 PM, PCWiz wrote: > What if I used NSInvocationOperation like this: > > NSInvocationOperation *myOperation = [[NSInvocationOperation alloc] > initWithTarget:self > selector:@selector(doResourceHungryTask) object:nil]; > [operationQueue addOperation:myOperation]; > > "doResourceHungryTask" would be a method in my delegate class. Would I still > need to lock/unlock (I'm modifying the class's properties from itself, not > another class)? I'm not sure on the exact workings of NSInvocationOperation, > I just found out about it.
You still need to design and implement -doResourceHungryTask and everything it calls very, very carefully. It doesn't matter that you're modifying the class's properties rather than another's. It's not about crossing class boundaries. It's about things happening simultaneously on different threads. The threads can modify shared data structures in ways which don't maintain their internal consistency, resulting in corrupted data and, if you're lucky, crashes. Multi-threaded programming is hard. Apple introduced NSOperation/Queue as one way to help programmers be safer, but it's not magical. It helps provide safety only when you use it in the way I described in my earlier email. Basically, it encourages designs where the data used for an operation is encapsulated within an independent object (of a custom subclass of NSOperation) and is not shared by any other thread. If you don't take Apple's encouragement and just use NSOperation to perform "un-encapsulated" threading, it doesn't make things any easier than traditional multi-threaded programming. That's what NSInvocationOperation does, really. It doesn't make the selector it invokes any more thread-safe. The only advantage NSInvocationOperation has over -performSelectorInBackground:withObject: is that NSOperationQueue manages the number of threads in use. Regards, Ken _______________________________________________ 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 arch...@mail-archive.com
