Grand Central Dispatch Basics

Analogy categoryAnalogies

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.

objectivec

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.