Thread safety in design in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Thread Safety in Shared Resource Access

In a multi-threaded system, what is the main reason to use locks when multiple threads access a shared resource?

A To prevent threads from reading stale data by ensuring exclusive access during updates

B To increase the speed of thread execution by allowing simultaneous writes

C To allow threads to skip resource access if another thread is using it

D To reduce memory usage by sharing locks among unrelated resources

💡 Hint

Think about what happens if two threads write to the same data at the same time.

Locks ensure that only one thread can modify or read the shared resource at a time, preventing inconsistent or corrupted data.

❓ Architecture

intermediate

Designing a Thread-Safe Counter

You need to design a thread-safe counter that multiple threads can increment concurrently without losing updates. Which design choice ensures correctness?

A Use an atomic increment operation provided by the hardware or language runtime

B Use a simple integer variable without synchronization

C Use a global lock but only lock during reads, not writes

D Use separate counters per thread without combining results

💡 Hint

Consider how to avoid race conditions when multiple threads update the same value.

Atomic operations guarantee that increments happen without interruption, preventing lost updates.

❓ scaling

advanced

Scaling a Thread-Safe Cache System

You have a cache accessed by many threads. Using a single global lock causes contention and slows down the system. Which design improves scalability while maintaining thread safety?

A Use a single lock but increase its timeout to reduce waiting

B Partition the cache into multiple segments, each with its own lock

C Remove all locks and rely on eventual consistency

D Use a global lock but only lock during cache misses

💡 Hint

Think about dividing work to reduce contention.

Segmenting the cache reduces lock contention by allowing parallel access to different parts.

❓ tradeoff

advanced

Choosing Between Locking and Lock-Free Designs

Which is a key tradeoff when choosing a lock-free data structure over a lock-based one?

A Lock-free designs guarantee better performance in all scenarios

B Lock-free designs always use more memory and are slower than lock-based ones

C Lock-based designs never cause deadlocks or performance issues

D Lock-free designs reduce blocking but are often more complex to implement and debug

💡 Hint

Consider complexity and debugging challenges.

Lock-free designs avoid blocking but require careful design to avoid subtle bugs and are harder to maintain.

❓ estimation

expert

Estimating Maximum Throughput with Locks

A system has 8 threads accessing a shared resource protected by a single lock. Each thread holds the lock for 5 milliseconds per operation. Assuming no other delays, what is the maximum number of operations per second the system can perform?

A 400 operations per second

B 1600 operations per second

C 200 operations per second

D 800 operations per second

💡 Hint

Calculate how many operations fit in one second considering the lock is exclusive.

Since the lock is exclusive, only one thread can operate at a time. Each operation takes 5 ms, so 1000 ms / 5 ms = 200 operations per second.

Practice

1. What does thread safety in system design primarily ensure?

easy

A. Multiple threads can access shared data without causing errors

B. The system runs faster by using more threads

C. Only one thread runs at a time in the entire system

D. Threads do not use any shared resources

Solution

1. Step 1: Understand thread safety concept

   Thread safety means multiple threads can work with shared data without causing conflicts or errors.

2. Step 2: Analyze options

   Multiple threads can access shared data without causing errors correctly states this. Options B, C, and D misunderstand thread safety or describe unrelated concepts.

3. Final Answer:

   Multiple threads can access shared data without causing errors -> Option A

4. Quick Check:

   Thread safety = safe shared data access [OK]

Hint: Thread safety means safe shared data access [OK]

Common Mistakes:

• Confusing thread safety with performance
• Thinking only one thread runs at a time
• Assuming no shared data is used

2. Which of the following is the correct way to declare a lock object in a typical low-level design for thread safety?

easy

A. lock = synchronized()

B. lock = new Lock()

C. lock = create_lock()

D. lock = Lock()

Solution

1. Step 1: Identify common lock declaration syntax

   In many low-level designs, a lock is created by calling a constructor like Lock().

2. Step 2: Compare options

   lock = Lock() uses lock = Lock(), which is typical. lock = new Lock() uses 'new' which is not common in low-level design languages. lock = create_lock() and D use incorrect or non-standard functions.

3. Final Answer:

   lock = Lock() -> Option D

4. Quick Check:

   Lock creation = Lock() [OK]

Hint: Lock objects are usually created by calling Lock() [OK]

Common Mistakes:

• Using 'new' keyword incorrectly
• Assuming lock creation uses special functions
• Confusing lock with synchronization keyword

3. Consider this pseudocode for a shared counter increment:

lock.acquire()
counter = counter + 1
lock.release()
print(counter)

If two threads run this code simultaneously starting with counter = 0, what is the possible output?

medium

A. 0

B. 3

C. 2

D. Any number greater than 2

Solution

1. Step 1: Understand lock usage in code

   The lock ensures only one thread increments the counter at a time, preventing race conditions.

2. Step 2: Calculate final counter value

   Two threads each increment once, so counter goes from 0 to 2 safely.

3. Final Answer:

   2 -> Option C

4. Quick Check:

   Lock ensures increments are safe, so counter = 2 [OK]

Hint: Locks prevent lost updates, so increments add up [OK]

Common Mistakes:

• Ignoring lock and assuming race condition
• Thinking output can be 0 or 1 due to concurrency
• Assuming counter can exceed 2 without loops

4. In this code snippet, what is the main thread safety issue?

lock.acquire()
shared_list.append(1)
# Missing lock.release()

medium

A. No issue, code is safe

B. Deadlock due to missing lock release

C. Syntax error in lock usage

D. Race condition on shared_list

Solution

1. Step 1: Analyze lock usage

   The code acquires a lock but never releases it, causing other threads to wait forever.

2. Step 2: Identify consequence

   This causes a deadlock, where threads block indefinitely waiting for the lock.

3. Final Answer:

   Deadlock due to missing lock release -> Option B

4. Quick Check:

   Missing release = deadlock [OK]

Hint: Always release locks to avoid deadlocks [OK]

Common Mistakes:

• Thinking race condition occurs despite lock
• Assuming syntax error without checking code
• Believing code is safe without release

5. You design a system where multiple threads update a shared cache. To improve performance, you want to minimize locking time. Which design approach best balances thread safety and performance?

hard

A. Use fine-grained locks for each cache entry

B. Avoid locks and allow unsynchronized updates

C. Use a single global lock for all cache updates

D. Lock the entire cache for every read and write

Solution

1. Step 1: Understand locking strategies

   A single global lock (Use a single global lock for all cache updates) causes contention and slows performance. No locks (Avoid locks and allow unsynchronized updates) risks data corruption. Locking entire cache for reads and writes (Lock the entire cache for every read and write) is too heavy.

2. Step 2: Choose fine-grained locks

   Fine-grained locks (Use fine-grained locks for each cache entry) lock only parts of the cache, reducing waiting time and keeping thread safety.

3. Final Answer:

   Use fine-grained locks for each cache entry -> Option A

4. Quick Check:

   Fine-grained locks = safety + speed [OK]

Hint: Fine-grained locks reduce wait and keep safety [OK]

Common Mistakes:

• Using one big lock causing slowdowns
• Skipping locks causing data errors
• Locking too much causing bottlenecks