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.
Receive_Data()is non-blocking, that is it cannot consume time, then putting aforkaround it makes no sense. If the calls to Dispatch_TX are from different forked threads, are you concerned about atomic execution within those threads? \$\endgroup\$fork...joinmay be a "Queued process" i.e. the execution of each is dependent on sequential/temporal ordering. I want to confirm that multiplefork...join_nonecalls 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 \$\endgroup\$