2.3 Round Robin

Round robin describes the behavior of threads sharing the same processor in a circular fashion. Imagine all the threads sit around a round table, and the processor is a server circling the table to serve each thread.

In most round robin implementations, a thread has the ability to voluntarily give up control, so that the next thread has a chance to execute. In our example, we may have the following code in the communication subroutine:

$\begin{algorithmic} \WHILE{there is in query} \STATE yield \ENDWHILE \end{algorithmic}$

In other words, each time the communication thread has a chance to execute, it checks to see if there is a query to reply. If not, it immediately yield control to the next available thread.

Round robin scheduling assuming threads give up control voluntarily is easy to implement. The costatements in Z-World's Dynamic C is basd on such an assumption. This assumption is useful for threads that do not have hard real-time deadlines. For example, communication with an operator often falls into this category. If it taska a controller half a second to reply, the operator probably will not consider it as a failure.

On the other hand, for operations with ``hard real-time constraints'', relying on peer threads to voluntarily give up control is not an option. Consider the control logic for a gripper that catches falling objects. A 50ms delay can lead to failure. We do not want to rely on peer threads to give up control in this case, because a poorly written peer thread may not give up control quickly enough.

This is the limitation of any implementation basd on the assumption of threads know when it should give up control. Such implementations are also called ``cooperative multithreading'' and ``cooperative multitasking''.