Join, Join Any and Join None

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

1. Join, Join Any and Join None
2. What IfThe Timeout That Killed the MonitorL1 JuniorL2 Mid-Level

   Asked once they add disable fork

   After a request-with-timeout task was added, a background beat counter in the same test stops counting. Here is the task and the log. What happened?

   // task wait_resp: fork response / timeout join_any; disable fork;
   @0    beat counter forked (join_none)
   @25   beats=3
   @30   response received, disable fork
   @80   beats=3          <- counter stopped at t=30

   Reveal the Model Answer

   disable fork kills every active descendant of the calling process, not just the fork above it. The task runs in the test's process, so it also killed the counter the test had forked earlier. Put the race in its own scope, fork begin ... end join around it, so disable fork only reaches the response and timeout branches.

   1. Bare: everything is a child of the testt=5 (illustrative)

      The test forks the monitor. Then wait_rsp_bare runs inside the test process, so the response and timer branches it forks are children of the test too.

      More context

      The response model, fork #6 rsp = 1; join_none, is a child of the test as well. It sets rsp at t=11 and ends, so it is not drawn.

      Follow the calls, values and waits

      1. call fork: Test process → Monitor
      2. call fork: Test process → Response branch
      3. call fork: Test process → Timer branch
      4. Waiting: Test process — join_any
      5. Waiting: Response branch — waiting for rsp
      6. Waiting: Timer branch — counting to t=25
   2. The response winst=11 (illustrative)

      The response branch prints t=11 response and finishes, so join_any returns. The monitor has beaten once, at t=9.

      Follow the calls, values and waits

      1. return done: Response branch → Test process
      2. Released: Response branch
      3. Released: Test process
   3. disable fork in the test processt=11 (illustrative)

      disable fork stops every child of the process that runs it. That is the test, so the timer and the monitor both stop, and t=22 prints beats=1.

      Follow the calls, values and waits

      1. call disable: Test process → Timer branch
      2. call disable: Test process → Monitor
      3. Released: Timer branch
   4. Wrapped: the race gets its own parentt=22 (illustrative)

      The test forks a new monitor. wait_rsp_wrapped forks a wrapper process, and the wrapper forks the response and timer branches.

      Follow the calls, values and waits

      1. call fork: Test process → Monitor
      2. call fork: Test process → Wrapper process
      3. call fork: Wrapper process → Response branch
      4. call fork: Wrapper process → Timer branch
      5. Waiting: Test process — join
      6. Waiting: Wrapper process — join_any
      7. Waiting: Response branch — waiting for rsp
      8. Waiting: Timer branch — counting to t=42
   5. disable fork in the wrappert=28 (illustrative)

      The response wins at t=28. Now disable fork runs in the wrapper, so it stops only the timer. The wrapper ends and the task returns.

      Follow the calls, values and waits

      1. return done: Response branch → Wrapper process
      2. call disable: Wrapper process → Timer branch
      3. Released: Response branch
      4. Released: Timer branch
      5. Released: Wrapper process
      6. Released: Test process
   6. The monitor survivest=39 (illustrative)

      The monitor beats at t=26, 30, 34 and 38, so t=39 prints beats=4.

   Read the diagram as text

   • Monitor: forever #4 beats++
   • Test process: calls the wait task
   • Wrapper process: fork begin ... end join
   • Response branch: bare race: wait (rsp)
   • Timer branch: bare race: #20 TIMEOUT
   • Response branch: wrapped race: wait (rsp)
   • Timer branch: wrapped race: #20 TIMEOUT

   • Test process → Monitor: child
   • Test process → Response branch: child
   • Test process → Timer branch: child
   • Test process → Wrapper process: child
   • Wrapper process → Response branch: child
   • Wrapper process → Timer branch: child

   disable fork acts on the process that runs it. The wrapper gives the race a process of its own.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 disable fork kills every active descendant of the calling process, not just the fork above it. Key point 2 The task runs in the test's process, so it also killed the counter the test had forked earlier. Key point 3 Put the race in its own scope, fork begin ... end join around it, so disable fork only reaches the response and timeout branches.

   What Interviewers Listen For (Junior)

   A good junior answer says that calling a task does not create a new process. So disable fork inside the task reaches the caller's children too.

   Misconception

   "disable fork kills only the processes of the fork statement just before it."

   It kills all active descendants of the current process. The twin loses a background monitor forked earlier by the same test.

   Run It

   A response-or-timeout task called from a test that already forked a beat counter.

   RUNVerilator · simulator service

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: ok=1 beats=3 FAIL: disable fork also killed the monitor this process forked earlier

   See the Fix

   module tb;
     logic clk = 0;
     int beats = 0;
     bit ok;
     always #5 clk = ~clk;
     task automatic wait_resp();
       fork begin                   // the fix: a private scope for the race
       fork
         begin #30 ok = 1; end      // the response
         begin #100 ok = 0; end     // the timeout
       join_any
       disable fork;                // kill the loser
       end join
     endtask
     initial begin
       fork
         forever @(posedge clk) beats++;   // a background monitor forked earlier
       join_none
       wait_resp();
       #50 $display("ok=%0d beats=%0d", ok, beats);
       if (beats < 5) $display("FAIL: disable fork also killed the monitor this process forked earlier");
       else $display("PASS: only the timeout was killed; the monitor kept counting");
       $finish;
     end
   endmodule
   

   Prints: ok=1 beats=8 PASS: only the timeout was killed; the monitor kept counting

   Missed Corner

   "Use disable wait_resp instead; it only touches the task."

   Disabling a named task stops every active call of that task, in every thread, which is a different trap.

   Source IEEE 1800-2017 §9.6.2

   • Lesson 3.3Fork, Join and Cancellation
   • Problem 3.3.3Cancellation Scope Repair
   • Problem 3.3.6The Timer That Outlived Its Race
