OSNews: http://www.osnews.com/story/23234/Multitasking_the_Android_Way Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Tue, 21 May 2013 19:22:54 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Comment by mtzmtulivu http://www.osnews.com/thread?422030 http://www.osnews.com/thread?422030 the linked page is 404Edited 2010-05-01 19:11 UTC Sat, 01 May 2010 19:11:00 GMT donotreply@osnews.com (mtzmtulivu) Comments RE: Comment by mtzmtulivu http://www.osnews.com/thread?422031 http://www.osnews.com/thread?422031 Just remove the \" from the link Sat, 01 May 2010 19:13:00 GMT donotreply@osnews.com (boulabiar) Comments paradigm http://www.osnews.com/thread?422035 http://www.osnews.com/thread?422035 Nice and verz informative article. I actually believe the need for multitasking as we know it now should be completely eradicated. When you think about it, opening applications is just a crutch designed to obfuscate memory limitation of today's PC architecture. Apps are really just an abstraction, interfaces between user and data. Ideally, user shouldn't even worry about opening an app to be able to work with data. We can get there in the future when there is no difference between short term (RAM) and long term (HDD) memory.

I think that's where Apple (and others, of course) is headed with state-saving on iPhone and dock in OSX, which further diminishes the indication of running/not running applications with each release. Sat, 01 May 2010 19:58:00 GMT donotreply@osnews.com (stooovie) Comments RE: paradigm http://www.osnews.com/thread?422039 http://www.osnews.com/thread?422039 That's just wrong.

Multitasking has very little to do with memory (albeit memory management might be required) and everything to do with concurrency of processes - i.e. faking concurrency by interrupting program execution every now and then to let another process use the CPU(s) for a while.

And yes - it does context switching - but that is not necessarily the same as memory management. Sat, 01 May 2010 20:29:00 GMT donotreply@osnews.com (pel!) Comments RE: paradigm http://www.osnews.com/thread?422043 http://www.osnews.com/thread?422043 This concept of unified Memory for both RAM and HDD is not new, in fact is has been practiced for years in IBMs Minis: http://en.wikipedia.org/wiki/IBM_System_i#Features Sat, 01 May 2010 21:32:00 GMT donotreply@osnews.com (oreissig) Comments RE[2]: paradigm http://www.osnews.com/thread?422046 http://www.osnews.com/thread?422046
Multitasking has very little to do with memory (albeit memory management might be required)

That's exactly the point, as mobile devices are low on RAM and do not have suitable storage for swapping/paging as larger computers do. So memory management IS key to serious multitasking on the phone. Sat, 01 May 2010 21:34:00 GMT donotreply@osnews.com (oreissig) Comments RE[3]: paradigm http://www.osnews.com/thread?422078 http://www.osnews.com/thread?422078 By that logic Amigas did not multitask. Sat, 01 May 2010 22:46:00 GMT donotreply@osnews.com (Earl Colby pottinger) Comments RE[2]: paradigm http://www.osnews.com/thread?422083 http://www.osnews.com/thread?422083
That's just wrong.

Multitasking has very little to do with memory (albeit memory management might be required) and everything to do with concurrency of processes - i.e. faking concurrency by interrupting program execution every now and then to let another process use the CPU(s) for a while.

And yes - it does context switching - but that is not necessarily the same as memory management.


How assigning order of precedence to each process is now being coined as faking priority seems rather odd.

Concurrency of threads per process, now that's an even finer grained process methodology. Sat, 01 May 2010 23:01:00 GMT donotreply@osnews.com (tyrione) Comments RE: paradigm http://www.osnews.com/thread?422165 http://www.osnews.com/thread?422165
Nice and verz informative article. I actually believe the need for multitasking as we know it now should be completely eradicated. When you think about it, opening applications is just a crutch designed to obfuscate memory limitation of today's PC architecture.

What is the link between multitasking (having several apps running seemingly at the same time, crucial for any modern computing) and opening apps (which means, I suppose, loading them in main memory) ?

And why would opening apps be bad ? Do you want to keep everything running in the background permanently ? It would require an insane amount of memory to get everything properly on a computer where the whole Adobe Creative Suite plus Windows Vista plus Cubase are installed, as an example. And if you use swap space, you effectively go back to the need of loading the app from the HDD (and hence will experience lag and everything).

Do you think that main memory is going to be large enough that we won't need slow but large memories someday in order to hold all apps in the average computer ? I don't see that happening at the moment, because at least until now, each time computer RAM increased, software got more bloated in order to fill it, in an amoeba-like fashion... But who knows, those MRAM and memristor things could change the computing world as we know it...

Apps are really just an abstraction, interfaces between user and data.

No. It's this illusion of user-data interface and the unified "data" model coming with it that is an abstraction. Apps are needed at a core of an OS, in order to separate various pieces of work. It allows countless Good Things, including better security, bug prevention, hardware allocation to one task at a time, and so on...

Ideally, user shouldn't even worry about opening an app to be able to work with data.

Yes, maybe the unified data model should be pushed even further. Even though doing so works only when you make the assumption that all applications live to work with user data (A model which has some limitations when you have modern computing in mind : What about games ? What kind of user data do they operate on ? Same for web browsers ?)

But would it catch up or not, I think that apps (processes) will continue to exist at the core of an OS as a developper abstraction for a long time. It's a rather simple abstraction, and it works damn good. It's like threads : everyone seems to hate them, but I did not encounter an Occam-compliant replacement yet...

We can get there in the future when there is no difference between short term (RAM) and long term (HDD) memory.

