What are thread explosion and priority inversion, and how do QoS and the system help?

Thread explosion happens when you submit many blocks to a concurrent queue and those blocks block (waiting on I/O, a lock or a sync call). GCD sees idle CPU cores and no progress, so it starts more threads to run the next blocks, and can reach the system’s thread limit while all of them wait. Costs: memory for each thread’s stack, scheduling overhead, and potential deadlock when every worker thread is waiting for work that needs a free one. The fixes are to not block (use async APIs and callbacks), to serialise work on a serial queue or limit it with an OperationQueue’s maxConcurrentOperationCount or a semaphore, and to avoid nested sync calls. Swift concurrency addresses this by running tasks on a cooperative thread pool with about one thread per core: tasks must not block threads, they suspend at await, which is why blocking calls in async code are flagged.

Priority inversion is a high-priority task waiting on a resource held by a lower-priority one, which in turn is starved by medium-priority work: the urgent task is effectively running at the lowest priority. Apple’s libraries cope in two ways: QoS inheritance and promotion (a queue or thread blocked on by a higher-QoS caller is temporarily raised, and sync and locks like os_unfair_lock, DispatchQueue.sync and pthread mutexes donate priority) and QoS-aware primitives. Things that do not propagate priority, such as a semaphore or a spin loop, can cause inversion, which the Thread Performance Checker flags in Xcode (“priority inversion” warnings). Use the lowest QoS that fits, never wait on a low-QoS queue from a high-QoS one, and prefer locks and queues that donate priority.