Concurrency Coordinator Table (CocoTable)

Classes
class	CocoTable
	CocoTable. More...

Detailed Description

The need for a separate module focusing on managing concurrencies arises due to the fact that multiple clients can send multiple requests with different priorities for the same resource. It becomes important for Resource Tuner to intelligently decide the order in which the requests are applied.

Every resource is allotted a Policy beforehand according to the requirements and the nature of the resource. These four policies were included:

• Instant Apply (or Always Apply): This policy is for resources where the latest request needs to be honored. This is kept as the default policy.
• Higher is better: This policy honors the request writing the highest value to the node. One of the cases where this makes sense is for resources that describe the upper bound value. By applying the higher-valued request, the lower-valued request is implicitly honored.
• Lower is better: Self-explanatory. Works exactly opposite of the higher is better policy.
• Lazy Apply: Sometimes, you want the resources to apply requests in a first-in-first-out manner.

We provide 4 different Priority Levels for all requests. The requests are first divided into either a system request or a 3rd party request based on the thread IDs of the client. Later, the client has the opportunity to provide either a High or Low priority according to their requirements.

• System High
• System Low
• 3rd Party High
• 3rd Party Low

The Concurrency Coordinator needs to honor both, the policy of the resource and the priority of the requests while taking decisions.

Algorithm: Create 4 (number of currently supported priorities) doubly linked lists for each resource (or for each core in each resource if core level conflict exists). Behavior of each linked list would depend on the policy specified in the resource table.

Request Flow:

Tune Request:

1. Associate a timer with the requested duration with the request.
   
2. Create a CocoNode for each of the Resource part of the Request it requires
   
3. Insert each of the CocoNodes to the doubly-linked list corresponding to the Resource and the Priority
   
4. The Node will be inserted in accordance to the Resource Policy
   
5. When the node reaches the head of the Linked List it will be applied, i.e. the value
   specified by the Tune Request will take effect on that Resource Node.
   
6. When the Request Expires, the timer will trigger a Callback and an Untune Request will be issued for this handle, to clean up the Tune Request and Reset the Resource Nodes.

Retune Request:
Update the Request duration, which involves killing the Timer associated with the Request and starting it again with the new Duration

Untune Request:

1. For each Resource in the request, remove the corresponding CocoNode node from the list
   
2. Reset each of the Resource Sysfs Nodes to their original values, if there are no other Pending Requests for that Resource.