Language-Level Concurrency and Multithreading Questions

Approach (brief)
Provide a global lock-free slab allocator with per-thread caches (thread-local free lists) for fast paths. Slabs are fixed-size pages subdivided into N object slots. Global allocator handles slab creation, reclamation and cross-thread freeing.

Data structures

• Global: atomic list of partial/full slabs, and concurrent free-slab pool.
• Slab: 4KB aligned block, bitmap for allocations, atomic refcount.
• Per-thread cache: thread_local array of free pointers (stack-like), capacity C.

Fast path

• Allocation: try pop from thread_local cache (lock-free).
• If empty: pop from slab’s lock-free free-list or fetch a new slab from global (slow path).
• Free: if current thread owns slab, push to thread_local cache; else push to slab’s atomic remote-free-list and optionally signal owner.

Synchronization

• Use atomic operations (compare-and-swap) for per-thread stacks and slab free-lists.
• Global slab lists use lock-free Treiber stacks or a small mutex for slab metadata changes to simplify correctness.

Thread exit & reclamation

• On thread exit, drain thread_local cache back to global: push into slab remote-free-lists or return whole slabs to global pool.
• Use epoch-based reclamation (lightweight) or a hazard-pointer style epoch to safely free slabs when no thread can access them.
• Slab garbage: when all slots free and not referenced, move slab to OS return pool.

Sketch (Swift-like pseudocode)

final class Slab {
  var base: UnsafeMutableRawPointer
  var bitmap: Atomic<UInt64>
  var remoteFreeHead: Atomic<UnsafeMutableRawPointer?> = Atomic(nil)
  var freeCount: Atomic<Int>
}
@_threadLocal var localCache: [UnsafeMutableRawPointer] = []
func alloc() -> UnsafeMutableRawPointer? {
  if let p = localCache.popLast() { return p }                      // fast path
  // slow path: try pop from slab free-list, else acquire new slab
}
func free(_ p: UnsafeMutableRawPointer) {
  if localCache.count < CAP { localCache.append(p); return }       // fast path
  // remote push into slab.remoteFreeHead (CAS)
}

Trade-offs & notes

• Fixed-size slabs reduce fragmentation; for multiple sizes, maintain size-classes.
• Epoch-based reclamation costs periodic scans but avoids global locks.
• Use small mutex only for rare global operations to keep fast paths lock-free.
• Measure per-device; tune slab size and per-thread cache capacity for memory vs latency.

Root-cause analysis plan

• Collect thread dumps at multiple moments: (1) when UI is frozen, (2) when background sync is active, (3) periodic under load. For each dump capture:

  • Main/UI thread stack (look for synchronous DB reads, locks, wait/park).
  • All sync worker thread stacks (thread-pool workers doing network→DB).
  • Dedicated DB thread/connection stack (if single-threaded executor exists).
  • Native threads (SQLite/ndk) and any mutex/waiting on java.util.concurrent locks.

• Inspect lock-orderings:

  • Application locks (e.g., ReentrantLock, synchronized) held on main while calling DB read.
  • DB connection mutexes (SQLite native mutex) held by background worker while trying to acquire app-level locks — map sequences like:
    • Main: acquire AppLock A → call syncRead() → wait for DBLock
    • Worker: acquire DBLock → attempt to acquire AppLock A
  • Look for inverse ordering (AppLock then DBLock vs DBLock then AppLock).

• Additional artifacts:

  • Logging around DB queue enqueue/dequeue times and backpressure.
  • Trace of thread-pool queue lengths and task latencies.

Recommended architectural/code changes

