KR101635295B1 - Batching of resource requests into a transaction and forking of this transaction in a portable computing device - Google Patents

Abstract

In a handheld computing device having a node-based resource structure, resource requests are batched or otherwise transactional to help minimize entity messaging or other messaging between processes or to provide other benefits. In a resource graph that defines an architecture, each node or resource in the graph represents an encapsulation of the functionality of one or more resources controlled by a processor or other processing entity, each edge representing a client request, Dependencies. A single transaction of resource requests provided for two or more of the resources is forked so that parallel processing between the client issuing a single transaction and the resources processing requests of a single transaction is achieved.

Description

BATCHING OF RESOURCE REQUESTS INTO A TRANSACTION IN A PORTABLE COMPUTING DEVICE BACKGROUND OF THE INVENTION 1. Field of the Invention < RTI ID = 0.0 > [0001] <

delete

Portable computing devices ("PCDs") are becoming more and more popular. Such devices may include cellular telephones, portable / personal digital assistants ("PDAs"), portable game consoles, portable navigation units, palmtop computers, and other portable electronic devices. Each of these devices may have a primary function. For example, a cellular telephone typically has a primary function of receiving and transmitting telephone calls.

In addition to the main functions of these devices, many devices include peripheral functions. For example, a cellular telephone may have a primary function of placing a cellular telephone, such as a cellular telephone, as described above, and a mobile telephone, such as a still camera, video camera, global positioning system ("GPS") navigation, web browsing, To-talk capabilities, and the like. As the functionality of PCDs increases, the computing or processing power required to support this functionality also increases. The processing power may be increased by increasing the number of processors in the PCD. As computing power and the number of processors increase, there is a greater need for effective management of processors.

Functions such as those described above may be embodied in various corresponding hardware elements and software elements that may be referred to as resources. A processor may request various resources at various times under the control of software, such as an application program. In a multi-processor PCD, the first processor may control resources that are different than the resources controlled by the second processor. However, it may be desirable for the first processor to be able to request resources controlled by the second processor.

Methods and systems for batching or otherwise transactionizing resource requests in a portable computing device having multiple resources may help minimize inter-processor messaging or other messaging, or may provide other benefits. In a portable computing device having a node-based software architecture, resources may be included in the node. In an exemplary method, a plurality of nodes are instantiated. The plurality of resources of the nodes may be defined by a directional acyclic graph. Each node or resource in the graph represents the encapsulation of the functionality of one or more resources controlled by the processor or other processing entity. Each edge of the graph represents a client request. Adjacent nodes in the graph represent resource dependencies. According to an exemplary method, a single transaction of resource requests may be provided for two or more of the resources.

 Also, this single transaction of resource requests may be forked, resulting in parallel processing. For example, in a forked transaction, a client issuing a single transaction of resource requests may continue to run, without having to wait for the transaction to complete, i.e., wait for requests issued in the transaction to be serviced by the resources , It may issue other requests or perform some other processing. Clients may continue to operate as described above by receiving requests in the transaction and the resources responsible for processing them in parallel.

In the drawings, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals having character names such as "102A" or "102B ", character names may distinguish two similar portions or elements in the same figure. The character names for the reference numerals may be omitted when the reference numerals are intended to cover all the parts having the same reference numerals in all the drawings.
1 is a functional block diagram illustrating exemplary elements of a system for distributed resource management in a portable computing device ("PCD");
2 is a functional block diagram illustrating an embodiment of an example where a first processor needs to request resources controlled by a second processor;
3 is a diagram of a first aspect of a node architecture for managing resources of a PCD;
Figure 4 is a graphical directional acyclic resource graph for a group of exemplary resources of a PCD;
5 is a general diagram of a second aspect of a node architecture for managing resources of a PCD;
Figure 6 is a specific diagram of a second aspect of a node architecture for managing resources of a PCD;
7 is a flowchart illustrating a method for creating a node architecture for managing resources of a PCD;
Figure 8 is a subsequent flow chart of Figure 7 illustrating a method of creating a node architecture for managing resources of a PCD;
9 is a flowchart illustrating the sub-methods or routines of FIGS. 7 and 8 that receive node structure data in a software architecture for a PCD;
FIG. 10 is a flowchart showing the sub-methods or routines of FIGS. 7 and 8 for generating nodes in a software architecture for a PCD;
Figure 11 is a flowchart showing the sub-method or routine of Figure 10 that creates a client in the software architecture of the PCD;
12 is a flowchart illustrating a method for generating a client request for a resource in a software architecture for a PCD;
Figure 13 shows the communication path between two processors, each controlling the resources of the resource graphs of the processors themselves;
14 is another flowchart illustrating a method of creating a node architecture for managing resources of a PCD, wherein some of the resources are distributed resources;
15 is another flowchart illustrating a method for generating a client request for a distributed resource in a software architecture for a PCD;
16 is a flowchart illustrating a method for processing status queries for non-proxy distributed resources in a software architecture for the PCD;
17A is a flowchart illustrating a first portion of a method for processing a status query for a non-proxy distributed resource in a software architecture for a PCD;
17B is a flowchart illustrating a second portion of a method for processing status queries for non-proxy distributed resources in a software architecture for a PCD.
18 is a flowchart showing a method for batching or transactionizing a plurality of resource requests.
19 is an exemplary resource graph in which graph topology blocks deadlock conditions.
Figure 20 is another example resource graph in which the graph topology does not prevent deadlock conditions.
FIG. 21 is an exemplary event timeline showing an example where a deadlock occurs.
Figure 22 is another exemplary event timeline illustrating an example in which the skeptical locking method prevents deadlocks.
Figure 23 is a flow chart illustrating a method for resources to process a resource request, which may be part of a transaction of resource requests.
24 is a timeline diagram illustrating operations of an embodiment of a method and system for managing resource requests that are batched and faked in a portable computing device.

delete

delete

delete

delete

delete

In this description, the term "portable computing device" ("PCD") is used to describe any device that operates on a limited capacity power source, such as a battery. Although battery operated PCDs have been around for decades, technological advances in rechargeable batteries in combination with the advent of third generation ("3G") and fourth generation ("4G") wireless technologies have led many PCDs . Thus, PCDs include, among others, cellular phones, satellite telephones, pagers, personal digital assistants ("PDAs"), smart phones, navigation devices, smartbooks or readers, media players, Lt; / RTI >

1 is a functional block diagram of an exemplary, non-limiting, aspect of a PCD 100 in the form of a wireless telephone that implements methods and systems for distributed resource management in a portable computing device. As shown, the PCD 100 includes an on-chip system 102 having a multi-core, a central processing unit ("CPU") 110A, a graphics processor 110B, and an analog signal processor 126 do. These processors 110A, 110B, 126 may be coupled together into one or more system buses, or other interconnect architectures, as is known to those skilled in the art.

CPU 110A may include up to the Nth core 226 from the zeroth core 222, the first core 224, etc., as will be appreciated by those skilled in the art. In alternative embodiments, one or more digital signal processors ("DSPs") may also be used in place of CPU 110A and graphics processor 110B, as will be appreciated by those skilled in the art. Also, in alternative embodiments, two or more multi-core processors may be included.

As shown in FIG. 1, a display controller 128 and a touch screen controller 130 are coupled to the multi-core CPU 110A. The touch screen display 132, which is external to the on-chip system 102, is coupled to the display controller 128 and the touch screen controller 130. Included also in PCD 100 is a video coder / decoder ("codec") 134, e.g., a phase-alternating line (PAL) encoder, a sequential couleur avec memoire (NTSC) encoder, or any other type of video encoder 134 coupled to a multi-core central processing unit ("CPU") 110A. The video amplifier 136 is coupled to the video encoder 134 and the touch screen display 132. A video port 138 is coupled to the video amplifier 136. As shown in FIG. 2, a universal serial bus ("USB") controller 140 is coupled to CPU 110A. Also, the USB port 142 is coupled to the USB controller 140. A subscriber identity module (SIM) card 146 may also be coupled to the CPU 110A. 1, a digital camera 148 may be coupled to the CPU 110A. In an exemplary aspect, the digital camera 148 is a " CCD "(charge-coupled device) camera or a" CMOS "(complementary metal-oxide semiconductor) camera.

