Concurrency and Synchronization Questions

Covers the principles and practical techniques for safely coordinating concurrent execution and access to shared resources. Topics include models of concurrency such as threads, processes, interrupt handlers, and tasks in a real time operating system; differences between preemptive and cooperative scheduling; shared data hazards including race conditions and read modify write hazards; critical sections and approaches to protect them including disabling interrupts in embedded contexts and scoped locks. Synchronization primitives and patterns are included: mutexes, binary semaphores, counting semaphores, condition variables, message queues, atomic operations and lock free primitives such as compare and swap. Memory ordering concerns and memory barrier usage on multi core systems are covered, along with priority inversion and priority inheritance. Also addressed are deadlock, livelock, and starvation concepts and avoidance strategies, granularity and performance trade offs of locking, and practical synchronization patterns. Preparation should include identifying and fixing races in code, designing correct concurrent interfaces, and debugging and testing techniques such as stress testing, instrumentation, deterministic replay, race detectors, static analysis, and code review strategies.

MediumTechnical

68 practiced

A cryptographic key rotation job updates in-memory keys while request threads verify tokens. What synchronization pattern would you use to guarantee readers see a consistent key version without pausing all traffic?

HardTechnical

55 practiced

A static analyzer flags a potential data race in a secure telemetry collector, but the team believes the code is safe because the write is atomic. How would you evaluate whether the code is actually safe, and what additional issues besides atomicity would you check?

MediumTechnical

59 practiced

Implement a thread-safe sliding-window rate limiter in C++ for login attempts. It must support many concurrent callers, keep the hot path fast, and return allow or deny for each request. Explain your data structures and synchronization strategy, including how you would expire old entries.

Sample Answer

For a login rate limiter, I would use a sliding-window counter with per-key buckets, protected by sharding. The hot path should be O(1): hash the client/user key to a shard, lock only that shard, expire old buckets, update the current bucket, and decide allow/deny.

cpp

struct Bucket { int64_t ts; int count; };

Each shard can hold a deque of time buckets plus a running total. On each request:- Compute current time window- Lock the shard mutex briefly- Remove expired buckets from the front- If total >= limit, deny- Otherwise increment the current bucket and allow

I would keep expiration lazy, triggered by reads/writes, so there is no background sweeper on the critical path. For many concurrent callers, sharding reduces contention far better than one global lock. If I needed even lower latency, I could use atomics for per-bucket increments, but I would be careful about complexity and exactness.

Complexity is O(1) amortized per request per shard, with bounded memory based on the number of active windows.

HardTechnical

57 practiced

Given a security appliance that must process packets in parallel across cores, identify where memory barriers or acquire/release semantics would be required if one thread publishes a new rule table and another thread consumes it. What bugs can appear if the barriers are wrong or missing?

Sample Answer

The key point is that the new rule table must become visible to other cores only after it is fully initialized.

**Where barriers are needed**- The publishing thread initializes the table, then performs a release store when swapping the global pointer.- The consuming packet thread loads that pointer with acquire semantics before dereferencing the table.- If there is a reference count or generation number, its updates also need ordering with the table publication.

text

writer: init table -> release store(global_table = new_table)
reader: acquire load(ptr = global_table) -> use table

**What can go wrong**- The reader may see the new pointer but stale contents inside the table.- One core may observe partially initialized rules, causing false accepts or false drops.- Reordering can break reference counts and free a table while still in use.

**Security impact**In a packet processor, that can become policy bypass, inconsistent filtering, or a crash under load. I would also prefer RCU-style publication for read-heavy tables, because it gives fast reads and safe replacement with a clear grace period.

HardSystem Design

100 practiced

In a multi-tenant SIEM pipeline, several threads update shared correlation state, per-tenant quotas, and alert deduplication tables. Design a synchronization strategy that prevents deadlocks and reduces contention while still preserving tenant isolation and predictable latency.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.