Patent Description:
When signaling a processor core with a wake up instruction to execute an atomic process, some operating systems, such as Linux, reorder the wake up in software to avoid cache ping-pong issues. In these instances operating system level handling may require kernel activity and context switches. This may result in reduced performance and increased resource usage in an architecture employing the above described indiscriminant instruction signaling in which multiple processor cores would be signaled to wake up to obtain an available lock when only one core will be able to use the resource. <CIT> discloses a method to switch among various real-time scheduling algorithms as specified in a program, at run time.

The invention is set out in independent method claim <NUM>, corresponding device claim <NUM> and a claim for a corresponding computer program, claim <NUM>.

In an embodiment, receiving a parameter for use in calculating the priority of the processor element may include receiving a temperature related to the processor element. In an embodiment, receiving the parameter for use in calculating the priority of the processor element may include receiving a frequency related to the processor element. In an embodiment, receiving the parameter for use in calculating the priority of the processor element may include receiving an indication of a cache shared by the processor element with another processor element. In an embodiment, receiving the parameter for use in calculating the priority of the processor element may include receiving an indication of proximity of the processor element to another processor element.

In an embodiment assigning a priority to the processor element for accessing the resource in response to its availability may include tracking a wake up statistic for the processor element, determining whether the wake up statistic for the processor element exceeds wake up threshold, and assigning a high priority to the processor element for accessing the resource in response to determining that the wake up statistic for the processor element exceeds the wake up threshold.

An embodiment method may include sending the priority assigned to the processor element to another processor element currently accessing the resource, and in which signaling the processor element to access the resource in response to the resource becoming available may include signaling the processor element by the another processor element currently accessing the resource upon releasing the resource. An embodiment method may include detecting a plurality of threads requesting access to the resource, and requesting an operating system to migrate the plurality of threads to a selected group of the plurality of processor elements.

An embodiment method may include estimating a sleep time for the processor element while waiting for the resource, determining a sleep state for the processor element based on the estimated sleep time, and notifying the processor element of the sleep state to implement while waiting for the resource. An embodiment method may include estimating a sleep time for the processor element while waiting for the resource, and notifying an operating system of the computing device of the estimated sleep time for the processor element. An embodiment method may include removing the processor element from a scheduling queue for a period of time associated with the estimated sleep time for the processor element. An embodiment method may include assigning a thread to the processor element during the estimated sleep time. An embodiment method may include communicating between signaling event managers to manage signaling of the plurality of processor elements.

The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate example embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.

The terms "computing device" and "mobile computing device" are used interchangeably herein to refer to any one or all of cellular telephones, smartphones, personal or mobile multi-media players, personal data assistants (PDA's), laptop computers, tablet computers, smartbooks, ultrabooks, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, and similar personal electronic devices that include a memory, and a programmable multi-processor (e.g. multi-core, multi-socket, or multi-CPU). While the various embodiments are particularly useful for mobile computing devices, such as smartphones, which have limited memory and battery resources, the embodiments are generally useful in any electronic device that implements a plurality of memory devices and a limited power budget in which reducing the power consumption of the processors can extend the battery-operating time of the mobile computing device.

The term "system-on-chip" (SoC) is used herein to refer to a set of interconnected electronic circuits typically, but not exclusively, including a hardware core, a memory, and a communication interface. A hardware core may include a variety of different types of processor elements, such as a general purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), an auxiliary processor, a single-core processor, a multi-core processor, and individual processor cores. A hardware core may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASCI), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material, such as silicon.

Embodiments include methods and computing devices implementing such methods for dynamically changing the time at which each processor element in a multi-processor element system receives a signal by using system state information. A signaling event manager may be implemented in hardware and/or software for managing the event and wake up signaling to each of the processor elements by ordering events based on system and environment states. One or more signaling event managers may compute heuristic-based notification priorities and send notifications of events (e.g., wake up and wait signals) to individual processor elements in an order determined by the priorities determined from a heuristic. The heuristic for determining processor element priorities that is applied in response to a particular signaling event may be selected based on the signaling event, and may be supplied to the signaling event manager by being directly encoded in a received signaling event instruction, read from a register or memory location associated with the signaling event, or predefined and stored in the signaling event manager for different signaling modes or events. In an embodiment, a heuristic may be used to determine the order of a signaling priority for the processor elements based on temperatures of the processer elements (from low to high) to reduce the chance of thermal throttling. In an embodiment, the heuristic may be based on operating frequency of the elements (from high to low) to minimize execution time. In an embodiment, the heuristic may be based on sharing cache, or other resources, such as accelerators or functional units, between certain processor elements and proximity of the processor elements (preferring a local processor element than a remote processor element).

Using one or more of the embodiment heuristics for determining the priority of the processor elements, the signaling event manager may create and manage a list of processor elements and their priorities. The list may be used to send out event notifications to the processor elements signaling to one of the processor elements (vs. all processor cores as in the prior art) the availability of a resource and to accept/verify requests for a resource from all processor elements. The list may be managed such that the priority of the processor elements may be rearranged based on the heuristic factors described above.

In an embodiment, when a processor element receives an event, the processor element may wake up and try to grab a lock. The signaling event manager may receive a request from the processor element to grab a lock for a resource and identify the priority of the processor element. If a lock is available and the processor element has the highest priority, the signaling event manager may allow the processor element to obtain the available lock. However, if locks on the resource are unavailable or the processor element does not have the highest priority, the signaling event manager may instruct the processor element to wait. Upon a lock becoming available and the signaling event manager identifying a highest priority processor element, the signaling event manager may signal the highest priority processor element to wake up and request to obtain the lock. When a processor element releases a lock and the lock becomes available, the signaling event manager may send a signal to a next waiting processor element according to a previous priority ordering of the processor elements, or the signaling event manager may update the list of waiting processor elements and send the signal to a new highest priority waiting processor element.

The heuristic used by the signaling event manager to determine the priorities of the processor elements may be provided by the processor elements. In an embodiment, the processor elements may include a wait-for-event ("WFE") instruction that may be executed when requesting a resource lock. The wait-for-event instruction may list the heuristic information that is desired for determining the priority of the processor elements. Executing the wait-for-event instruction may cause the processor elements to forward the heuristic information along with the request for the resource lock. For example, the processor element may return thermal information in response to an indication of a thermal-based heuristic, cache locality information in response to an indication of a location-based heuristic, power state information in response to an indication of a frequency-based heuristic. A processor element may provide one or more of these information types to the signaling event manager in the request to grab the lock. The heuristic information type sent may be predetermined by a type of system implementing the signaling event manager. In an embodiment, the signaling event manager may respond to the request for the resource lock and heuristic information with a WFE signal, which may trigger the receiving processor element to enter a sleep/low power state.

In an embodiment in which the processor elements do not include a WFE instruction and the heuristic information type is indicated by the signaling event manager-selected or in which the signaling event manager changes the heuristic information that it requires to determine priority, the type of heuristic information requested may be included in the WFE signal sent to the processor elements. Bits in the WFE signal may prompt the processor element to respond to the signaling event manager with state information relevant to a heuristic so that the signaling event manager may apply that information to the heuristic in order to determine the priority of the processor element. As above, examples may include the processor element returning one or more of thermal information in response to an indication of a thermal-based heuristic, cache locality information in response to an indication of a location-based heuristic, power state information in response to an indication of a frequency-based heuristic in response to an indication of a signaling event manager-selected heuristic. The wait-for-event signal may also trigger the sleep state in the requesting processor elements.

In an embodiment, the heuristic information for the requesting processor elements may be determined, rather than retrieved, by the signaling event manager in response to resource lock requests. The signaling event manager may still send the wait-for-event signal to the requesting processor elements to trigger the sleep state in the requesting processor elements.

The signaling event manager may keep track of the number of wake ups and/or when the wake ups last occurred for each processor element. The signaling event manager may compare this data to a starvation threshold to prioritize processor elements so that all processor elements eventually receive the lock. For example, when a processor element exceeds the threshold indicating that the processor element is receiving a skewed number of locks (high or low), the signaling event manager may adjust the priorities of the processor elements to balance the number of locks obtained by the various processor elements to prompt forward progress of the waiting processes.

The various embodiments may be useful for any synchronization primitive when multiple participants attempt to access the resources of the computing device and there is a potential for contention for accessing the resources. For ease of explanation, the various embodiments are described with reference to resource locks, however such descriptions are not meant to be limiting.

<FIG> illustrates a system including a computing device <NUM> in communication with a remote computing device <NUM> suitable for use with the various embodiments. The computing device <NUM> may include an SoC <NUM> with a processor <NUM>, a memory <NUM>, a communication interface <NUM>, and a storage interface <NUM>. The computing device may further include a communication component <NUM> such as a wired or wireless modem, a storage component <NUM>, an antenna <NUM> for establishing a wireless connection <NUM> to a wireless network <NUM>, and/or the network interface <NUM> for connecting to a wired connection <NUM> to the Internet <NUM>. The processor <NUM> may include any of a variety of processor elements, including a number of processor cores. The SoC <NUM> may include one or more processors <NUM>. The computing device <NUM> may include more than one SoC <NUM>, thereby increasing the number of processors <NUM>, processor elements, and processor cores. The computing device <NUM> may also include processor <NUM> that are not associated with an SoC <NUM>. Individual processors <NUM> may be multi-core processors as described below with reference to <FIG>. The processors <NUM> may each be configured for specific purposes that may be the same as or different from other processors <NUM> of the computing device <NUM>. As such, various processors <NUM> may include various processor elements of the same or different type. One or more of the processors <NUM> and processor cores of the same or different configurations may be grouped together.

The memory <NUM> of the SoC <NUM> may be a volatile or non-volatile memory configured for storing data and processor-executable code for access by the processor <NUM>. In an embodiment, the memory <NUM> may be configured to store data structures at least temporarily, such as intermediate processing data output by one or more of the processors <NUM>. In an embodiment, the memory <NUM> may be cache memory or random access memory (RAM) configured to store information for prioritizing processor elements making lock resource access request. The memory <NUM> may include non-volatile read-only memory (ROM) in order to retain the information for prioritizing processor elements attempting to obtain a lock on a resource on the computing device.

The computing device <NUM> and/or SoC <NUM> may include one or more memories <NUM> configured for various purposes. In an embodiment, one or more memories <NUM> may be configured to be dedicated to storing the information for prioritizing processor elements for a designated set of processor elements. The memory <NUM> may store the information in a manner that enables the information to be interpreted by the signaling event manager for directed event signaling for multi-processor element systems.

The communication interface <NUM>, communication component <NUM>, antenna <NUM>, and/or network interface <NUM>, may work in unison to enable the computing device <NUM> to communicate over a wireless network <NUM> via a wireless connection <NUM>, and/or a wired network <NUM> with the remote computing device <NUM>. The wireless network <NUM> may be implemented using a variety of wireless communication technologies, including, for example, radio frequency spectrum used for wireless communications, to provide the computing device <NUM> with a connection to the Internet <NUM> by which it may exchange data with the remote computing device <NUM>.

The storage interface <NUM> and the storage component <NUM> may work in unison to allow the computing device <NUM> to store data on a non-volatile storage medium. The storage component <NUM> may be configured much like an embodiment of the memory <NUM> in which the storage component <NUM> may store the information for prioritizing processor elements making lock resource access request, such that information may be accessed by one or more processors <NUM>. The storage component <NUM>, being non-volatile, may retain the information even after the power of the computing device <NUM> has been shut off. When the power is turned back on and the computing device <NUM> reboots, the information stored on the storage component <NUM> may be available to the computing device <NUM>. The storage interface <NUM> may control access to the storage device <NUM> and allow the processor <NUM> to read data from and write data to the storage device <NUM>.

Some or all of the components of the computing device <NUM> may be differently arranged and/or combined while still serving the necessary functions. Moreover, the computing device <NUM> may not be limited to one of each of the components, and multiple instances of each component may be included in various configurations of the computing device <NUM>.

<FIG> illustrates a processor element, such as a multi-core processor <NUM>, suitable for implementing an embodiment. The multi-core processor <NUM> may have a plurality of homogeneous or heterogeneous processor elements, such as processor cores <NUM>, <NUM>, <NUM>, <NUM>. The processor cores <NUM>, <NUM>, <NUM>, <NUM> may be homogeneous in that, the processor cores <NUM>, <NUM>, <NUM>, <NUM> of a single processor <NUM> may be configured for the same purpose and have the same or similar performance characteristics. For example, the processor <NUM> may be a general purpose processor, and the processor cores <NUM>, <NUM>, <NUM>, <NUM> may be homogeneous general purpose processor cores. Alternatively, the processor <NUM> may be a graphics processing unit or a digital signal processor, and the processor cores <NUM>, <NUM>, <NUM>, <NUM> may be homogeneous graphics processor cores or digital signal processor cores, respectively.

Through variations in the manufacturing process and materials, the performance characteristics of homogeneous processor cores <NUM>, <NUM>, <NUM>, <NUM>, may differ from processor core to processor core within the same multi-core processor <NUM> or within another multi-core processor <NUM> using the same designed processor cores.

