Windows Phone 7 multi-tasking and computer processing primer

I know guys, I haven’t written much if anything lately, and even less about Symbian lately (partly because I no longer use it and thus can’t speak much to its merits in the present tense) but one of  the common criticisms that was leveled at iOS when it introduced its version of “multitasking” was that it was “fake”. That is, third-party applications could only run in a few, very limited instances, an approach supposedly taken in order to “Preserve battery life”. While there’s a ton of merit to this statement, the exceptionally limited circumstances under which applications could actually be allowed to run in the background is a little restrictive to anyone using Symbian.

Android, much like Symbian allows most applications to run completely in the background and while this allows us power users to get the most out of our devices and use cases, it’s more than a slight annoyance to have issues with rogue programs running off with precious resources and leaving foreground tasks to either grind to a halt, crash outright or inundate us with low-memory errors (something S^3 went a long way towards fixing I’ll admit). In Android’s case, the OS supposedly “handles” memory and CPU usage itself and kills apps when resources run a little low. That’s all well and good but user control and granularity are important to power users and we’d prefer not having to dig through menus in the hopes of killing something that we don’t want running. The common message however is that for power and battery reasons multitasking has to be significantly managed either by the OS itself or limiting the API’s available to devs. It’s not really debatable that as a general rule Android devices have (in the past) had barely passable battery life and  Symbian while generally considered the best in the battery life stakes can suffer similar problems if the wrong app is left running (remembers bad experiences with Fring).

Windows Phone 7’s multitasking mantra with the upcoming Mango update seems rather similar to iOS on first glimpse, some applications (likely a decent majority) will simply save state to the RAM or ROM and that’s that. When needed they’ll be brought back up. A “feature” called “Fast-App switching” in modern parlance. But what happens if you’re running an IM client, a VOIP application etc or even an application like twitter that you want to update your feed every once in a while or a feed reader that leaves a little notification when your favourite site puts up an update. That’s rather hard to do without some degree of multitasking don’t you think?

Other, undescribed use cases can likely pop up that users may not be aware of but developers will absolutely need in order to create highly functional, interactive and context sensitive applications for end users. At the same time, it’s likely highly unnecessary to run the full code of an application in the background at all times even when it’s not in the foreground. That will, for obvious reasons slow down and/or interfere with the application you’re actually focusing on and interacting with no? Microsoft have thusly come up with what is to me an ingenious way to allow both background processing and all the associated functionality while being very frugal with resources.

Of course, before beginning it’d be prudent that we ALL come to a common train of thought regarding multitasking and what it entails. First and foremost, up until recently (circa 2009) with the advent of ARMv7 based processors like Snapdragons, OMAP3’s, Samsung Hummingbird’s etc, mobile CPU’s could fetch (take in) and dispatch (output) ONE instruction per clock cycle. That’s not to say that there was no parallelism involved such as offloaded specified tasks to certain other processors but the CPU itself could only take in one instruction per clock cycle. The lower the clock speed of the processor, the less instructions it can process at a single time. Current ARMv7 processors based on the Cortex A8 design can process at most 2 instructions per clock cycle (taking in 2 instructions and outputting  2 others) while even newer processors like the Cortex A9 designs range from 2-4 instructions per clock and possibly more dependent on the number of cores available at any given time.

Dual issue processing pipeline

Knowing that, how in the world could we have possibly run multiple applications at once if those dreaded ARM11’s can only perform a single task at once?!?   The main way in which we (the users) are made to believe that multiple things are occurring at the same time has to deal with schedulers and thread/process priority. The former is an intrinsic part of the operating system kernel that controls which instructions are carried out by the CPU at any given point in time. The latter determines which processes are given greater significance/time to run on the CPU when compared to other processes. Of course, with this method of processing, if an instruction takes a long time to complete as is often the case, the rest of the system is held up until that process can be completed.

Pre-emptive multitasking allows the kernel to interrupt processes before they reach completion in the event that time and processing constraints are not readily available. There is obviously, a lot of work that has to go into managing processes running, the conditions under which each process can run  and all the fun things that would be required to get that entire system up and running. Creating a GOOD, EFFICIENT, FAST and WELL-ENGINEERED system that  takes a good deal of time, energy and expertise and admittedly, kernel design was likely a big part of why Symbian was as efficient with resources as it was. As with any complex system there will be overhead involved and in the case of pre-emption and multitasking, the main overhead is what is called a context/task switch in which the scheduler determines that a process should be cut temporarily in order to allow another process to run.

