Aggregation Operator for Assignment of Resources in Distributed Systems

In distributed processing systems it is often necessary to coordinate the allocation of shared resources that should be assigned to processes in the modality of mutual exclusion; in such cases, the order in which the shared resources will be assigned to processes that require them must be decided; in this paper we propose an aggregation operator (which could be used by a shared resources manager module) that will decide the order of allocation of the resources to the processes considering the requirements of the processes (shared resources) and the state of the distributed nodes where the processes operate (their computational load). Keywords—Aggregation operators; concurrency control; communication between groups of processes; mutual exclusion; operating systems; processor scheduling


I. INTRODUCTION
The proliferation of computer systems, many of them distributed in different nodes with multiple processes that cooperate for the achievement of a particular function, require decision models that allow groups of processes to use shared resources that can only be accessed in the modality of mutual exclusion.
The traditional solutions for this problem are found in [1] and [2], which describe the main synchronization algorithms in distributed systems; in [3], it presents an efficient and fault tolerant solution for the problem of distributed mutual exclusion; in [4]- [6], which present algorithms to manage the mutual exclusion in computer networks; in [7], which details the main algorithms for distributed process management, distributed global states and distributed mutual exclusion.
In addition, a reliable communication protocol in the presence of faults is presented in [8].In [9] a multicast communication protocol is presented for groups of processes in the atomic mode, [10] study technologies, web services and applications of reliable distributed systems; in [11] reliable communication protocols are presented in broadcast mode; in [12] the main communication algorithms in distributed systems are described, [13] describes a network architecture for large-scale virtual environments to support communication between groups of distributed processes, and in [14] the main algorithms of distributed coordination and management of the mutual exclusion.
Similarly, in [15] the communication between groups of processes is analyzed in depth, analyzing protocols such as FLIP: Fast Local Internet Protocol and BP: Broadcast Protocol, analyzing reliable and efficient group communication, parallel programming, the fault-tolerant programming using broadcasting and proposing a three-level architecture, the lower one for FLIP protocol, the medium for communication in groups of processes and the upper one for the applications.Additional information can be found in [16].
Also, solutions (which may be considered classic or traditional) have been proposed for very different types of systems distributed in [17]- [21].Other works focused on ensuring mutual exclusion have been presented in [22] and [23].An interesting distributed solution based on permissions is presented in [24] and a solution based on process priorities in [25].
The traditional solutions for the allocation of shared resources distributed in the modality of mutual exclusion are concentrated on guaranteeing mutual exclusion, without considering the computational load on the nodes where the processes operate and the impact that will create on the access to the shared resources requested by the processes in the context of such load.
However, this allocation of resources in processes should be performed taking into account the priorities of the processes and also the current workload of the computational nodes on which the processes are executed.
The new decision models for allocating shared resources could be executed in the context of a shared resource manager for the distributed system, which would receive the shared resource requirements of the processes running on the different distributed nodes, as well as the computational load state of the nodes and, considering that information, the order (priority) of allocation of the requested resources for the requesting processes should be decided on.Consequently, there is a need for specially designed aggregation operators.
In this paper, a new aggregation operator will be presented specifically for the aforementioned problem.This falls under the category of OWA (Ordered Weighted Averaging) operators, and more specifically Neat OWA.
The use of aggregation operators in group decision models has been extensively studied, for example, in [26] a group decision model is presented with the use of aggregation operators of the OWA family; in [27] the use of OWA aggregation operators (Ordered Weighted Averaging) for decision making is presented; in [28] methodologies are introduced to solve problems in the presence of multiple attributes and criteria and in [29] the way of obtaining a collective priority vector is studied, which is created from www.ijacsa.thesai.orgdifferent formats of expression of the preferences of the decision makers.The model can reduce the complexity of decision making and avoid the loss of information when the different formats are transformed into a unique format of expression of the preferences.Also, in [30]- [32] several aggregation operators that can be used to make decisions in groups are presented; in [33] the operator WKC-OWA is presented to add information on problems of democratic decision; in [34] a group decision model is presented with the use of linguistic tags and a new form for expression of the preferences of the decision makers; in [35] the main mathematical properties and behavioral measures related to aggregation operators are presented; in [36] a review about aggregation operators, especially those of the OWA family is presented; in [37]- [39] majority aggregation operators and their possible applications to group decision making are analyzed; in [40] and [41] the OWA (Ordered Weighted Averaging) operators applied to multicriteria decision making are presented and analyzed, and in [42] and [43] the OWA operators and their applications in the Multi-agent decision making are discussed.
In turn, in [44] the connection of the linguistic hierarchy and the numerical scale for the 2-tuple linguistic model and its use to treat unbalanced linguistic information is studied; in [45] a complex and dynamic problem of group decision making with multiple attributes is defined and a resolution method that uses a consensus process for groups of attributes, alternatives and preferences, resulting in a decision model for real-world problems is proposed.This article, which will present an innovative method for shared resource management in distributed systems, has been structured as follows: Section 2 will explain the data structures to be used by the proposed operator, in Section 3 the aggregation operator is described, Section 4 will show a detailed example of this, then the Conclusions and Future Work Lines will be presented, ending with the Acknowledgments and References.