The processor cores <NUM>, <NUM>, <NUM>, <NUM> may be heterogeneous in that, the processor cores <NUM>, <NUM>, <NUM>, <NUM> of a single processor <NUM> may be configured for different purposes and/or have different performance characteristics. Example of such heterogeneous processor cores may include what are known as "big. LITTLE" architectures in which slower, low-power processor cores may be coupled with more powerful and power-hungry processor cores.

The multi-core processor <NUM> may further include a signaling event manager <NUM> in communication with each the processor cores <NUM>, <NUM>, <NUM>, <NUM>. The signaling event manager (or the signaling manager) <NUM>, may receive resource access requests, including requests to lock or unlock a resource of the computing device, prioritize each processor core, and signal the processor cores to wait for an event and signal prioritized processor cores when the event occurs. In an embodiment, the event includes the release of a lock on a resource for which the processor core attempts to obtain a lock.

<FIG> illustrates a processor element suitable for implementing an embodiment much like <FIG>. In an embodiment, the processor element, in this instance the multi-core processor <NUM>, may include multiple signaling event managers <NUM>, <NUM>, <NUM>. In various embodiments, the signaling event managers <NUM>, <NUM>, <NUM> may be in communication with a variety of combinations or processor cores <NUM>, <NUM>, <NUM>, <NUM>. In an embodiment, multiple processor cores, like processor core <NUM><NUM>, processor core <NUM><NUM>, and processor core <NUM><NUM> may be in communication with a shared signaling event manager, like signaling event manager <NUM><NUM>. In an embodiment, one or more processor cores, like processor core <NUM><NUM>, may be in communication with multiple signaling event managers, like signaling event manager <NUM><NUM> and signaling event manager <NUM><NUM>. In an embodiment, a processor core, like processor core <NUM><NUM>, may be in communication with a dedicated signaling event manager, like signaling event manager <NUM><NUM>. The signaling event managers <NUM>, <NUM>, <NUM> may be in communication with each other via a common communication bus of the processor element, or via a dedicated signaling event manager communication bus <NUM>.

<FIG> illustrates an embodiment in which the signaling event managers <NUM>, <NUM>, <NUM> are local to the processor elements, like single or multi-core processor <NUM>, <NUM>, <NUM>, <NUM>. <FIG> illustrates an embodiment in which the signaling event managers <NUM>, <NUM>, <NUM> are local to the processing elements, like SoCs <NUM>, <NUM>, <NUM>, <NUM>. Similar to the example in <FIG>, the signaling event managers <NUM>, <NUM>, <NUM> may be in communication with each other via a common communication bus of the Soc <NUM> in <FIG> or the computing device <NUM> in <FIG>, or via a dedicated signaling event manager communication bus <NUM>. In an embodiment, there may be layers of signaling event managers <NUM>, <NUM>, <NUM> such that the signaling event managers <NUM>, <NUM>, <NUM> may be local to the processor cores <NUM>, <NUM>, <NUM>, <NUM> as in <FIG> and in communication with signaling event managers <NUM>, <NUM>, <NUM> local to higher level components, such as the multi-core processors <NUM>, <NUM>, <NUM>, <NUM> or the SoCs <NUM>, <NUM>, <NUM>, <NUM>. Similarly, the signaling event managers <NUM>, <NUM>, <NUM> local to the multi-core processors <NUM>, <NUM>, <NUM>, <NUM> may be in communication with the signaling event managers <NUM>, <NUM>, <NUM> local to SoCs <NUM>, <NUM>, <NUM>, <NUM>.

In the examples illustrated in <FIG>, the multi-core processor <NUM> includes four processor cores <NUM>, <NUM>, <NUM>, <NUM> (i.e., processor core <NUM>, processor core <NUM>, processor core <NUM>, and processor core <NUM>). The example illustrated in <FIG>, the SoC <NUM> includes four processors <NUM>, <NUM>, <NUM>, <NUM> (i.e. processor <NUM>, processor <NUM>, processor <NUM>, and processor <NUM>). In the example illustrated in <FIG>, the computing device <NUM> includes four SoCs <NUM>, <NUM>, <NUM>, <NUM> (i.e. SoC <NUM>, SoC <NUM>, SoC <NUM>, and SoC <NUM>). For ease of explanation, the various embodiments may be described with reference to any of the processor elements, including the four processor cores <NUM>, <NUM>, <NUM>, <NUM>, processors <NUM>, <NUM>, <NUM>, <NUM>, or SoCs <NUM>, <NUM>, <NUM>, <NUM> illustrated in <FIG>. However, the processor elements illustrated in <FIG> and referred to herein are provided merely as an example and in no way are meant to limit the various embodiments to a four-core processor system, a four processor system, or a four SoC system. The computing device <NUM>, the SoC <NUM>, or the multi-core processor <NUM> may individually or in combination include fewer or more than four processor cores, processor, or SoCs.

The multiple signaling event managers <NUM>, <NUM>, <NUM> may communicate with each other to manage the availability of resources requested by processing elements, the priorities of the processor elements, and signaling the processor elements to wake up and obtain a lock on the requested resource, as will be discussed further herein. The examples discussed herein may be explained in terms of a single signaling event manager; however this is only intended as an example and in no way meant to limit the various embodiments to a single signaling event manager system. The computing device <NUM>, the SoC <NUM>, or the multi-core processor <NUM> may individually or in combination include more than one signaling event manager.

<FIG> illustrates an example processor element, such as a multi-core processor <NUM>, employing a cluster architecture suitable for implementing an embodiment. Much like the example multi-core processor <NUM> in <FIG>, the multi-core processor <NUM> illustrated in <FIG> may include four processor cores <NUM>, <NUM>, <NUM>, <NUM>, although this configuration of processor cores is not limiting and the various embodiments function in a similar manner with fewer or more processor cores. Also similar to the multi-core processor <NUM> in <FIG>, the processor cores <NUM>, <NUM>, <NUM>, <NUM> may all be in communication with the signaling event manager(s) <NUM>, <NUM>, <NUM>, <NUM>. The multi-core processor illustrated in <FIG> may further include grouping the processor cores <NUM>, <NUM>, <NUM>, <NUM> into clusters <NUM>, <NUM>. The multi-core processor <NUM> may employ the clusters <NUM>, <NUM> to efficiently execute processing of program instructions and data.

