Puzzle

Difficulty: Medium · Puzzle 6 of 6 · Topic: Semaphore & Mailbox Puzzles

Does this pattern avoid deadlock? Explain why it still needs timing control and bounded retries.

Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

module tb;
  mailbox #(int) req_mb = new(2);
  mailbox #(int) rsp_mb = new(2);
  semaphore lock = new(1);

  task producer();
    int rsp;
    int sent = 0;
    while (!sent) begin
      if (req_mb.try_put(7)) sent = 1;
      else #1;
    end
    while (!rsp_mb.try_get(rsp)) #1;
    $display("[%0t] rsp=%0d", $time, rsp);
  endtask

  task consumer();
    int req;
    while (!req_mb.try_get(req)) #1;
    lock.get(1);
    rsp_mb.put(req + 1);
    lock.put(1);
  endtask

  initial fork
    producer();
    consumer();
  join
endmodule

Hint

No thread holds lock while waiting on mailbox progress.

Step-by-step solution

1) Producer retries try_put/try_get with #1 backoff, so no zero-delay spin.
2) Consumer acquires lock only around non-blocking short critical section.
3) No circular wait exists between lock and mailbox operations.
4) Pattern is deadlock-resistant but still needs timeout/limits for robustness.

Answer

Answer: Yes, this avoids classic lock+blocking-mailbox deadlock. It should print rsp=8 at a finite time, but production code still needs timeout guards.

Why candidates get it wrong

Deadlock-free does not mean livelock-free or starvation-free under all load patterns.

Interviewer follow-up

What timeout and error-report strategy would you add for regression triage?

Related topics

• Back to Semaphore & Mailbox Puzzles

• Concurrency & Timing Puzzles section