next up previous
Next: ctxsw Up: Xinu Mechanism for Previous: Ready List

resched

resched is a routine that is called by the current process when rescheduling is to take place. It is called not only when the time quantum of the current process expires but also when a blocking call such as wait is invoked by the current process or when a new process (of potentially higher priority) becomes eligible for execution. (We shall discuss later the exact conditions that determine when a rescheduling takes place)

The routine does the following:

Choosing a New Process: It chooses the new process to execute based on the scheduling policy described above. Thus it looks at the process at the tail of the ready list. If the priority of this process is lower than the priority of the current process, then the current process, if it is executable, retains control of the CPU and the routine returns. (The scheduling policy dictates that a lower priority process in the ready list will be executed only if there are no higher priority processes in the list). Otherwise the process at the tail of the process is chosen as the new process and the following steps are taken.

Change of State of New Process: The new process is removed from the ready list, its state is changed from ready to current.

Allocation of Time: The new process is is allocated a time interval to execute (we shall study later how this is done). This time interval is the maximum time it will execute control before rescheduling takes place.

Change of State of Old Process: The new state of old process depends on what caused the reshedule. If a timer interrupt caused it, then the the new state is ready. If on the other hand, a blocking call caused it, then the new state depends on the kind of blocking call. For example, in case of a semaphore wait call, the new state is wait. How does resched() set the right value of the state? More important, should it even be aware of state values such as wait assigned by higher layers?

The answer to the second question is No if we wish to strictly adhere to a layered architecture. Therefore, in Xinu, resched() assigns state values defined by it and leaves to higher level layers the job of assigning state values defined by them. The routine resched is never called directly by the user process. It is called indirectly by some other system provided routine such as wait on a semaphore. This routine may change the state of the process to a value defined by it. For instance wait changes the state of process to wait (as we will discuss later). At the point resched is called, the process is executable only if its state is still current. resched uses this information to determine if the old process needs to be put in the ready list. If the state is current it changes it to ready and inserts the process behind other processes with the same priority (so that it is picked last among processes with the same priority, thus ensuring round robin scheduling among processes with the same priority), and in front of processes with lower priority (so that a higher priority process is scheduled before a lower priority one). Otherwise it leaves the process untouched since some other routine took care of changing the state of the process and putting it in an appropriate list.

Call to ctxsw: Finally the routine ctxsw (discussed below) is called. This routine does work that cannot be done in a high level language (compared to assembly language) like C.



next up previous
Next: ctxsw Up: Xinu Mechanism for Previous: Ready List



Prasun Dewan
Tue Jan 20 11:58:31 EST 2004