Dispatch Sync

How dispatch sync works

Dispatch sync is a blocking submission pattern: the caller enqueues work onto a dispatch queue, then pauses until that work completes. That makes it useful when later code depends on an earlier result, but it also means the calling thread is unavailable for other work while it waits.

The key distinction is that dispatch sync does not merely schedule work, it also creates a hard sequencing point. On a serial queue, that sequencing is often straightforward; on the same serial queue, it can become self-referential if the queue must run the very block the current thread is waiting for.

Why dispatch sync can deadlock

Deadlock is the classic failure mode because the current thread is waiting for a block that cannot begin. If the thread is already executing on the same serial queue, the queue cannot make forward progress until the current block returns, but the current block will not return until the queued block finishes. Neither side can move first.

This is why dispatch sync is more dangerous than ordinary synchronous code. The deadlock is not caused by the block itself, but by the relationship between the waiting thread and the queue that must supply the completion. In practice, that makes queue ownership and call context part of the correctness model.

Where dispatch sync is appropriate

Used carefully, dispatch sync can make state transitions easier to reason about by forcing ordering. It is often chosen when a caller needs a computed value immediately or when a critical section must complete before control returns to the caller.

That convenience has a cost: every synchronous hop reduces concurrency and can amplify latency if the queued work is slow. The more nested the call path becomes, the easier it is to accidentally place a synchronous wait inside a context that already depends on the same execution lane.

Safer patterns and alternatives

The safer mental model is to treat dispatch sync as a coordination primitive, not a default communication style. If the work can be made asynchronous, that usually avoids self-waiting and preserves throughput. If synchronous ordering is unavoidable, the caller must know which queue it is on and whether the target queue can run independently.

In code review, the most important question is not whether dispatch sync is syntactically correct, but whether the call graph can re-enter the same serial queue. A small-looking synchronous call can become a system-wide stall when it sits on a path that already owns the queue it targets.

Risk and Threat Considerations

Dispatch sync can create a reliability risk when it is used across queue boundaries without a clear ownership model, because one blocked thread may hold up other work that depends on the same execution path. In user-facing or service code, that can surface as stalls, timeouts, and cascading latency under load.

Failure mechanism: A thread submits work to a serial queue and then waits, but the queue cannot start the new block because the waiting thread is still occupying the queue's current turn. That self-dependency produces deadlock or, in broader call chains, prolonged blocking and resource starvation.

Impact: The result can be frozen UI threads, worker pool exhaustion, request pile-ups, or service degradation that is difficult to diagnose because the system appears idle while it is actually waiting on itself.

Practitioner Guidance

What to watch for: Treat every dispatch sync call as a context-sensitive decision. The main thing to verify is whether the caller might already be running on the same queue, especially a serial queue, because that is the condition that turns a harmless-looking wait into a deadlock risk.

Practitioner note: Prefer explicit queue ownership rules and use asynchronous handoff where possible. When synchronous dispatch is truly required, make the queue relationship obvious in design and review, so the waiting path cannot silently become the same path it is waiting on.

Related resources from NHI Mgmt Group

• How does OneDrive auto-sync create secrets exposure in SharePoint?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• Should security teams disable OneDrive auto-sync by default?
• What is the difference between hard matching and soft matching in identity sync?