II. DATA STRUCTURES TO BE USED
The following premises and data structures will be used.
You have groups of processes distributed in process nodes that access critical resources.These resources are shared in the form of distributed mutual exclusion and it must be decided, according to the demand for resources by the processes, what the priorities to allocate the resources to the processes that require them will be (only the available resources that have not yet been allocated to processes will need to be considered):  The access permission to the shared resources of a node will not only depend on whether the nodes are using them or not, but on the aggregation value of the preferences (priorities) of the different nodes regarding granting access to shared resources (alternatives) as well.
 The opinions (priorities) of the different nodes regarding granting access to shared resources (alternatives) will depend on the consideration of the value of variables that represent the state of each of the different nodes.Each node must express its priorities for assigning the different shared resources according to the resource requirements of each process (which may be part of a group of processes).
Nodes hosting processes: 1, …. , n.The set of nodes is represented as follows: Processes housed in each of the n nodes: 1, …. , p.The set of processes is represented as follows: Processes = {p ij } with i = 1, …, n (number of nodes in the distributed system) and j = 1, …, p (maximum number of processes in each node), which can be expressed by the Table 1.Distributed process Groups: 1, …. , g.The set of distributed process groups is represented as follows: Groups = {p ij } with i indicating the node and j the process in this node.
Size of each of the g process groups.The number of processes in each group indicates the group's cardinality and is represented as follows: Card = {card(g i )} with i = 1, …, g indicating the group.
Group priority of each of the g processes groups.These priorities can be set according to different criteria; in this proposal, it will be considered to be a function of the cardinality of each group and is represented as follows: Shared resources in distributed mutual exclusion mode available on n nodes: 1, …., r.The set of resources is represented as follows: Resources = {r ij } with i = 1, …, n (number of nodes in the distributed system) and j = 1, …, r (maximum number of resources at each node), which can be expressed by Table 2.These available shared resources hosted on different nodes of the distributed system may be required by the processes (clustered or independent) running on the nodes; these requests for resources by the processes are shown in Table 3. www.ijacsa.thesai.orgPossible states of each process:  Independent process.
 Process belonging to a group of processes.
Possible state of each of the nodes:  Number of processes.
 Priorities of the processes.
 CPU usage.
 Main memory usage.
 Use of virtual memory.
 Additional memory required for each resource requested by each process (depending on the availability of the data).
 Additional estimated processor load required for each resource requested by each process (depending on data availability).
 Additional estimated input / output load required for each resource requested by each process (depending on data availability).
 Status of each of the shares in the distributed mutual exclusion mode in the node: • Assigned to a local or remote process.
• Available. Predisposition (nodal priority) to grant access to each of the r shared resources in the modal of distributed mutual exclusion (will result from the consideration of the variables representative of the node status, the priority of the processes and the additional computational load which would mean allocating the resource to the requesting process).
 Current load of the node, which can be calculated as the average of the CPU, memory and input / output usage percentages at any given time (these load indicators may vary depending on the case, some may be added or changed); the current load categories, for example, High, Medium and Low, should also be defined, with value ranges for each category being indicated.

III. DESCRIPTION OF THE AGGREGATION OPERATOR
The proposed operator consists of the following steps:  Calculation of the current computational load of the nodes.
 Establishment of the categories of computational load and the vectors of weights associated with them.
 Calculation of the priorities or preferences of the processes considering the state of the node (they are calculated in each node for each process).
 Calculation of the priorities or preferences of the processes to access the shared resources available (calculated in the centralized manager of shared resources) and determination of the order and to which process the resources will be allocated.
 Each of the steps above is described below.