3. WhyWhy a Task Call Shares the Caller's ProcessL1 JuniorL2 Mid-Level

   Why did the task's disable fork reach a process the task never created?

   Reveal the Model Answer

   Calling a task does not start a new process; the task's statements run in the caller's process, as if pasted in. So the children of "the current process" include everything the caller had forked before the call. Only fork creates new processes.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Calling a task does not start a new process; the task's statements run in the caller's process, as if pasted in. Key point 2 So the children of "the current process" include everything the caller had forked before the call. Key point 3 Only fork creates new processes.

   Misconception

   "Every task call runs in its own thread."

   Tasks run in the calling thread. Concurrency comes only from fork, initial, always and similar constructs.

   Source IEEE 1800-2017 §9.5

   • Lesson 3.3Fork, Join and Cancellation
4. What IfScoping Disable Fork to the TaskL1 JuniorL2 Mid-Level

   What if you must keep disable fork in the task? How do you make it stop only the task's own children?

   Reveal the Model Answer

   Wrap the race in its own process: fork begin ... end join. Inside that block, the race's children are the only children of the new process. A disable fork there stops only them. The caller's monitors keep running.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Wrap the race in its own process: fork begin ... end join. Key point 2 Inside that block, the race's children are the only children of the new process. Key point 3 A disable fork there stops only them. Key point 4 The caller's monitors keep running.

   Missed Corner

   "Use wait fork instead; it is safer."

   wait fork also acts on every child of the process, including the caller's monitors. A forever monitor makes it hang.

   Source Lesson 3.3 key points

   • Lesson 3.3Fork, Join and Cancellation
   • Problem 3.3.3Cancellation Scope Repair
5. CompareProcess Handles vs Disable ForkL2 Mid-Level

   Compare killing the timeout through a process handle with using disable fork.

   Reveal the Model Answer

   Inside each branch, process::self() returns a handle, and calling kill() on the timeout's handle stops exactly that process and its descendants. disable fork is shorter but reaches everything the current process has forked. Handles also let you await() a process or check its status(), which suits library code that must not touch the caller's threads.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Inside each branch, process::self() returns a handle, and calling kill() on the timeout's handle stops exactly that process and its descendants. Key point 2 disable fork is shorter but reaches everything the current process has forked. Key point 3 Handles also let you await() a process or check its status(), which suits library code that must not touch the caller's threads.

   Misconception

   "kill() on a handle stops only that process; its children keep running."

   Killing a process also kills the processes it spawned.

   Source IEEE 1800-2017 §9.7

   • Lesson 3.3Fork, Join and Cancellation
6. Prove ItSolve 3.3.3: Cancellation Scope RepairSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 3.3.3