• Serialize DB access through a single dedicated executor/dispatcher to keep connection single-threaded, but avoid letting arbitrary threads block on DB. Patterns:
  • Create a single-thread DB dispatcher (newSingleThreadContext or ExecutorService) and funnel all DB ops through it.
  • Never perform synchronous DB reads on main. Make main requests asynchronous (suspend/callback/LiveData/Flow).
  • Avoid holding app-level locks across an await/DB call. Acquire locks only on the DB thread or after DB returns.
  • For background sync thread-pool tasks: do network and heavy work in pool, then post DB writes to the DB dispatcher (non-blocking enqueue).
  • Consider enabling WAL mode for concurrent readers if appropriate; but still use single writer serialized path.
  • Add timeouts and watchdogs for long-running DB ops; fail fast rather than block UI.

Example: safe DB access (Kotlin coroutines, Android)

// create single-threaded DB dispatcher at app startup
val dbDispatcher = Executors.newSingleThreadExecutor { Thread(it, "DB-Thread") }.asCoroutineDispatcher()

suspend fun readUser(userId: Long): User? = withContext(dbDispatcher) {
    // runs on DB thread, never blocks main
    database.userDao().getById(userId) // Room/SQLite call
}

fun loadUserOnUi(userId: Long, scope: CoroutineScope, onResult: (User?)->Unit) {
    scope.launch(Dispatchers.Main) {
        // show loading UI
        val user = withTimeoutOrNull(2000) { readUser(userId) } // protect UI responsiveness
        // update UI on Main
        onResult(user)
    }
}

// background sync: network -> enqueue DB write
suspend fun performSync() {
    val data = withContext(Dispatchers.IO) { fetchFromNetwork() } // background pool
    withContext(dbDispatcher) { database.userDao().insertOrUpdate(data) } // serialize DB write
}

Why this prevents deadlock

• All DB operations run on one thread (no concurrent native SQLite contention).
• Main thread never blocks waiting for DB; uses suspend/callbacks with timeouts.
• Background workers do not hold DB locks while trying to obtain app locks — they only enqueue DB work.
• Lock ordering becomes consistent: app-level locks (if any) are not acquired while waiting for DB; DB thread can perform writes without needing app locks.

Other mitigations

• Audit code for any synchronized blocks around DB calls; refactor to avoid cross-thread locking.
• Add metrics/alerts for DB queue depth and longest-running DB op.
• If using multiple processes or legacy code, consider migrating to a connection pool with serializing proxy but keep main non-blocking.

Answer (concise, role-specific)

What the main/UI thread is

• The main (UI) thread is the single thread the OS reserves for processing user events and updating the UI (UIKit on iOS, Android View system). It runs the app runloop/Looper and must remain responsive.

Why UI ops must run there

• UI frameworks are not thread-safe; view hierarchies and rendering must be mutated on the main thread to avoid race conditions, corrupt state, or inconsistent draws. Doing heavy work on it blocks event processing and causes freezes (iOS UI jank) or ANR on Android.

Two examples of operations that must run on the main thread

• Updating view properties or layouts (e.g., setting UIView.frame, changing TextView.text).
• Presenting/dismissing UI components (e.g., presenting UIAlertController, committing FragmentTransaction / starting Activities).

Platform APIs to schedule UI work

• iOS: DispatchQueue.main.async / DispatchQueue.main.sync (careful with sync), OperationQueue.main, RunLoop.main.

// iOS
DispatchQueue.global().async {
    // background work
    DispatchQueue.main.async {
        label.text = "Done"
    }
}

• Android: Activity.runOnUiThread, View.post, Handler(Looper.getMainLooper()).post, or Kotlin coroutines with Dispatchers.Main.

// Android
GlobalScope.launch(Dispatchers.IO) {
    // background work
    withContext(Dispatchers.Main) {
        textView.text = "Done"
    }
}

Consequence of violating

• Race conditions, crashes, visual corruption; heavy work on main thread -> UI freeze and ANR (Application Not Responding) on Android or poor responsiveness/jank on iOS.

Best practice

• Keep main thread for UI; move CPU/network work to background threads and marshal results back to DispatchQueue.main / Dispatchers.Main / Handler.

