Concurrency, Synchronization & Deadlock Questions

Coroutine basics (mobile dev perspective)
CoroutineScope defines lifecycle for coroutines — tie it to component lifecycle (e.g., lifecycleScope in Activities/Fragments, viewModelScope in ViewModel) so work cancels automatically to avoid leaks.

Dispatchers

• Main: runs on UI thread; use for UI updates.
• IO: optimized for blocking I/O (network, disk).
• Default: CPU-bound work (sorting, parsing).

launch vs async

• launch: fire-and-forget, returns Job, good for side-effects.
• async: returns Deferred<T>, use when you need a result and await it.

Example:

lifecycleScope.launch(Dispatchers.Main) {
  val data = async(Dispatchers.IO) { fetchFromNetwork() }.await()
  updateUI(data)
}

Structured concurrency
Child coroutines inherit parent scope/context; cancelling parent cancels children. Use coroutineScope { } to create scoped concurrency and ensure exceptions propagate and resources are cleaned.

CoroutineContext & thread dispatching
Context = Job + Dispatcher + other elements. Dispatcher determines which thread or thread-pool executes coroutine code. You can switch with withContext(Dispatchers.IO) { ... } to run a block on a different dispatcher.

Common pitfalls

• Updating UI off Main after switching to IO/Default.
• Using GlobalScope (leaks, unmanaged lifecycles).
• Blocking threads inside coroutines (avoid Thread.sleep(), use delay()).
• Not using structured scopes — lost exceptions or orphaned coroutines.

Clarify goals & constraints

• Maximize throughput (frames/sec) while keeping UI latency low for visible images.
• Mobile: limited CPU cores, aggressive power/memory limits, heterogeneous cores (big.LITTLE).

High-level schedul­ing

• Use a small fixed-size thread pool per stage (fetch/ decode / ML / annotate / render) with bounded queues between stages.
• Prefer a pipeline with worker counts tuned to stage cost: 1–2 threads for I/O/decoding, 1–2 for ML (use NNAPI/Metal to offload where possible), 1 for main-thread rendering.

Pooling & reuse

• Reuse byte buffers and decoded bitmap objects via object pools to avoid GC/alloc churn.
• Keep a small LRU cache for decoded images of visible items only (soft size limit).

Batch sizes & ML

• Prefer micro-batching on ML when hardware supports it (e.g., batch = 2–4) to improve accelerator utilization, but cap latency: if any frame is visible and waiting, flush the batch early.
• If inference uses GPU/NNAPI, overlap data transfer with CPU decode.

Backpressure

• Bounded queues with backpressure: if decode→ML queue full, slow fetch (drop or deprioritize non-visible requests).
• Apply token-bucket rate control to avoid CPU/GPU saturation and thermal throttling.

Prioritization

• Each task carries priority: visible > prefetch nearby > background. Priority queue feeding decode and ML workers.
• When under pressure, cancel or drop lowest-priority jobs; always keep one fast-path for current visible image rendering.

Memory & energy

• Enforce overall memory budget; monitor image sizes and trim caches on memory warnings.
• Use lower decode resolution for thumbnails; lazy decode full-res only when needed.
• Throttle frame rate and ML frequency when battery/thermal constraints detected.

Metrics & tuning

• Measure latency per stage, queue lengths, and throughput. Start with worker ratio: decode:ML:annotate = 2:2:1 and iterate per device class.

Overview / Goals
Design a client-side sync engine that keeps a local DB (SQLite/Room/CoreData) eventually consistent with server, tolerates offline, conserves battery, retries with backoff, and handles conflicts at scale.

High-level architecture

• Local DB + Sync Engine + Network Layer + Conflict Resolver + Persistent Operation Queue.
• Server exposes incremental change feed (shadow copies / per-record revision vector + timestamp) and batch APIs.

Thread model

• Main/UI: reads from local DB, applies optimistic local writes.
• Background worker thread(s): single-threaded executor for sync jobs to avoid DB contention; small thread-pool for parallel upload batches when safe.
• Use transactions/DB WAL for concurrency.

Scheduling

• iOS: BGTaskScheduler for periodic background processing + push-based silent notifications (VoIP/Remote notification with content-available) to trigger immediate sync. Limit work to short tasks; chain tasks for longer syncs. Respect background fetch budget.
• Android: WorkManager with constraints (unmetered/wifi, battery not low). Use unique periodic and expedited OneTimeWorkRequests for foreground triggers. Fallback to JobScheduler on older devices.

Retry & backoff

• Exponential backoff with jitter per-batch. Persist retry metadata in operation queue. Use HTTP 429/503 headers when present to adapt backoff. Cap retries and surface error to user if persistent.

Conflict resolution

• Hybrid strategy:
  • Use server-assigned revision vectors (CRDTs or OT for complex merges).
  • Default: last-writer-wins using logical clock (lamport timestamp) for simple fields.
  • For business-critical fields, field-level merge rules and server-side authoritative resolution with merge metadata; surface manual conflict UI when automatic merge uncertain.
  • Keep audit/version history to allow rollbacks.

