SystemVerilog - Are multiple fork join statements mutually concurrent/parallel

Question

Lets say I have task which is called an unknown amount of times by an external condition that I (the task designer) do not know, this task then must create a thread and execute a different task is parallel (for example, to receive data for a read request that was dispatched). There could be multiple calls to Dispatch_Tx so multiple threads would need to be created (Receive_Data cannot block Dispatch_Tx from finishing). (traffic may be out-of-order, and many interleaved requests must be processed simultaneously) s. The fork...join syntax shows that threads created inside of it are indeed concurrent, however, are multiple fork...join's themselves mutually concurrent?

interface ...
.
.
.
task automatic Dispatch_TX(input clk);
 .
 .
 .
 fork 
 Receive_Data();
 join_none
endtask
.
.
.
endinterface

So in the above example, would there be multiple threads for the Receive_Data() task.

This is written in the LRM:

Table 9-1—fork-join control options: " join_none: The parent process continues to execute concurrently with all the processes spawned by the fork. The spawned processes do not start executing until the parent thread executes a blocking statement or terminates."

I may be wrongfully equating process == thread, but this seems to suggest a fork_join is only concurrent with the parent thread.

• dave_59: If Receive_Data() is non-blocking, that is it cannot consume time, then putting a fork around it makes no sense. If the calls to Dispatch_TX are from different forked threads, are you concerned about atomic execution within those threads?
• DR. Palson_PH.d: Receive_Data() is blocking, so I can't get away with using a function(). The calls are made by one single for loop, however the condition for the call to be made relies entirely on the space in a queue -- which is dynamic/unpredictable. My concern is that fork...join may be a "Queued process" i.e. the execution of each is dependent on sequential/temporal ordering. I want to confirm that multiple fork...join_none calls each create a seperate threads to execute Recieve_Data(). From the quick read I did of chapter 9 of the LRM, I wasn't able to confirm this
• DR. Palson_PH.d: I think this is relevant to my question: Table 9-1—fork-join control options: " join_none: "The parent process continues to execute concurrently with all the processes spawned by the fork. The spawned processes do not start executing until the parent thread executes a blocking statement or terminates." -- Seems to suggest that the concurrency is only among the fork_jone_none and the parent thread, but what about other fork_join_nones?

Answer 1

All threads are concurrent by defintion. Does not matter how they created. https://verificationacademy.com/forums/systemverilog/process-vs-thread

• DR. Palson_PH.d: bit odd that fork join_none doesn't start right away after join_none is reached.
• dave_59: This was done to preserve some predictability in the behavior of the code the follows the join_none. Comes more into play when the fork/join_none is in a loop.