There are a few options if the requested quantity of the resource cannot be allocated immediately when the request is made. The transaction can be put into a queue to wait for the resource according to a specified queuing discipline (either FIFO or LIFO), it can be sent out the reject output without seizing any resource units, or it can take the available resource units. The first possibility is called Wait_for_Resource, the second Exit_without_any_Resource_Units, the third Seize_Available_Units. These are chosen with the Blocking Mechanism resource attribute, which has these three possible values. The default value is Wait_for_Resource.
If the Blocking Mechanism is Seize_Available_Units, a transaction seizes its requested number of units or the amount in the pool, whichever is smaller. The unitsGranted output can (and should) be used to determine the number of resource units that were seized. If the number of units in the pool is zero and the blocking mechanism is Seize_Available_Units, the transaction is instead rejected, and the arbitrary data structure associated with the transaction is sent out the rejectDS output.
Setting the Blocking Mechanism to Exit_without_any_Resource_Units could be used to model ”blocked calls cleared”, as is the case with the common Erlang B model used in telephony. Setting the blocking mechanism to this value could also be used to divert transactions to a second resource when the first one is not immediately available, rather than having them queue and wait for the first resource to become available.
If the Blocking Mechanism is Wait_for_Resource, a transaction simply waits in the queue according to the specified queuing discipline until the resources become available. If the queue is full and the Queue Reject Mechanism is Incoming_DS_Rejected, then this transaction exits on the rejectDS output port. Else, if the Queue Reject Mechanism is Lowest_Priority_DS_Rejected and there is another transaction in the queue with lower priority, then the incoming transaction gets to take its place, otherwise the incoming transaction is rejected.
There is a single queue maintained for the entire resource (actually one for each dimension as explained in Number of Dimensions), which is ordered first by priority and, within each priority, either FIFO or LIFO, according to the Queue Discipline resource attribute. When a transaction is queued, the Allocate block from which the transaction entered the queue is remembered, so the transaction can be sent out the same block when it is granted resource units or rejected from the queue. Priorities of transactions are greater than or equal to zero, with zero being the lowest priority.