I have seen codes like the following one in a project in my company. Does it make sense to fork a single process/statement like the one in the following code? If it does, how these fork behave?
fork
forever begin
fork
function_1();
join_none
fork
function_2();
join_none
end
join
In reply to RB87:
The two functions1,2 will execute in a parallel manner…
In reply to RB87:
There is no difference between
forever begin
fork
statement_1;
join_none
fork
statement_2;
join_none
end
and
forever begin
fork
statement_1;
statement_2;
join_none
end
or
forever
fork
statement_1;
statement_2;
join_none
Can only guess this was from cut&paste.
BTW, it makes no sense to have a function call, or any other non-time consuming statement as a fork’ed process.
In reply to dave_59:
In reply to RB87:
There is no difference between
forever begin
fork
statement_1;
join_none
fork
statement_2;
join_none
end
and
forever begin
fork
statement_1;
statement_2;
join_none
end
or
forever
fork
statement_1;
statement_2;
join_none
Can only guess this was from cut&paste.
BTW, it makes no sense to have a function call, or any other non-time consuming statement as a fork’ed process.
Hi Dave,
Correct me, if I am wrong.
I feel in the first snippet of code, function_1 will always starts first and then, function_2 concurrently. But in case of snippet 2 and snippet 3 either of the function can start first based on the simulator.
In other words, in snippet 1 there won’t be any race condition, but snippet 2 and 3 will have race condition.
In reply to Narendra Sharma:
Correct me, if I am wrong.
You are wrong, I’m correcting you. :)
The process starting order is a race condition with both code snippets. The processes spawned by a fork/join_none gets queued and does not start executing until the parent process blocks or terminates. In this particular example that is not shown, so each iteration of the forever loop spawns two processes and gets into an infinite loop spawning more processes.