But again, there is a chance that the data transfer is slower than the delay I had introduced.
Just try playing with the delay value a little to see if that helps.
Now, the problem here is, apart from the scheduler and the worker, there is the hardware which singals the worker of the availability of the packet. Now, if the signal by the worker was sent before the scheduler can execute the ctx_arb [inter_thread], then I felt the singal is missed for good and the scheduler will wait for ever. Can you tell me if the concept of missed signal is valid ?
Yes, I think that there is a race condition here, as you described above, and the signal can be missed. However, even if the signal is not missed, this method still does not seem to guarantee that the rcv-rdy bits will not be stale. Note that there is still some delay between the worker thread reading the rcv_cntl register and signalling the scheduler to go ahead, and the FBI sampling the ports and refreshing the rcv_rdy bits. The FBI does not clear off the rcv_rdy bit after moving data from the port to the fifo, it overwrites it with the new bits when it samples the ports again. So, I think you just narrowed the window, but the bits could still be stale. So even with this handshake method, you would still need a delay loop before the scheduler reads the bits again (assuming the turnaround time is quick).