Resource management
Application developers who use dynamic resources should be aware of the following information:
- Resources are associated with channels. When an application allocates a resource, it is attached to the channel. The resource can only be applied to the given channel. The application cannot share a single resource over a number of channels that it owns. In general, applications should return resources to the resource manager as soon as they are done with them.
- Dynamic resources are described to RM when the system initializes. The IRAPI uses these descriptions to drive the dynamic resources. This description comes in three parts.
- Functions are individual capabilities of which a dynamic resource card is capable. For instance, play, record, and whole word recognition are examples of functions.
- Each function is identified by a name and has a "utilization vector" that describes the load that it places on a resource card.
- Each time a function is invoked, it consumes the specified amount of the resource on the card.
- Resource cards are complex. The loads presented by various functions to resources are also complex. The IRAPI includes a facility for resource cards and functions to describe themselves to the platform. These descriptions drive the use of the cards.
- Function and resource card usage descriptions are represented as vectors. In order for the IRAPI to allocate a function to a card, the function's usage description added to the card's current usage must not exceed the maximum or saturated usage.
- When a resource card is brought in service, it is assigned a saturated usage. The saturated usage of the card can vary depending on the physical configuration. Users can examine the usage values of resource cards using the rmdb command.
- In general, the IRAPI tends to assign work to cards that run the fewest number of functions. For example, if a system contains two cards – one capable of recognition, echo cancellation, speech record and speech play and the second capable of only speech record and speech play – the IRAPI tends to assign all speech play and record functions to the second, less capable card. If the second card eventually reaches its saturated usage, then the IRAPI starts assigning speech play and record functions to the first card. In cases where multiple cards have the same number of functions, the IRAPI spreads the load evenly on those cards.
- The IRAPI includes facilities for managing contention for scarce resources. If there are more requests for work than can be accommodated with the current set of resource cards, applications are free to wait for definite or indefinite amounts of time for the resource to become available. If the resource becomes free within those time constraints, the IRAPI allocates the resource to the application and notifies the application via an IRE_GRANT message. If the resource request cannot be filled within the time period, the IRAPI notifies the application via an IRE_DENY message.
Note:
You can also examine pending requests using the rmdb command.
Applications can also choose to not wait for a resource. In this case, if the request cannot be filled immediately, the IRAPI does not notify the application when the resource becomes free.
If a resource card is removed from service gracefully (that is, the immediate argument is not used), the IRAPI does not assign any more work to it until the card is returned to service. This allows the system to gracefully remove resource requests from cards with pending remove requests.
The following example of the rmdb -c command shows:
- Usage vector per function utilization
- Saturated usage is vector at maximum utilization
- High water mark is high historical value (since last start_vs )
- Current is current usage value
rmdb -c 14
Card table:
14 : MTC_INSERV 2 0x00000000
0 "SP_RECORD " [83 0 0 0] [0/0 /120]
1 "SP_ECHOCAN " [150 0 0 0] [0/0 /60]
2 "SP_PLAY " [83 0 0 0] [0/0 /120]
3 "SP_TTS " [166 0 0 0] [0/0 /60]
4 "SP_WW_RECOG " [600 0 0 0] [0/0 /15]
5 "SP_CELPCODE " [166 0 0 0] [0/0 /60]
Saturated : [10000 10000 10000 10000]
High Water : [0 0 0 0]
Current : [0 0 0 0]
Allocation # : 0x0 0x0 0x0 0x0
rmdb -c 12
12 : MTC_INSERV 0 0x00000000
0 "LSPS_RECORD " [78 200 0 125] [0/0 /50]
1 "LSPS_PLAY " [78 0 200 125] [1/1 /50]
2 "LSPS_WW_RECOG " [333 200 0 0] [0/0 /30]
3 "LSPS_DATA_COLLECT" [2500 500 0 0] [0/0 /1]
4 "LSPS_BUS_DIAG " [1250 1500 1500 1500] [0/0 /1]
Saturated : [10000 10000 10000 10000]
High Water : [78 0 200 125]
Current : [78 0 200 125]
Allocation # : 0x0 0x1 0x0 0xn,