A. Calculation of the Current Computational Load of the Nodes
To obtain an indicator of the current computational load of each node, different criteria can be adopted; in this proposal, the criteria will be the percentage of CPU usage, the percentage of memory usage and the percentage of use of input / output operations, as will be seen in the example.
The computational load of each node will be calculated as follows: Establishment of the number of criteria to determine the load of the nodes: Establishment of the criteria that apply (may differ from one node to another): number of nodes in the distributed system) y j = 1, …, c (maximum number of criteria for each node), which can be expressed by the Table 4.

Nodes
Eventually, all nodes could use the same set of criteria.
Calculation of the computational load of each node:

Establishment of the categories of computational load and of the vectors of weights associated thereto
Different criteria can be adopted to establish the current computational load categories of each node; in this proposal, the categories will be: High (if the load is more than 70%), Medium (if the load is between 40% and 70% inclusive) and Low (if the load is less than 40%), as you will see in the example.
Establishment of the number of categories to determine the load of the nodes: Card({categories}) = a www.ijacsa.thesai.orgEstablishment of the categories that apply (they may differ from one node to another): Categories = {cat ij } with i = 1, …, n (number of nodes in the distributed system) and j = 1, …, a (maximum number of categories for each node), which can be expressed by the Table 5.
Eventually all nodes could use the same set of categories.
In order to establish the vectors of weights associated with the current computational load categories of each node, different criteria can be adopted; in this proposal, the criteria will be: number of processes in the node, percentage of CPU usage, percentage of memory usage, percentage of virtual memory usage, process priority (process priority in the node where it is executed), memory overhead (additional memory that will require the requested resource to be available, if the data is available), processor overhead (additional processor use that will require the requested resource if the data is available), and input / output overhead (input / additional output that will require to arrange the requested resource, if the data is available), as will be seen in the example.
Establishment of the number of criteria to determine the priority or preference that will be granted in each node according to its load to each order of a shared resource made by each process: Establishment of the criteria that apply (same for all nodes): Criteria for preferences = {cp ij } with i = 1, …, a (number of categories of computational load) and j = 1, …, e (maximum number of criteria), which can be expressed by Table VI.
Eventually, all nodes could use different sets of criteria applicable to the different categories of computational load; in this proposal and as will be seen in the example, the same criteria are used for all nodes.
First, the categories to indicate the load of the nodes and the criteria that will be applied to evaluate the priority to be given to each request of resources of each process are determined.Then the values corresponding to the criteria that constitute the vectors of weights for the different categories of load are established.

Establishment of vectors of weights (same for all nodes):
Weights = {w ij } con i = 1, …, a (categories number of computational load) y j = 1, …, e (maximum number of criteria), which can be expressed by Table 7.The assignment of weights to the different criteria will be a function of previously performed statistical studies about the distributed system; there will then be a weight assignment function to the criteria for constituting the weight vectors of each load category: a (numbers of category) y j = 1, …, e (numbers of criteria); norm indicates that the values must be normalized (in the range of 0 to 1 inclusive) and with the constraints that the sum of the elements of a vector of weights must give 1: This means that the sum of the weights assigned to the different criteria will be 1 for each of the categories, or equally, that the sum of elements of the vector of weights of each category is 1.

C. Calculation of the Priorities or Preferences of the
Processes taking into Account the Status of the Node (They are calculated in Each Node for Each Process and Could be called Nodal Priorities) These priorities are calculated at each node for each resource request originated in each process; the calculation considers the corresponding weight vector according to the current load of the node and the vector of the values granted by the node according to the evaluation criteria of the request.The range of values is between 0 and 1, where a value close to 0 means that the related criterion will contribute little to the calculation of the priority of the request, while a value close to 1 means otherwise.Thus a node can influence a request for a resource by a process according to its state and the additional impact or burden that would mean assigning the requested resource to the requesting process, e.g., if accessing the request means increasing the memory usage and the node has little memory available, then it could assign to that criterion a value close to 0, in turn, if the additional processor consumption is considered low and the CPU usage of node is little, then a value close to 1 would be assigned to that criterion.
The valuation vectors that will be applied for each request of a resource by a process, according to the criteria established www.ijacsa.thesai.orgfor the determination of the priority that in each case and moment will fix the node in which the request occurs, are the following: Valuations (r ij p kl ) = {cp m } con i = 1, …, n (node where the resource resides), j = 1, …, r (resource on node i), k = 1, …, n (node where the process resides), l = 1, …, p (process at node k) and m = 1, …, e (valuation criteria of the requirement priority), which can be expressed by Table 8.To sum up, the nodal priority (to be calculated at the node where the request occurs) of a process to access a given resource (which can be at any node) is calculated by the scalar product of the mentioned vectors: Nodal priority (r ij p kl ) = Σ w om * cp m indicating o the weights vector according to the load of the node, keeping the other subscripts, the meanings explained above.

