Concurrency the C-Based Way
Grand Central Dispatch (GCD) is a pure C API — despite living deep inside Objective-C codebases — built around 'dispatch_queue_t', an opaque object representing a FIFO queue of work items, and blocks, the C-language closures Apple added specifically to make GCD ergonomic. Rather than manually spinning up NSThread objects and managing their lifecycles, you submit a block of work to a queue with 'dispatch_async' or 'dispatch_sync', and the system decides which underlying thread from a shared thread pool actually executes it, scaling the pool up or down based on available CPU cores and system load. This inversion — you describe units of work, the system manages threads — is what makes GCD dramatically simpler to reason about than manual thread management.
Cricket analogy: It's like a franchise's central talent pool shared across all its age-group teams rather than each coach hiring dedicated players — GCD's thread pool is that shared resource, and you submit 'training drills' (blocks) without personally assigning which specific player (thread) runs them.
Serial vs Concurrent Queues
GCD queues come in two flavors. A serial queue runs exactly one block at a time, in the order submitted, making it useful for protecting shared mutable state without explicit locks — the main queue, obtained via 'dispatch_get_main_queue()', is a serial queue guaranteed to run on the main thread, which is why all UIKit updates must happen there. A concurrent queue, obtained via 'dispatch_get_global_queue()' with a Quality of Service class like 'DISPATCH_QUEUE_PRIORITY_DEFAULT' (or the newer 'qos_class_t' values), can run multiple blocks simultaneously on different threads, ideal for independent, parallelizable work like decoding several images at once. You can also create your own custom serial or concurrent queues with 'dispatch_queue_create', specifying 'DISPATCH_QUEUE_SERIAL' or 'DISPATCH_QUEUE_CONCURRENT'.
Cricket analogy: It's like a single bowling crease that only allows one bowler to deliver at a time in strict over order — a serial queue enforces that same one-at-a-time discipline — versus a multi-net practice session where several bowlers bowl simultaneously in parallel nets, like a concurrent queue.
dispatch_queue_t backgroundQueue = dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0);
dispatch_async(backgroundQueue, ^{
NSData *imageData = [NSData dataWithContentsOfURL:self.imageURL];
UIImage *image = [UIImage imageWithData:imageData];
dispatch_async(dispatch_get_main_queue(), ^{
self.imageView.image = image;
});
});Dispatch Groups and Barriers
'dispatch_group_t' lets you track a set of asynchronous blocks and be notified when all of them finish, regardless of which queues they ran on: you call 'dispatch_group_enter' before starting each unit of work and 'dispatch_group_leave' when it completes (or wrap the submission with 'dispatch_group_async'), then register a completion handler with 'dispatch_group_notify'. A dispatch barrier, submitted with 'dispatch_barrier_async' onto a custom concurrent queue, guarantees that block runs exclusively — no other block on that queue runs concurrently with it, and it waits for all previously submitted blocks to finish first — which is the standard GCD pattern for implementing a thread-safe reader-writer lock: reads go through the queue normally (concurrent), writes go through as barriers (exclusive).
Cricket analogy: It's like a tour selector waiting for scouting reports from every regional selector before finalizing a squad — dispatch_group_enter/leave track each report as it comes in, and dispatch_group_notify is the moment the chief selector is notified all reports are in and the squad can be announced.
'dispatch_once' was historically the standard thread-safe way to implement a singleton in Objective-C, executing its block exactly once no matter how many threads call it concurrently. Since Swift's 'static let' and Objective-C's own '+initialize' pattern cover most singleton needs today, dispatch_once is less common in new code but still appears throughout legacy codebases.
Avoiding Deadlocks
'dispatch_sync' submits a block and blocks the calling thread until that block finishes — useful when you genuinely need the result before continuing, such as reading from a value protected by a serial queue. The classic GCD deadlock happens when you call 'dispatch_sync' targeting the same serial queue you're already executing on: the calling block can't finish until the queue is free, but the queue can't become free until the calling block finishes, so both wait forever. This most commonly shows up as calling 'dispatch_sync(dispatch_get_main_queue(), ...)' from code that is itself already running on the main thread — a mistake that instantly and completely freezes the app.
Cricket analogy: It's like a batter refusing to run until the non-striker confirms they've already completed the run, while the non-striker is simultaneously waiting on the batter to go first — both stand frozen at the crease, exactly like two dispatch_sync calls waiting on each other in a deadlock.
Never call dispatch_sync targeting dispatch_get_main_queue() from code already running on the main thread — it deadlocks immediately and freezes the entire app's UI. If you need to guarantee main-thread execution without deadlock risk, use dispatch_async, or check dispatch_queue_get_label / NSThread.isMainThread first when the calling context is uncertain.
- GCD is a C API built on dispatch_queue_t and blocks; you submit work, and the system decides which pooled thread executes it.
- Serial queues run one block at a time in submission order; the main queue is a serial queue tied to the main thread.
- Concurrent queues, including the global QoS-classed queues, can run multiple blocks simultaneously on different threads.
- dispatch_group tracks multiple asynchronous blocks across queues and fires a notify handler once all have completed.
- dispatch_barrier_async on a custom concurrent queue provides exclusive execution, the standard pattern for a reader-writer lock.
- dispatch_sync blocks the calling thread until the submitted block finishes, unlike dispatch_async which returns immediately.
- Calling dispatch_sync targeting the queue you're currently running on — especially the main queue from main-thread code — causes an immediate deadlock.
Practice what you learned
1. What distinguishes a serial dispatch queue from a concurrent dispatch queue?
2. What is the classic cause of a GCD deadlock involving dispatch_sync?
3. What GCD construct notifies you once a set of asynchronous blocks, possibly on different queues, have all completed?
4. What does dispatch_barrier_async guarantee when submitted to a custom concurrent queue?
5. Which queue is guaranteed to run its blocks on the main thread?
Was this page helpful?
You May Also Like
Objective-C Runtime and Dynamism
How Objective-C's message-passing runtime enables introspection, method swizzling, and associated objects, and the risks that come with that power.
Unit Testing Objective-C Code
How XCTest structures test cases and assertions, how to isolate dependencies with mocks, and how to test asynchronous Objective-C code reliably.
Cocoa Touch and UIKit Basics
An introduction to the Cocoa Touch layer, UIKit's view hierarchy, view controller lifecycle, and how touch events and Auto Layout combine to build iOS interfaces.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics