Câu hỏi phỏng vấn Concurrency

Your team maintains a shared counter updated by 32 worker threads on a 16-core server. The current implementation uses a mutex around `counter++`. A colleague proposes replacing it with a lock-free loop using an atomic compare-and-swap (CAS) on the counter, arguing it will 'eliminate blocking and always be faster'. Under sustained high contention from all 32 threads hammering the same cache line, what is the most accurate assessment of this trade-off?

Two threads in a banking app each need to lock both `accountA` and `accountB` to transfer money. Thread 1 does `lock(accountA); lock(accountB);` while Thread 2 does `lock(accountB); lock(accountA);`. Occasionally the program freezes with both threads stuck and no CPU usage. What is happening, and what is the simplest fix?

Your team maintains a Python service that handles ~2000 concurrent client connections, each spending most of its time waiting on HTTP calls to downstream APIs, plus a short CPU-bound JSON signature check (~5ms) per request. The service currently uses a thread pool of 200 OS threads. A colleague proposes rewriting it on asyncio with a single event loop. What is the most accurate assessment of this trade-off?

In an operating system, an application creates execution units to perform tasks concurrently. How does memory sharing differ between multiple threads within the same process compared to multiple independent processes?

In a high-throughput multi-threaded application, you replace a mutex-protected counter with a single `std::atomic<int64_t>` using `fetch_add`. While this initially improves throughput, the system experiences significant performance degradation on multi-socket servers under heavy contention, characterized by high CPU utilization despite low effective throughput. What is the physical mechanism causing this performance collapse, and what is the standard architectural mitigation for high-frequency write contention in this scenario?