Kindly revert me a exact behaviour of for loop by changing the "#0 delay" position for the below code

In reply to kitanisi:

In reply to Sriram Yalavatti:
Hi,
Doubt 1.
Nobody predict the order of threads which are scheduled in same time slot.
This is because SystemVerilog/VHDL are for Hardware design, not software.
In Hardware world, nobody knows the order of simultaneous events.
You should keep it in your mind.
Doubt 2.
These behaviours are correct.
The key to understand these behaviour is - in which timeslot (when) is “i++” executed.

  • same time slot as $display, or
  • one time slot later (because of #0) from $display.

Hello kitanisi,

Thank you for the response,

1)Your assumption is wrong about prediction of threads which are schedules in same time slot,
Why because if we do not have any control over the forks then the threads present in the
fork-join, fork-join_any and fork-join_none will execute sequentially.
example code:

module semaphore_example;
class driver;

		task send(input string message);
  	        begin
		fork 
			
		 begin	
		 sem.get(2);
		 $display("=======%s",message);
		 sem.put(1);
		 end

		begin
                sem.get(1);
		$display("---------%s",message);
		sem.put(2);
	        end
		
	 	begin  
                sem.get(2);
		$display("+++++++++%s",message);
		sem.put(1);
		end
		join
		end
		endtask
  end	
endclass


driver dr[3];
semaphore sem;

initial begin

	foreach(dr[i])
		dr[i]= new();
	
sem = new(2);

fork 
	
    dr[1].send("driver12");
    dr[0].send("driver1");
    dr[2].send("driver13");
    dr[1].send("driver2");
join_none
end
endmodule
     Try to analyse the above code with semaphore concept to control the threads. At the same time change the thread positions which are inside the send task then you will come to know how the thread is giving priorities to the threads.

2)If the behaviour is correct can you just elaborate the process in words, I couldn’t able to understand your points.