iPhone OS is one of the most advanced OS available today – and it s a mobile OS. Using the OS, it is clear to see why mobile computing is the future. When compared to other OSs, the iPhone OS holds it’s own. Broadly, looking at most modern desktop OSs, it has support for nearly everything that one would have available in a “full”, modern OS. It has support for network, full graphics support (video, animation, photos), security, etc. The one thing that it lacks is true multitasking. Let’s be clear though; Today’s iPhone 3.x firmware is a fully preemptive multitasking operating system, but it artificially restricts apps (other than specific ones bundled with the system by Apple) from running in the background.

But why? Apple initially avoided an app model supporting multiple apps running at once to help preserve battery life and simplify the user experience.

So, Apple decided instead to opt for a “compromise”, push notifications to enable third party apps to appear to respond to outside updates (such as incoming messages or news alerts) even when they were not actually running. It would give the “illusion” of allowing 3rd party multitasking by displaying messages to the user when the app needed their attention. Other OSs, such as Android and Blackberry have full support for 3rd party multitasking, at the expense of battery life and perhaps a more complicated user experience.

So what is one to do? After writing the initial draft of this post, the news of iPhone OS 4.0 supporting multitasking came out a few days later. But, I don’t care about rumors – I want results. Just as in “Jerry Maguire”, show me the money. Oh, and for the sake of argument, let’s assume that our hardware is a single processor and our OS is using kernal threads and round-robin scheduling.

First, let’s consider the model for most modern OS and how they implement multitasking. Multitasking is actually a simple slight of hand. A process is simply an instance of a program or executable that is mapped into memory. We all know that we can have multiple programs or processes running at a time. But does the computer work with all the processes all at the same time? No. Similar to how a human works and processes information, a processor works with whatever data it is handed, but is only capable of working with particular process at a time. The processes are scheduled in a round-robin queue and when their turn comes up, they get a small piece of time with the processor. After their time, or quantum, expires, or the process blocks, the process is removed from the running context and placed back in the queue to wait for their turn again. This context switching happens so fast that a normal user cannot tell that this is the true model of what is happening and they believe that all programs are executing concurrently, as in the processor sharing model. The model described above has a whole array of issues relating to memory management (including page faulting), security and protection. The model I would like to describe below would have the same issues, but I will only talk about security and protection.

Armed with a very basic idea of how processes work, how can we adapt this to a more mobile OS? What are the areas that we can adjust.

QuantumBAD
First, we can adjust the quantum, so there is less overhead associated with servicing each process and hence less power consumption. But Is this a good solution? Absolutely not. Quanta that are too short cause unnecessary thrashing with all the context switching that is occurring and if in an extreme case, the time servicing a context switch, may be longer than the actual time the process receives from the processor. What about variable quanta? Not a good idea either. The process would receive non-uniform amounts of time, making scheduling more difficult and perhaps a “jittery” response in the UI.

SchedulingBAD
What if we change the type of scheduling we do? What if we try FCFS (first come, first served) or SJF (shortest job first)? That is not a good solution either because with FCFS, the process will continue to run and hog the processor until it is finished and in the case of applications, they will never finish until the user terminates the app. However, the solution proposed will draw inspiration from this category.

NotificationBAD
What if we eliminate the context switching and interrupts? We can set bits to indicate the app needs service. This idea is the absolute worst of them so far. What happens if two background applications request OS services in the same off round-robin cycle. If you proposed using shared memory for notification, you just lost an “interrupt.” What about not using shared memory? What a pain! Now you have to setup dynamic data structures for each app that runs and terminates. Ok, enough with the freshmen ideas. Are you ready to have a heap of knowledge dumped on you?

Let’s revisit the scheduling idea and draw inspiration from a multi-level feedback queue. In this proposed solution, there would be the same blocked and ready queues that any scheduler would have. However, there would be a foreground queue and a background queue. The foreground queue would contain the currently “focused” app, i.e. the process that the user is actively using. The background queue would contain all the remaining ready processes. The foreground queue would receive processor cycles as normal and the background queue would receive a fraction of the cycles to the tune of 1/n processes, with n capped at some upper bound to ensure that all processes still receive decent service. Giving the background processes some processor time ensure they can still continue to work. When the user wants to switch to a different process, the foreground process is removed and placed in the background queue. The rest of the process paradigm would stay the same, where a process could interrupt and request services from the OS

There are security implications of allowing multiprocessing on the iPhone, and the major one is security and protection. When the user presses the home button on the iPhone, the application receives a delegate message from the OS, applicationWillTerminate. From that point, the application has 5 whole seconds to exit, before the OS steps in and kills the process. With multiple processes, we now have to consider how multiple apps will behave together. Obviously the iPhone OS implements a virtual address space, so that separate processes have separate chunks of transparent memory. However, some additional security measures might need to be taken so that other processes are unable to access anything but their own VAs.

As much as I wish I could test this hypothesis, I can’t because I have no access to the iPhone firmware. So I will leave it up to the folks at 1 Infinite Loop, but this is just my .02.

« »