Performant runtime pause with no CPU utilization

#When a user executes applications on a desktop computer, multiple applications can typically execute simultaneously without adversely affecting performance. In a device that has limited resources multiple applications running at the same time can quickly deplete resources such as battery power. Often output from multiple applications cannot be displayed simultaneously because of a small display area. Consequently, on these types of devices, sometimes a first application is paused, ended, or is run in the background when the user switches to a second application. However, if the user switches back to the first application, prompt resumption of the first application is often expected.

#A paused application utilizes minimal resources, but when the application is resumed, it becomes responsive quickly because the application is still loaded in memory. It resumes at the point at which it was paused because application state at the time of pausing is saved. In response to lack of user interaction, an application may be transferred from foreground. to background and paused. When an application is paused, the application code stops executing and the application consumes no (zero) CPU (central processing unit) cycles. When the application is paused, functions such as sleep and wait do not timeout and cause a context switch that changes the CPU from a low-power state to a high-power state. When the application is not paused, there is no overhead caused by the 0 CPU usage pause feature. That is, no additional resources are consumed if the application is never paused. When the paused application is resumed, it starts up quickly in foreground at the point at which it was paused.

#After a pause is signaled, the application state can be saved to a permanent store (e.g., in isolated storage). After the paused state is reached, no managed code for the application executes, either in foreground or in background. All executing managed threads of the application are stopped essentially simultaneously. All threads belonging to the application that are in a wait or sleep state are prevented from starting up again.

#In the drawings:

#FIG. 1a illustrates an example of a system 100 that utilizes no CPU cycles when an application is paused in accordance with aspects of the subject matter disclosed herein;

#FIG. 1b illustrates an example 105 of stages of application pause and resume operations in accordance with aspects of the subject matter disclosed herein;

#Overview

#Some known solutions for handling the running of multiple applications on limited-resource devices provide 0 CPU usage when an application is paused but consume additional resources to implement the feature. For example, one way to deliver 0 CPU usage when an application is paused is to create a global flag to indicate that the runtime is requesting a pause. If the flag is set, the code branches to a central function that handles the pause operation (and later handles the resume operation). Operating system primitives can be used to support calls to wait functions including but not limited to sleep functions, functions that wait on a handle, timeouts and timers with specified durations. However, the actual wait is not under the control of the runtime. For example, suppose an application calls a sleep function and requests a sleep for 7 seconds. The program execution manager can forward that call to an application programming interface. Suppose after 4 seconds, the application is paused, causing all the managed threads to be paused. After another 3 seconds the OS sleep function expires and the associated thread returns, utilizing the CPU and causing a CPU usage spike until the native code to managed code transition is blocked by the program execution manager.

#To avoid a CPU spike, a global pausing event can be created at device startup. A timeout implemented by calling a sleep function can be replaced by a timeout that is implemented by waiting for a pausing event handle. When a pausing event is signaled, all the waits can be ended and can be made to wait on a resume event which is only signaled at a resuming stage. A consequence of this approach is that all waits have the overhead described above. This can use extra resources all the time even though the pause and resume condition is typically relatively rare.