NSOperationQueue vs NSThread Priority — controlling how much cpu is consumed in NSOperationQueue

Question

I have some textures and sound effects preloading I need to do asynchronously to create a smooth user experience in an iOS game I am developing.

I am trying to decide between NSOperationQueue and NSThread to load these game resources during gameplay.

NSOperationQueue seems to be a clear winner and have numerous benefits, but I'm concerned about having effective priority control over this 'background' resource loading task, so that I can turn it down in terms of how many cycles it consumes so as not to affect frame-rates.

I see that NSOperationQueue has a concept of 'priority', but it looks different than NSThread's concept of 'priority'. Correct me if I'm wrong, but NSThread's priority is in relation to other threads running on the system, and NSOperation's priority is the priority of that task in relation to the other queued tasks.

What I want to know is....

Is there a way to control the priority of a given NSOperationQueue task in relation to how many cycles (as opposed to relative priority vs. other queued tasks) it can consume compared to other threads currently running on the device?

Is it safe within an NSOperationQueue's task to change the current thread's priority? (with NSThread's +setPriority)

Answer 1

An instance of NSOperation also have a 'setThreadPriority:' method, along with 'setQueuePriority:'.

This is definitively what you are looking for.

- (void)setThreadPriority:(double)priority

The value you specify is mapped to the operating system’s priority values. The specified thread priority is applied to the thread only while the operation’s main method is executing. It is not applied while the operation’s completion block is executing. For a concurrent operation in which you create your own thread, you must set the thread priority yourself in your custom start method and reset the original priority when the operation is finished.