As also shown in FIG. 1, a stereo audio codec 150 may be coupled to the analog signal processor 126. In addition, an audio amplifier 152 may be coupled to the stereo audio codec 150. In an exemplary aspect, a first stereo speaker 154 and a second stereo speaker 156 are coupled to the audio amplifier 152. 1 illustrates that a microphone amplifier 158 may also be coupled to the stereo audio codec 150. [ In addition, the microphone 160 may be coupled to the microphone amplifier 158. In a particular aspect, a frequency modulation ("FM") radio tuner 162 may be coupled to the stereo audio codec 150. In addition, an FM antenna 164 is coupled to the FM radio tuner 162. In addition, stereo headphones 166 may be coupled to the stereo audio codec 150.

1 also shows that a radio frequency ("RF") transceiver 168 may be coupled to the analog signal processor 126. [ RF switch 170 may be coupled to RF transceiver 168 and RF antenna 172. As shown in FIG. 1, a keypad 174 may be coupled to the analog signal processor 126. In addition, a mono headset with a microphone 176 may be coupled to the analog signal processor 126. Vibrator device 178 may also be coupled to analog signal processor 126. 1 also illustrates a power supply 180, e.g., a battery, coupled to the on-chip system 102. The on- In a particular aspect, the power source 180 includes a direct current ("DC") power source or rechargeable battery derived from an alternating current ("AC ") -to-DC transformer connected to an AC power source.

Some of the elements of the above-described elements of the PCD 100 may include hardware, while other elements may include software, and other elements may comprise a combination of hardware and software. The term "resource" is used herein to refer to any such element, whether hardware, software, or a combination thereof, that is controllable by a processor. Resources may be defined as encapsulation of the functionality of these elements in one aspect. The term "processor ", as used herein, refers to a processor, such as a CPU 110, a graphics processor 110B, an analog signal processor 126, or any other processor, controller, Or similar elements that operate under the control of similar control logic. References to two or more "processing entities" may include processors on different chips, different processing cores of the same processor chip, threads of execution on the same core, or arbitrary Other processing entities are included.

As will be described in more detail below, an example of a resource is a software element that runs on a processor. A thread of execution on the processor, for example, a thread associated with the executing application program, may access the resource by causing a "request" to be issued to the resource. As described below, resource requests are processed through a software-based system referred to in this disclosure as a "framework ". The term "client" is widely used in this disclosure to refer to an element that brings the ability to request a resource. Thus, as the terms are used herein, a thread may cause a client to be created or utilized for the purpose of issuing resource requests. It should be noted that, in some cases, a resource may create or use a client so that the resource may cause a resource request to be issued to another resource. As will be described in more detail below, these other resources may be referred to herein as "dependent" resources due to the dependency relationship between the requesting resource and the requested resource. Resources and clients may be represented by data structures in memory.

Not all processors in the PCD 100 have access to all resources in the PCD 100, since the resources are controlled by specific processors in the multi-processor PCD 100. Figure 2 illustrates how the first processor 202 in the PCD 100 may desire to issue a resource request 203 for a resource 204 controlled by the second processor 206 in the PCD 100 Fig. 6 shows an embodiment of the present invention. It is noted that the first processor 202 may also control a plurality of resources 205. Likewise, the second processor 206 may control a plurality of additional resources 207.

In an example where the first processor 202 executes a thread 208 associated with a video player application program, for example, the thread 208 includes a first processor 202 that improves the performance of the first processor 202 ) Of one or more of the operating parameters. (Although the thread 208 and the resource 204 are conceptually shown as being in their respective processors 202 and 206 for clarity, these elements are shown in the processor's memory space in accordance with well-understood computing principles Those skilled in the art will appreciate that these operating parameters may be, for example, clock speed and bus speed. For example, the various processors may use the same bus clock, but only one of the processors may have direct (hardware-level) control of the bus clock. Increasing clock speeds may result in better performance, for example, by video player application programs, since playback of video is generally a more processing power-intensive task than some other tasks. Since the processing power is usually expressed in millions of instructions per second (MIPS), the thread 208 may issue a request for a predetermined number of MIPS. In response to a request for a particular number of MIPS, the resource power manager 204 may generate signals that may indicate clock speed, bus speed, or other parameters that enhance the first processor 202 operating at the requested MIPS level RTI ID = 0.0 > 210 < / RTI >

It may be possible for a thread to access the resource power manager 204 via a bus or protocol specific application program interface (API) through which the first processor 202 may communicate with the second processor 206. However, the framework described below may provide a more uniform way to handle resource requests than resource-specific and bus-specific APIs. Through the framework, through the framework, as described below, whether the request is for a resource controlled by the same processor from which it is issued, or for a resource controlled by a different processor, Are published and serviced. A resource controlled by the same processor from which the resource request is issued may be referred to as a "native" resource. From which a resource controlled by a processor other than the processor from which the resource request is issued may be referred to herein as a "remote resource" or a "distributed resource ".

In addition, issuing a request for a remote resource results in processing overhead in the form of a time delay or latency. That is, a certain amount of time is required for a message or messages associated with a resource request to be sent between processors. In some cases, a single resource request may result in multiple inter-processor messages. The resource request batting feature described herein may help in minimizing the number of interprocessor messages in some instances.

FIG. 3 is a diagram illustrating functional blocks representing software and / or hardware (or both) of the PCD 100. FIG. The blocks on the left side of line "A " represent the resources of PCD 100 controlled by CPU 110A. These resources include: CPU 110A itself; generally referred to as a first hardware element (hardware element # 1); A clock 442 for CPU 110A, generally referred to as a second hardware element (hardware element # 2); A bus arbiter or scheduler 422, also commonly referred to as a third hardware element (hardware element # 3); A bus program (A-444A), also commonly referred to as a first software element (software element # 1); A bus program (B-444B), also commonly referred to as a second software element (software element # 2); A clock program (AHB), also commonly referred to as a third software element (software element # 3); And an action or function that is typically monitored by a software component labeled key press 448. [ CPU 110A controls or has access to the above-referenced resources, such as security constraints that prohibit resources from being accessed by CPU 110A and that resources are within the memory space of CPU 110A There are no other restrictions. For example, it may be possible for the CPU 110A to control or access the hardware registers of these resources. It should be noted that the PCD 100 may include other CPUs 110 (e.g., see FIG. 2) that control resources other than the above-mentioned resources or have access to resources.

A framework manager 440, which may include a library of computer instructions, manages nodes that encapsulate the functionality of resources. That is, the nodes may be accessed to access resources indirectly. For convenience, a node encapsulating the functionality of a resource may be referred to herein as including, including, or having resources. Each node may include one or more resources. The nodes may be defined as software code, firmware code, or similar media, and may be instantiated as data structures in memory 112, for example, during operation of PCD 100. Nodes 601 may be instantiated during startup, power-up, initialization, boot-up, or the like, or at any other suitable time during the operation of PCD 100. It should be noted that references herein to instantiate a resource, issue a request to a resource, or otherwise interact with a resource should be understood to mean an interaction with a node containing the resource. For the remainder of this disclosure, a comprehensive or nonspecific node, as described below with reference to FIG. 5, will be referred to as a reference numeral 601.

Nodes 601 may include, for example, a first node 602 having a single resource, generally corresponding to a first hardware element or central processing unit 110. With the software architecture described in this disclosure, each resource of node 601 may be provided with a unique name that includes one or more alphanumeric characters. In the exemplary embodiment shown in FIG. 3, the resource of the first node 602 is assigned the resource name "/ core / cpu ". These exemplary resource names generally correspond to conventional file naming structures known to those skilled in the art. However, as will be appreciated by those skilled in the art, other types of resource names including alphanumeric characters and / or any other combination of symbols are naturally within the scope of this disclosure.

The nodes 601 may further include, for example, a second node 622 having a plurality of resources. In this exemplary embodiment, the second node 622 has a first resource that includes a single hardware element that corresponds to a bus arbiter or scheduler 422. The second resource of the second node 622 typically includes a software element corresponding to the first software element of bus program A 444A. The third resource of the second node 622 typically includes another software element corresponding to the second software element of bus program B 444B. Those skilled in the art will recognize that any combination and any number of resources and resource types for a given node 601 are, of course, within the scope of this disclosure.

FIG. 3 also illustrates a first client 648 that generally corresponds to the action or function of two software components 448, 450. In the exemplary embodiment shown in FIG. 3, the first client 648 corresponds to a press action that may occur within a particular application program module 105, which is typically supported by the portable computing device 100. However, those skilled in the art will recognize that other actions and / or functions of software elements other than key presses are, of course, within the scope of the present disclosure. Further details regarding client requests 648 and their respective generation will be described below in conjunction with FIG.

Figure 3 also shows the relationships between specific architectural elements. For example, FIG. 3 illustrates the relationship between a client 648 and a first node 602. Specifically, the first client 648 may generate a client request 675A, shown as dashed lines, and the client request 675A may be generated by the first node 602, which includes the resource "/ core / cpu & Managed or processed. Typically, there are client requests 675 of a predetermined or set number of types. Client requests 675 will be described in more detail below in conjunction with FIG.

Other relationships shown in FIG. 3 include dependencies shown as dashed lines 680. The dependencies are the relationships between the respective resources of the other node 601. The dependency relationship usually indicates that the first resource A relies on a second resource B that may provide information to the first resource A or may implement some behavior. This information may be the result of an operation performed by the second source B, or it may simply include state information required by the first resource A or any combination thereof. The first resource A and the second resource B may be part of the same node 601 or they may be part of different nodes 601. It should be noted that the client requests 675 may also originate not only in the threads of execution, but also in other nodes 601 as in the example of the above-described pressure action. In order to obtain information or behavior from the dependent node 601, the node 601 may issue a client request 675 to its dependent node 601. Thus, dashed lines 680 indicating dependencies may also indicate the direction of potential client requests 675.

In Figure 3, the first node 602 relies on a second node 622, as indicated by the dependency arrow 680B, which originates at the first node 602 and extends to the second node at 622. [ 3 also shows that the first node 602 also depends on the third node 642 as shown by the dependency arrow 680A. FIG. 3 also shows that second node 622 depends on fourth node 646 as shown by dependency arrow 680C. Those skilled in the art will recognize that the dependencies 680 shown by the dashed arrows in FIG. 3 are merely exemplary, and that different combinations of dependencies between each of the nodes 601 are within the scope of this disclosure.

Framework manager 440 is responsible for managing the relationships described above, including, but not limited to, client requests 675 and dependencies 680 shown in FIG. Some such relationships, such as dependencies, may be generated by the framework manager 440 in such a way that the nodes 601 of the resources and resources to which it has access to such start-up time to start the node instantiation process, (I.e., power-up, initialization, boot-up, etc.) by the PCD start time. Other such relationships, such as client requests 675, occur after the nodes 601 are instantiated, for example, during execution of an application program thread in which the application program loads resources. Depending on whether the client requests 675 originated from similar elements other than the executing application program threads or nodes 601 (e.g., client request 675A) or from node 601, (S) 675 are indicated through the framework manager 440. The framework manager 440 directs the transmission of information between the nodes 601. Conceptually, framework manager 440 acts as a matrix through which multiple threads may communicate with nodes 601 at essentially the same time. Different threads may carry different data, but the same framework manager software code may serve multiple threads.

As described in more detail below, the framework manager 440 can be configured to allow the nodes 601 (601), 602 (601) and 602 ). ≪ / RTI > The framework manager 440 attempts to instantiate all the nodes 601 defined in the software architecture of the PCD 100. The dependency 680 is completed or resolved when the resource supporting the dependency exists or is ready to process information related to the dependency 680. [

For example, if the third node 642 containing a single resource "/ clk / cpu" is not instantiated due to the dependency relationship 680A that exists between the first node 602 and the third node 642 , The first node 602 containing a single resource "/ core / cpu" may not be instantiated by the framework manager 440. If the third node 642 is instantiated by the framework manager 440, the framework manager 440 may instantiate the second node 602 due to the dependency relationship 680A.

If the framework manager 440 can not instantiate a particular node 601 because the dependency of one or more of the dependencies 680 of the node 601 has not been completed or has not been resolved, Gt; 601 < / RTI > The framework manager 440 skips calls to specific nodes 601 that may not be due to incomplete dependencies for which normally dependent resources have not been created and sends messages reflecting the incomplete state to the call Will return.

In the multi-core environment as shown in Figure 1, the framework manager 440 may be implemented on separate cores such as the zeroth core, the first core, and the Nth core 222, 224, and 226 of Figure 1 Nodes 601 may be created or instantiated. Nodes 601 are generally located on separate cores and in parallel when nodes 601 are not dependent on each other and when all of the corresponding dependencies of a particular node are completed, In a multi-core environment. In a multi-processor environment, nodes 601 may be created or instantiated in various processors, such as CPU 110A, graphics processor 110B, etc. in FIG. That is, some nodes 601 may reside in the memory space of one processor while other nodes 601 may reside in the memory space of another processor. It should be noted, however, that nodes 601 on one processor may not be able to access nodes 601 on another processor only through framework manager 440. [

A remote framework manager 300 similar to the (main) framework manager 440 described above may exist in parallel with and as an extension to the framework manager 440. The remote framework manager 300 cooperates with or otherwise works with the framework manager 440 to coordinate the inter-processor information transfers between the nodes 601 on the different processors. In other words, the remote framework manager 300 may be configured such that in cases where the involved nodes 601 are on different processors, the framework manager 440 may be configured to perform the above-described relationships, such as dependencies and client requests, Helping to keep it. Thus, nodes 601 on one processor may not be provided to be accessible to nodes 601 on another processor through the combined effect of framework managers 440 and 300. [ Further, the combination of framework managers 440 and 300 may be implemented in any way that is contemplated to belong to framework manager 440 in this disclosure, whether the accompanying nodes 601 are on the same processor or on different processors Functions may be performed. In such multi-processor embodiments, individual copies of the software that framework managers 300 and 440 include may be in each domain of the processors. Thus, each processor has access to the same framework manager software.

4 conveniently reorganizes the nodes 602, 622, 642, and 646 described above in the form of a directed acyclic graph ("DAG") 400. FIG. The graph 400 is another way of defining the software architecture described above. In the vocabulary of graph theory, the vertices of graph 400 correspond to nodes 601, the edges of graph 400 correspond to client requests 675, and adjacent nodes or vertices represent resource dependencies. As the framework manager 440 prevents the cycle from being dependent on resource B and resource B being defined as dependent on resource A, one skilled in the art will appreciate that graph 400 is a directional graph and acyclic as a result of dependencies I will recognize. That is, the framework manager 440 will not instantiate the two nodes 601 that are (incorrectly) defined as dependent on each other. The acyclic nature of the graph is important to prevent deadlocks because each node 601 is locked (in terms of transaction processing), as described below. Two nodes 601 in the case where a first thread is accessed and one of these two nodes 601 is locked while a second thread is accessed and another of these two nodes 601 is locked, If they depend on each other, both threads will hang. However, in the relatively rare cases where it is desirable to define two resources in software architecture that are dependent on each other, such as a software developer or other such person involved in defining a software architecture, two (or more) May be included in the same node 601 with respect to the same node 601. The two resources at the same node will share the same lock state. This is because at least in part the software developer or other such person may choose to define a multi-resource node, such as node 622, in the architecture.

It should be appreciated that for clarity and convenience, although the present disclosure may refer to a "node" 601 rather than a "resource" of node 601, client requests may be sent to specific resources rather than nodes . In other words, the node 601, which may be a data structure that encapsulates the functionality of one or more resources, as described above, may be easy to see from the perspective of another issuer of a client request, such as a client or other node 601. From the client's perspective, the request is issued to the resource rather than the node. Likewise, from a client's point of view, an architecture's state query, event, or other element is associated with a resource rather than a node.

A resource graph such as the exemplary graph 400 is useful for understanding instantiation of nodes 601 according to the dependencies described below with respect to Figures 6-10. Leaf nodes, such as nodes 642 and 646, are instantiated before non-leaf nodes, since leaf nodes do not have dependencies. In general, node 601 must be instantiated before a node that relies on node 601 may be instantiated. It can also be seen that servicing a resource request corresponds to traversing a directional acyclic graph, in a directed acyclic graph, vertices correspond to nodes 601, edges correspond to client requests 675, The nodes or vertices represent resource dependencies.

In the multi-processor PCD 100, the first processor may have or control access to the first set of nodes 601 in the first resource graph, while the second processor may be in the second resource graph The first and second resource graphs may have access to or control an access to the second set of nodes 601 of the first and second resource graphs, where the first and second resource graphs do not share any resources, that is, they are mutually exclusive resource graphs . That is, in such an environment, each processor has its own resource graph that defines relationships between resources and other elements that are not accessible by other processors. Distributed resource management of the present disclosure is advantageous in situations where two or more processors each have access to resources in their own resource graphs and do not have access to resources in resource graphs of other processors, To maintaining the above relationships, e.g., dependencies and client requests.

The above-mentioned restrictions on access to resources may, in some embodiments, be limited by hardware configuration. That is, a processor may not have a means, such as a register, that may affect a hardware device, since the hardware device is controlled by another processor or is in a memory space of another processor. Alternatively, or additionally, a restriction on access to resources may be imposed on the software because it minimizes processor exposure to security risks (e.g., viruses that may infect other processors) .

FIG. 5 is a general diagram of another aspect of the software architecture 500B1 for a system for managing resources of the PCD 100 of FIG. This aspect is described in the context of PCD 100 and architecture in which all the resources and other elements involved are controlled by the same processor, that is, they are included in the same resource graph. In this general diagram, unique names are not provided for one or more resources of each node 601. The node or resource graph 500B1 of Figure 5 includes only nodes 601, clients 648, events 690, and query functions 695 supported by the architecture or framework manager 440 . Each node 601 is shown with arrows 680 having an oval shape and specific directions representing respective dependencies between the resources in the node 601. [

Figure 5 also illustrates how a client 648 of a first node 601A may issue a client request 675 to a first node 601A. After these client requests 675 have been issued, the second node 601B may trigger an event 690 or provide a response to the query 695, where event 690 and query 695 The corresponding messages are moved back to the client 648.

FIG. 6 shows a more specific diagram of the above-described aspects of the software architecture 500B2 for a system for managing resources of the PCD 100 of FIG. Figure 6 includes only nodes 601, which are exemplary but specific resource names, as well as clients 648, events 690, and query functions 695, corresponding to those of Figure 3 Lt; RTI ID = 0.0 > 500B2 < / RTI > Each node 601 is shown with arrows 680 having an oval shape and specific directions representing respective dependencies between the resources in the node 601. [

For example, the first node 602 has a dependency arrow 680B indicating that the first node 602 depends on the three resources of the second node 622. [ Similarly, a third resource " / bus / ahb / sysB / ", which includes the second software element 444B and is generally designated by the reference character "C & / Clk / sys / ahb "resource of resource 646, as shown in FIG.

FIG. 6 also shows output data from nodes 601, which may include one or more events 690 or query functions 695. The query function 695 is similar to the event 690. Query function 695 may have query processing that may or may not be unique. The query function is generally not externally identified, and generally has no status. The query function 695 may be used to determine the state of a particular resource of the node 601. The query function 695 and events 690 may have relationships with the established client 648 and these relationships may include information from each event 690 and query function 695 to a particular client 648 Indicated by directional arrows 697 indicating that it is delivered.

The nodes or resource graphs 500B of FIGS. 5 and 6 show relationships that exist in memory under the control of the processor and are managed by the framework manager 440. FIG. The node or resource graph 500B may be used by the frame manager 440 to identify relationships between each of the elements managed by the framework manager 440 and to automatically .

FIG. 7 is a flowchart illustrating a method 1000A for creating or instantiating software structures for managing the resource (s) of the PCD 100. FIG. This method is described in the context of an architecture in which all the resources and other elements involved are controlled by the same processor, that is, they are included in the same resource graph. Block 1005 is a first routine of the method 1000 or process 1000 for managing resources of the PCD 100. At block 1005, the routine may be executed or activated by framework manager 440 to receive node structure data. The node structure data may include a dependency array that outlines the dependencies that a particular node 601 may have with other nodes 601. [ Further details regarding the node structure data and these routines or sub-methods 705 will be described in more detail below in conjunction with FIG.

Next, at block 1010, framework manager 440 may review dependency data that is part of the node structure data received at block 1005. [ At decision block 1015, the framework manager 440 may determine if the node structure data defines a leaf node 601. The leaf node 601 generally means that the node to be created based on the node structure data does not have any dependencies such as nodes 642 and 646 in Figs. 3 and 4. If the inquiry to the decision block 1015 is positive (meaning that the node structure data for creating the current node does not have any dependencies), the framework manager 440 sends the routine block 1025 Continue.

If the query to decision block 1015 is negative, then a "no" branch is followed by decision block 1020, where the framework manager determines if all strong dependencies in the node structure data are present. A strong dependency may include that a resource can not exist without it. On the other hand, a weak dependency may include that the resource may utilize a dependent resource as an optional step. A weak dependency means that the resources of node 601 or node 601 with a weak dependency may be created or instantiated in the node architecture even if there is no weak dependency.

Embodiments of the weak dependency may include optimization features that are not critical to the operation of the resource-oriented node 601 including a plurality of resources. The resource manager 440 may create or instantiate a node or resource for all the strong dependencies that are present even if the weak dependencies are not weakly dependent on those nodes or resources with weak dependencies that are not created. If the call back feature is used to refer to a weak dependency so that a weak dependency is made available to the framework manager 440, then the framework manager 440 may refer to the weak dependency that weak dependencies are now available Will be notified to each callback.

If the query to decision block 1020 is negative, then a "no" branch will follow block 1027, where the node structure data is stored by the framework manager 440 in a temporary storage such as memory, The work manager 440 creates callback features associated with these un-instantiated nodes.

If the query to decision block 1015 is positive, then the routine 1025 follows the "yes" branch, where the node 601 is created or instantiated based on the node structure data received at the routine block 1005 . Additional details of the routine block 1025 will be described below in conjunction with FIG. Next, at block 1030, the framework manager 440 publishes the newly created node 601 using its unique resource name (s) to allow the other nodes 601 to access the newly created node 601 ) Or may receive information from a newly created node.

Referring now to FIG. 8, which is a flowchart of the subsequent flow chart of FIG. 7, at block 1035, framework manager 440 determines that the newly created node 601 has been instantiated and is ready to receive or transmit information to the newly created node 601 to other nodes 601 that depend on that node. According to one exemplary aspect, notifications are immediately triggered when a dependent node, such as node 601B of FIG. 5, is created, i.e., notifications are performed recursively. Thus, when the node 601B of Fig. 5 is configured, it is immediately notified to the node 601A. (Since node 601B is the final dependency of node 601A), this notification may allow node 601A to be configured. The configuration of node 601B may cause other nodes 601 to be notified, and so on. The node 601B is not completed until the final resource that depends on the node 601B is completed.

The second, slightly more complex implementation is to place all of the notifications on a separate notice queue, then run through the queue starting at a single point in time, i.e., notifications are repeatedly performed. Thus, when node 601B of FIG. 5 is configured, the notification for node 601A is pushed on the list. Then, the list is executed and node 601A is notified. This causes a notification to the other additional nodes 601 (other than node 601A, not shown in FIG. 5) to be placed on the same list, and the notification is then sent to node 601A after the notification to node 601A is sent . Notifications to other nodes 601 (in addition to the notification to node 601A) do not occur until after all operations associated with node 601B and node 601A have been completed.

Logically, these two implementations are equivalent, but implementations have different memory consumption characteristics when implemented. Recursive realization is simple, but it can consume any amount of stack space, and stack consumption is a function of depth of dependency graph. The iterative implementation is slightly more complex and requires more static memory (notification list), but the stack usage is constant regardless of the depth of the dependency graph as shown in FIG.

Also, the notification of node creation at block 1035 is not limited to other nodes. It may also be used internally for an alias configuration. When any node, not other nodes, becomes available, any of the elements in system 500A may request notification using the same mechanism. All of the nodes may use the same notification mechanism, or none of the nodes may use the same notification mechanism.

At decision block 1040, the framework manager 440 determines whether other nodes 601 or weak dependencies are now released for creation or instantiation based on the creation of the current node 601. [ Decision block 1040 generally determines whether resources may be created because certain dependency relationships 680 have been achieved by the current node that has undergone a recent creation or instantiation.

If the inquiry to decision block 1040 is affirmative, then a "Yes" branch is followed by a routine block 1025, where node 601, which is not understood due to the achievement of dependency by node 601 just created, It can now be created or instantiated.

If the query to decision block 1040 is negative, then a "no" branch is followed by block 1045 where framework manager 440 manages communications between elements of the software architecture as shown in FIG. 2 You may. Next, at block 1050, the framework manager 440 may continue to log or log actions taken by the resources by using resource names associated with the particular resource. Block 1045 may be any action taken by framework manager 440 or elements that are managed by framework manager 440 such as sources 602 and clients 648, May be executed by framework manager 440 after any of query functions 695, query functions 697, Block 1045 illustrates another aspect of the node architecture in that it is a unique identifier of each element provided by the authors who created the particular element, such as the resources of node 601, Depending on the name, you can also keep an activity log of activity diagrams listing the actions performed by each element.

In comparison to the prior art, logging of this activity in block 1050, which lists the unique names assigned to each resource in the system, is unique and provides significant advantages as used in debugging and error problem solving . Another unique aspect of the node architecture 500A is that separate teams may work independently of different hardware and / or software components, where each team is associated with another team and / or original equipment manufacturer (OEM) It would be possible to use unique and easy resource names to track without having to create a table to interpret meaningless and usually confusing resource names assigned by.

Next, at decision block 1055, framework manager 440 determines if a log of the activity recorded by framework administrator 440 has been requested. If the query to decision block 1055 is negative, then a "no" branch is followed by the end of the process, where the process returns to routine 1005 again. If the lookup for decision block 1055 is affirmative, then block 1060 follows the "Yes" branch, where framework manager 440 determines that each of the resource names An activity log containing actions is transmitted to an output device, e.g., a printer or display screen, and / or both. The process then returns to the routine block 1005 described above.

FIG. 9 is a flowchart showing the sub-method or routine 1005 of FIG. 7 for receiving node structure data defining the software architecture of the PCD 100. FIG. The receiving method may occur at any suitable time, for example, when the PCD 100 is started or initialized. In this case, the node structure data is received when the processor reads the corresponding software code from the memory in preparation for instantiation of the nodes 601 according to the architecture. Block 1105 is the first step in the sub-method or routine 1005 of FIG. At block 1105, framework manager 440 may receive a unique name for a software or hardware element, such as CPU 110 and clock 442 in FIG. As discussed previously, node 601 should reference at least one resource. Each resource has a unique name in system 500A. Each element in the system 500A may be identified by a unique name. Each element has a unique name in the character plane. In other words, generally there are no two elements with the same name in system 500A. According to exemplary aspects of the system, the resources of the nodes 601 may generally have unique names across the system, but the client or event names are not required to be unique, You may.

For convenience, a conventional tree file naming scheme or file naming "metaphor" that uses forward slash "/" characters to generate unique names may be used, for example, but not limited to, "/ core / cpu "for clock 442, and" / clk / cpu "for clock 442. However, as will be appreciated by those skilled in the art, other types of resource names including alphanumeric characters and / or any other combination of symbols are naturally within the scope of this disclosure.

Next, at block 1110, the framework manager 440 may receive data for one or more drive functions associated with one or more resources of the node 601 being created. The drive function generally includes actions to be completed by one or more resources for a particular node 601. [ For example, in FIGS. 7A and 7B, the drive function for the resource (/ core / cpu) of the node 602 is determined by the amount of bus bandwidth and CPU clock frequency required to provide the requested amount of requested processing You can also request it. These requests will be made through the clients of resources at nodes 642 and node 622. [ The drive function for / clk / cpu at node 642 will be responsible for actually setting the physical clock frequency according to the request received by the drive function from the / core / cpu resource of node 602 in general.

At block 1115, the framework manager 440 may receive node attribute data. The node attribute data typically includes security (which is that the node can be accessed through user space applications), remoteness (which can be accessed from other processors in the system), and accessibility Which can support a large number of concurrent clients). The framework manager 440 may also define attributes that allow the resource to ignore the default framework behavior, e.g., request evaluation or logging policy.

Subsequently, at block 1120, the framework manager 440 may receive customized user data for the particular node 601 being created. The user data may include a void "star" field as understood by those skilled in the art for the "C" programming language. User data is also known to those skilled in the art as "trust me" field. Exemplary customized user data may include, but is not limited to, tables such as frequency tables, register maps, and the like. The user data received at block 1120 is not referenced by system 500A, but allows customization of resources if alignment is not recognized by framework administrator 440 or is not fully supported. This user data structure is a base class in the "C" programming language intended to be extended to specific or special uses.

Those skilled in the art will recognize that other types of data structures for extending special uses of a particular class are within the scope of this disclosure. For example, in a programming language of "C ++" (C-plus-plus), an equivalent structure may include the keyword "public" to be an extension mechanism for resources in node 601.

Next, at block 1125, framework manager 440 may receive dependent array data. The dependency array data may include unique and specific names of one or more resources 601 upon which the node 601 to be created depends. For example, if the first node 602 of FIG. 6 is created, then at this block 1125, the dependent array data may be stored in the memory of the second node 622 of the second node 622 on which the first node 602 depends, Names and a single resource name of the third node 642. [

Subsequently, at block 1130, the framework manager 440 may receive the resource array data. The resource array data may include parameters for the current node being created, e.g., parameters associated with the first node 602 of FIGS. 7B and 7C when this first node 602 is created. Resource array data includes the following data: names of other resources; unit; Maximum value; Resource attributes; Plug-in data; And any customized resource data that is similar to the customized user data in block 1120. [ The plug-in data generally identifies the functions taken from the software library and typically lists the client types that may be supported by a particular node or a plurality of generated nodes. The plug-in data also allows customization of client creation and destruction. After block 1130, the process returns to block 1010 of FIG.

In Figure 9, attribute data block 1115, customized user data block 1120, and dependent array data block 1125 are used to indicate that these particular steps are optional and are not required for any given node 601 Dashed lines. On the other hand, a unique name block 1105, a driving function block 1110, and a resource array data block 1130 are used to indicate that the steps of this routine 1005 are important for generating the node 601 It is shown as solid lines.

10 is a flow chart showing the sub-method or routine 1025 of Fig. 7 for generating nodes in a software architecture for PCD 100. Fig. Routine block 1205 is a first routine in sub-method or routine 1025 for instantiating or generating node 601 in accordance with one exemplary embodiment. At the routine block 1205, one or more clients 648 associated with the node 601 being instantiated are created at this stage. Additional details on the routine block 1205 will be described in more detail below in conjunction with FIG.

At block 1210, the framework manager may create or instantiate one or more resources corresponding to the node structure data of block 705. [ Next, at block 1215, the framework manager 440 may activate the drive functions received at the routine block 1110 of the routine block 1005. According to one exemplary aspect, the driving functions may be activated using the maximum values received in the resource array data block 1130 of the routine block 1005. [ According to another, preferred, exemplary aspect, each drive function may be activated with an optional, initial value that is passed along with the node structure data from the routine 1005. If no initial data is provided, the drive function is initialized to a zero-minimum value -. The drive function is also activated in a manner that is normally known in which the drive function is initialized. This enables the resource to perform certain operations that are specific to initialization, but that do not need to be performed during regular or routine operations. The process then returns to step 1030 of FIG.

FIG. 11 is a flowchart showing the sub-method or routine 1025 of FIG. 10 that creates or instantiates a client 648 in the software architecture of the PCD 100. FIG. Block 1305 is the first step in the routine block 1205 in which the client 648 of one or more of the sources 601 is created. At block 1205, the framework manager 440 receives the name assigned to the client 648 being created. Similar to resource names, the name for the client 648 may include any type of alphanumeric and / or symbols.

Next, at block 1310, customized user data may be received by framework manager 440 if there are any specific customizations to these generated clients 648. [ Block 1310 is shown with dashed lines to indicate that the step is optional. The customized user data in block 1310 is similar to the customized user data discussed above in connection with the generation of resources for nodes 601. [

At block 1315, framework manager 440 receives the client type category assigned to the particular client being created. The client type category in this article may include one of four types: (a) required, (b) impulse, (c) vector, and (d) isochron. The client type category list may be extended depending on the resources managed by the system 101 and depending on the application programs that rely on the resources of the nodes 601. [

The requested category generally corresponds to the processing of the scalar value passed to the specific resource 601 in the required client 648. For example, the requested request may include a predetermined number of millions of instructions per second (MIP). On the other hand, the impulse category generally corresponds to the processing of a request to complete some activities within a predetermined time period without specifying any start time or stop time.

An isochronous category generally corresponds to a request for an action that typically recurs and has a well-defined start time and a well-defined end time. The vector category generally corresponds to an array of data that is part of a number of actions that are usually required in series or in parallel.

Subsequently, at block 1320, the framework manager 440 receives data indicating whether the client 648 has been designated synchronously or asynchronously. The synchronous client 648 may request that the framework manager 440 send an indication to the resource 601 that the resource 601 has finished completing the requested task from the synchronous client 648, Lt; / RTI > of the resource).

On the other hand, the asynchronous client 648 may be processed in parallel by one or more threads that are accessed by the framework manager 440. Framework 440 may generate a callback for the thread and may return a value if the callback is executed by each thread. Those skilled in the art will appreciate that asynchronous client 648 does not lock resources, such as synchronous client 648, when the task of synchronous client 648 is executed.

After block 1320, at decision block 1325, framework manager 440 determines if the resource identified by client 645 is available. If the query to decision block 1325 is negative, then a "no" branch is followed by block 1330, where a null value indicating that client 648 can not be created at this time, .

If the lookup to decision block 1325 is affirmative, a decision block 1335 follows the "yes" branch, where each resource identified by client 648 supports the client type provided at block 1310 Is determined by the framework manager 440. If the query to decision block 1335 is negative, then a "no" branch is followed by block 1330 where a null value or message indicating that client 648 can not be created at this point is returned.

If the lookup to decision block 1335 is affirmative, block 1340 follows the "Yes" branch, where framework manager 440 creates or instantiates client 648 in memory. Next, at block 1345, if any customized user data, such as optional arguments, are received at block 1310, these optional arguments may be mapped to their respective resources for a particular node 601 . Next, at block 1350, the newly created client 645 is coupled to the corresponding one or more resources of the newly created client in the idle state or in the requested state, as described above. The process then returns to block 1210 of FIG.

12 is a flow chart illustrating a method 1400 of generating a client request 675 for a resource 601 in a software architecture for the PCD 100. [ The method 1400 is generally executed after client and node creation (instantiation) as described above in connection with Figures 7-11.

Block 1405 is the first step in method 1400 of generating a client request 675 for a resource 601. The method 1400 describes three types of client requests 675: (a) required, (b) impulse, and (c) how the vector is processed by framework manager 440 will be. As suggested by the names of the requests 675 described above, the client requests 675 generally correspond to the client types created and described above.

At block 1405, framework manager 440 receives data associated with a particular client request 675, such as one of the three: (a) requested, (b) impulse, and (c) It is possible. The data associated with the requested request generally includes a scalar value that is passed from the requested client 648 to the particular resource 601. [ For example, the requested request may include a predetermined number of millions of instructions per second (MIP). The impulse request includes a request to complete some activity within a predetermined time period without any designation of a start time or a stop time. The data for the vector request typically includes an array of a number of actions that are required to be completed serially or in parallel. The vector request may contain values of any length. A vector request usually has an array of size values and values. Each resource of node 601 may be extended to have a pointer filter to support vector requests. In the "C" programming language, the pointer field is supported by an integrate function as understood by those skilled in the art.

Next, at block 1410, framework manager 440 issues a request through client 648 generated by the method described above in conjunction with FIG. Subsequently, at block 1415, the frame manager 440 double-buffers the request data delivered via the client if the request is of the type or vector type required. If the request is an impulse type, block 1415 is skipped by framework manager 440.

For the requested requests, at this block 1415, the values from the previous request are kept in memory to indicate to the frame manager 440 whether there is any difference between the previously requested values in the current set of requested values. May decide. For vector requests, the previous requests are not usually held in memory, but the resources of node 601 may maintain previous requests according to the requirements for a particular implementation. Thus, block 1415 is optional for the vector types of requests.

At block 1420, the framework manager 440 calculates the delta and the difference between the previous set of requested values in the current set of requested values. At decision block 1425, the framework manager determines whether the current set of requested values is the same as the previous set of requested values. In other words, the framework manager 440 determines if there is a difference between the current set of requested values and the previous set of requested values. If there is no difference between the current set of requested values and the previous set, block 1475 follows (which skips blocks 1430 through 1470) followed by the "yes" branch, where the process ends .

If the lookup to decision block 1425 is negative (which means that the set of requested values is different compared to a pre-set of previously requested values), a decision block 1430 follows the "no" branch come.

At decision block 1430, framework manager 440 determines if the current request is an asynchronous request. If the query to decision block 1430 is negative, then a "no" branch is followed by block 1440 where the resource 601 corresponding to the client request 675 is locked by the framework manager 440. If the lookup for decision block 1430 is positive (which means that the current request is an asynchronous request type), block 1435 follows the "Yes" branch, where the multi-core system, If currently managed by the work manager 440, the request may be pushed onto another thread or executed by another core. Block 1435 is shown with dashed lines to indicate that this step may be optional if PCD 100 is a single core central processing system.

Subsequently, at block 1440, the resources 601 corresponding to the request 675 are locked by the framework manager 440. Next, at block 1445, the resource 601 typically executes an update function corresponding to the plug-in data of the resource array data received at block 1130 of FIG. Update functions typically include functions that take into account new client requests and are responsible for new resource states. The update function compares its previous state with the requested state in the client request. If the requested state is greater than the previous state, the update function will perform the client request. However, if the requested state is less than or equal to the current state, and the resource is operating in the current state, the client request will not be performed to increase efficiency since the old state achieves or satisfies the requested state. The update function takes a new request from the client and aggregates it with all other active requests to determine a new state for the resource.

As an embodiment, multiple clients may request a bus clock frequency. The update function for the bus clock will usually take the maximum of all client requests and use it as the new desired state for the bus clock. Although there are some update functions that will be used for multiple resources, not all resources will use the same update function. Some common update functions take the maximum of client requests, take the minimum of client requests, and sum the client requests. Alternatively, resources may define a custom update function of the resources themselves if their resources need to aggregate requests in some unique way.

Next, at block 1450, the framework manager 440 may pass data to the resource corresponding to the client 648 so that the resource may execute a drive function specific to the resource of the node 601. [ The drive function applies the computed resource state by the update function. This may involve updating hardware configurations, issuing requests for dependent resources, calling legacy functions, or a combination of the above.

In the previous embodiment, the update function computed the requested bus clock frequency. The drive function may receive the requested frequency and update the clock frequency control HW to operate at that frequency. It is noted that sometimes the drive function may not be able to satisfy the exact requested state that the update function has completed. In this case, the driving function may choose a frequency that best meets the request. For example, the bus clock HW may only operate at 128 MHz and 160 MHz, but the requested state may be 150 MHz. In this case, the drive function will have to run at 160 MHz, which exceeds the requested state.

Next, at block 1455, the framework 440 receives state control from the resource that executed the drive function at block 1450. [ Subsequently, at block 1460, events 690 may be triggered such that data is passed back to the client 648 corresponding to the event 690 if defined for the resource. Events may be processed in other threads. This may minimize the amount of time spent in locking resources and allow for parallel operation in a multi-core system as shown in FIG. One or more events 690 may be defined for the resource in a manner similar to the manner in which a request such as that described in method 1400 may be defined for the resource. In other words, the event generation process is largely parallel to the client creation process. One thing that is different from events is that it is possible to define events that are triggered only if they exceed certain thresholds.

This provision of events that are triggered only on the basis of thresholds allows notification of a resource being requested more than necessary (having more simultaneous users than the resource can support), and the notification can be a system overload condition, A resource shortage / off that may allow others to shut off, and a re-store functionality that is disabled if the system is requested more than necessary. Because the event registration may be done according to the thresholds, it only reduces the amount of work the system has to do for the event notification to happen only when something really needs to happen. It is also possible to register events for all state changes.

Next, in optional block 1465, if the request being processed is a vector request, then this optional block 1465 is usually performed. Selective block 1465 typically includes a check or decision to assess whether the vector pointer is still positioned to the same data that the user has delivered to the vector. If the lookup for this optional block 1465 is positive (which means that the pointer is still pointing to the same data passed in as a vector by the user), the pointer is erased and references to the old data are not maintained. This optional block 1465 is generally performed to account for the double buffering block 1415 described above when a vector request is processed, as compared to an impulse request and a requested request.

Subsequently, at block 1470, the framework 440 unlocks the requested resource so that other client requests 648 may now be processed by the now-released requested resource of the particular node 601, do. The process then returns to the first block 1405 to receive the next client request.

The above-described methods and data structures are fundamentally applicable to multi-processor PCD 100 as they are applicable to single-processor PCD 100. [ However, the remote framework 300 (FIG. 3) may provide additional features that may improve operation in a multi-processor embodiment. For example, the remote framework 300 may advantageously provide details of interprocessor communication that is easy for an application programmer or similar person to understand. Thus, an application program may define a client issuing a request for a target resource without having to include any identification of the processor domain controlling the resource, for example, in the client specification. Rather, the remote framework 300 ensures that the request reaches the target resource, regardless of which processor controls the client and which processor controls the target resource. The remote framework 300 also manages inter-processor communications, for example, to allow an application program to execute arbitrary instructions associated with protocols or other aspects of communication paths (e.g., busses) between processors You do not need to include it. Also, as different interprocessor communication paths may use different protocols, the remote framework 300 allows the resource provision to specify the protocol with other aspects of the resource. These and other features associated with distributed resource management are described below with respect to Figures 13-23.

Figure 13 illustrates that a first resource 1302 controlled by a first processor (not shown) acts as a distributed or remote resource corresponding to a second resource 1304 controlled by a second processor (not shown) An embodiment or a case. The term " distributed resource "or" remote resource "is used in this disclosure to refer to a resource on one processor corresponding to a" native "resource on another processor. The second resource 1304 in this embodiment serves as a native resource for the second processor. Distributed resources are used as a means to access corresponding native resources. In such an embodiment, the term "resource" may be used interchangeably with the term "node ", since such resources may be included in the node.

Dotted line 1301 illustrates the division between the resources controlled by the first processor (left of line 1301) and the resources controlled by the second processor (right of line 1301). The first resource 1302 is one of two or more resources controlled by the first processor. One such resource may be the protocol resource 1306 on which the first resource 1302 depends. Likewise, the second resource 1304 is one of two or more resources controlled by the second processor. In some embodiments, only distributed resources depend on protocol resources, and native resources do not depend on protocol resources. Thus, in these embodiments, only the first (distributed) resource 1302 depends on the protocol resources 1306. [ However, in other embodiments, any resource may depend on the protocol resources. Thus, in an alternative embodiment, the second resource 1304 may also depend on protocol resources (not shown). The first and second resources 1302 and 1306 may also generally rely on additional resources in the same manner as described above for resources or nodes, but these additional resources are not shown in FIG. 13 for clarity. Do not. Resources controlled by the first processor are defined by a first resource graph (i.e., directional acyclic graph), and resources controlled by the second processor are defined by a second such that they do not share any resources with the first resource graph. Note that it is defined by the resource graph.

Under the control of their respective processors, the first and second resources 1302 and 1304 are capable of communicating information via communication path 1303. Communication path 1303 represents a physical medium between the first and second processors, and a combination of one or more layers of transport protocols used to communicate through the medium. Accordingly, any communications between the first resource 1302 and the second resource 1304 must conform to the protocols. Protocol resources 1306 and 1308 may define a protocol, or may point to a protocol specification in a library (not shown). The remote framework 300 and (main) framework 440 operate in conjunction with one another to manage resources and communications between them. Under the control of the first processor, the client 1312 may issue one or more resource requests for the first resource 1302, as described below. The first resource 1302 services the resource request using the functionality of the corresponding second resource 1304.

FIG. 14 is a flowchart illustrating a method 1400 of creating or instantiating distributed resources, such as the first resource 1302 of FIG. 13. The flowchart of FIG. 14 is intended to illustrate features that enhance the above-described features in addition to or in addition to those described above with respect to methods for instantiating resources, such as the method illustrated in FIGS. Accordingly, any or all of the blocks in Figs. 7 to 10 may be included, except where they may otherwise be displayed, but the clarity is not shown in Fig. 14 above.

As indicated at block 1402, framework managers 300 and 440 receive node structure data that defines a node, such as including a first resource 1302. In an exemplary embodiment, the dependencies are determined in substantially the same manner as described above with respect to Figures 7 to 10, except that the protocol resources may be instantiated at any time, as indicated by block 1406. [ . A resource that depends on a protocol resource does not have to wait for its protocol resources to be instantiated. Instantiation of dependencies in the manner described above with respect to Figures 7-10 is generally illustrated by block 1408. [

It should be noted that although instantiation generally follows the methods described above with respect to Figures 7-10, distributed resources can not be instantiated until a native resource corresponding to the distributed resource is instantiated. Thus, instantiation of native resources may delay instantiation of distributed resources in the same way that instantiation of dependent resources may delay instantiation of resources dependent on native resources. It should also be noted that messages relating to the state of instantiation of native resources communicated between the first processor and the second processor and the framework managers 300 and 440 via communication path 1303 generally conform to the stated protocol . For example, after a protocol resource 1306 on a first protocol is instantiated, a first processor operating according to the remote framework manager 300 may send a request for a notification that is encoded or otherwise compliant to a second processor . If the second resource 1304 has been instantiated, the second resource operating in accordance with the remote framework manager 300 may send a request to the notification by sending a response to the first processor indicating that the second resource 1304 has been instantiated You can also respond. The remote framework manager 300 may manage these communications and others as part of the process of instantiating the software architecture.

The protocol resources 1306 on the first processor include functions that, among other functions, create a client, such as client 1312 shown in FIG. 13, and return processing for clients that may be used by the thread of execution . A thread of execution (e.g., an application program or a portion of the execution of another software element) may invoke a function to create such a client 1312. The thread may use the client 1312 to issue resource requests or otherwise use the client 1312 in the same manner as described above for clients in general. The resource request is protocol-specific and allows the thread to access the second resource 1304 without the need for the thread to provide any information related to the protocol. From the perspective of clients of threads and threads, the protocol may be irrelevant or easy to understand.

As shown in block 1410, frameworks 300 and 400 determine if the aggregation method is specified in the received node structure data. If it is determined that the aggregation method is specified, then the aggregation method is set to the distributed resource (node) and the native resource (node), as indicated at block 1412. There are two types of aggregation: local and proxy. When defining a resource, one of the two flocculation types may be selected as the flocculation type. Thus, when instantiating a resource (node), the resource is set to perform either local cohesion or remote cohesion.

A resource performs local aggregation by applying an algorithm to a number of resource requests that may be received "simultaneously ". In this context, two (or more) requests are "concurrent" while both requests remain active. For example, the first processor may issue a resource request to set the speed of the first processor to 50 MIPS, and before the request of the first processor is completed or otherwise terminated, Lt; RTI ID = 0.0 > 100 MIPS. ≪ / RTI > Aggregation may be accomplished by determining the maximum of all of the multiple resource requests, by determining the minimum of all of the multiple resource requests, or by adding each argument of the multiple simultaneous resource requests Or the like. The aggregation method may be specified or specified with the aggregation type in the node structure data defining the resource (node).

The node structure data may indicate that the node will be instantiated as a proxied node or an unproxy node. The manner in which this feature may be used is described below with reference to Figs. 16 and 17. Fig. As indicated by block 1414, the node type is set to the indicated type. In the case of a non-proxied node, client requests are aggregated locally in a manner determined by the node structure, and a drive function is used to transfer the locally aggregated request to the native resource. Queries and events are handled by distributed resources. In the case of a proxyed node, client requests are not aggregated, but are instead sent separately to native resources. In addition, all queries and events are forwarded to the native resource.

As indicated by block 1416, any remaining steps in the instantiation process occur. These aspects of instantiating the distributed nodes may be fundamentally the same as described above with respect to Figs. If additional nodes are defined, as indicated by block 1418, the method repeats or continues for these nodes.

15 is a flow chart illustrating a method 1500 of servicing a client request. The flowchart of FIG. 15 is intended to illustrate features that enhance the above-described features in addition to or in addition to those described above with respect to methods of servicing client requests, such as the method illustrated in FIG. Accordingly, any or all of the blocks in FIG. 12 may be included, except where they may be otherwise displayed, but are not shown in FIG. 15 for clarity.

As indicated by block 1502, a distributed resource, such as the first node 1302 in FIG. 13, receives the client request. As indicated by block 1504, it is determined whether the type of cohesion associated with the requested resource is local or remote. If the cohesion type is local, as indicated by block 1506, the requested resource aggregates the request arguments with others occurring within the same window. As described above, coherence relates to handling concurrent resource requests. If the aggregation type associated with the requested resource is remote, then the request will be left for the corresponding native resource, such as the second resource 1304 in FIG. 13, to coalesce with the others.

Whether local or remote, cohesion suggests three sequential states of the client request: (1) Request Issued, (2) Request in Progress, and (3) Request Applied . If the client requests are issued simultaneously, that is, if the two client requests each start the request issuance state at substantially the same time or within the windows of each other mentioned above, the first occurring client request may be that the requested resource is locked The second client request is processed after the first client request. The client request is processed or serviced during the request progress state. After the client request is completed, the client request is assigned a request application status. Aggregation works when a large number of concurrent client requests reach the request application state. For example, if a resource is defined to use the maximum aggregation method mentioned above, and client "A" requests 50 MIPS, perhaps a few microseconds later, when client "B" requests 100 MIPS, The requests will be serialized. Thus, when the first client request is processed, the resource will be set to the argument of the first client request or 50 MIPS. Then, when the second client request is processed, the resource will be set to 100, because 100 is the maximum of 50 and 100, according to the maximum aggregation method. Thereafter, when both of these initial client requests are in the request application state, client "B" may issue another client request for 25 MIPS. According to the maximum flocculation method, the requested resource will be set to 50, since 50 is the maximum of 50 and 25.

As indicated at block 1508, it is determined whether the requested resource is dependent on protocol resources, e.g., protocol resources 1306 in FIG. 13. When the requested resource depends on the protocol resource, the protocol resource is called and used so that the resource request conforms to the protocol defined by the protocol resource, as indicated by block 1510 and block 1512, respectively. As indicated by block 1514, in compliance with the protocol, when a resource request reflecting the aggregation result (the result of block 1506) is sent, or when the remote resource performs aggregation, the second A resource request is forwarded to a native resource, such as resource 1304. The driving function (not shown) of the distributed resource invokes the protocol.

Although not shown in FIG. 15, events involving distributed resources may be processed in a manner substantially similar to that described above with respect to FIG. The types of events that monitor for values above a threshold may be particularly useful in combination with the proxyed resource, as described below.

16 is a flow chart illustrating a method 1600 of servicing a status query for a non-proxied type of distributed resource. The state queries are maintained by the framework 440 as described above with respect to Figures 5 and 6. The flowcharts of FIGS. 16 and 17 illustrate features that add to or in addition to the features described above with respect to FIGS. 5 and 6. FIG. Accordingly, any or all of the features described above with respect to Figures 5 and 6 may be included, except where they may be otherwise displayed, but are not shown in Figures 16 and 17 for clarity.

As represented by block 1602, a distributed resource, such as that of the first node 1302 in FIG. 13, receives a status query. In this embodiment, the first node 1302 represents a node or resource that has not been proxied. As indicated by block 1604, the state query is forwarded to the corresponding native resource, such as the second resource 1304 in FIG. As indicated by block 1606, in response to the state query, the state of the native resource is transferred back to the distributed resource. As indicated by block 1608, the distributed resource may then provide a status indication to the query requester (client) indicating the status of the native resource.

17A is a flow chart illustrating a first portion of a method 1700 of servicing a state query for a distributed resource of a proxyed type. As indicated by block 1702, a distributed resource, such as that of the first node 1302 in FIG. 13, receives the status query. In this embodiment, the first node 1302 represents a proxyed node or resource. As indicated by block 1704 and block 1706, each time a distributed resource receives an indication of the status of a native resource, the distributed resource updates its status to reflect the status of the native resource . As indicated by block 1608, the distributed resource provides an indication of the self-status of the distributed resource to the query requester (client). Thus, in the case of proxied distributed resources, the state of the distributed resource only changes if it receives a notification of a change in state from the corresponding native resource.

As indicated by the block, the state query is forwarded to the corresponding native resource, such as the second resource 1304 in FIG. As indicated by block 1606, in response to the state query, the state of the native resource is transferred back to the distributed resource.

17B is a flow chart illustrating a second portion of a method 1700 of servicing a state query for a distributed resource of a proxyed type. This second part reflects the viewpoint of native resources and operates asynchronously and in parallel with the first part shown in Figure 17A. As indicated at block 1710, the state of the native resource, such as the second node 1304 of FIG. 13, is monitored. When a change in the state of the native resource is detected, as indicated by block 1712 and block 1714, respectively, an indication of the state of the native resource is sent to the corresponding distributed resource.

The use of distributed resources that are proxied in appropriate cases may promote the desired goal of minimizing interprocessor traffic, but only when the state information changes from the native resource's processor to the distributed resource's processor . In contrast, in the case of a non-proxied resource, a status query is sent each time a distributed resource receives a status query, and status information is returned. Proxyed resources may be used, for example, in situations where the task most relevant to the task to be performed under the control of the first processor is the state of the distributed resource rather than the corresponding native resource.

As mentioned above with respect to Figures 5 and 6, events and queries are related aspects of the software architecture. The types of events that monitor values above a threshold may be particularly useful in combination with proxied resources because interprocessor messages are only sent when the state of the native resource exceeds the threshold rather than only when the state of the native resource changes to be.

In some cases, it may be desirable to group or "batch" a plurality of distinct resource requests together into a single "transactions of resource requests. &Quot; In cases where a plurality of resource requests are for a remote resource or a distributed resource controlled by the same processor, the transactionizing of the resource requests may include a communication path 1303 between the first processor and the second processor Lt; RTI ID = 0.0 > (e. As will be appreciated by those skilled in the art, a "transaction" is an action that typically occurs in accordance with properties referred to as abbreviation ACID: atomicity, consistency, isolation, and durability. Atomicity implies that all of the configuration steps of a transaction are performed or none of them are performed to avoid problems associated with partially executed transactions. Consistency means that a transaction takes a system from one coherent / coherent state to another coherent / coherent state. Isolation means that other operations can not access the modified data during a transaction that has not yet completed. Locking access to data is typically used to ensure isolation of transactions. As described above, the resource is locked when accessed in response to the resource request, and unlocked when the resource request is completed. Durability relates to recovery from system failures. The term "transaction" is used herein to refer to a group of resource requests that are performed together according to at least the characteristics of atomicity and isolation. The framework or programming interface for resource request transactions supports consistency in its design but whether or not the system is in a consistent state after a transaction depends on the actions of the individual transactional resource requests, It does not depend on the properties of the work or programming interface.

Providing a transaction of resource requests may involve two aspects. In an aspect, a transaction of resource requests may be specified. In defining a transaction of resource requests, a transaction of resource requests is assigned a unique name or identifier, a lock type is specified, and resources that may be involved in the transaction of resource requests are enumerated. The result defining the transaction of resource requests is a transaction that can be referenced by the entity to issue a transaction of resource requests (or to create an instance of a transaction of resource requests).

A second aspect of providing a transaction of resource requests involves issuing or creating an instance of a defined transaction of resource requests. The transaction of resource requests may be performed by a resource (e.g., as a substitute for resource requests to other dependent resources), or alternatively by an execution thread, or by the resource graph of the PCD 100 described above Or may be issued by an entity other than a resource, such as by a device driver not included in one of the resources. A transaction of a resource request, like other resource requests, is a type of client request. Any entity capable of issuing a client request in the manner described above (or, in normal computer science terminology, "possesses" the client) may issue a transaction of resource requests.

Other such entity execution software code that "starts" or sets a previously defined transaction of a resource, thread, or resource request to issue a transaction of resource requests may be used for various resources defined as part of a transaction of resource requests Issues resource requests, then terminates the transaction of resource requests, initiates processing of the batched requests, and terminates the transaction of resource requests. The process of terminating the transaction of resource requests comprises sending a batch of requests from a first processing entity to a second processing entity, processing batches of requests from a second processing entity, notification of completion of processing at the first processing entity And then upon receipt of the notification, it may involve performing any updates to the local resource proxies or executing the registered callbacks at the first processing entity.

18 is a flow chart illustrating a method 1800 of issuing a transaction of resource requests. The method 1800 is described below with reference to an exemplary pseudo code. The following is an example of a pseudocode that generally represents the code executed by an entity issuing a transaction of resource requests:

BEGIN_TRANSACTION (HANDLE)

REQUEST (A)

REQUEST (B)

REQUEST (C)

END_TRANSACTION (HANDLE)

An indication of a sequence of events is provided, as indicated by block 1802 in Fig. For example, a sequence of events may be provided by the execution of code represented by the above pseudocode. The sequence of events to be displayed is: an indication of the beginning of a transaction of resource requests (as indicated in the exemplary pseudocode by "BEGIN_TRANSACTION (HANDLE)"); An indication of the end of the transaction of resource requests (indicated by an exemplary pseudo code by "END_TRANS ACTION"); And indications of two or more resource requests that occur as part of the transaction, i. E. Between the start of the transaction and the end of the transaction. The pseudo code "BEGIN_TRANSACTION (HANDLE)" indicates the setting of the transaction of resource requests for the processing specified in the manner described above. As the process of issuing a transaction of resource requests continues through these many steps, any transaction of resource requests for processing may be terminated by the type of lock and resource requests associated with that transaction, Lt; / RTI >

It is useful to note that transactions of resource requests may include conditional logic, although this is not reflected in the above pseudocode for clarity. For example, a code representing a transaction of resource requests may be a logic having a type "IF (condition) issuing a resource request (THEN) ", or a resource listed in a rule of a transaction of resource requests, Lt; RTI ID = 0.0 > of < / RTI > In other words, a transaction of resource requests may be defined to include a predetermined resource request only if certain conditions are met at the time of issuance of a transaction of resource requests, i.e., at the time the code representing the transaction of resource requests is executed . For example, the transaction of resource requests may be defined as involving resources (A, B, C, and D), but the evaluation of the conditional logic in a given case is limited to only resources (A, ≪ / RTI > only the indications of the resource requests for the resource request. That is, as a result of evaluating the conditional logic in this illustrative example of a transaction of resource requests, the resource request for resource D may not be included in the actual transaction of resource requests. Potentially any resource defined as being involved in a transaction of resource requests may not be required in all cases. For clarity, the exemplary pseudocode above shows only the resource requests displayed in a given case and does not show any conditional logic. Nevertheless, it should be understood that the transaction of resource requests may include any suitable number of resource requests, and any suitable conditional logic that may determine which resource requests are included, if any.

As indicated by block 1803, a queue is established for resource requests that accompany the transaction of resource requests. As indicated by block 1804, each resource involved in the transaction of resource requests is locked for the duration of the transaction of resource requests. As will be described below, the resources may be assigned different locking types, e.g., a first locking type referred to as "pessimistic locking ", or a second locking type referred to as" lazy locking " . As described above, the lock type is specified when a transaction of resource requests is specified. Thus, if a transaction of resource requests is issued, whether or not the transaction of resource requests will be performed according to a skeptical locking method, or alternatively, according to a loosely locked method, would have been predetermined at the time of publication. Depending on the locking method, the resources involved in the transaction of resource requests may be locked at different times, as described in more detail below. Also, depending on the locking type, only a subset of these resources (loosely locked) in which all of the defined resources as part of the transaction of resource requests are locked (skeptic locking) or only requests are issued as part of the transaction.

In another embodiment, when a lock type associated with a transaction of resource requests is "loose" (as further described below), an entity that defines and issues a transaction of resource requests, There is no need to be constrained to enumerate or enumerate all resources that may be part of a transaction. By one or more requests for these resources issued in the context of a transaction, it is entirely possible that resources that are part of (or become part of) the transaction are dynamically included in the transaction. By way of example, in the above pseudocode, the entity issuing the transaction does not need to specify A, B, and C as part of the transaction during the stipulation phase if the locking type associated with the transaction is "loose" . Initiate a transaction, and then issue requests for two or more of A, B, and C. These resources are then implicitly part of the transaction of resource requests, and requests for these resources are just batched and not immediately processed. Thus, in the present embodiment, it is possible to configure a "dynamic" or " run-time defined "transaction in that any number of resources may be added to the transaction after starting the transaction without having to define everything ahead It is possible. Further, apparent from the description of the locking types in the following, these "dynamic" or "run-time defined" transactions of resource requests can not be of the "skeptical" locked type.

As indicated by block 1806, information associated with each of the resource requests included in the transaction of resource requests is added to the queue. Referring to the pseudocode above, a resource A (or resource A) (e.g., if REQUEST (A) indicates a request for a resource A to process 50 MIPS of throughput, (The distributed counterpart of the resource A) may be added to the queue by a value of 50 if it is controlled by a processor other than issuing a transaction of these resource requests. Likewise, any suitable parameters associated with other resource requests that are part of the transaction of resource requests are added to the queue at the time of execution of the corresponding code, such as the code represented by the pseudo code "REQUEST (B) ". For clarity, the above pseudocode does not reflect all the parameters that may be included in the resource request, such as the parameter representing "50" in this embodiment.

It should be noted that the locking and queuing steps represented by blocks 1804 and 1806, respectively, may be performed in any order and may involve one or more sub-steps. For example, as described below, in a transaction of resource requests that are defined as being of a skeptic lock type, all resources indicated in the provision of the transaction of resource requests can be used before any information associated with resource requests is added to the queue It is locked. However, in the transaction of resource requests that are defined to be a loose lock type, each resource request results in the locking of the requested resource in turn and only the addition of information associated with that resource request to the queue. In other words, in the transaction of resource requests, the locking phase and the adding to queue may be performed in an alternating manner. The skeptic and loose locks are described in more detail below.

As indicated by block 1808, a queue is sent to the recipient in response to an indication of the end of the transaction. The recipient may be, for example, another processor. The receiver may be, for example, another processor, i.e. a processor other than the processor from which the transaction of resource requests is issued. In this case, the queue takes the location of multiple messages associated with multiple resource requests to be issued when resource requests are not transactional in the manner described above. At the issuing entity, the thread of execution is blocked until there is a notification from the recipient that the queue of requests has been processed. Then, any residual processing at the issuing entity is completed (which may involve the execution of any updates to local resource proxies and any registered callbacks), then the transaction is considered complete. All of these are represented by "END_TRANSACTION (HANDLE)" in the above pseudocode.

As indicated by block 1810, all of the resources represented in the transaction of resource requests are unlocked after the end of the transaction, as indicated by "END TRANS ACTION" in the above pseudocode. Thus, after the queue is transmitted, the resources are unlocked and the batched requests are processed.

The term "queue" refers to any of the characteristics of a standard queue, such as a first-in-first-out scheme It should be noted that it is not necessary to have an ordering of the elements to. This does not mean, in certain implementations, that a standard queue can not be used for batting requests. Such queues may of course be used, but in other implementations, requests may be added to any kind of container or buffer that can receive and store one or more elements at a time until final transmission or processing. In these cases, the "queue" may be considered a back or bucket of resource requests.

19 illustrates an exemplary resource graph 1900 for an exemplary transaction of resource requests that includes resource requests for resources A, B, For example, the resources A, B, and C in FIG. 19 correspond to REQUEST (A), REQUEST (B), and REQUEST (C) in the above exemplary pseudocode It is possible to do.

In response to a first resource request 1902 for a resource A, if the transaction of resource requests is defined as a loose lock type, the resource A is locked and the information associated with the first resource request 1902 is Is added to the queue mentioned above. The resource A then issues a second resource request 1094 for the resource B because the resource A depends on the resource B. [ In response to the second resource request 1094, the resource B is locked and the information associated with the second resource request 1904 is added to the queue. The resource A then issues a third resource request 1906 for the resource C because the resource C depends on the resource B. [ In response to the third resource request 1906, the resource C is locked, and the information associated with the third resource request 1906 is added to the queue. Referring to the above pseudocode: Resource A is locked at the time the code represented by pseudo code "REQUEST (A) " is executed; The resource B is locked at the time the code represented by the pseudo code "REQUEST (B) " is executed; The resource C is locked at the time when the code represented by the pseudo code "REQUEST (C) " is executed.

The loosely locked method may be satisfactory if the characteristics of the resource graph that define the set of resources involved in the transaction of resource requests prevent the possibility of a deadlock condition. Figure 20 illustrates an exemplary resource graph 2000 that is similar to the resource graph 1900 but does not prevent the possibility of a deadlock condition. With further reference to the event timeline 2100 of FIG. 21, in the illustrative case, the first thread and the second thread each request resources represented by the resource graph 2000 (FIG. 20). The first thread issues a first (transactional) resource request 2002 (FIG. 20) for resource A, which locks resource A. Because resource A is dependent on resource B, resource A then locks resource B by issuing a second resource request 2004 for resource B. [ Because resource B depends on resource D, resource B then locks resource D by issuing a third resource request 2006 for resource D. [ Then the second thread locks the resource C by issuing a fourth resource request 2008 for the resource C. [ Since resource C depends on resource D, resource C then issues a fifth resource request 2010 for resource D. [ However, since the resource D has already been locked as a result of the resource request 2006, the resource request 2010 is "blocked ", and thus is not completed until the resource D is unlocked. However, the sixth resource request 2012 for the resource C resulting from the dependence of the resource A on the resource C issued in the context of the first thread will also be blocked, ) Is locked as a result of the resource request 2008 by the second thread. In this case, the first thread can not complete the resource request 2002 of the first thread until the resources on which the resource A depends are unlocked, while the resources on which the resource C depends are unlocked There is a deadlock condition because the second thread can not complete the resource request 2008 of the second thread until.

To avoid the possibility of a deadlock condition in this case, the transaction of resource requests may be defined as a sneak lock type rather than a loose lock type. In the transaction of the skeptic lock type resource requests, all resources indicated in the transaction of resource requests are returned before any indications of the individual resource requests (or before any arbitrary resource requests are issued), in response to the indication of the start of the transaction It is locked. Thus, with reference to the above pseudo code and FIGS. 20 and 22, resources A, B, and C are all locked in response to the execution of the code represented by "BEGIN TRANSACTION ". Resources may be locked in the order indicated by the resource graph of one topological sort. As methods for topological sorting, directional acyclic graphs are well understood by those skilled in the art, but they are not described in further detail herein. Any suitable topological sorting method may be used. The results of the topological sorting of the resource graph 2000 (FIG. 20) may be, for example, A, B, C, D in the exemplary case represented by the event time line 2200 of FIG. Thus, in response to an indication of the start of a transaction of resource requests for resource A: the resource B is locked after the resource A is locked; Then the resource C is locked after the resource B is locked; Finally, the resource (D) is locked after the resource (C) is locked. After all of the resources (A, B, C, and D) are locked, the indicated resource requests may be processed for resources (B, C, and D). In another embodiment (or implementation), as part of the setting of a transaction of resource requests, as indicated in the pseudocode by "BEGIN TRANSACTION ", resources may be locked in the order indicated by the topological sort.

23 is a flow chart illustrating a method 2300 for resources to respond to a resource request. The resource referred to for method 2300 may be any of the resources (A, B, and C) mentioned in the pseudocode, for example. As indicated by block 2302, the resource receives the resource request. For example, the resource A may receive the request in response to the execution of the code represented by "REQUEST (A)" in the above pseudocode. If the resource is accompanied by a transaction of loose lock type resource requests, the resource is locked at this point. However, the lock is not shown in FIG. 23 because the method 2300 indicates a view of the resource on which the resource request is issued, and the resource may be locked and unlocked by the controlling entity that is not part of the resource. For example, as part of the control functions involved in routing messages to and from resources, the entities included in the framework manager 440 may lock and unlock resources and any of the deadlocks that may occur Processing may be controlled.

As indicated by block 2304, the resource determines whether the resource is involved in a transaction of resource requests. A status indicator, which may be set at the beginning of a transaction of resource requests, is included in each resource to indicate that the resource is included in the transaction of resource requests. In another embodiment (or implementation), a status indicator may be set on the thread after the thread executes the pseudo code represented by "BEGIN TRANSACTION ", indicating that the current thread has initiated a transaction of resource requests. If the resource determines that the resource is not involved in a transaction of resource requests, the resource performs the resource request in a regular manner, as indicated by block 2306. [ That is, the resource may perform and complete the resource request in the normal manner described above with respect to Figures 12 and 15. [ Note that at the beginning of the execution of a resource request (which is not transactional), as described above with respect to FIG. 12, the resource is locked, and upon completion of the resource request, the resource is unlocked.

When a resource determines that a resource is involved in a transaction of resource requests, the resource may be updated (e.g., by another resource, or by a pseudocode indicated by "BEGIN_TRANSACTION ", as indicated by block 2308) ) ≪ / RTI > determines whether the above-mentioned queue has been created. If the resource determines that the queue does not exist, then the resource creates a queue, as indicated by block 2310. As indicated by block 2312, the resource involved in the transaction of resource requests then adds the information associated with the request to the resource to the queue. Note that as a result of loose locking methods or alternative skeptic locking methods, the resources are locked before adding information to the queue. Locks are not removed after the resource has added information to the queue. Rather, as described above, the lock is removed only at the time of subsequent processing of an indication of the transaction and transmission of the queue to another processor or other recipient, and the batching of requests at another processor or other recipient.

24 is a timeline diagram illustrating operations of an embodiment of a method and system for managing resource requests that are batched and faked in a portable computing device. The modem 202 and the resource power manager ("RPM") 204, as will be understood from the description of the system shown in Figures 2-6 described above, Entities. As shown in FIG. 24, exemplary embodiments of system 101 may utilize other processing entities in addition to modem 202 and RPM 204, as will be understood by those skilled in the art.

The owner of the two proxy resources RES0 207A and RES1 207B, shown in FIG. 24, is also the resource power manager ("RPM") 204 shown in FIG. As an owner of these two proxy resources RES0 207A and RES1 207B, the RPM 204, as shown in Figure 24, fulfills any of the requests issued to these two proxy resources in the transaction do.

RES0 207A and RES1 207B as shown in Fig. 24 are proxies. Proxies are logical representations of actual resources as understood by those skilled in the art. Proxies are representations of remotely located hardware or software resources accessible by the local processing entity, such as modem 202, via RPM 204, in memory. The RPM 204 is in control of the actual resources remotely located with respect to the modem 202.

These two proxies RES0 (207A) and RES1 (207B) may be part of framework manager (440). In some embodiments, the two proxy resources 207A, 207B manage a queue 115 of batched requests as described below (and described above in conjunction with block 1803 of FIG. 18) It is possible. In other embodiments where the framework manager 440 is present, the framework manager 440 may manage the queue 115 as described below.

As discussed above, the actual resources managed by the RPM 204 and located in close proximity to the RPM 204 (and not shown for brevity) are contained within the RPM 204 or within the RPM 204. On the other hand, these proxies 207A and 207B are managed by software, as understood by those skilled in the art, and stored in memory by the modem 202. [ The proxies receive the requests, and then pass these requests to the actual resources located within the RPM 204 or near the RPM 204. [

Client applications, such as the first client 208, are the owners of the modem 202, which is the first processing entity in this exemplary embodiment. Client applications 208 issue requests for two proxy resources RES0 207A and RES0 207B, which are typically managed by RPM 204. [

Because the first client 208 needs access to two proxy resources 207A, 207B for a particular transaction and for optimization, the first client 208 can use these two distinct proxy resources 207A , 207B together with the transaction at the position 305 in the timeline shown in Fig. In the timeline position 305 of FIG. 24, the two proxy resources 207A and 207B are alerted to the incoming of the batched request.

Further details of how requests are batched together into transactions are discussed above in connection with Figures 15-23. At position 307, the proxy resources 207A, 207B via the framework manager 440 acknowledge the initiation of the batched request formed by the first client 208. [

At position 310, the first client 208 issues a first request to the first proxy resource RES0 207A. The first request is not serviced by the first proxy resource 207A. Instead, the first proxy resource 207A is locked from accessing the first proxy resource 207A by other clients. At position 311, the first proxy resource 207A forwards the received first request to the queue 115. [

The queue 115 may or may not have any particular ordering for the information contained in the queue. A queue may or may not have any standard queue requirements that control the data structure of the queue. In other words, the queue 115 may comprise any type of logical bucket as will be understood by those skilled in the art. The first proxy resource 207A issues an acknowledgment or call return back to the first client 208 at position 312. [

At position 315, the first client 208 issues a second request to the second proxy resource 207B. Similar to the first proxy resource 207A, the second proxy resource 207B is locked from accessing the second proxy resource 207B by other clients. At position 316, the second proxy resource 207B forwards the received first request to the serving queue 115. [ The second proxy resource 207B then issues an acknowledgment or call return back to the first client 208 at position 317. [

At position 252, a forked transaction call was initiated by the first client 208. The position 252 also marks an instance at the time the regular batting transaction call is to end, as described above in connection with Figs. 15-23. In both cases, the batched requests will be sent to the RPM 204 here.

The actual resources (not shown in this figure) represented by the first proxy resource 207A and the second proxy resource 207B will be locked during the batched transaction and the actual resources will be locked in the transaction ), ≪ / RTI > After completing the batched transaction (s), then the actual resources would have returned an acknowledgment to the first client 208 via the proxies 207A, 207B of the actual resources.

The first and second proxy resources 207A, 207B will then be unlocked under the regular batched transaction scenario shown in Figures 15-23. Instead of initiating / initiating the execution of a regularly batched transaction at position 252, the inventive system 101 initiates the forked transaction at position 252 as shown in FIG.

In the forked transaction, tasks and / or operations may be divided so that tasks and / or operations are performed in parallel. From the timeline position 255 assigned to the dashed line, the batched transaction is sent by the framework manager 440 to the RPM 204 in an asynchronous manner and without waiting for any response from the RPM 204.

At position 258, which is immediately after the asynchronous invocation that includes the bqed request from position 255, framework manager 440 unlocks first proxy resource 207A and second proxy resource 207B. The first and second proxy resources 207A and 207B may be unlocked and may not accept or process any subsequent requests as will be understood by those skilled in the art.

At position 257, the call is returned to the first client 208, indicating that the proxy resources 207A and 207B are unlocked. The first and second proxy resources 207A, 207B are in an incoherent state at this stage. These two proxy resources 207A, 207B have not been processed with requests to accept requests at this stage.

The timeline position 260 is characterized by a potential first parallel processing block. At position 260 the first client 208 continues to make other requests without waiting for requests issued for the first and second proxy resources 207A and 207B to be completed under control from the RPM 204. [ Publish and / or execute other tasks. In conventional systems, the first client 208 would have been blocked at position 260.

The position 260 and the corresponding position 256 may be characterized as a second parallel processing block. This second parallel processing block at position 256 is the second parallel processing block in position 2 which is executed by actual resources (not shown) and relayed by first and second resource proxies 207A, 207B under control of RPM 204 Lt; / RTI > requests.

Although these two parallel processing blocks 256 and 257 have been shown to occur on separate processors, it will be appreciated by those skilled in the art that such parallel processing may be performed between different cores in a multi-core system, It is possible to occur in the same system on the chip between two different processing threads in the system.

Next, at timeline position 262, the first client 208 may issue a third request to the first proxy resource 207A. At the position 262, it is possible that another client (not shown) may issue this third request to the first proxy resource 207A. This third request is either a single request or a portion of another transaction.

The framework manager 440 or the proxy resource 207A will monitor this third request to be issued when either the framework manager 440 or the proxy resource 207A has been issued by the first client 208 ≪ / RTI > of the transactions have been unfrozen from the transaction (flagged as forked requests) for parallel processing.

The framework manager 440 or the first proxy resource 207A has a third request and the first request and the second request (constituting the binding request) are completed and serviced by the first proxy resource 207A And waits until it receives a notification from the RPM 204 at the positions 269 and 270.

The messages at positions 269 and 270 are generated by an interrupt service routine ("ISR") 299 that has received a completion notification from the RPM 204. The ISR 299 is a message transport or message medium in which the RPM 204 may signal to the issuing entity that it is forked and represented as local proxies that the batched requests have been serviced and completed. ISR 299 is a convenient conventional mechanism that may only be used in this manner. The system 101 is not limited to the ISR 299 for relaying communications between the RPM 204 and the first client 208 and may be any other means for sending messages to indicate that a batched request has been completed, Mechanisms can be used.

In addition to ISR 299, as will be understood by those skilled in the art, any other communication medium for relaying messages between two processing entities may be used. One advantage of the ISR 299 that relays communications is that communications between the two processing entities are not required in that the modem 202 does not need to expect a forked, batched request completion signal from the RPM 204 And may be relayed asynchronously.

Using the ISR 299, the RPM 204 may send the forged request completion signal to the modem 204. In another exemplary embodiment, instead of using the ISR 299, the modem 202 may be designed to poll the RPM 204 and retrieve the forged, fired request completion signal to be issued by the RPM 204 have. These alternative examples of communicating the forged, completed request completion signal are understood by those skilled in the art.

If the forged, batched request containing the first and second requests has already been completed at position 262 or before position 262 (at which the third request is issued), the framework manager or proxy first proxy resource 207A will have a third request instead of immediately starting processing the third request issued by the first client 208 without waiting.

Subsequently, at position 272, the first proxy resource 207A forwards the third request to the RPM 204. [ After the third request is serviced by the actual resource (not shown) corresponding to the first resource 207A, the RPM 204 sends a third request completion signal associated with the first proxy resource 207A to the position 274, .

24, this position may be characterized as a fork point for the first proxy resource 207A and the second proxy resource 207B, in the timeline position 258. [ This is where the first proxy resource 207A and the second proxy resource 207B are forked because they are part of the forked transaction. These two proxy resources 207A, 207B are implicitly forked because they are part of the forked transaction.

This means that the two proxy resources 207A and 207B are also forked while the batched transaction of FIG. 24 is being forked. In other words, three distinct logical entities or representations: the transaction itself, the first proxy resource 207A, and the second proxy resource 207B were forked at the fork point 258. [ At the fork point 252, the first and second proxy resources 207A and 207B enter the incoherent state, as will be described below, where the first and second proxy resources 207A and 207B are joined the first and second proxy resources 207A and 207B can not service the new request until they are joined at the join point.

In this incoherent state, the first and second proxy resources 207A, 207B are unable to service new requests until the forked request is completed and all associated clean-up tasks are completed locally. In this scenario, multiple join points may be possible. The join points will now be described as follows.

In the exemplary embodiment shown in FIG. 24, there is a join point 280 at the timeline position 270 where the batched request complete signal crosses the first proxy resource 207A. This join point 280 may be characterized as a first proxy resource 207A and a join point 280 for the transaction that includes the batting request.

At join point 280, although there are two requests (a first request scheduled for the first proxy resource 207A and a second request scheduled for the second proxy resource 207B) Only the first proxy resource 207A is joined at the join point 280. [ Since the first proxy resource 207A is the only entity that the first client 208 considers for the third request, any cleanup operations needed to join the second proxy resource 207B may be continuously deferred. The cleanup operation may refer to additional tasks or tasks needed to keep the second resource in a coherent state (represented by second proxy resource 207B), and in a coherent state the second resource May serve other requests.

Although the first proxy resource 207A and the second proxy resource 207B are joinable at the join point 280, only the first proxy resource 207A is selected because the third request only requires the first proxy resource 207A, Are joined at the join point 280. The second proxy resource 207B may be characterized as being in an incoherent state at the join point 280. [ Since the second proxy resource 207B is joinable at this stage, but the second proxy resource 207B is not required by the third request, the second proxy resource may be in its inchoherent state.

In this exemplary embodiment, the forked resource, such as the second proxy resource 207B, is not joined until it is needed by another request. While in this incoherent state, if the other entity does not require services from the second proxy resource, then the second proxy resource 207B needs to complete any cleanup or cleanup tasks associated with the fork request none. This allows clean-up or clean-up tasks to be completed later. Deferring cleanup or cleanup tasks later saves processing power: it allows you to postpone until cleanup is absolutely needed (when services from resources that might be in an incoherent state may be needed) .

At a point in time when served from a resource (which is required to be in an incoherent state), such as a second resource (represented by a second proxy resource 207B shown in FIG. 24) At the time of a fourth request (not shown) issued from some other client, then such cleanup or cleanup tasks are processed before the processing and processing of the fourth request issued for this second resource in the current incoherent state May be completed by a second actual resource (denoted as second proxy resource 207B).

Thus, upon receipt of a request, such as a fourth request, a resource in an incoherent state based on a previously forked request performs a cleanup operation when receiving an authoritative request from an entity such as the first client 208 And may enter again in a coherent state.

Each time a request is made for any one resource being used to service a transaction, the transaction joins or enters a coherent state. Separate requests for each of the resources that are part of the transaction are made, but if the transaction entity is deemed to be joined at the first join point to be executed, i.e., as described further below, There may be multiple join points when arriving at any of the resources at, or when the transaction itself is explicitly joined.

Thus, for example, if the fourth request is issued by the first client 208 to the second proxy resource 207B, then the second join point (not shown) Lt; RTI ID = 0.0 > 207B < / RTI > The mechanism may be provided to explicitly join the transaction. This mechanism will join all single resources that are part of the transaction as well as the transaction.

This mechanism for joining transactions may be characterized as a blocking call because the system is designed to wait until all requests for a transaction have been completed. Thus, for example, if an entity, such as a first client 208 that made an explicit call, joins a transaction, the first request and the second request by the first and second resources under control of the RPM 204 Until this is done, the join transaction call will block the client.

Since the first and second proxy resources 207A and 207B are part of the transaction when a join transaction call receives notification that the first and second requests have been completed, as indicated by the positions 269 and 270, The join transaction call will join the first and second proxy resources 207A, 207B together. The join transaction call may then send a notification back to the requesting entity, such as the first client 208, so that the first and second proxy resources 207A and 207B may again send any other additional requests And is in a coherent state ready for processing. If these proxy resources (207A, 207B) were in an incoherent state with no joining transaction invocation, support would have been due to the cleanup.

Exemplary scenarios in which a join transaction call will be used are as follows: A join transaction may be used if there is a need for explicit synchronization, or gating of a set of requests and / or tasks. So, for example, assume a request that needs to be issued to the RPM 204 to turn on some power rails. Individual requests for each power rail may be bundled or batched into a transaction.

In this scenario with requests issued for power rails, while the RPM 204 is turning on some of the power rails for the various types of resources 207A, 207B, It is assumed that it is necessary to issue a request for the local resources required for the rails to be turned on.

An explicit join call is used here and the system client may wait until the rails are powered up before issuing / servicing local requests. The opposite of an explicit join call is a call that may be characterized as a "loose join" or a "fire-and-forget" call. A loose join call requires that resources 207A, 207B remain in a coherent state only if a subsequent request is made to this resource or only after a predetermined time period.

The system allows all resources (207A, 207B) to co-exist again at the point where the transaction joins itself (coherently). The third issued request at position 262 can easily be used to ensure that everything (transaction itself, as well as two proxy resources 207A, 207B) is again coherent, as understood by those skilled in the art It might have been possible. As discussed above, this is for optimization for the particular embodiment of FIG. 24 discussed above in which all proxy resources 207A, 207B do not come back into a coherent state. In the above-described embodiment, it is advantageous to delay the cleanup operation for some resources, which means that not all resources are in a coherent state after the transaction is joined.

As described above, the client 208 may specify that the proxy resources 207A, 207B may be forkable as well as transactions involving multiple requests. The client 208 may also specify (in a negative context) that the proxy resource 207A, 207B or the transaction may not be able to be made available.

The resource may fork the resource itself, even if the transaction that may not have been specified by the client 208 is forked or loosable. For example, assume that the second resource 207B is a local resource and not a proxy. On the other hand, the first resource 207A as shown in Fig. 24 remains as a proxy and is under the control of the RPM 204. [ In this scenario, where the second resource 207B is a local resource for the modem 202, the second resource 207B will not be under the control of the RPM 204. [

Although the client 208 has issued a transaction involving a batting request for the first and second resources 207A and 207B and the client has not specified that the transaction is forkable, Depending on itself, to process the request of the second resource 207B independently of the request to be forked from the transaction and processed by the first resource 207A, which in turn may request the newly assigned second local resource 207B It is a proxy for. This is an embodiment in which the second local resource 207B is loosened from the transaction itself, even though the transaction may not have been specified by the client 208 as being forkable.

Those skilled in the art will recognize that in terms of the transactions, a number of transactions may be nested. In multiple embedded transaction scenarios, it is possible to want the inner transaction of the embedded local transactions to be synchronously terminated while the outer transaction is to be made available. In such a scenario, controlling the behavior of the embedded group of transactions is the outer transaction of a number of inserted transactions. So, in the scenario just described, an inner transaction would allow such forking if it wanted the outer transaction to be able to be forked.

The system 101 described above also supports join callbacks. Join callbacks are only conditional to the transaction and are the paths that are executed after the transaction is joined. The join callbacks may be described in connection with a particular embodiment in which the clock settings of the CPU are desired to be changed. In such a scenario, calls and requests may be made to locally managed resources, as well as to remote resources such as those shown in FIG. 24, which may be under the control of the RPM 204.

The clock may require that the system be operated and operated at a predetermined voltage to maintain a predetermined processing rate. So, for example, if you want to change the clock rate from 200 MHz to 400 MHz, you might need to change the voltage. The voltage may be controlled by the RPM 204, i.e., to increase the operating voltage of the CPU, it may be necessary for one or more requests to be sent to the remote resources.

Thus, for efficiency, the transaction must be created to bind a set of remote requests. The transaction may also be forked so that the client can continue with other tasks while the change in voltage is enforced by the RPM 204. [ However, in a scenario where the voltage is not at the required level for a new clock rate, the voltage will need to be raised before the clock rate is raised.

If the clock is increased before a new voltage rise, some hardware may be damaged, which is undesirable. In such a scenario, it may be possible for the resource to issue a transaction that is tokenized in the RPM 204 to change the voltage and then bundle the completion of the request (join callback), and the callback may request a request for a local clock Will be issued.

A join callback that includes logic to increase the local clock frequency (by issuing a request to that clock resource) may thus be used to ensure that this request is processed only after the necessary dependencies (i.e., voltages) are ready. It is assumed that the first client 208 wants to turn on two rails controlled by the RPM 204. It is also assumed that the first client 208 needs to turn on the local clock. This local clock may not be set to a specific value until these two rails are turned on.

Because the first client 208 needs to turn on multiple rails with the RPM 204, the first client 208 may also bind the requests for these two rails of the first client into a single transaction . Only when such a single transaction has been completed can the first client 208 request a change to the local clock to occur.

In the forked transaction, the first client 208 does not know exactly when the requests will be serviced, and in this particular scenario, the first client 208 is configured such that when the first and second rails are turned on by the RPM 204 You will not know. Thus, the first client 208 may attach the transaction of the first client, which includes two requests for two rails, to the local clock as a join callback function. In this exemplary embodiment, the join callback will occur at position 270 as shown in FIG. After position 270, the local clock may be adjusted because the callback would have indicated that the first and second rails were turned on by the RPM 204. The join callback feature is part of the process of a resource or transaction that achieves coherency after a request or transaction is serviced.

The forked transaction may be joined at multiple points. These multiple join points are managed by the use of a configuration called a join token. A join token has state information that is used to ensure that the transaction is joined only once by a first subsequent request to one of the resources in the transaction or by an explicit client call to join the transaction.

The dynamics of the fork (how the fork is achieved) is determined by configurations called extensions (s) attached to the transaction. In the case of RPM, as shown in FIG. 24, for example, the extension would be an implementation of an RPM transport protocol (how the requests from modem 202 are delivered to RPM 204 and responses are received).

The design also provides a mechanism by which the client 202 may specify fork preferences. This is used by extensions when forking a transaction synchronously or when deciding whether to complete a transaction. Along with the transactions, as well as the resources 207, the call to fork the transaction is a request. If the extension is unable to fork the transaction, it will synchronously complete the transaction and then invoke the registered joint callback.

The design for the transactions is that the client 202 issues requests for local resources (not shown in Figure 24, including those not serviced by the RPM 204) after calling the function named begin_transaction It is also noted that. On the surface, these requests are part of the transaction, but they are not included in the batting. Associated resources, however, are locked or unlocked with other resources in the transaction.

In the case of a fork / join, this becomes important when the local request is self-popping during the service. To facilitate this, references to a transaction's join token are distinct from the resource's own join token. This approach allows both the resource to be locked on its own and as part of the transaction.

Forked transactions may be supported by an application programming interface ("API"). Each transaction API will be extended to include the following functions: fork_transaction is a request to fork this transaction and is called on behalf of end_transaction. This accepts a callback that will be called if the transaction later joins. If the extension does not fork a transaction, these callbacks will be called synchronously.

There may be cases where a transaction implicitly joins when a subsequent request arrives on any one of the resources in the transaction, while the client wants to force the join without creating a new request.

The join_transaction function will explicitly join the transaction. Such a function may be implemented to allow all resources associated with a transaction to be joined together with the transaction itself, or to join only transaction entities, while allowing subsequent resources to become coherent when processing subsequent requests have.

Using the transaction_get / set_fork_pref APIs, a FORK_ALLOWED / DISALLOWED / DEFAULT function may be queried or set. Extensions call the mark_transaction_forked API to obtain the join token and actually fork the transaction.

Additional APIs, such as the attach_client_to_transaction function and the attach_resource_to_transaction function, are provided to allow arbitrary resources to be attached to the transaction, and subsequent requests for these resources will also cause the transaction to join. This is useful if transactions are started and requests are issued from within the driving function of the 'parent' resource. The parent will attach itself to the transaction (even though it is not part of the transaction), allowing subsequent transactions to the transaction to join the forked transaction.

From the standpoint of the above disclosure, those skilled in the art will be able to write computer code or identify appropriate hardware and / or other logic or circuitry to determine, for example, distributed resources without difficulty based on the flowcharts and associated descriptions herein Management system and method. Accordingly, the disclosure of a specific set of program code instructions or detailed hardware devices is not considered essential for a proper understanding of how to create and use distributed resource management systems and methods. The inventive functionality of the claimed computer implemented processes is described in more detail in connection with the above description, and with reference to the drawings, which may illustrate various process flows. In addition, the processors 110, 126, 202, 206, etc., in combination with the instructions stored in the memory 112 and memory, serve as means for performing one or more method steps of the method steps described herein It is possible.

In one or more of the exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as a computer-readable medium as one or more instructions or code. Computer-readable media includes both computer storage media and communication media including any medium that enables transmission of a computer program from one place to another. The storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise a computer-readable medium such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other optical or magnetic storage devices, Or any other medium which can be used to transport and store code and which can be accessed by a computer. The terms "disk" and " disc ", as used herein, include but are not limited to a compact disk (CD), a laser disk, an optical disk, a digital versatile disk (DVD), a floppy disk, Ray disc. Combinations of the above should also be included within the scope of computer readable media.

While the selected aspects have been shown and described in detail, it will be appreciated that various alternatives and modifications may be made without departing from the spirit and scope of the present disclosure as defined by the following claims.

Claims (40)

CLAIMS What is claimed is: 1. A method for managing resource requests of a portable computing device having a plurality of resources,
Claims 1. A method comprising: issuing a transaction of resource requests by a client, wherein each of the resource requests requests two or more of the plurality of resources, and the resource requests of the transaction are directed to the two or more resources Wherein the step of issuing further comprises:
Issuing a first request by the client,
Locking the first resource associated with the first request such that no other clients can access the first resource,
Forwarding the first request by the first resource for processing of the first request,
Issuing a second request by the client,
Locking the second resource associated with the second request such that no other clients can access the second resource, and
And forwarding the second request by the second resource for processing of the second request, comprising: issuing a transaction of the resource requests; And
Forking the transaction so that the client may issue additional transactions or requests for at least one of the resources completing at least one of the requests of the forked transaction, Lt; / RTI >
Sending the transaction to a resource power manager that controls processing of the first request and the second request;
Unlocking the first and second resources by the framework manager so that the resources may not process but accept additional resource requests, wherein the client does not wait for completion of the first and second requests Unlocking the first and second resources, issuing additional requests and executing additional tasks, and
And processing the request for at least one of the first and second requests while the client issues additional requests and executes additional tasks. ≪ Desc / Clms Page number 21 > Way. delete The method according to claim 1,
Wherein issuing a transaction of the resource requests is completed by the framework manager. The method of claim 3,
Wherein the framework manager comprises a software module responsible for managing communications between the client and the resources. 5. The method of claim 4,
Wherein the resources and the client comprise at least one of software and hardware. delete delete delete The method according to claim 1,
Further comprising placing each resource in an incoherent state during fork of the transaction, wherein the resource services one or more requests of the poached transaction, and wherein the incoherent state is associated with the request How to manage resource requests, including the tasks necessary to delay the cleanup operation and to make the cleanup task associated with the request be in a coherent state so that the resource can serve another request . 10. The method of claim 9,
In response to receiving an external request for one or more requests of the forked transaction, sending, in response to receiving an external request for one or more requests of the forked transaction, The method further comprising: changing a heuristic state. A computer system for managing resource requests of a portable computing device having a plurality of resources,
The system comprising a processor in the portable computing device,
The processor in the portable computing device,
Issuing a transaction of resource requests by a client, wherein each of the resource requests requests two or more of the plurality of resources, the resource requests of the transaction are completed by the two or more resources, The above-
Issuing a first request by the client,
Locking the first resource associated with the first request such that no other clients can access the first resource,
Forwarding the first request by the first resource for processing of the first request,
Issuing a second request by the client,
Locking the second resource associated with the second request such that no other clients can access the second resource; and
And forwarding the second request by the second resource for processing of the second request; And
Forking the transaction so that the client may issue additional transactions or requests for at least one of the resources completing the request of at least one of the requests of the forked transaction,
Sending the transaction to a resource power manager that controls processing of the first request and the second request,
Unlocking the first and second resources such that the resources may not process but accept additional resource requests, the client issues additional requests without waiting for the completion of the first and second requests Unlocking the first and second resources to execute additional tasks, and
The method comprising: processing a request for at least one of the first and second requests while the client issues additional requests and executes additional tasks. Computer system. delete 12. The method of claim 11,
Wherein the processor issuing a transaction of the resource requests is completed by a Framework Manager module. 14. The method of claim 13,
The framework manager module comprising software responsible for managing communications between the client and the resources. 15. The method of claim 14,
Wherein the resources and the client include at least one of software and hardware. delete delete delete 12. The method of claim 11,
Wherein during the fork of the transaction, the processor is operable to place each resource in an inchoherent state, the resource servicing one or more requests of the tokenized transaction, the incoherent state being associated with a cleanup operation Wherein the cleanup operation associated with the request includes a task required to cause the resource to coherent such that the resource may service another request. 20. The method of claim 19,
In response to receiving an external request for one or more requests of the forked transaction, the processor is operable to cause one or more resources to be associated with one or more of the resources associated with the external request Wherein the computer system is operable to change the incoherent state for the resource request. A computer system for managing resource requests of a portable computing device having a plurality of resources,
A remote framework means in the portable computing device for issuing a transaction of resource requests by a client, wherein each of the resource requests requests two or more of the plurality of resources, Wherein the issuing is completed by two or more resources,
Issuing a first request by the client,
Locking the first resource associated with the first request such that no other clients can access the first resource,
Forwarding the first request by the first resource for processing of the first request,
Issuing a second request by the client,
Locking the second resource associated with the second request such that no other clients can access the second resource; and
Forwarding the second request by the second resource for processing of the second request; And
Forking the transaction such that the client may issue additional transactions or requests for at least one of the resources to complete at least one of the requests of the forked transaction. , Said forking
Sending the transaction to a resource power manager that controls processing of the first request and the second request,
Unlocking the first and second resources such that the resources may not process but accept additional resource requests, the client issues additional requests without waiting for the completion of the first and second requests Unlocking the first and second resources to execute additional tasks, and
And forking the transaction including processing a request for at least one of the first and second requests while the client issues additional requests and executes additional tasks. A computer system for managing resource requests. delete 22. The method of claim 21,
Wherein the remote framework means for issuing a transaction of resource requests to the client comprises software executing on the processor. 24. The method of claim 23,
Wherein the remote framework means manages communications between the client and the resources. 25. The method of claim 24,
Wherein the resources and the client include at least one of software and hardware. delete delete delete 22. The method of claim 21,
Further comprising means in the portable computing device for placing each resource in an incoherent state, the resource serving one or more requests of the poached transaction, the incoherent state being associated with a request associated with the request during the transaction Wherein the cleanup operation associated with the request is to coherent the resource such that the resource may service the other request. 30. The method of claim 29,
The method of claim 1, wherein in response to receipt of an external request, the at least one resource for one or more of the resources associated with the external request for one or more requests of the forked transaction, Further comprising means within said portable computing device for changing runt status. A computer readable storage medium comprising computer readable program code,
The computer readable program code being adapted to execute to implement a method of managing resource requests of a portable computing device having a plurality of resources,
The method comprises:
Issuing a transaction of resource requests by a client, wherein each of the resource requests requests two or more of the plurality of resources, and the resource requests of the transaction are completed by the two or more resources Wherein the step of issuing comprises:
Issuing a first request by the client,
Locking the first resource associated with the first request such that no other clients can access the first resource,
Forwarding the first request by the first resource for processing of the first request,
Issuing a second request by the client,
Locking the second resource associated with the second request such that no other clients can access the second resource, and
And forwarding the second request by the second resource for processing of the second request, comprising: issuing a transaction of the resource requests; And
Forking the transaction such that the client may issue additional transactions or requests for at least one of the resources completing the request of at least one of the requests of the forked transaction,
Sending the transaction to a resource power manager controlling the processing of the first request and the second request,
Unlocking the first and second resources such that the resources may not process but accept additional resource requests, wherein the client issues additional requests without waiting for completion of the first and second requests And executing additional tasks, unlocking the first and second resources, and
Processing said at least one of said first and second requests while said client issues additional requests and executes further tasks. . delete 32. The method of claim 31,
Wherein issuing a transaction of the resource requests is completed by a framework manager. 34. The method of claim 33,
Wherein the framework manager comprises a software module responsible for managing communications between the client and the resources. 35. The method of claim 34,
Wherein the resources and the client comprise at least one of software and hardware. delete delete delete 32. The method of claim 31,
The program code embodying the method,
Further comprising placing each resource in an inchoherent state during fork of the transaction, wherein the resource services one or more requests of the tokenized transaction, the incoherent state delays the cleanup operation associated with the request, And wherein the cleanup operation associated with the request comprises an action required to place the resource in a coherent state such that the resource may service another request. 40. The method of claim 39,
The program code embodying the method,
In response to receiving an external request for one or more requests of the forked transaction, sending, in response to receiving an external request for one or more requests of the forked transaction, Further comprising changing a state of the computer program.

Images