In addition, the lower the clock speed, the longer it takes for a given processor to switch between tasks and/or decide which tasks it should run. Worse still is the fact that these tasks take even longer to get completed with the lower clock speed!!! On the OS level (separate from kernel level) there may be even more restrictions on processes running at certain times and this (OS level regulation) represents the crux of the differences in multitasking implementations we see in Android, iOS, WP7, Symbian and WebOS. Editor’s Note: We’ll be following up on this post with another explaining the importance of modern parts (including CPU’s) in devices in the coming weeks.

Now that we’re all much on the same page re: Multitasking, processing and all that other fun stuff, Let’s dive in to the meat of this post shall we?

NB. All slides taken from Darin Miller’s presentation on Multitasking in the Next Version of Windows Phone at MIX2011 This first image describes the WP7 application life cycle as of the Mango update.

Applications vary between the active state, running state, the deactivated state, the dormant state and in the event that the application can no longer fit in RAM due to application demands etc is tombstoned and paged out to ROM. When an app is placed in the dormant state, they’re more or less paused; much like in iOS the application’s access to the CPU is stopped and it’s state is saved in the RAM. When called upon again by the OS the application’s access to and utilisation of the CPU  is resumed. Much like iOS there are API’s for background audio, notifications Nothing special right? This however, is where the similarity to iOS ends and the multitasking begins to mimic that seen elsewhere.

Mango introduces an interesting concept known as “background agents”. These agents, as their name suggests act on behalf of the main program in order to carry out specific functionality and tasks while the main application is no longer “in focus”. These agents are written by individual developers to suit their chosen purposes and their own needs albeit, like any managed system, there are/will be restrictions. While the restrictions as present today may be lifted in the future (especially in light of Microsoft’s emphasis on functionality and integration) these shouldn’t pose too much of a hindrance to developers. The abilities of the background agents are detailed in the following image.

Background agents, these small bits of code have access to the important things but aren’t allowed to alter the UI, record information with the microphone and/or camera (no spy apps for you!! 🙂 ) or access the core, powerful API libraries. They can do most of everything else however. Microsoft has also ensured that there are restrictions on how these agents can run at any given time and strangely enough, you don’t have to relaunch every app in order to get their  functionality as agents are carried across reboots. The current browser also preserves tabs across reboots too so you really don’t lose anything unless you ever really want to.

There are, unfortunately, limitations on how many agents can actually run in the background and (for the time being at least) we’re currently limited to 18 agents at any time. The nice touch is, given that these agents start up on boot, utilise valuable resources etc is that they can be controlled by the user on the setting page. Furthermore, agents are only given a license to run for a maximum of 14 days before they require renewal. In essence, if you don’t use the application for 2 weeks, the agent will stop running and you don’t have to worry about that consuming your resources while you remain unawares :).

The agents are also broken into two categories, “periodic” and “on idle”  though developer applications can contain either or both of these. Periodic agents are run in periodic intervals of 30 minutes for 15 seconds apiece one after the other when the screen is on but pretty much in parallel when the screen is off. If the user is running 10 applications that require agents, you’ll have a situation where every half hour your apps may poll the CPU or network for 2 1/2 half minutes to cache information, sync data, check message servers etc. What wasn’t made absolutely clear was whether the applications are all on a single schedule or whether they’re independent in their polling (personally prefer the latter).

“On idle” are somewhat different and may depend on conditions like external power, Wi-Fi access etc, time of day ,etc. When triggered, and when all conditions have been met, these agents can run for up to 10 minutes at a time. Use cases for this sort of  agent would be to load all your favorite web pages, download your entire twitter feed while you sleep and your phone is charging, update your RSS reader, sync wirelessly with your PC for music, PIM etc.   While the screen is on, and the user is interacting with applications in the foreground, background tasks are limited to 5mb of RAM and ~10% of non-system required CPU time. When the user is not interacting with the device, the RAM limitation seems to remain but there’s no mention of the CPU restriction being kept at ~10%.

I can’t think of a circumstance that couldn’t possibly be covered by a set-up like this, albeit it’ll mean you can’t watch videos in a browser window AND read a document at the same time but for the VAST majority of users, from a performance and functionality perspective, this’ll cover and exceed use cases.

Coupled with the already existing push notifications framework and a load of battery-saving improvements (likely to be even more prevalent on Nokia devices) I think they’ve achieved what is likely the best compromise between functionality and saving battery life while not making life overly hard for developers.

If all of this reading proved a little too much for you, or you’d rather listen to all of this from the horse’s mouth (so to speak) then the link below.

http://media.ch9.ms/ch9/E54A/2D14FDFD-08CC-45B3-B596-9EB800F6E54A/MIX11DVC18_high_ch9.mp4

Now then, let the Symbian and Maemo comparisons and criticisms begin!!

Tags: featured, Mango, Multitasking, Nokia, Windows Phone 7.1, Windows Phone 7.5

Category: Nokia