Brief approach
Fix at two levels: immediate code-level changes to remove blocking work from critical sections and use atomic/async file APIs; and architectural changes to ensure latency-sensitive UI work never waits for disk IO or low-QoS threads.

Code-level fixes (examples)

• Move synchronous disk writes out of locks:

let cacheLock = NSLock()
var dataToWrite: Data?

func updateCache(_ newData: Data) {
    cacheLock.lock()
    // update in-memory state quickly
    dataToWrite = newData
    cacheLock.unlock()

    // perform disk IO asynchronously at appropriate QoS
    DispatchQueue.global(qos: .utility).async {
        dataToWrite?.write(to: fileURL, options: .atomic)
    }
}

• Use atomic writes / replaceItem to avoid partial files:

try data.write(to: url, options: .atomic)

• Use DispatchIO or FileHandle.writeabilityHandler for nonblocking streaming writes if large files are common.
• If you must protect a resource briefly, use os_unfair_lock or serial DispatchQueue but keep critical section tiny; never hold lock during IO.
• Avoid using low QoS for worker threads that may block higher-QoS work; explicitly set QoS on queues.

Architectural changes

• Introduce a write-behind cache: enqueue write tasks to a dedicated writer queue with backpressure; persist in batches.
• Separate responsibilities: UI thread updates read/write in-memory model; persistence is eventually consistent via background queue.
• Use operation queues with qualityOfService and maxConcurrentOperationCount to control resource usage.
• For shared resources, prefer lock-free patterns (atomic pointers, copy-on-write) to eliminate long-held locks.

How to test under stress

• Create synthetic workload: many background threads performing synchronous writes while driving UI interactions (touch gestures, animations). Automate using UI Tests or XCTMeasure to run repeatable scenarios.
• Ramp up concurrency, file sizes, and frequency to reproduce inversion.
• Use NSLog/os_signpost around lock acquire/release and file IO to correlate events.

Instruments views to validate

• Time Profiler: find where CPU is spent and stack traces showing UI thread waiting.
• Thread/Call Tree and Thread State: see blocked/locked states and which thread holds lock.
• System Trace: shows CPU scheduling, context switches, and QoS inversion patterns.
• File Activity / I/O: observe disk write durations and frequencies.
• Core Animation (FPS): detect frame drops and UI jank correlated with disk activity.
• Activity Monitor / Energy: verify background writer's impact.

This combination of localized code fixes plus architectural separation and targeted stress tests with Instruments will eliminate priority inversion and validate the fix on device.

Clarify the problem
I’d treat RejectedExecutionException as a symptom of executor saturation under bursts — need metrics and quick mitigations plus architectural fixes.

Parameters & runtime metrics to inspect

• Executor config: corePoolSize, maximumPoolSize, keepAliveTime, workQueue type/capacity, ThreadFactory, RejectedExecutionHandler.
• Runtime: current pool size, active thread count, queue size, completed task count, rejection count, GC/CPU usage, memory, latency of tasks, thread dump during bursts.

Immediate configuration changes / rejection handlers

• Switch to a bounded BlockingQueue sized to expected burst (e.g., ArrayBlockingQueue) and increase maximumPoolSize cautiously.
• Use CallerRunsPolicy to apply backpressure (runs on caller thread) or a custom handler that drops low-priority tasks and logs/metrics.
• Increase keepAliveTime for faster thread reuse; ensure threads are non-daemon and have proper uncaught exception handling.

Long-term architectural changes

• Introduce a rate limiter (Token Bucket) at producers to smooth bursts.
• Use a persistent lightweight work queue (Room/SQLite, or WorkManager/JobScheduler) for retryable background work.
• Prioritize tasks: separate executors for latency-sensitive vs batch work; use bounded queues per class.
• Add circuit-breaker / graceful degradation: drop nonessential work and surface progress to UI.
• Instrument metrics/alerts (Firebase Performance/Crashlytics, custom counters) and load-test bursts.

These steps provide immediate relief and predictable resource use while moving toward resilient, backpressure-aware architecture.