D. Calculation of Process Priorities or Preferences to Access
Available Shares (it is calculated in the Centralized Manager of the Shared Resources).In Addition, Determining the Order in Which the Resources will be allocated and to Which Process Each Resource will be allocated At this stage, the nodal priorities calculated in the previous stage are considered for each requirement of access to resources by the processes.The global or final priorities must be calculated from these nodal priorities, that is, with what priority, or in what order, the requested resources will be provided and to which processes the allocation will be made.The requirements that cannot be attended because they result in low priorities will be considered again in the next iteration of the method.Table 9 is used for the calculation of the final priorities, in which the priorities or nodal preferences calculated in the previous stage are placed; in this table, each row contains the information of the nodal priorities of the different processes to access a given resource.
Next, it is necessary to calculate the vector of final weights that will be used in the process of aggregation to determine the order or priority of access to the resources.
Final weights = {wf kl } con k = 1, …, n (number of nodes) y l = 1, …, p (maximum number of processes per node), which can be expressed by Table 10, where np is the number of processes in the system and prg i is the priority of the process group to which the process belongs (explained in the previous section).Thus, a normalized weight vector (in the range of 0 to 1 inclusive) is obtained and with the restriction that the sum of the elements of the vector must give 1: Σ {nwf kl } = 1 with k = 1, …, n (number of nodes) and l = 1, …, p (maximum number of processes per node).
The nodal priorities given in Table 9 taken row by row for each resource will be scalar multiplied by the normalized final weight vector indicated in Table 11.In this way, it is possible to obtain the final global access priorities of each process to each resource.It is indicated below how the order or priority with which the resources will be allocated is obtained and to which process each one will be assigned.
Overall final priority (r ij p kl ) = nwf kl * p kl with r ij indicating the resource j of node i, p kl the process l of node k and the product of the overall final priority of the process to access such resource.The greater of these products made for the different processes in relation to the same resource will indicate which of the processes will have access to the resource.
The addition of all these products in relation to the same resource will indicate the priority that will have that resource to be assigned, in relation to the other resources that will also have to be assigned.This is what will be called Distributed Systems Assignment Function (DSAF): DSAF (r ij ) = Σ nwf kl * p kl = resource allocation priority r ij .
By calculating the DSAF for all resources a vector will be www.ijacsa.thesai.orgobtained, and by ordering its elements from highest to lowest, the priority order of allocation of resources will be obtained.In addition, as already indicated, the largest of the products nwf kl * p kl for each resource will indicate the process to which the resource will be assigned.This is shown in Table 12.

Considerations for Aggregation Operations
The characteristics of the aggregation operations described allow considering that the proposed method belongs to the family of aggregation operators Neat-OWA, which are characterized by the following: The definition of OWA operators indicates that , , , , where b j is the jth highest value of the a n , with the restriction for weights to satisfy (1) [ ] and (2) ∑ .
For the Neat OWA operator family the weights will be calculated according to the elements that are added, or more exactly of the values to be added orderly, the b j , maintaining conditions (1) and (2).In this case the weights are: For this family, where the weights depend on the aggregation, the satisfaction of all properties of OWA operators is not required.
In addition, in order to be able to assert that an aggregation operator is neat, the final aggregation value needs to be independent of the order of the values.One of the characteristics to be pointed out by Neat OWA operators is that the values to be added need not be sorted out for their process.This implies that the formulation of a neat operator can be defined by directly using the arguments instead of the orderly elements.
In the proposed aggregation operator, the weights are calculated according to context values.From this context arise the values to be aggregated.

IV. EXAMPLE AND DISCUSSION OF RESULTS
This section will explain in detail an example application of the proposed aggregation operator.The distributed processing system has three nodes: The processes running on the nodes are as follows: three processes on node 1, five processes on node 2 and seven processes on node 3.
Processes = {p ij } with i indicating the node and j indicating the process, which can be expressed by Table 13.

Nodes
Processes Several processes are independent and others constitute groups of cooperative processes.In this example four groups will be considered, as shown in Table 14.