Well, consider computing a long time ago. HDD were 20 MB large and it seemed huge. If we continued to make applications like on those days, the 2 GB of RAM that most modern computers have would be huge, and would allow one to keep everything in RAM and only store saved data on non-volatile memories.

Sadly, it didn't happen. Instead, every time RAM did grow bigger, software got bloated enough to fill it, in an amoeba-like fashion. DOS fit on a few dozens of KB of memory, now Windows XP takes hundreds of MB and its successors even more, though the purpose of operating system (help user to safely play with data and apps and help developers to code said apps) did not change that much. And let's not get me started about Steinberg and Adobe software compared to their freeware counterparts (if any).

Even if something as fast as RAM and as large and nonvolatile as HDD/SDD appeared someday, it will stay expensive and unreliable for ages. During this time, RAM would have got larger and faster, software would have got ten times bigger, and the old organization would take place again. At least that's how I see it.

I think that's where Apple (and others, of course) is headed with state-saving on iPhone and dock in OSX, which further diminishes the indication of running/not running applications with each release.

Saving state cannot be applied to everything, mostly because...
-> Storage memory is incredibly slow. If you have 10GB of apps running in memory + swap, saving it when the machine turns off and loading it when it turns on will take several minutes, which is unacceptable.
-> Endlessly saving state is not good for cleanness. Of course, in an ideal environment where bugs and memory leaks wouldn't exist, it would be fine. But human specie is not ready for bug-free coding. If there's a memory leak somewhere, memory usage of the OS will gradually increase, to the point where the whole software will fill the entire RAM and swapping will occur, leading to major performance loss. Sometimes, it's good to close all data, turn of the computer, and go back to a "clean" state, instead of always keeping some mess around in main memory... Sun, 02 May 2010 06:44:00 GMT donotreply@osnews.com (Neolander) Comments RE[2]: paradigm http://www.osnews.com/thread?422185 http://www.osnews.com/thread?422185 -storage memory +nonvolatile memory
I must have fell asleep for a second... Sun, 02 May 2010 10:16:00 GMT donotreply@osnews.com (Neolander) Comments RE[2]: paradigm http://www.osnews.com/thread?422224 http://www.osnews.com/thread?422224 I know all that, Neolander ;) I was talking about user interaction paradigms as a whole. Sun, 02 May 2010 15:01:00 GMT donotreply@osnews.com (stooovie) Comments Battery Life http://www.osnews.com/thread?422245 http://www.osnews.com/thread?422245 Of course what they don't happen to mention is that googles method for multitasking also sucks down battery like a fat pig sucks down slop.

If I as a user say "close the email program" but then the email program just sits there running checking for email every few minutes for the next few hours and my battery is then dead, there's only one thing to blame going wrong. Poor multitasking management.

Google may think software can do a better job, and maybe it can, but it certainly isn't doing a very good job yet even as of android 2.1. Perhaps instead of just simply taking memory in to account for the lifetime of a process/application they should take in to account the battery situation and allow me to set some desired battery life. If I want maximum battery life and am willing to put up with a little bit slower app startup times that should be allowed. Sun, 02 May 2010 16:32:00 GMT donotreply@osnews.com (TheMonoTone) Comments RE: Battery Life http://www.osnews.com/thread?422267 http://www.osnews.com/thread?422267
Of course what they don't happen to mention is that googles method for multitasking also sucks down battery like a fat pig sucks down slop.

If I as a user say "close the email program" but then the email program just sits there running checking for email every few minutes for the next few hours and my battery is then dead, there's only one thing to blame going wrong. Poor multitasking management.


Agreed. And to me, that sounds like an argument in favour of the "old school" UNIX (and BeOS) way of dealing with mail. Rather than a single end-to-end "MUA" application, you'd have at least 2: a viewer/reader application, and a daemon that would handle the actual communication with the server(s). So instead of having a full-fledged MUA running 24/7, all you need is the mail_daemon.

IMO, that's one of the most interesting aspects of handheld devices/platforms: the hardware limitations are leading to the re-discovery of concepts that were previously abandoned as "old-fashioned". Sun, 02 May 2010 18:39:00 GMT donotreply@osnews.com (StephenBeDoper) Comments RE[4]: paradigm http://www.osnews.com/thread?422404 http://www.osnews.com/thread?422404 In games/demos they're not. Because there was no room in memory and CPU resources for both OS and games. Mon, 03 May 2010 14:23:00 GMT donotreply@osnews.com (viton) Comments RE: Battery Life http://www.osnews.com/thread?422581 http://www.osnews.com/thread?422581 Pretty sure you have the option of uninstalling that app.

Why would you ever want a non-realtime OS to starve hardware resources? It should provide meaningful trace/report information so users know which app is causing the load, provide users a way to terminate misbehaving apps, and provide a interface to allow apps to release non-essential resources during scarcity, but that's about it.

Android and iPhone "multitasking" don't deserve the term. It's a marketing ploy by non-technical bimbos to apply a well-known technical term to something that clearly isn't.

WebOS, Maemo/meego and Blackberry all do a much better job of providing true multitasking. Tue, 04 May 2010 06:12:00 GMT donotreply@osnews.com (shawn.butler) Comments Comment by henderson101 http://www.osnews.com/thread?422633 http://www.osnews.com/thread?422633 I don't really have time for Android, but as Dianne Hackborn wrote the article, it got read :-) Tue, 04 May 2010 13:27:00 GMT donotreply@osnews.com (henderson101) Comments