Server Resources

A Server Resource is logically the combination of two fundamental components: a queue and a bank of one or more servers.

A data structure enters a Service block to request processing from the resource. The data structure and several attributes, such as the requested service time, are together called a transaction. A transaction immediately moves to a server if one is idle, or may optionally preempt lower priority transactions. While being processed by a server, transactions accumulate service time and they exit the Service block when they received the required amount of service time. Accumulation of service time is affected by several resource attributes.

If a new transaction cannot immediately move into a server, it is placed in a queue where it waits for a server to become available. The queue is ordered first by priority, then according to the queuing discipline attribute: either first in first out (FIFO) or last in first out (LIFO).

Each server in a Server Resource is capable of distributing its processing power to more than one transaction. Server sharing methods are either processor sharing or round robin. When a server is shared using processor sharing, each transaction receives service at a reduced rate, where the reduction is proportionate to the number of transactions sharing the server. With round robin server sharing, each transaction sharing the server receives the full power of the server for a (usually small) amount of time, its time-slice. Then, the next transaction receives its time-slice, and so on. Each time a transaction receives its time-slice, its remaining time is reduced by that amount. When a transaction has received all of its service time, it exits the Service block.

The primary block for accessing a server resource is the Service block. The inputs to this block are the transaction attributes, such as service time needed, priority, and so on. When a transaction completes service, the data structure which entered the arbitrary data structure input is placed on the OutArbitraryDS output port. There are versions of the Service block which have fewer inputs, where some of the transaction attributes are parameters instead of inputs.

General operation

For every resource of type Server Resource and scope Internal, there is one queue and a bank of servers for every dimension of the resource. The number of servers in the server bank is specified by the Number of Servers attribute of the resource.

A transaction is a request for some amount of time in a server. Each transaction has attributes such as its priority, service time, and other attributes needed by the resource. When all inputs of a Service block are enabled, the combination of all input values makes up a new transaction. One of the inputs (InArbitraryDS) is a data structure of any type that is kept with the transaction. When a transaction has received its requested service time, this data structure is enabled on the output of the Service block where the transaction originated. If for some reason the transaction is rejected from the resource, this data structure is instead placed on the RejectDS output of the block where the transaction originated.

When a new transaction enters the resource, it goes to an idle server or preempts a server currently processing a lower priority transaction. If it cannot do either, it checks to see if there is a transaction of equal or higher priority waiting in the queue. If so, it is enqueued based on its priority. If no equal or higher priority transactions are waiting in the queue, the new transaction sees if it can share a server or servers with other transactions of the same priority. If a server cannot be shared, the transaction is queued.

If a new transaction preempts a server, the transaction(s) that were being processed by that server first attempt to share another server. If another server cannot be found that can be shared, the transaction(s) that were being processed by the preempted server are said to be preempted, and they are handled according to the value of their Preempt Response attribute. Preempted transactions that are to be resumed or restarted move back to the queue and wait until they receive processing from a server. A preempted transaction can also be discarded, in which case its arbitrary data structure is sent out the RejectDS output of the Service block where the transaction originated.

When a transaction completes its service, its associated data structure is sent out the OutArbitraryDS output port of the Service block where the transaction originated. Prior to sending out the data structure, the server that had been processing the transaction, if it was not being shared, checks the queue for pending transactions. If there are any, it begins processing the transaction at the head of the queue, and all others in the queue having the same priority if server sharing is enabled.

Overview of resource attributes

Resource attributes in detail

Queuing Discipline

Transactions in the queue are ordered first by priority and then within each priority according to the Queuing Discipline. Any time a transaction is preempted, it is placed in the queue and ordered based on its priority and the time it entered the resource according to the Queuing Discipline. Priorities are greater than or equal to zero, with zero being the lowest priority.

Maximum Occupancy

The Maximum Occupancy attribute specifies the maximum number of transactions that can be anywhere in the resource. This includes those waiting in the queue, transactions in a server and transactions in a round robin wait list. Whenever accepting a new transaction would cause the occupancy of the resource to exceed this value, either the new transaction or the transaction at the tail of the queue is rejected.

Queue Reject Mechanism

The method of determining which transaction is rejected is specified by the Queue Reject Mechanism, which has two possible values: Incoming_DS_Rejected or Lowest_Priority_Rejected. If it is set to Incoming_DS_Rejected, the new transaction is rejected whenever the maximum occupancy would be exceeded. If it is set to Lowest_Priority_Rejected and there is at least one transaction in the wait queue, the new transaction is accepted and processed in the normal manner, and then the transaction at the tail of the queue is removed from the queue and its arbitrary data structure sent out the reject output. If the wait queue is empty, the incoming request is always rejected.

Number of Dimensions

One of the resource attributes, Number of Dimensions, allows a single grouping of resource models and resource elements to represent a collection of independent and identical resources which are distinguished by an integer index, called the dimension. Each dimension is isolated from all other dimensions. The dimension values are zero based, with valid values between zero, inclusive, and the number of dimensions attribute of the resource, exclusive.