Data-flow for sync

1. Local change -> write local DB, enqueue operation with change-set and local revision; mark UI updated.
2. Background sync picks upload batch (chunked, compressed), sends to server with client revisions.
3. Server returns accepted updates and conflict notices; client applies server diffs in a transaction.
4. Client requests change-feed since last-synced token and applies remote deltas.
5. Update local revision token, ack operations, remove from queue.

Scalability & efficiency

• Batch operations, delta sync (only changed fields), compression, pagination.
• Use push notifications to minimize polling; use network constraints to prefer Wi‑Fi for heavy transfers.
• Metrics and telemetry for sync success, latency, conflict rates.

Edge cases

• Clock drift: use server logical clocks not device time.
• Partial failures: idempotent ops, resume with operation IDs.
• Schema migrations: versioned migrations in DB and through API compatibility headers.

This design balances battery/network efficiency, robust offline support, scalable throughput, and clear conflict handling appropriate for mobile platforms.

Design summary
Expose a Flow<Value?> per key (StateFlow) backed by an in-memory map, allow refresh(key) to fetch from network on IO dispatcher, avoid main-thread blocking, and safely deduplicate concurrent refreshes with an in-flight map + Mutex.

APIs

• fun getFlow(key: K): Flow<V?> // cold -> hot StateFlow per key
• suspend fun refresh(key: K): Result<V>
• fun invalidate(key: K)
• fun invalidateAll()

Coroutine scope & dispatchers

• Use a CacheScope = CoroutineScope(SupervisorJob() + Dispatchers.IO) for background work.
• Emit into StateFlows using withContext(Dispatchers.IO) so UI collects on Main safely.

Concurrency & dedupe

• Maintain ConcurrentHashMap<K, MutableStateFlow<V?>> for cache.
• Maintain ConcurrentHashMap<K, Deferred<Result<V>>> inFlight to dedupe refreshes.
• Use atomic putIfAbsent to start fetch; others await the same Deferred.

Example

class Cache<K,V>(
  private val fetch: suspend (K)->V,
  parentScope: CoroutineScope = CoroutineScope(SupervisorJob() + Dispatchers.IO)
){
  private val scope = parentScope
  private val store = ConcurrentHashMap<K, MutableStateFlow<V?>>()
  private val inFlight = ConcurrentHashMap<K, Deferred<Result<V>>>()

  fun getFlow(key: K): Flow<V?> = store.computeIfAbsent(key){
    MutableStateFlow<V?>(null)
  }.asStateFlow()

  suspend fun refresh(key: K): Result<V> {
    val deferred = inFlight.computeIfAbsent(key) {
      scope.async {
        runCatching {
          withContext(Dispatchers.IO){ fetch(key) }.also { value ->
            store.computeIfAbsent(key){ MutableStateFlow(null) }.value = value
          }
        }.also { inFlight.remove(key) }
      }
    }
    return deferred.await()
  }

  fun invalidate(key: K){ store[key]?.value = null }
  fun invalidateAll(){ store.values.forEach{ it.value = null } }
}

Notes

• Use StateFlow so UI gets immediate latest value.
• runCatching propagates errors; callers handle retries.
• Consider TTL and scheduled invalidation using scope.launch + delay per key.
• Keep scope lifecycle tied to repository/VM to avoid leaks.

Approach overview
Reproduce under load, gather deterministic traces, isolate root cause, implement fix, and deploy mitigations to protect users while fixing.

Reproduce & stress

• Run stress tests on real devices/cloud device farms (Firebase Test Lab, AWS Device Farm).
• Use UI/functional stress (Monkey, Espresso/XCTest loops) + concurrent background tasks (network, DB, sensor).
• Simulate real network (Charles/Network Link Conditioner) and battery/CPU constraints.

Instrumentation & logging

• Add structured, high‑frequency logs (timestamp, thread id, task id, state). Use persistent logging (log to file) to capture post‑crash.
• Enable platform tools: Android Systrace/ADB, StrictMode, ThreadSanitizer (iOS), Xcode Instruments.
• Use distributed tracing / breadcrumbs (Firebase Crashlytics, Sentry) with correlation IDs.

Deterministic reproduction

• Reduce nondeterminism: mock network/time, inject schedulers to control thread interleavings, replay recorded event traces.
• Add assert/checkpoints and reproduce with single‑device deterministic harness (UI tests with injected delays).

Isolation & fix

• Narrow to component via binary search (disable features) and unit tests that reproduce race (use Robolectric/JUnit or XCTest).
• Fix with minimal correct change: prefer thread‑safe primitives (Atomic, synchronized/Mutex, serial DispatchQueue), avoid double‑checked locking pitfalls.
• Add regression tests (stress loops in CI, CI flakiness detectors).

Production mitigations

• Rollout via feature flags, gradual percentage rollouts, add circuit breakers, exponential backoff, and graceful degradation.
• Hotfix telemetry: increase sampling for affected path, alerting + kill switch.

Postmortem

• Document root cause, test added, and monitoring to prevent regressions.