This article originally appeared in TidBITS on 1992-03-16 at 12:00 p.m.
The permanent URL for this article is:
Include images: Off

Microkernel Mac

by Adam C. Engst

When NeXT or Amiga owners feel the need to disparage the Mac in conversation, they often mention the fact that Mac doesn't have "true" multitasking, tacking a little verbal sneer on the tail end of "true." That generally means that the Mac uses what's called "cooperative multitasking" instead of "pre-emptive multitasking."

I'm telling you this because Apple announced last week that it will be remodeling the Macintosh operating system to add pre-emptive multitasking and other operating system goodies including multi-threading, memory protection, support for dynamic link libraries, and some new I/O (input/output) features that will help peripherals to keep up with the CPU. Why is this good news and not merely propeller-head tech-speak? Well, let me explain what each of those goodies will do for you and then you'll see. For those of you fluent in said tech-speak, I'm aware that I'm over-simplifying. :-)

More multitasking -- Sooner or later, you'll need to figure out the difference between cooperative and pre-emptive multitasking (it's a great way to sound technical :-)). Please keep in mind that different people define this stuff differently. This is a painless-as-possible mainstream explanation.

In a cooperative system, the foreground application cooperates by deciding how much CPU time (the amount of time the microprocessor spends executing useful commands) it wishes to give up to background applications, whereas in a pre-emptive situation, the operating system mediates among the priorities of active applications. For example, on the Mac, Nisus dominates the CPU and doesn't give other applications much CPU time. Nisus gets to make that decision and is perfectly within its cooperative multitasking rights. In a pre-emptive system, every running application has a priority level, and the operating system parcels out CPU time based on those priority levels and the number of applications running.

A difficulty with pre-emptive multitasking is that in an ideal single-user interactive system, the foreground application is completely responsive. (If you click the Ignore button in Word 5's spell checker, you do not want the CPU giving priority to other programs since it's slow enough already!) In a pre-emptive system you can often manually set an application's priority level, but this can be a pain.

That's the advantage of cooperative multitasking - the foreground application can appropriate an ample amount of CPU time to being responsive. Windowing systems on fast Unix machines are often less responsive because the windowing system is merely another application that gets its share of CPU time, no matter how much you may use it. On the other hand, in a cooperative multitasking system, the computer may not work as efficiently because the CPU spends lots of cycles just spinning its wheels waiting for you to do something. For example, I'm composing this article in Nisus, and Navigator was recently downloading in the background. Nisus took so much CPU time that I had to send Nisus to the background so that Navigator could finish the download. If Nisus had been more willing to share CPU time, Navigator could have finished up during some of the extra CPU cycles. If I were using a Quadra instead of our SE/30, the CPU would be running even faster and Nisus would be wasting even more of the CPU's time. Remember, a CPU cycles many times per second, so if priorities are set right, pre-emptive multitasking can work out quite well.

In an ideal world, Apple might use a mixed scheduling technique that would give a lot of CPU time to the foreground application but would allow the operating system to parcel out CPU time to each of the background applications according to their priorities. That would provide fast foreground response while still allowing multiple background programs to do useful work.

Multi-threading -- Multi-threading allows a single application to do multiple things at the same time. Using multi-threading, a spreadsheet could simultaneously print a document, recalculate formulas, and accept data entry. Each task within the application, printing, calculating, accepting data, acts like a little program in a cooperative multitasking system, allowing you to keep working while other parts of the program do other tasks. Both multi-threading and pre-emptive multitasking will be even more necessary when Apple releases voice and handwriting recognition products because the Mac will have to be continually running the recognition code no matter what else is happening.

Kevlar memory -- Memory protection is an extremely useful feature that allows one program to bomb out of sight without disturbing its neighbors in memory, although it's still difficult to completely protect the system heap, since most applications use information in it. That mean that when you hit a nasty bug, such as the one that causes Word 5.0 to crash when using the grammar checker on 68000 Macs, only Word will stop working and all the other programs will continue working properly. As it is now, your machine restarts on that bug, which is a big no-no.

Dynamic link libraries -- When a programmer compiles a program, the compiler will link in various standard libraries to perform certain standard functions, like displaying text on screen. Those libraries are static but fast because they live in the program. Dynamic link libraries are a set of routines that applications can use at runtime rather than include those routines internally. Dynamic link libraries are slower than static link libraries. Like extensions, you could just drop some dynamic link libraries into a special folder and various applications could then use that code, allowing those applications to be smaller, simpler to write, and more similar to each other, thus increasing ease of overall use. If implemented correctly, dynamic link libraries also cut down on memory consumption, since they only need to exist in RAM once, no matter how many applications use them. Dynamic link libraries would be especially useful for companies like Claris and Microsoft, which have multiple applications with similar interfaces and shared features. I believe that dynamic link libraries are already available in Windows, so in this respect Apple is playing catch-up (cleaner than playing with ketchup).

DMA that SCSI! -- The two new I/O enhancements are direct memory access (DMA) and asynchronous SCSI. DMA has been around for a long time and many computers support it, including the Atari ST line. In fact, the Mac IIfx sports DMA in hardware, although it's somewhat useless since the current MacOS doesn't support it. DMA allows devices other than the CPU to read and write memory, thus allowing the CPU to spend more time on other tasks. It's not quite ideal because the CPU does have to check in occasionally to make sure that the right stuff is in memory, but it can significantly boost performance. DMA requires extra hardware as well as operating system support, so most people will need a new Mac to take advantage of it. Asynchronous SCSI requires DMA. When supported though, asynchronous SCSI allows the CPU to delegate a SCSI command to the SCSI controller and then stop paying attention to it and go perform other tasks, again increasing performance. For example, the CPU might tell the SCSI controller to load a sector from a hard disk into RAM. The controller can start this job while the CPU does something else.

When will rumor become reality? -- We've heard that these features will be available at about the same time as the PowerPC machines being co-developed with IBM. In other words, this is all fantasy because by the time the PowerPC machines come out in late 1993, Apple could completely change its mind about all this stuff. None of these ideas are new and many have been around for years in the Unix and mainframe worlds. So the moral of the story is that Apple, as always, is looking for ways to make the Mac into a better machine. In this case, Apple is looking back at standard operating system concepts that it didn't include the first time around. It's also useful to keep in mind that this means that Apple is not putting all its eggs under Taligent's Pink chicken. That's important because in many ways Apple is a software company and cannot afford to rely on another company for such key software. Moral or no, I'm still drooling over this stuff!

Information from:
Doug Davenport of SNAP Technologies

Related articles:
MacWEEK -- 09-Mar-92, Vol. 6, #10, pg. 1