The Server Mechanism is the resource attribute that determines whether transactions can share a server. It has seven possible values: Dedicated_Server, Round_Robin, Processor_Sharing, Earliest_Deadline_First, Least_Laxity_First, OSEK_OS_Server and OSEK_Time_Server.
If this is set to Dedicated_Server, each server can process only a single transaction at a time, and server sharing is not enabled.
When the Server Mechanism is set to Round_Robin, each server can process several transactions at once, but does so by dedicating service in a round robin fashion. In round robin, each transaction sharing the server gets a time slice of service each time the server process it. The time slice given to each eligible transaction is an attribute of the transaction, and can vary from one transaction to another.
If the Server Mechanism is set to Processor_Sharing, all transactions sharing the server accumulate service time at a rate inversely proportional to the number of transactions sharing the server and proportional to the number of servers which they are sharing. If the time slice quantum is small compared to the service time of transactions and the time slice is the same for every transaction, Processor_Sharing is a good approximation to Round_Robin.
A server can be shared only by transactions with equal priorities. Also, a number of servers can be shared by a number of transactions, as long as all transactions sharing the servers have equal priority.
If the Server Mechanism resource attribute is set to Processor_Sharing, processor sharing begins at the point where the number of transactions in the server bank of equal priority becomes greater than the number of servers available to process that priority. For example, consider a server resource with two servers. If all transactions that request the resource have the same priority, then when a third transaction enters the resource while two others are being processed, the three transactions then share the two servers. If no other transactions arrive before one of them completes service, the completed transaction exits the resource, and the two remaining transactions no longer have to share the servers because they each have their own. If a fourth transaction had entered the resource before one completed, the two servers would then be shared by four transactions.
When transactions are sharing a server or servers, the rate at which they receive service time is proportional to the number of servers being shared and inversely proportional to the number of transactions sharing the server(s). Going back to the example in which the resource has two servers, at the time the two servers become shared by three transactions, each transaction is receiving two-thirds the service time it would if the server were not shared. If four transactions are sharing two servers, the accumulation of service time is one-half (2/4) the rate if each transaction had a dedicated server.
If the Context Switching Overhead resource attribute is nonzero, it is applied to each transaction when it begins being processed by a server. There is no extra service time lost due to processor sharing.
If the Server Mechanism resource attribute is set to Round_Robin, round robin server sharing begins when the number of transactions in the server bank of equal priority becomes larger than the number of servers available to process that priority. At that time, the new transaction is placed in a round robin wait list (there is a separate list for each priority that is sharing servers round robin). Then, the transactions in shared servers are checked to see if they have received their time slice since they most recently received the server. A transaction that had been processed by a dedicated server that crosses the threshold to round robin sharing is allowed to continue service until its time slice has completed. If it has received more than its time slice of service time since it received the server, it is put at the end of the round robin wait list. Then the transaction at the head of the round robin wait list is moved to that server and remains in the server until it completes its time slice or its service, whichever comes first. This continues for all shared servers. If a new transaction is to share a set of servers which are already shared round robin, the transaction is placed at the end of the round robin wait list.
When a transaction completes its service, the transaction at the head of the round robin wait list is moved to the server just freed by the completed transaction. If no more transactions are in the round robin wait list, the server(s) is no longer shared and crosses the threshold back to dedicated server.
If the Context Switching Overhead resource attribute is nonzero, it is applied each time a transaction gets a server. Specifically, the context switching overhead is applied at the beginning of the time slice.
If the Server Mechanism resource attribute is set to Earliest_Deadline_First, every scheduling event will be placed in a queue. Each server can process only a single transaction at a time, and server sharing is not enabled. The transaction which is the next to be scheduled for execution is the transaction closest to its deadline.
If the Server Mechanism resource attribute is set to Least_Laxity_First, every scheduling event will be placed in a queue. Each server can process only a single transaction at a time, and server sharing is not enabled. The transaction which is the next to be scheduled for execution is the transaction with the smallest "slack time". Slack time is defined as the difference between the deadline and the sum of the current time and the time the transaction consumes. The time a transaction needed is defined as the difference of the service time and the access time.
If there was some time between the insertion of transactions and "now", their laxity decreased since then.
Therefor all levels before using the Queue will be recalculated.