The clusters <NUM>, <NUM> may be static, maintaining the same processor cores <NUM>, <NUM>, <NUM>, <NUM> in the cluster <NUM>, <NUM>. The clusters <NUM>, <NUM> may also be dynamic, changing the processor cores' membership in one or more cluster <NUM>, <NUM> based on various factors. The example illustrated in <FIG> shows two processor cores <NUM>, <NUM>, <NUM>, <NUM> in each cluster <NUM>, <NUM>. The number and combination of processor cores <NUM>, <NUM>, <NUM>, <NUM> in the clusters <NUM>, <NUM> are not meant to be limiting. Further, the number of clusters <NUM>, <NUM> and configuration of each cluster <NUM>, <NUM> is also not meant to be limiting. The clusters <NUM>, <NUM> may include any combination of processor cores <NUM>, <NUM>, <NUM>, <NUM>, including processor cores <NUM>, <NUM>, <NUM>, <NUM> included in both clusters <NUM>, <NUM>.

In addition to the processor cores <NUM>, <NUM>, <NUM>, <NUM>, the clusters <NUM>, <NUM> may each include a cluster cache <NUM>, <NUM>, which, in an embodiment, may be configured much like the memory device <NUM> in <FIG> described above. The cluster cache <NUM>, <NUM> may store data and program instructions for fast access by the processor cores <NUM>, <NUM>, <NUM>, <NUM> in their respective clusters <NUM>, <NUM>. The cluster cache <NUM>, <NUM> may store data related to prioritizing the processor cores <NUM>, <NUM>, <NUM>, <NUM> for resource access request. In an embodiment, the items stored in the cluster cache <NUM>, <NUM> may be relevant only to the respective cluster <NUM>, <NUM> of the cluster cache <NUM>, <NUM>. The cluster cache <NUM>, <NUM> may also store the resources for which the processor cores <NUM>, <NUM>, <NUM>, <NUM> of the respective clusters <NUM>, <NUM> issue resource access requests. The multi-core processor <NUM> may also include a processor cache <NUM> that may contain data and program instructions similar that in the cluster cache <NUM>, <NUM>. The processor cache <NUM> may maintain such information for one or more of the processor cores <NUM>, <NUM>, <NUM>, <NUM> allocated to one or more of the clusters <NUM>, <NUM>.

The clusters <NUM>, <NUM> may include processors cores <NUM>, <NUM>, <NUM>, <NUM> capable of similar or disparate processing. The clusters <NUM>, <NUM> may also include components, such as the processor cores <NUM>, <NUM>, <NUM>, <NUM> and cluster caches <NUM>, <NUM> of relatively close locality compared to other components of the multi-core processor <NUM> that may be options for inclusion in the clusters <NUM>, <NUM>. The clusters <NUM>, <NUM> may be configured to more efficiently execute processes and threads than without clustering the processor cores <NUM>, <NUM>, <NUM>, <NUM>.

<FIG> illustrates an example table <NUM> demonstrating relationships between processor elements and their assigned priorities in accordance with an embodiment. The table <NUM> is an exemplary and non-limiting format for relating some or all of the data shown in table <NUM>. The table <NUM> illustrates an example of how processor elements (listed in column <NUM>) may be correlated (by rows) with information (columns <NUM>-<NUM>) associated with the processor elements, although such data may be stored and related using any number of known data structures. Examples of information regarding each processor element may include a priority in column <NUM>, one or more parameters for determining the priority in column <NUM> (e.g. processor element temperature, operating frequency, and/or proximity of/sharing of resources by the elements) a number of times the processor element has been signaled to wake up to obtain a resource lock in column <NUM>, and an amount of time since the last occurrence of the processor element being signaled to wake up in column <NUM>, or a time of the last occurrence of the processor element being signaled to wake up. In an embodiment, the parameters for determining the priority may be preprogrammed in software running on the computing device, hardcoded to the signaling event manager, or selected based on various considerations by the signaling event manager.

The table <NUM> may include all processor elements that make a lock resource access request. In an embodiment, during a particular session on the computing device, until a first processor element makes a lock resource access request, the table <NUM> may be empty or may not exist. The table <NUM> may be initiated upon a first lock resource access request by a first processor element. The table <NUM> may be further populated as other processor elements make other lock resource access requests.

In an embodiment the table <NUM> may include a row <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> for relating the information of each processor element that makes a lock resource access request. A row <NUM>-<NUM> may be included in the table for each of N number processor elements (i.e. processor element <NUM> to processor element N-<NUM>). Each row <NUM>-<NUM> may be retained in the table <NUM> after the respective processor elements make an unlock resource access request. Each of the rows <NUM>-<NUM> make be updated upon the respective processor elements making another lock resource request, upon a processor element making an unlock resource access request, and/or at periodic intervals. In an embodiment, rows <NUM>-<NUM> for processor elements making unlock resource access request may be removed from the table <NUM>. The table <NUM> may be a universal table for all lock resource access requests.

The table <NUM> may maintain information for each row <NUM>-<NUM> identifying the resource for which the associated processor element (listed in column <NUM>) is attempting to obtain a lock. In such a table <NUM>, it is possible for different processor elements to have the same priority (listed in column <NUM>) as long as each priority relates to different resources.

In an embodiment, multiple tables <NUM> may be implemented in memory, in which case each of the tables <NUM> may be dedicated for a specific resource.

As an example of the relationship of various processor elements with their respective priorities, and other information relating to the processor elements that may be stored tables, table <NUM> illustrates how a criterion for determining priority according to a heuristic may be the processor element temperature <NUM>. The example shows that the priority (listed in column <NUM>) for each processor element may be determined based on an inverse relationship with the processor element temperature (listed in column <NUM>). In this example, the lowest processor element temperature may correlate with the highest priority. Thus, processor element <NUM> in row <NUM>, having the lowest processor element temperature of <NUM>, may be assigned the highest priority of <NUM>. Conversely, processor element <NUM> in row <NUM>, having the highest processor element temperature of <NUM>, may be assigned the highest priority of <NUM>. As noted above, parameters other than the processor element temperature <NUM> may be used as the criterion for determining the priority <NUM> of the processor elements. In an embodiment, any combination of parameters may be used as criteria for determining priorities of processor elements.

In an embodiment, the number of times that the processor element has been signaled to wake up to obtain a resource lock (listed in column <NUM>), and/or the amount of time since the last occurrence of the processor element being signaled to wake up (listed in column <NUM>) may be used in a heuristic for setting priorities of processor elements in order to avoid a starvation condition for any of the processor elements. A starved processor element may be forced to wait so long that the process for which the starving processor element attempts to obtain the resource lock may not be progressing in a timely manner. Starvation may occur when a processor element is signaled to wake up significantly less often than other processor elements or waits significantly longer to be signaled to wake up than the other processor elements. The number of times that the processor element has been signaled to wake up to obtain a resource lock may be compared to a wake up number threshold. Additionally or alternatively, the amount of time since the last occurrence of the processor element being signaled to wake up may be compared to a time-since-wake up threshold. The comparison(s) may occur periodically and/or upon a processor element issuing an unlock resource access request. In response to determining that one or more of the starvation thresholds are exceeded, the priority of the starving processor element may be increased to enable the starving processor element to obtain the resource lock before other processor elements that previously had higher priority.

