Great! Thanks for the detailed explanation Ben.
Alex
On 31 jan 2008, at 00:38, Ben Trumbull wrote:
Alex,
Conceptually, you should treat NSOperations as if they were on a
separate thread. The OS may take certain liberties with
implementation details based on system load and other factors, but
basically NSOperations might as well be described as a light weight
mechanism for creating threaded tasks.
Importing tasks are often easily parallelizable by simply importing
1/Nth of the data on a thread/operation. Here's an excerpt of some
code I've been working with recently. It's GC and non-GC
compatible, and has 3 implementations for comparison: NSOperation,
NSThread, and boring serial code. As you can see, the NSOperation
version is basically the same in terms of thread handling, but
NSOperationQueue provides some convenient out-of-box handling for
finding out when the tasks are complete. The NSThread code has
whacky NSConditions and memory barriers.
The key to making this pattern useful is that each element in the
work queue ('keyQueues' below) is sufficiently large to be worth the
overhead of queuing up. In this sample code, each key is a file
path, so this is importing from a directory of files, importing
'maxCores' files simultaneously.
This division of labor doesn't work if the data in each 1/N sets has
relationships to data in other import groups.
**********************************************
** Alexander Griekspoor PhD **
**********************************************
mekentosj.com
EnzymeX - To cut or not to cut
2006 Winner of the Apple Design Awards
Best Mac OS X Scientific Solution
http://www.mekentosj.com/enzymex
**********************************************
_______________________________________________
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
