iPhone OS 4’s big deal yesterday was multitasking. They announced Seven Services which provide multi-tasking components to developers.
This fulfils pretty much what I was looking for in the iPhone OS: pull and background and goes even further than I had intended. It permits the backgrounding of music apps, VoIP apps, location-based apps and timers (local notifications). It permits apps which have longer processing to background their processing and permit the user to move on to do something else. To be honest, I’ve got everything I wanted.
David Kirk writes:
Following the Apple OS4 announcement today that the iPhone and iPad would be “multitasking” a lively discussion sprang up on Twitter. 140 characters is woefully inadequate for that discussion so hopefully @cimota will post this on his (soon to be) award winning blog.
First let me define my terms and concepts so we can get agreement on our vocabulary. And multitasking and multi-threading need agreement.
A general purpose computer is a collection of processors dedicated to specific functions [program execution graphics, I/O, communications, etc.]
Processors execute [we’ll not get into instruction fetch, operations, etc.] only one instruction at a time, and do so until they issue an instruction that causes the processor to “wait” for the specific completion of some other task (e.g. read / write to complete, packet received on communications line, timer to pop, etc.). If there are no other tasks ready to execute, then the processor itself will wait until it receives an interrupt from the processor handling the I/O or communications or timer. Then the operating system will “awaken” the waiting task, restore its context, and schedule the next instruction. Even non-multitasking OS’s need interrupts (DOS).
Multitasking was designed to take vantage of all those “waits” by scheduling other tasks – that are ready to execute. A multitasking OS, once one task “waits”, will restore the context of another task that is ready, and schedule it for execution. Of course if there are no other tasks ready for execution, the processor will itself wait.
One other wrinkle. Many multitasking OS’s have a priority schedule, whereby certain tasks get priority over others. For example, if a task is receiving bytes from a communications line into a buffer, its probably needs priority to empty the buffer before the next packet comes in else the buffer will be overwritten – so that task may need “priority”. This is implemented in the OS. Once an interrupt occurs, the OS decides if the task running is the highest priority task that is “ready to run”. If not the OS will store the tasks context and schedule the task which is the highest priority.
So, multitasking requires hardware interrupts and a multitasking OS that manages context and administers priority [for all compsc geeks, including the old timers, yes that is a GROSS simplification}.
Multi-threading is a concept that simplifies programming in software systems that support multiple users concurrently. In essence its performs psuedo multitasking between its own threads, but never “waits” or gets interrupted from the OS. An application that performs multi-threading can its – without awareness – be multitasked.
Finally, and to the point of the OS4, the act of multi-tasking (whether or not these are multi-threading or non-multithreading applications, is transparent to the application.
David is right, right down the last sentence. Users don’t care how multitasking is implemented. They really don’t. Back in the olden days on the Mac, people were happy with the simple ‘co-operative multitasking’ that was presented by the Mac and Windows 95 and didn’t cream out for pre-emptive multitasking which came with the Windows NT kernel and (eventually) Mac OS X. They just didn’t care. They cared about the symptoms – that under the co-operative model a single application could block the whole machine and they cared about the lack of protected memory on some of these operating systems insofar as one wrong write to memory could crash the device but in the scale of things they didn’t care. The system appeared to multi-task and that’s what was important. And it’s still what’s important.
Jeff LaMarche writes on the iPhone OS4 multitasking:
I’ve used Android’s “multitasking”, and I think that Apple has been 100% right not to just port the workstation model of “multitasking” to the phone. It’s hard to say how well these new “multitasking” APIs will meet our needs as developers, but the best that I can tell from the presentation, Apple seems to have struck a good balance. Battery life can really suffer with a traditional “multitasking” approach, as I’ve discovered using my Nexus One.
I think this is very valid. We don’t need a repeat of the desktop model on mobile. As long as multi-tasking is transparent to the user, it doesn’t matter which way it is done. And if these measures mean pausing apps which are not currently being used, permitting audio, VOIP services and location services and allowing longer-timed processing to continue, what else is needed?