The table <NUM> may be stored in any of the above mentioned memory and storage devices. For example, the table <NUM> may be stored in the memory device <NUM> shown in <FIG>, the processor cache <NUM> shown in <FIG>, or in the signaling event manager <NUM> shown in <FIG> and <FIG>. In another example, the table <NUM> may be stored in the above mentioned memory device <NUM>, the processor cache <NUM>, the signaling event manager <NUM>, the cluster cache <NUM>, or the cluster cache <NUM> shown in <FIG>. The signaling event manager may access the table <NUM> from any of these storage locations.

<FIG> illustrates a process and signaling flows of directed event signaling in a multiprocessor system in accordance with an embodiment. For ease of explanation, the example in <FIG> includes signaling between the signaling event manager <NUM>, processor element <NUM><NUM>, processor element <NUM><NUM>, and processor element <NUM><NUM>. This example is not meant to be limiting regarding the number of processor elements that may communication with a signaling event manager, or the number of signaling event managers that may communicate with a processor element. In this example, processor element <NUM><NUM> may send a lock resource access request <NUM> to the signaling event manager <NUM>. In response to no other processor element <NUM>, <NUM> having a resource lock on the same resource for which processor element <NUM><NUM> is requesting the resource lock, the processor element <NUM><NUM> may obtain a resource lock <NUM>. The signaling event manager <NUM> may respond to the lock resource access request <NUM>, but it may not respond in some embodiments when the resource lock is available at the time of the lock resource access request <NUM>.

The signaling event manager <NUM> may update or initiate a table for associating the processor elements <NUM>, <NUM>, <NUM> with respective priorities. In an embodiment, various schemes may be used to indicate the priority of a processor element that obtains a resource lock. For example, the processor element having the resource lock may be given the highest priority until it relinquishes the lock, at which point its priority may be updated based on the criterion for priority, whether the processor element issues another lock resource access request, and/or based on an opposite use of the starvation information. In other examples, the processor element having the resource lock may be assigned the lowest priority or no priority until making another lock resource access request.

When the processor element <NUM><NUM> sends a lock resource access request <NUM> to the signaling event manager <NUM> for the same resource locked by resource lock <NUM>, the signaling event manager <NUM> may update the table and assign processor element <NUM><NUM> a priority for obtaining the requested resource lock. The signaling event manager <NUM> may return a wait-for-event signal <NUM> to the processor element <NUM><NUM> in response to the request resource being locked by the resource lock <NUM>. The wait-for-event signal <NUM> may trigger the processor element <NUM><NUM> to enter a sleep state until it receives a signal that the resource is available for a resource lock (e.g. set event signal). However, the processor element <NUM><NUM> may not receive such a set event signal upon a first instance of the resource being available for a resource lock if it does not have the highest priority.

For the above lock resource access requests <NUM>, <NUM> the information for the criterion of assigning priority may or may not be required by the signaling event manager <NUM>. For the lock resource access request <NUM> the information may not be required as it is the first lock resource access request and no other processor elements <NUM>, <NUM> are vying for the resource lock. The lock resource access request <NUM> may require the information, but it may not be necessary for assigning the priority for processor element <NUM><NUM> if it is the next processor element in line for the resource lock. However, the information may be stored in the table for comparison to subsequent lock resource access request as they may cause the signaling event manager <NUM> to alter the priority of processor element <NUM><NUM> in the future.

When processor element <NUM><NUM> sends a lock resource access request <NUM> to the signaling event manager <NUM> for the same resource as processor element <NUM><NUM> and processor element <NUM><NUM>, the signaling event manager may update the table by comparing the information of the priority criterion for the processor element <NUM><NUM> with the information in the table for the other waiting processor elements, in this case processor element <NUM><NUM>. In this example, processor element <NUM><NUM> has parameter values for the priority criterion that result in a higher priority than processor element <NUM>. If the processor element <NUM><NUM> still has the resource lock <NUM>, the signaling event manager may return a wait-for-event signal <NUM> to the processor element <NUM><NUM>. The wait-for-event signal <NUM> may trigger the processor element <NUM><NUM> to enter a sleep state until it receives a signal that the resource is available for a resource lock (e.g. a set event signal).

Processor element <NUM><NUM> may send an unlock resource access request <NUM> to the signaling event manager <NUM>, indicating that the processor element <NUM><NUM> is relinquishing the resource lock <NUM>, making that resource available for another of the processor elements <NUM>, <NUM> to obtain a resource lock on the resource. In response, the signaling event manager <NUM> may check the table to determine the processor element <NUM>, <NUM>, <NUM> that has the highest priority. In response to determining that processor element <NUM><NUM> has the highest priority, the signaling event manager <NUM> may send a set event signal, or a wake up signal <NUM> to that processor element <NUM><NUM>. The wake up signal <NUM> may trigger the processor element <NUM><NUM> to wake up from its sleep state to obtain a resource lock <NUM>. When it is finished with the resource, the processor element <NUM><NUM> may send an unlock resource access request <NUM> to the set signaling event manager <NUM> and relinquish the resource lock <NUM>. In response, the signaling event manager <NUM> may again check the table to determine the processor element <NUM>, <NUM>, <NUM> with the highest priority. In the example illustrated in <FIG>, at this point processor element <NUM><NUM> is the only processor element waiting for a resource lock, and therefore it is also the processor element <NUM><NUM> with the highest priority. Thus, the signaling event manager <NUM> may send a wake up signal <NUM> triggering processor element <NUM><NUM> to wake up from its sleep state and obtain a resource lock <NUM>.

The lock resource access requests <NUM>, <NUM>, <NUM> may or may not include the information for the criterion for the priority and/or starvation. In an embodiment, the criterion for the priority and/or starvation may not be known to the processor elements <NUM>, <NUM>, <NUM>. In this embodiment, the signaling event manager <NUM> may retrieve the information for the requesting processor elements <NUM>, <NUM>, <NUM> by requesting the information from another source, such as a kernel or operating system running on the computing device, retrieving the information from memory, or taking measurements from sensors (e.g., temperature sensors) near the processor elements <NUM>, <NUM>, <NUM>. In other embodiments, the processor elements <NUM>, <NUM>, <NUM> may know the information, but may not know the information that is required by the signaling event manager <NUM>, which may depend upon the particular heuristic that the signaling event manager has selected. Therefore, in response to receiving a lock resource access request <NUM>, <NUM>, <NUM>, the signaling event manager <NUM> may send a request for the required information and receive the information from the lock requesting processor element in return. In an embodiment, the request for information by the signaling event manager <NUM> may be part of the wait-for-event signal <NUM>, <NUM>, and the signaling event manager <NUM> may receive the requested information prior to the processor elements <NUM>, <NUM>, <NUM> entering the sleep state. In an embodiment, the required information may be indicated in a special register, a memory location, or an added NOP instruction with special meaning before or after the wait-for-event signal <NUM>, <NUM>.