Groups
Processes The number of processes in each group indicates the cardinality of the group and is represented as follows: Card = {card (g i )} = {3, 2, 2, 3} with i indicating the group.
The priority of the groups of processes will be considered the cardinality of each group and is represented as follows: The shared resources available in the nodes are as follows: three resources in node 1, four resources in node 2 and three resources in node 3.
Resources = {p ij } with i indicating the node and j indicating the process, as expressed in Table 15.The requests for resources by the processes are shown in Table 16.www.ijacsa.thesai.orgEach of the calculation steps will now be described.

A. Calculation of the Current Computational Load of the Nodes
To obtain an indicator of the current computational load of each node, the same three criteria will be adopted in the three nodes: Criteria = {% CPU usage, % of memory usage, % use of input / output operations}.
The values to be assumed for the computational load indicators of the three nodes and the average load calculation for each node are shown in Table 17.

B. Establishment of the Categories of Computational Load and of the Vectors of Weights Associated Thereto
In this proposal, the categories will be the same for all nodes: High (if the load is greater than 70%), Medium (if the load is between 40% and 70% inclusive) and Low (if the load is less than 40%).

Categories = {High, Medium, Low}
The values obtained for the load categories based on the averages shown in Table 17 are shown in Table 18.To establish the weight vectors associated with the current computational load categories of each node, the following criteria will be used for all nodes and for all load categories: Number of processes in the node, % CPU usage, % memory usage, % virtual memory usage, process priority (process priority in the node where it is executed), memory overhead (additional memory that will require (additional processor use that will require the requested resource to be available, if the data is available) and input / output overhead (additional input / output that will require the requested resource to be available), if the data is available).Card ({critpref}) = 8.
Criteria for preferences = {Node of processes in the node, % of CPU usage, % of memory usage, % of virtual memory usage, process priority, memory overhead, processor overload, input / output overhead} Next, the values corresponding to the criteria must be established, constituting the vectors of weights for the different categories of load, which will be the same for all nodes, which is indicated in Table 19.
The sum of the weights assigned to the different criteria is 1 for each of the categories, i.e. the sum of elements of the vector of weights of each category is 1.

C. Calculation of the Priorities or Preferences of the Processes taking into Account the Status of the Node (they are calculated in Each Node for Each Process and could be Called Nodal Priorities)
The valuation vectors are applied for each requirement of a resource made by a process, according to the criteria established for the determination of the priority that in each case and moment fixes the node in which the request occurs; each vector of evaluations of each requirement is scalar multiplied by the vector of weights corresponding to the current load category of the node to obtain the priority according to each criterion and the nodal priority granted to each requirement; this is shown in Table 20.
Next it is necessary to calculate the vector of final weights that will be used in the final process of aggregation to determine the order or priority of access to the resources.This is shown in Table 22.
The nodal priorities indicated in Table 21 taken row by row, that is, for each resource, will be scalar multiplied by the normalized final weight vector indicated in Table 22 to obtain the final global access priorities of each process to each resource, and from there, the order or priority with which the resources will be allocated and to which process each one will be assigned, as indicated in Table 23.

D. Calculation of process priorities or preferences to access available shares (it is calculated in the centralized manager of the shared resources). In addition, determining the order in which the resources will be allocated and to which process each resource will be allocated
From the nodal priorities, the global or final priorities must be calculated, that is, with what priority, in what order, the requested resources will be awarded and to which processes such grant will be made.The greatest of these products made for the different processes in relation to the same resource will indicate which of the processes will have access to the resource (in the case of ties the process identified with the smallest number could be chosen); this is shown in bold in Table 23.
The addition of all these products in relation to the same resource will indicate the priority of such resource to be assigned.This is the Distributed Systems Assignment Function (DSAF), which is shown in Table 24.
The final allocation order of the resources and the target processes are obtained by ordering Table 24, which is shown in Table 25.
The next step is to reiterate the procedure, but removing from the requests for resources the assignments already made; it should also be taken into account that the allocated resources will be available when the processes have released them and can therefore be assigned to other processes.The results of successive iterations are shown in Tables 26 to 36.In this way, all the requests for resources of all the processes have been taken care of, respecting the mutual exclusion and the priorities of the processes, the nodal priorities and the final priorities.www.ijacsa.thesai.org

A. Conclusions
The proposed model makes it possible for the distributed system to self-regulate repeatedly according to the local state of the n nodes, resulting in an update of their local states, as a consequence of the evolution of their respective processes and the decisions of access to resources: the distributed system in which groups of processes requiring access to critical resources are executed, produces access decisions to resources that modify the state of the system and readjusts it repetitively, also guaranteeing the mutual exclusion in access to the shared resources, indicating the priority of granting access to each resource and the process to which it is assigned.This process is repeated as long as there are processes that request access to shared resources.
The proposed model includes as a particular case one of the most used methods, consisting in considering only the priority of the processes, instead of a group of state variables of each node.Another notable feature of the proposal is its ease of deployment in a centralized shared resource manager environment of a distributed system.

