What is the priority inversion the warning refers to?
Let’s walk you through an example here:
Imagine you have a subsystem that varnishes waffles. This subsystem needs to be thread safe, so you serialise all the work on a dispatch queue. Varnishing waffles is generally not a high priority task, so that queue uses a standard priority.
You decide to give this subsystem an async API. There’s two entries points:
Most of the time this is fine. However, imagine you have a UI that you need to synchronously update based on the waffle varnish state. To do that you need to call the status API, but you need to results immediately so you use the synthetic synchronous approach.
This is where you see a priority inversion. The main thread generally runs with a high priority because it’s updating the UI. However, in this case the main thread is stuck waiting for the waffle varnishing queue to handle its status request, but the waffle varnishing queue runs at the default priority. Hence the priority inversion: High-priority work is stuck behind low-priority work.
This is more than just a performance issue. For example, on an iOS device in low power mode, the system might not service low-priority queues at all, which means that the UI could effectively deadlock.
We resolve this using a priority boost mechanism. If the main thread waits using a construct that tracks ownership, the system can boost the priority of the waffle varnishing subsystem while the UI thread is waiting.
One neat-o feature of this is that this priority boost mechanism can work across processes.
Coming back to
NSURLSession
itself, this problem is complicated by a couple of things:
Given that, it’s not clear to me how this priority boost mechanism would apply.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