In an embodiment, rather than the signaling event manager <NUM> receiving unlock resource access requests <NUM>, <NUM>, and sending wake up signals <NUM>, <NUM>, the signaling event manager <NUM> may send updated priority information to the processor element that has the resource lock, and in response to relinquishing the resource lock, the relinquishing processor element may send a wake up signal to the processor element with the highest priority. In this manner, the highest priority processor element may receive the wake up signal from the relinquishing processor element, causing it to wake up from its sleep state and obtain a resource lock that is now available.

<FIG> illustrates an embodiment method <NUM> for implementing directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may receive a resource access request from a processor element. In an embodiment the resource access request may include information that may aid the signaling event manager to determine a priority of the requesting processor element to obtain a lock on the requested resource as discussed above.

In determination block <NUM>, the signaling event manager may determine whether the resource access request is for unlocking an obtained resource lock or for obtaining a resource lock. For example, the resource access request may specify whether the request is an unlock resource access request or a lock resource access request. In response to determining that the resource access request is an unlock resource access request (i.e. determination block <NUM> = "Unlock"), the signaling event manager may determine whether there are any pending lock resource access requests for the same resource in determination block <NUM>. In an embodiment, the signaling event manager may check the priorities of the processor elements that have previously sent lock resource access requests but were denied because the requested resource was already locked by another processor element. In response to determining that there are no pending lock resource access requests for the same resource (i.e. determination block <NUM> = "NO"), the signaling event manager may return to block <NUM> to receive other resource access requests. In response to determining that there are pending lock resource access requests, (i.e. determination block <NUM> = "YES"), the signaling event manager may send a wake up signal to the highest priority processor element in block <NUM>, thereby triggering the processor element to wake up from a sleep state and obtain a lock on the available resource. The signaling event manager may receive other resource access requests in block <NUM>.

In response to determining that the resource access request is a lock resource access request (i.e. determination block <NUM> = "Lock"), the signaling event manager may determine whether a lock on the requested resource is owned, or already obtained, by another processor element in determination block <NUM>. As discussed above, the signaling event manager may store and maintain data regarding the lock and the processor elements that may be accessed for this operation, such as in a table. Such a table may be dedicated to particular resources and the signaling event manager may determine the status of an obtained resource lock by analyzing the data in the table. In an embodiment, the data in a table for a particular resource may indicate the status of a resource lock by the priority value. For example, a certain priority value may indicate that the associated processor element currently owns the resource lock. In another embodiment, data (e.g., a binary flag) may indicate ownership of a resource lock. Other embodiments include a universal table (rather than a resource specific table) that may include an indication of the resource(s) that the processor elements are requesting or own a resource lock. In response to determining, that the requested resource is not locked, the requested resource is available, or the resource lock is not owned (i.e. determination block <NUM> = "NO"), the signaling event manager may confirm acquisition of the resource lock to the requesting processor element in block <NUM>. In block <NUM>, the signaling event manager may update the table, or lock request wait list, to reflect the ownership of the resource lock. In the above described embodiment, the signaling event manager may accomplish updating the table by updating one or more of the indicators of resource lock ownership. The signaling event manager may receive other resource access requests in block <NUM>.

In response to determining that the requested resource is locked/ the requested resource is unavailable/the resource lock is owned (i.e. determination block <NUM> = "YES"), the signaling event manager may signal the requesting processor element to wait for an event in block <NUM>. In an embodiment, the wait-for-event signal may trigger the processor element to enter a sleep more until being notified of the event as described above. In block <NUM>, the signaling event manager may update the table, or lock request wait list, to reflect the denied request for the resource lock. In an embodiment, the signaling event manager may update at least the priority of the requesting processor element in the table, indicating that the requesting processor element has made a request for a resource lock, and where among the other requests of resource locks the current request ranks. The signaling event manager may receive other resource access requests in block <NUM>.

In an embodiment, during a session on a computing device, the table may not yet be initiated, or fully or partially populated, prior to a first lock resource access request. A fully or partially populated table may include data, but the data may be irrelevant or incomplete before receiving updated data associated with lock resource access requests. To address this embodiment, the signaling event manager or another processor may implement an embodiment method <NUM> for determining whether such a table exists, and implementing a lock resource access request table, or wait list, when it does not exist as illustrated in <FIG>. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware.

When the signaling event manager has a need to access a lock resource access request or wait list table, such as upon receiving a resource request in block <NUM> or determining whether a requested resource is locked in determination block <NUM> in method <NUM>, the signaling event manager may determine in determination block <NUM> whether a lock resource access request table, or wait list, exist, or is populated. In response to determining that the table is does not exist or is not initiated (i.e. determination block <NUM> = "NO"), the signaling event manager may initiate the table, or wait list in block <NUM>. In an embodiment, initiating the table may involve creating and filling the table with data associated with at least one processor element making a lock resource access request. In block <NUM>, the signaling event manager may assign the requesting processor element a priority. As described above, the first processor element of the table may have any priority since there are no other processor elements for comparison. In an embodiment, the first processor element in the table may be assigned a default priority or a random priority.

In response to determining that the table is does exist or is initiated (i.e. determination block <NUM> = "YES"), the signaling event manager may determine the priority of the requesting processor elements in block <NUM>. As discussed above, the signaling event manager may receive the relevant data for determining the priority of a processor element by various means, including multiple signals between the signaling event manager and other hardware and software components of the computing device. The data that is relevant for determining the priority of a processor element may be predetermined by software or firmware, or may be selected by the signaling event manager. In block <NUM>, the signaling event manager may update the table. Depending on the configuration of the table, the signaling event manager may update the priority of the requesting processor element, and the other processor elements listed in the table based on comparisons of the data associated with the requesting processor element with the data associated with the other processor elements. Updating the table to include or update the priority of the requesting processor element may cause changes to the priorities of the other processor elements in response to the priority of the requesting processor element being higher. In optional block <NUM>, the signaling event manager may send the table to the processor element that owns the resource lock in embodiments in which the processor element owning the resource lock notifies the next waiting processor element when the resource is unlocked. The operations in optional block <NUM> enable the processor element owning the resource lock to determine the next waiting processor element that will receive the lock based on the priorities in the table.