B. Future Work
It is planned to develop variants of the proposed method considering other aggregation operators (especially the OWA family) and the possibility of being used by a resource manager shared (instead of centralized as in the proposed method).

1 (
It produces the same result for any assignment C = B.

TABLE III .
RESOURCES REQUESTED BY PROCESSES

TABLE VI .
CRITERIA TO CALCULATE THE PRIORITY OR PREFERENCE THAT EACH NODE WILL GRANT TO EACH REQUIREMENT OF EACH PROCESS ACCORDING TO THE LOAD OF THE NODE

TABLE VII .
WEIGHTS ASSIGNED TO THE CRITERIA TO CALCULATE THE PRIORITY OR PREFERENCE THAT EACH NODE WILL GRANT TO EACH REQUIREMENT OF EACH PROCESS ACCORDING TO THE LOAD OF THE NODE

TABLE VIII .
EVALUATIONS ASSIGNED TO THE CRITERIA TO CALCULATE THE PRIORITY OR PREFERENCE THAT EACH NODE WILL GRANT EACH REQUIREMENT OF EACH PROCESS ACCORDING TO THE NODE LOAD

TABLE IX .
NODAL PRIORITIES OF THE PROCESSES TO ACCESS EACH RESOURCE

TABLE X .
WEIGHTS ASSIGNED TO THE PROCESSES TO CALCULATE THE PRIORITY OR FINAL PREFERENCE FOR ACCESS TO RESOURCES The next step is to normalize the newly obtained weights by dividing each by the sum of all of them, which is indicated in

TABLE XI .
FINAL NORMALIZED WEIGHTS ASSIGNED TO PROCESSES TO CALCULATE PRIORITY OR FINAL PREFERENCE FOR ACCESS TO RESOURCES

TABLE XII .
ORDER OR FINAL PRIORITY OF ALLOCATION OF THE RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED

TABLE XV .
SHARED RESOURCES AVAILABLE AT EACH NODE

TABLE XVI .
RESOURCES REQUESTED BY THE PROCESSES

TABLE XVII .
VALUES OF THE CRITERIA FOR MEASURING THE COMPUTATIONAL LOAD AT EACH NODE

TABLE XVIII .
VALUES OF THE CATEGORIES TO MEASURE THE COMPUTATIONAL LOAD AT EACH NODE Table XXI is used to calculate the final priorities.www.ijacsa.thesai.org

TABLE XIX .
WEIGHTS ASSIGNED TO THE CRITERIA TO CALCULATE THE PRIORITY OR PREFERENCE THAT EACH NODE WILL GRANT TO EACH REQUIREMENT OF EACH PROCESS ACCORDING TO THE LOAD OF THE NODE

TABLE XX .
THE VALUATIONS ASSIGNED TO THE CRITERIA TO CALCULATE THE PRIORITY OR NODAL PREFERENCE THAT EACH NODE WILL GRANT EACH REQUIREMENT OF EACH PROCESS ACCORDING TO THE NODE LOAD

TABLE XXII .
FINAL WEIGHTS AND NORMALIZED FINAL WEIGHTS ASSIGNED TO PROCESSES TO CALCULATE THE PRIORITY OR FINAL PREFERENCE FOR ACCESS TO RESOURCES

TABLE XXIV .
FINAL GLOBAL PRIORITIES FOR ALLOCATING RESOURCES

TABLE XXV .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED

TABLE XXVI .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (SECOND ITERATION)

TABLE XXVII .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (THIRD ITERATION)

TABLE XXVIII .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (FOURTH ITERATION)

TABLE XXIX .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (FIFTH ITERATION)

TABLE XXX .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (SIXTH ITERATION)

TABLE XXXI .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (SEVENTH ITERATION)

TABLE XXXII .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (EIGHTH ITERATION)

TABLE XXXIII .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (NINTH ITERATION)

TABLE XXXIV .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (TENTH ITERATION)

TABLE XXXV .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (ELEVENTH ITERATION)

TABLE XXXVI .
ORDER OR FINAL PRIORITY OF ALLOCATION OF RESOURCES AND PROCESS TO WHICH EACH RESOURCE IS ASSIGNED (TWELFTH ITERATION)