Concurrency and Multithreading Questions

Principles and practical techniques for concurrent execution and safe access to shared state across threads or execution contexts. Covers synchronization primitives (locks, mutexes, semaphores, condition variables), atomic operations and memory ordering, avoiding deadlocks, race conditions, and livelocks, designing thread safe data structures, thread pools and work scheduling, and asynchronous or event driven execution models such as coroutines, futures and promises, and reactive streams. Also covers platform and language specific concurrency tools, for example java.util.concurrent and POSIX threads on backend systems, Grand Central Dispatch and OperationQueue on iOS, coroutines and structured concurrency on Android/Kotlin, and async/await models in other languages. Evaluations focus on reasoning about correctness under concurrent access, performance trade offs (throughput, latency, contention), and preventing blocking of latency sensitive execution paths (server request handlers, UI threads, game loops) to maintain responsiveness.

EasyTechnical

55 practiced

Explain practical steps you would take to reproduce, isolate, and fix a concurrency bug that only appears under heavy load on real devices. Include instrumentation, logging, deterministic reproductions, and mitigation strategies for production.

EasyTechnical

53 practiced

Explain thread confinement and how it helps avoid locks and race conditions in mobile apps. Provide two examples: one for confining state to the main thread and one for confining state to a dedicated serial background queue.

Sample Answer

**What is thread confinement (brief)** Thread confinement means restricting access and mutation of a piece of state to a single thread or a single-threaded queue. If only one execution context can touch that state, you eliminate concurrent access — no locks, no races.

**Why it avoids locks and races**- Single writer/reader context prevents simultaneous conflicting operations.- Removes need for mutexes/atomic operations, simplifying reasoning and improving performance on mobile devices.

**Example A — Confining UI state to the main thread (iOS / Android)** - Principle: All UI updates run on the main thread; keep UI-related model mutations there.

Swift:

swift

DispatchQueue.main.async {
  self.usernameLabel.text = user.name  // confined to main thread
  self.profileState = .loaded          // mutate UI state only on main
}

Kotlin (Android):

kotlin

runOnUiThread {
  usernameTextView.text = user.name
  profileState = ProfileState.LOADED
}

**Example B — Confining background state to a dedicated serial queue** - Principle: Use a single serial queue for a shared cache or DB access to serialize access without locks.

Swift:

swift

let serialQueue = DispatchQueue(label: "com.app.cache")
serialQueue.async {
  cache[key] = value      // only this queue mutates cache
  let v = cache[key]
}

Kotlin:

kotlin

val handlerThread = HandlerThread("cache").apply { start() }
val handler = Handler(handlerThread.looper)
handler.post {
  cache[key] = value     // confined to handler's thread
}

**Takeaway** Confinement keeps reasoning simple: guarantee single-threaded access to state, preventing races and avoiding lock-related overhead and deadlocks.

HardTechnical

60 practiced

A concurrency bug occurs only in release builds on a specific device and cannot be reproduced in debug. Outline a systematic debugging strategy to reproduce, diagnose, and fix such a heisenbug. Include compiler optimizations, timing differences, instrumentation trade-offs, and methods for capturing traces on-device.

Sample Answer

**Goal & quick plan**Reproduce deterministically, capture evidence on-device, diagnose root cause (race/UB/optimization bug), apply minimal fix and verify with regression tests. Work iteratively to avoid perturbing timing.

**1) Confirm & isolate**- Reproduce: collect device, OS/build/version, app build id, CPU, background apps. Record exact steps and environment.- Minimize surface: reduce features, enable verbose logging toggle, create a minimal test harness that exercises the suspect code path repeatedly.

**2) Build variants to narrow compiler impact**- Build a release-like binary with debug info: keep -O2/-O3 but enable -g (strip later) and retain frame pointers if possible. On Android use a release build with ANDROID_STL and -g; on iOS use Release + DWARF.- Try intermediate optimization levels (-O1, -Os, -Og) and link-time-optimization off. If bug disappears at lower opt, optimization reordering likely triggers it.- Enable/disable specific flags (LTO, inlining) to pinpoint optimization class.

**3) Non-invasive tracing on-device**- Android: capture Perfetto/atrace, logcat, adb bugreport, tombstones, and use systrace; use perfetto SDK tracing to instrument spans. Use ART method tracing if Java layer suspected.- iOS: run Instruments (Time Profiler, Thread State), collect sysdiagnose, use os_signpost and unified logging (os_log) with level control.- Always symbolicate traces and crash dumps with matching dSYM or symbols.

**4) Instrument carefully (trade-offs)**- Avoid heavy printf/logging in release path — it changes timing. Use lightweight, conditional signposts, or circular in-memory ring buffers flushed on crash.- Use sampling profilers (Perfetto, Instruments) before enabling dense logging.- Use counters/metrics and atomic flags instead of serializing logs.

**5) Use sanitizers and race detectors**- ThreadSanitizer (TSan): build a sanitizer-enabled variant. On Android use Native TSan (requires custom runner); on iOS Xcode supports Thread Sanitizer in some configurations but may need non-release settings.- AddressSanitizer/UndefinedBehaviorSanitizer for memory/UB issues in native code; they often force different timing — treat results as hints.- If sanitizers aren't available on the target, reproduce on similar architecture in an instrumented CI runner.

**6) Deterministic / timing control**- Inject deliberate delays, yield points, or deterministic scheduling in suspect code to make races reproducible. Add debug toggles to enable deterministic single-threaded sequencing or force certain interleavings.- Use atomic fences or acquire/release debugging variants to test hypothesis.

**7) Capture low-level traces**- On Android, use perfetto with ftrace events (sched switches, futex) and native stack sampling to see kernel-level contention.- On iOS, capture thread state transitions and syscall activity via Instruments and sysdiagnose.