<FIG> illustrates an embodiment method <NUM> for implementing prioritization of processor elements for directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may determine the criterion or criteria for assigning priorities to the requesting processor elements. The criterion or criteria may include one or more of the processor element temperature, operating frequency, and locality. In an embodiment, the signaling event manager may select the criterion or criteria for assigning priorities, which may depend on the states of the computing device at the time. For example, states of high temperature, low power availability, power saving modes, and low priority processes may lead the signaling event manager to select low processor element temperature and/or low operating frequency as the criteria for higher priority. On the other hand, a fully charged or charging battery, and high performance software may lead the signaling event manager to select high operating frequency and/or high degree of locality as the criteria for higher priority. In other embodiments, the signaling event manager may determine the criterion or criteria for assigning priority by retrieving the criterion/criteria from storage, such as a register integrated in or external to the signaling event manager, or as provided by a software program running on the computing device.

In block <NUM>, the signaling event manager may compare the one or more parameters of the requesting processor element related to the selected criterion to one or more similar parameters of the other processor elements stored in the table to determine the processing element that best satisfies the selected criterion or criteria for assigning priority. Depending on the selected criterion or criteria for determining the priorities of the processor elements, a favorable comparison for the requesting processor element may result from the data of the requesting processor element being higher or lower than that of the comparable data of the other processor elements. A favorable comparison for the requesting processor element may result in a higher priority than at least one of the other processor elements waiting to obtain a resource lock on the same resource as the requesting processor element. In some embodiments, the comparison in block <NUM> may be a direct comparison of the values of these parameters. In some embodiments, the comparison in block <NUM> may be an indirect comparison in which one or more algorithms/calculations are applied to the values of these parameters and the results of these algorithms/calculations are compared.

In block <NUM>, the signaling event manager may assign a priority to the requesting processor element based on the parameter comparisons. Assigning the priority to the requesting processor element may also result in changes in priority for one or more of the other processor elements waiting to obtain a resource lock on the same resource. For example, in response to the requesting processor element being assigned a higher priority than three other processor elements, the priority of each of the three other processor elements may be decremented accordingly. At the same time, other processor elements having a higher priority than the priority assigned to the requesting processor element may remain unchanged by the priority assignment.

<FIG> illustrates an embodiment method <NUM> for implementing starvation avoidance for directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may track wake up statistics for one or more processor elements that have made a lock resource access request. In an embodiment, such wake up statistics may include the number of times the signaling event manager has sent a wake up signal to a processor element, the time at which the processor element was last sent a wake up signal, the elapsed time since the last wake up signal was sent to the processor element, the time at which the processor element made the pending lock resources access request, and/or the elapsed time since the processor element made the pending lock resources access request.

In block <NUM>, the signaling event manager may compare the wake up statistics for a processor element with a pending lock resource access request to a wake up threshold. In an embodiment, the wake up threshold may be a predetermined value, a value based on historical information for the same statistic, or a function of one or more of the values of the same statistic for other processor elements with pending lock resource access requests.

In determination block <NUM>, the signaling event manager may determine whether the wake up statistics of the processor element with the pending lock resource access request exceed the wake up threshold. In response to determining that the wake up statistics of the processor element with the pending lock resource access request do not exceed the wake up threshold (i.e. determination block <NUM> = "NO"), the signaling event manager may maintain the table without changes in block <NUM>.

In response to determining that the wake up statistics of the processor element with the pending lock resource access request do exceed the wake up threshold (i.e. determination block <NUM> = "YES"), the signaling event manager may assign the processor element a higher priority in block <NUM>, and update the table in block <NUM> as described for block <NUM> above. The higher priority assigned to the processor element may be determined numerous ways. In an embodiment, the higher priority may be assigned according to a predetermined rule, such as decrementing the priority by a certain value, assigning the processor element a constant priority (e.g., the highest priority), or inverting the position of the processor element in the priority queue. In an embodiment, the higher priority may be assigned according to a severity of starvation of the processor element. The severity may be determined by a function of the wake up statistics of the processor element as compared to the wake up statistics of the other processor elements. The greater the severity of starvation, the higher the priority that may be assigned to the processor element.

<FIG> illustrates an embodiment method <NUM> for implementing lock aware scheduling with directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may detect that multiple threads are requesting the same resource lock, such as when multiple threads use common resources to execute on different processor elements.

In block <NUM>, the signaling event manager may request the operating system/scheduler to migrate some or all of the threads contending for the same resource to certain processor elements. The signaling event manager may request migrating the threads to certain elements to take advantage of certain efficiencies of different system architectures. In an embodiment, the processor elements may be arranged in a cluster architecture. Selecting certain processors elements of a cluster to execute threads contending for the same resource may maximize performance when the processor elements of the cluster are operating at the same frequency. In an embodiment, processor elements of a cluster tend to be in close proximity. Thermal dissipation may be improved when waiting processor elements of the cluster can be stalled with almost zero power consumption, and the area of the stalled processor elements can be used to dissipate the heat generated by other running processor elements. In an embodiment, the maximum frequency of the running processor elements may exceed the maximum recommended temperature and/or operating frequency when the extra area of the stalled processor elements is used for thermal dissipation. In an embodiment, processor architectures may employ shared portions of memory hierarchy by multiple processor elements, in which case access latency to the memory may be reduced or minimized as priority criteria, and locality increased or maximized as priority criteria in various heuristics. In computing systems that include multiple power sources, priority criteria may be adjusted so that threads may be moved to processor elements using the same power sources while processor elements on other power sources may be reduced in priority so they may not receive threads and therefore powered off. In block <NUM>, the signaling event manager may receive confirmation of the reallocation of the threads contesting for the same resources are reallocated to the requested processor elements. In block <NUM>, the signaling event manager may update the table as described above for block <NUM>.

<FIG> illustrates an embodiment method <NUM> for implementing lock stall actions with directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may estimate the sleep time for a processor element (i.e., the duration that the processor may remain in a low-power state) while in a current wait-for-event state waiting for a requested resource lock to become available. In an embodiment, the signaling event manager may make the estimate based on one or more of historical information, expected execution times for threads on processor elements waiting for the same resource with higher priorities, and the number of higher priority processor elements waiting for the resource. For example, if the processor element has low priority and there are multiple processor elements with higher priority waiting for the same resource, the signaling event manager may estimate that the processing element will have a relatively long sleep time, especially compared to when the processor element has the highest priority or is the only element on the waiting list and thus is next in line to use the resource.

