Enhancements of Fixed-Priority Sporadic Server: We now discuss several enhancements as an exercise in server design. If we are willing to make sporadic servers somewhat more complex and pay for slightly higher scheduling overhead, there are many ways to replenish the execution budget more aggressively and preserve it longer. One point to keep in mind in this discussion is the relationship between the replenishment and consumption rules. If we change one rule, we may need to change some other rule(s) in order for the entire set of rules to remain correct.

Sporadic/Background Server. The example in Figure 7–8 tells us that rule R3b of the simple fixed-priority sporadic server is overly conservative. At time 18.5, the periodic system becomes idle. The aperiodic job A3 remains incomplete, but the server budget is exhausted. According to this rule, the budget is not replenished until the job J3,2 is released at 19. While A3 waits, the processor idles. It is clear that the schedulability of the periodic system will not be adversely affected if we replenish the server budget at 18.5 and let the server execute until 19 with its budget undiminished. In this way, the server claims all the background time that is not used by the periodic task system. For this example, A3 would complete by time 19 if the server were allowed to claim the background time. We call a sporadic server that claims the background time a sporadic/background server; in essence, it is a combination of a sporadic server and a background server and is defined by the following rules.

• Consumption rules of simple sporadic/background servers are the same as the rules of simple sporadic servers except when the period task system is idle. As long as the periodic task system is idle, the execution budget of the server stays at es .
• Replenishment rules of simple sporadic/background servers are same as those of the simple sporadic server except R3b. The budget of a sporadic/background server is replenished at the beginning of each idle interval of the periodic task system. tr is set at the end of the idle interval.

When there is only one server in the system, there is no reason not to make it a sporadic/ background server. When there is more than one sporadic/background server, the highest priority server gets the background time whenever it can execute at the time. This may or may not be desirable. For this reason, we may want to keep some servers simple and give the background time to some other servers, or even make all sporadic servers simple servers and use a separate background server to execute in the background of the periodic task system and the servers.

As an example, suppose that a system has two aperiodic tasks. The jobs in one task are released whenever the operator issues a command, and their execution times are small.We use a sporadic server to execute these jobs. In order to make the system responsive to the operator, we choose to make the server period 100 milliseconds and execution budget sufficiently large to complete a job (at least most of time). Each job of the other aperiodic task is released to process a message. The messages arrive infrequently, say one a minute on the average. The execution times of jobs in this task vary widely because the messages have widely differing lengths. To execute these jobs, we use a sporadic server with a much longer period. Suppose that the system is scheduled rate-monotonically.We may want to give all the background time to the message-processing server. This can be done by making the command-processing server a simple sporadic server and the message-processing server a sporadic/background server.

Cumulative Replenishment. A reason for the simplicity of simple sporadic servers is that all the budget a server has at any time was replenished at the same time. In particular, a simple server is not allowed to cumulate its execution budget from replenishment to replenishment. This simplifies the consumption and replenishment rules. A way to give the server more budget is to let the server keep any budget that remains unconsumed. In other words, rather than setting the budget to es , we increment its budget by es units at each replenishment time. Hence the budget of a server may exceed es . As a result of this change in replenishment rule R1, the server emulates a periodic task in which some jobs do not complete before the subsequent jobs in the task are released. Of course, as stated in the beginning of this section, we must take into account the fact that the response times of some server jobs may be longer than the server period when we check for the schedulability of the periodic tasks and choose the server parameters ps and es accordingly.

Figure 7–10 gives an example. The server with period 15 and execution budget 6 cannot consume its budget at time 15 when its budget is replenished. This example illustrates that it is safe to increment its budget by 6 units. By doing so, the server emulates the periodic task (15, 6) whose first job cannot complete within one period. As a consequence of this enhancement, the server completes the aperiodic job A2 by time 27. In contrast, a simple sporadic server cannot complete the job until time 36.

Let us now examine an enhanced sporadic server which increments its budget by es units at each replenishment and see what its consumption rules should be. Clearly, the budget still should be consumed at the rate of 1 per time unit whenever the server is executing; rule C1 of simple sporadic servers always applies. However, we need to modify rule C2 of simple sporadic servers to make it work for an enhanced sporadic server. In particular, it is necessary to treat the es-unit chunk of new budget replenished at the latest replenishment time differently from the chunk of old budget left unconsumed at the time. Whenever the server has both new budget and old budget, it always consumes the old budget first; this emulates the behavior that jobs in a periodic task are executed in the FIFO order whenever more than one job of the task is ready for execution at the same time.

At any time t after the latest replenishment time tr , it is still safe to consume the new budget according to C1 and C2. However, we cannot use rule C2 to govern the consumption of the old budget. To see why, we note that because of the way tr was determined, the server must have executed in the interval between the replenishment time of the old budget and tr . Hence after tr , the old budget should be consumed at the rate of 1 per unit time when the server is suspended and the higher-priority subsystem TH is idle independent of whether the server has executed since tr . To illustrate this point, we look at the example in Figure 7–10 again and suppose that job A2 is released at time 17 instead. From time 15 to 17 while the lower-priority task (59, 5) is executing, the server holds on to its new budget replenished at time 15 according to rule C2. However, the 1-unit chunk of old budget should be consumed by

time 16, leaving the server with only its new budget at 16. You may want to convince yourself that if the server were to consume the old budget according to rule C2 (i.e., holding on the budget as long as its has not executed since tr ), it would in essence defer the use of the old budget, and this deference might affect the schedulability of some lower-priority task. It is easy to see that we can further improve the replenishment rule R3a as follows:

Replenish the budget at time tr ps whenever the higher-priority subsystem TH has been busy throughout the interval (tr , tr ps ]. This additional change in replenishment rules in turn makes it necessary to treat the budget that is not consumed in this interval with care. As an exercise in server design, you may want to write up consumption and replenishment rules of enhanced sporadic servers. You can find the statement of this exercise in Problem 7.11.