**8) Diagnose & fix**- If data race: enforce proper synchronization (mutex, atomic, read-write lock) or use double-checked locking correctly with atomics and memory_order.- If UB from compiler optimization (relying on unspecified evaluation order or aliasing): fix code to avoid UB (use volatile, restrict, or well-defined memory model idioms), mark functions as noinline only as temporary.- Prefer correct synchronization over ad-hoc compiler fences.

**9) Verify & prevent regressions**- Add unit/integration tests that stress the code (threaded harness with randomized seeds), run in CI with sanitizer builds and reproducible device tests.- Keep lightweight tracing toggles for future on-device capture.- Document root cause, reproducible steps, and why the fix is correct (memory model explanation).

Why this approach works- Systematically isolates compiler vs timing issues, captures non-invasive traces first to avoid masking the bug, then uses heavier instrumentation/sanitizers to find the root cause. On mobile, careful trade-offs between observability and perturbation are essential; final fixes should address the underlying concurrency/UB rather than rely on timing.

HardTechnical

53 practiced

You have a callback-based SDK that performs a sequence of dependent async operations using nested callbacks. In Kotlin, refactor and implement a coroutine-based pipeline using suspend functions and structured concurrency so the sequence is sequential in code but runs asynchronously, and errors propagate properly to the caller.

Sample Answer

**Approach (brief)** Wrap each callback-based SDK method into a suspend function using suspendCancellableCoroutine, then compose them sequentially inside a suspending function (coroutineScope) so structured concurrency, cancellation, and error propagation work naturally.

**Code (Kotlin)**

kotlin

import kotlinx.coroutines.*
import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock
import kotlin.coroutines.resume
import kotlin.coroutines.resumeWithException
import kotlin.coroutines.CancellableContinuation
import kotlin.coroutines.ensureActive

// Example callback SDK signatures:
// fun sdkStepOne(param: String, cb: (Result<String>) -> Unit)
// fun sdkStepTwo(token: String, cb: (Result<Int>) -> Unit)
// fun sdkStepThree(id: Int, cb: (Result<Unit>) -> Unit)

suspend fun <T> awaitSdk(call: ( (Result<T>) -> Unit ) -> Unit): T =
    suspendCancellableCoroutine { cont ->
        // start SDK call
        call { result ->
            if (cont.isCancelled) return@call
            result.fold(
                onSuccess = { cont.resume(it) },
                onFailure = { cont.resumeWithException(it) }
            )
        }
        // optional: hook cancellation to SDK cancel API if available
        cont.invokeOnCancellation { /* sdkCancel() if SDK supports */ }
    }

suspend fun performPipeline(param: String): Unit = coroutineScope {
    // run sequentially but non-blocking
    val token = withContext(Dispatchers.IO) { awaitSdk<String> { sdkStepOne(param, it) } }
    val id = withContext(Dispatchers.IO) { awaitSdk<Int> { sdkStepTwo(token, it) } }
    withContext(Dispatchers.IO) { awaitSdk<Unit> { sdkStepThree(id, it) } }
}

**Key points / reasoning**- suspendCancellableCoroutine transforms callbacks to suspend; resumeWithException propagates errors to caller.- coroutineScope ensures structured concurrency: if caller cancels, children cancel.- withContext(Dispatchers.IO) keeps SDK work off main thread (mobile best practice).- invokeOnCancellation allows SDK-level cancellation/cleanup.- Errors thrown in any step bubble up; caller can catch or let parent scope handle retries.

**Edge cases & alternatives**- If steps are independent, use async/await for parallelism.- Use SupervisorJob if you want some children to survive sibling failures.- Ensure SDK callbacks are invoked exactly once; guard with a Mutex or atomic flag if SDK might call multiple times.

EasyTechnical

51 practiced

Describe the core concepts of Grand Central Dispatch (GCD) on iOS: serial vs concurrent queues, global queues, dispatch_async vs dispatch_sync, and main queue. Explain typical usage patterns and pitfalls when dispatching work between queues.

Sample Answer

**Overview — core concepts**- GCD schedules work on queues. Queues are FIFO; tasks (blocks/closures) are dispatched to queues which the system maps to threads.

**Serial vs Concurrent**- Serial queue: executes one task at a time in order. Useful for protecting shared mutable state without locks.- Concurrent queue: starts tasks immediately and runs them in parallel when threads are available, but completion order is not guaranteed.

**Global queues**- System-provided concurrent queues with different QoS (userInteractive, userInitiated, default, utility, background). Use for general background work.

**dispatch_async vs dispatch_sync**- dispatch_async / DispatchQueue.global().async: schedules work and returns immediately — non-blocking.- dispatch_sync / DispatchQueue.sync: schedules work and waits for it to finish — blocking the caller thread.- Danger: calling sync on the same serial queue -> deadlock.

**Main queue**- Serial queue for UI work. Must run UI updates on DispatchQueue.main. Long tasks on main freeze UI.

**Typical patterns & pitfalls**- Pattern: Dispatch heavy I/O or computation to global queue, then DispatchQueue.main.async to update UI.

swift

DispatchQueue.global(qos: .userInitiated).async {
    let image = loadImage()
    DispatchQueue.main.async { imageView.image = image }
}

- Avoid DispatchQueue.main.sync from background threads expecting main to call back — can deadlock.- Avoid capture cycles (use [weak self]) when dispatching closures.- Use serial queues for synchronization; use QoS appropriately; prefer OperationQueue when you need dependencies/cancelation.

Unlock Full Question Bank

Get access to hundreds of Concurrency and Multithreading interview questions and detailed answers.

Join thousands of developers preparing for their dream job.