In block <NUM>, the signaling event manager may determine a sleep state for the requesting processor element based on the estimated sleep time. Various embodiments may implement numerous different sleep states for the processor elements. Different sleep states may be characterized by the level of power consumption. Higher power consumption sleep states may provide less power savings but be capable of waking up faster, such as by retain state and working data in volatile memory. In contrast, lower power consumption sleep states may save more power by turning off more resources and powering down memory, resulting in the need to reenergize more resources (which requires power) and reload state data into volatile memory (which takes more time) in order to ramp up to executing instructions. In an embodiment, the signaling event manager may select higher power consumption sleep states for shorter estimated sleep times because the power savings over a shorter period of time may not be worth the loss in efficiency due to having to reestablish the processor element within the system. Similarly, for longer sleep times the signaling event manager may select lower power consumption sleep states because of the net benefit of the greater power savings. In block <NUM>, the signaling event manager may notify the requesting processor element of the designated sleep state for the estimated sleep time. In an embodiment, the requesting processor element may implement the designated sleep state.

<FIG> illustrates an embodiment method <NUM> for implementing lock stall actions with directed event signaling in a multiprocessor system. The method <NUM> may be executed in a computing device using software, general purpose or dedicated hardware, such as the processor or signaling event manager, or a combination of software and hardware. In block <NUM>, the signaling event manager may estimate the sleep time for a processor element (i.e., the duration that the processor may remain in a low-power state) while in a current wait-for-event state waiting for a requested resource lock to become available as in block <NUM>. In block <NUM>, the signaling event manager may notify the operating system/scheduler of the estimated sleep time. In an embodiment, in optional block <NUM>, the operating system/scheduler may remove the requesting processor element from a scheduling queue for a period of time associated with the estimated sleep time. In an alternative embodiment, in optional block <NUM>, the operating system/scheduler may assign a different thread to the processor element during the estimated sleep time, such as a thread that will not require use of the resource for which the processor element received a wait-for-event signal.

<FIG> illustrates an example mobile computing device suitable for use with the various embodiments, for instance, embodiments shown in and/or described with reference to <FIG>. The mobile computing device <NUM> may include a processor <NUM> coupled to a touchscreen controller <NUM> and an internal memory <NUM>. The processor <NUM> may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory <NUM> may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. Examples of memory types which can be leveraged include but are not limited to DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller <NUM> and the processor <NUM> may also be coupled to a touchscreen panel <NUM>, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the computing device <NUM> need not have touch screen capability.

The mobile computing device <NUM> may have one or more radio signal transceivers <NUM> (e.g., Peanut, Bluetooth, Zigbee, Wi-Fi, RF radio) and antennae <NUM>, for sending and receiving communications, coupled to each other and/or to the processor <NUM>. The transceivers <NUM> and antennae <NUM> may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The mobile computing device <NUM> may include a cellular network wireless modem chip <NUM> that enables communication via a cellular network and is coupled to the processor.

The mobile computing device <NUM> may include a peripheral device connection interface <NUM> coupled to the processor <NUM>. The peripheral device connection interface <NUM> may be singularly configured to accept one type of connection, or may be configured to accept various types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe. The peripheral device connection interface <NUM> may also be coupled to a similarly configured peripheral device connection port (not shown).

The mobile computing device <NUM> may also include speakers <NUM> for providing audio outputs. The mobile computing device <NUM> may also include a housing <NUM>, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The mobile computing device <NUM> may include a power source <NUM> coupled to the processor <NUM>, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile computing device <NUM>. The mobile computing device <NUM> may also include a physical button <NUM> for receiving user inputs. The mobile computing device <NUM> may also include a power button <NUM> for turning the mobile computing device <NUM> on and off.

The various embodiments, for instance, embodiments shown in and/or described with reference to <FIG>, may also be implemented within a variety of mobile computing devices, such as a laptop computer <NUM> illustrated in <FIG>. Many laptop computers include a touchpad touch surface <NUM> that serves as the computer's pointing device, and thus may receive drag, scroll, and flick gestures similar to those implemented on computing devices equipped with a touch screen display and described above. A laptop computer <NUM> will typically include a processor <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM> of Flash memory. Additionally, the computer <NUM> may have one or more antenna <NUM> for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver <NUM> coupled to the processor <NUM>. The computer <NUM> may also include a floppy disc drive <NUM> and a compact disc (CD) drive <NUM> coupled to the processor <NUM>. In a notebook configuration, the computer housing includes the touchpad <NUM>, the keyboard <NUM>, and the display <NUM> all coupled to the processor <NUM>. Other configurations of the computing device may include a computer mouse or trackball coupled to the processor (e.g., via a USB input) as are well known, which may also be used in conjunction with the various embodiments.

The various embodiments, for instance, embodiments shown in and/or described with reference to <FIG>, may also be implemented in any of a variety of commercially available servers for compressing data in server cache memory. An example server <NUM> is illustrated in <FIG>. Such a server <NUM> typically includes one or more multi-core processor assemblies <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM>. As illustrated in <FIG>, multi-core processor assemblies <NUM> may be added to the server <NUM> by inserting them into the racks of the assembly. The server <NUM> may also include a floppy disc drive, compact disc (CD) or DVD disc drive <NUM> coupled to the processor <NUM>. The server <NUM> may also include network access ports <NUM> coupled to the multi-core processor assemblies <NUM> for establishing network interface connections with a network <NUM>, such as a local area network coupled to other broadcast system computers and servers, the Internet, the public switched telephone network, and/or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, <NUM>, <NUM>, LTE, or any other type of cellular data network).

Computer program code or "program code" for execution on a programmable processor for carrying out operations of the various embodiments may be written in a high level programming language such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, a Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or programs stored on a computer readable storage medium as used in this application may refer to machine language code (such as object code) whose format is understandable by a processor.

Many computing devices operating system kernels are organized into a user space (where non-privileged code runs) and a kernel space (where privileged code runs). This separation is of particular importance in Android and other general public license (GPL) environments in which code that is part of the kernel space must be GPL licensed, while code running in the user-space may not be GPL licensed. It should be understood that at least some of the various software components/modules discussed here may be implemented in either the kernel space or the user space, unless expressly stated otherwise.

The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented.

The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the various embodiments may be implemented as electronic hardware, computer software, or combinations of both.

The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

Claim 1:
A method for managing processor elements (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) contending for one or more common resources on a computing device (<NUM>) having a plurality of processor elements (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), comprising:
determining a parameter for use in assigning priorities to the plurality of processor elements (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) requesting access to a resource based on an operating state of the computing device (<NUM>);
assigning a priority to a processor element (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) for requesting access to the resource, wherein the priority is assigned based on a comparison of the parameter for the processor element to one or more similar parameters of the other processor elements;
signaling the processor element (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) requesting access to the resource to wait for the resource to become available in response to determining that the resource is not available; and
signaling the processor element (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) to access the resource in response to determining that the resource is available and that the processor element (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) is assigned a highest priority for requesting access to the resource.