Quality of Service Inference and Promotion

Note that QoS is not a static setting for operations and queues, and could fluctuate over time depending on a variety of criteria. For example, situations may occur where the QoS of an operation and the QoS of a queue don’t match, an operation and a dependent operation don’t match, or an operation has no QoS assigned. In these scenarios, a QoS may be inferred.

Numerous rules govern how QoS inference and promotion occurs with regard to queues (see Table 10-3) and operations (see Table 10-4).

Adjust the QoS of a Running Operation

Once an operation is running, you can change its QoS in one of the following ways:

• Change the qualityOfService property of the operation. Note that doing this also changes the QoS of the thread that’s running the operation.

• Add a new operation with a higher QoS to the running operation’s queue. This will promote the QoS of the running operation to match the QoS of the operation.

• Use addDependency: to add an operation with a higher QoS to the running operation as a dependent.

• Use waitUntilFinished or waitUntilAllOperationsAreFinished. This will promote the QoS of the running operation to match the QoS of the caller.

Dispatch Queues

For dispatch queues, you can specify a QoS by calling dispatch_queue_attr_make_with_qos_class when creating the queue. First, create a dispatch queue attribute for the QoS, and then provide that attribute when you create the queue, as shown in Listing 10-2.

Table 10-5 shows how GCD QoS classes map to Foundation QoS equivalents.

QoS is an immutable attribute of a dispatch queue, and can’t be changed once the queue has been created. To retrieve the QoS that’s assigned to a dispatch queue, call dispatch_queue_get_qos_class.

Global Concurrent Queues

In the past, GCD has provided high, default, low, and background global concurrent queues for prioritizing work. Corresponding QoS classes should be used in place of these queues. Table 10-6 describes the mappings between these queues and QoS classes.

A global concurrent queue exists for each QoS class. To retrieve the global concurrent queue corresponding to a given QoS, call dispatch_get_global_queue and pass it the desired QoS class. Listing 10-4, for example, retrieves the global concurrent queue for the utility QoS class.

Queues that don’t have a QoS assigned and don’t target a global concurrent queue infer a QoS class of unspecified.

Dispatch Blocks

The GCD block API allows QoS classes to be applied at the block level, such as when calling dispatch_async, dispatch_sync, dispatch_after, dispatch_apply, or dispatch_once. You do this when you create the block, as shown in Listing 10-5.

Priority Inversions

When high-priority work becomes dependent on lower priority work, or it becomes the result of lower priority work, a priority inversion occurs. As a result, blocking, spinning, and polling may occur.

In the case of synchronous work, the system will try to resolve the priority inversion automatically by raising the QoS of the lower priority work for the duration of the inversion. This will occur in the following situations:

• When dispatch_sync() and dispatch_wait() are called for a block on a serial queue.

• When pthread_mutex_lock() is called while the mutex is held by a thread with lower QoS. In this situation, the thread holding the lock is raised to the QoS of the caller. However, this QoS promotion does not occur across multiple locks.

In the case of asynchronous work, the system will attempt to resolve the priority inversions occurring on a serial queue.

NSTask and NSThread

Both NSTask and NSThread possesses a qualityOfService property, of type NSQualityOfService. These classes will not infer a QoS based on the context of their execution, so the value of this property may only be changed before the task or thread has started. Reading the qualityOfService of a task or thread at any time will provide its current value.

The Main Thread and the Current Thread

The main thread is automatically assigned a QoS based on its environment. In an app, the main thread runs at a QoS level of user-interactive. In an XPC service, the main thread runs at a QoS of default. To retrieve the QoS of the main thread, call the qos_class_main function, as shown in Listing 10-6.

To retrieve the QoS of the currently running thread, call the qos_class_self function, as shown in Listing 10-7.

pthreads

You can assign a QoS class when creating a pthread by using an attribute, as shown in Listing 10-8, which creates a utility pthread.

To change the QoS of a pthread, call pthread_set_qos_class_self_np and pass it the new QoS to apply, as shown in Listing 10-9.

Xcode

By setting breakpoints in Xcode or pausing your app while testing, you can inspect your app with the CPU usage gauge in the debug navigator in order to confirm that requested QoS classes are being applied. See Figure 10-1.

Figure 10-1QoS classes in the Xcode CPU gauge

powermetrics

Use the powermetrics tool to analyze your app and determine how much time is being allocated to different QoS classes.

In Listing 10-10, metrics are retrieved for the running tasks on a device. The results show that an app is running primarily at a QoS level of user-interactive (19.96), with much less user-initiated (0.62), utility (0.0), and background (0.0) work occurring. As a result, the app is using more energy than if it were running more work at the lower QoS classes. If the breakdown provided for your app is not what you expect, then you should investigate further. Consider running spindump to analyze your code.

See powermetrics(1) Mac OS X Manual Page for information on using this tool.

spindump

Use the spindump tool with the -timeline option to sample and profile your app in order to determine which QoS class applies as a specific portion of code executes at a given time. Listing 10-11 shows that a thread is running at a QoS level of user-initiated.

See spindump(8) Mac OS X Manual Page for information on using this tool.