7. Scale ItProcesses That Outlive Their TestL3 Senior

   A regression runs hundreds of sequences in one simulation. How do leftover timers and watchers from join_any races show up, and what rule prevents them?

   Reveal the Model Answer

   They fire later, in an unrelated sequence. A stale timeout reports an error, or a watcher takes an event meant for someone else. The failure depends on which sequences ran before. The rule is that every race ends with an explicit cleanup in its own scope, fork begin ... end join around the race plus disable fork. End-of-test checks then confirm that no sequence-owned processes are still alive.

   One column per 100 ns. The task returned at 100 ns, but its timer branch kept running.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 They fire later, in an unrelated sequence. Key point 2 A stale timeout reports an error, or a watcher takes an event meant for someone else. Key point 3 The failure depends on which sequences ran before. Key point 4 The rule is that every race ends with an explicit cleanup in its own scope, fork begin ... end join around the race plus disable fork. Key point 5 End-of-test checks then confirm that no sequence-owned processes are still alive.

   What Interviewers Listen For (Senior)

   A good senior answer links failures that depend on test order to processes left running. It turns the cleanup into a review rule and an end-of-test check.

   Misconception

   "Leftover processes die when the sequence object is garbage collected."

   A process is not owned by the object that started it. It runs until it finishes or is killed.

   Source IEEE 1800-2017 §9.7

   • Lesson 3.3Fork, Join and Cancellation
   • Lesson 7.7Capstone: The Complete Layered Testbench
   • Problem 3.3.6The Timer That Outlived Its Race
   • Problem 7.7.3Premature Test Completion
8. CompareFork Join vs Begin EndL0 Fresher

   Compare begin #5 a = 1; #5 b = 1; end with the same two statements inside fork ... join. When does b become 1?

   Reveal the Model Answer

   In begin ... end the statements run in sequence, so b is set at t=10. In fork ... join, each statement is its own process, and all start at the same time. Both delays count from t=0, so b is set at t=5. The fork still finishes only when both are done.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 In begin ... end the statements run in sequence, so b is set at t=10. Key point 2 In fork ... join, each statement is its own process, and all start at the same time. Key point 3 Both delays count from t=0, so b is set at t=5. Key point 4 The fork still finishes only when both are done.

   Half-Truth

   "fork runs statements in parallel, so it is always faster."

   It changes when they start, not how long each takes. Dependent steps inside a fork can race or run in the wrong order.

   Source IEEE 1800-2017 §9.3.2

   • Lesson 3.3Fork, Join and Cancellation
9. Prove ItSolve 3.3.1: Wait for Two WorkersSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 3.3.1

10. Scale ItProcesses That Outlive Their TestL3 Senior

    A regression runs hundreds of sequences in one simulation. How do leftover timers and watchers from join_any races show up, and what rule prevents them?

    Reveal the Model Answer

    They fire later, in an unrelated sequence. A stale timeout reports an error, or a watcher takes an event meant for someone else. The failure depends on which sequences ran before. The rule is that every race ends with an explicit cleanup in its own scope, fork begin ... end join around the race plus disable fork. End-of-test checks then confirm that no sequence-owned processes are still alive.

    One column per 100 ns. The task returned at 100 ns, but its timer branch kept running.

    Self-Check

    Tick each key point you covered in your answer.

    Key point 1 They fire later, in an unrelated sequence. Key point 2 A stale timeout reports an error, or a watcher takes an event meant for someone else. Key point 3 The failure depends on which sequences ran before. Key point 4 The rule is that every race ends with an explicit cleanup in its own scope, fork begin ... end join around the race plus disable fork. Key point 5 End-of-test checks then confirm that no sequence-owned processes are still alive.

    What Interviewers Listen For (Senior)

    A good senior answer links failures that depend on test order to processes left running. It turns the cleanup into a review rule and an end-of-test check.

    Misconception

    "Leftover processes die when the sequence object is garbage collected."

    A process is not owned by the object that started it. It runs until it finishes or is killed.

    Source IEEE 1800-2017 §9.7

    • Lesson 3.3Fork, Join and Cancellation
    • Lesson 7.7Capstone: The Complete Layered Testbench
    • Problem 3.3.6The Timer That Outlived Its Race
    • Problem 7.7.3Premature Test Completion