Why isn't Mac OS good at Multitasking? Is it because of the hardware? or Apple engineers can't do it?

How can this be? RISC system supposed to be more superior isn't it?

[This message has been edited by antdesign (edited 12-28-1999).]

[This message has been edited by antdesign (edited 12-28-1999).]

[Heman]

Mac OS has been here for a while, it remains the way it was, And I think this is why people love Mac. As for the Multitasking thing, it is either RISC or CISC thing, nor can't Apple build a good one. it is the problem with compatibility. Remember when introduction of PPC, a lot of 68K software couldn't run on power Mac. software developers have to develop both PPC and 68K version of their software. So as Windows, when the NT came out, heaps of win3.1 software couldnt run on NT.
Building a new OS require a tremendous brian power and capital, and there are heaps of constraints as well such as compatibility, collaboration with other software developer to develop applications etc etc, and indeed, it is not easy, remember the Copland project?
Apple is actually working hard on the OS X that base on the unix, and I think this is the most wonderful thing the computer industry has ever done. Imagine a Mac OS interface sit on top of the most powerful OS Kernel! I just can't wait to try it out. But be patient, When OS X cleint come out, there will be no more post regarding the comparison of OS and NT. people are gonna rush to buy Macs and OS X.

Hope this help.

[Keda]

When the Mac boots, you see a smile. This sort of defines the approach that Mac applications take when dealing with each other.

Macs divide the systems resources by using Cooporative Multitasking. This is a friendly way of doing things, where apps are assigned memory, use it and dont take more than their share. When you set the memory prefs in the 'get info' windows, you are controling this.

The good news is that you dont get 'illegal operation' messages when greedy apps steal all the system resources. The bad news is that an app gets its share weather it is using it or not. If SimpleText and Photoshop are open, and both assigned 40MB of memory, it wont matter that Simple Text is only using 600k. If Photoshop needs 41MB...SOL...that belongs to SimpleText and Photoshop will have to make due.

In OSX(and NT), the Mac will begin to use Preemptive Multitasking. In this model, the CPU is the boss and it issues memory as needed. As a result several Apps can be active at the same time more efficiently since they will only use the resources they need.

Processor speed is not an issue here, neither is RISC or CISC. I just hope they think of a better error message than...'PhotoShop has performed an illegal opperation. It will be shut down imediately"

[drewman]

Heman you have it backwards. The reason that PPC and 68K applications had to be maintained is to keep the people with 68k machines in the mix until they upgraded to PPC.

Apple did an amazing job of allowing 68k applications running on PPC hardware. It was most impressive and got much better over time.

Apple would have to break almost every application to get preemptive multitasking working in the current OS, so they developed another emulation layer like 68k-PPC only it works great since the processor doesn't have to be emulated. Applications will have to be rewritten, but until they are they will still run.

drewman

[Heman]

Yeah, you're right Drewman, but they have to be running in emulation mode. some applications did refuse to work with PPC.

[Misha]

Keda, you seem to be describing more the dynamic allocation of virtual memory under NT vs. Mac OS rather than cooperative multitasking...

The problem with cooperative multitasking is that it essentially only allows one thing to be done at a time. You can have 4 processes going on (dialing up, printing, selecting a file and running an application in the background, for example) but only 1 process can be run at a time. With cooperative multitasking the OS decides which task gets the processing power... most of the time it's relatively seamless; while you're browsing and printing something the Mac needs only to give the printer spooler a split second of time to transfer the data so you don't notice the small hiccup.

With preemptive multitasking (NT, 2000) you can have 4 processes going on at the same time... each uses as many resources as it needs/can.

There are some glaring problems with the Mac OS and its cooperative multitasking... holding down the mouse button, for example, will bring the OS to a grinding halt as 100% of the resources are devoted to that task. Likewise for browsing menus.

Unfortuantely it's these small things that make an OS frustrating to use. We all have grown used to it (except for converts), but I sure will be happy when the day comes when my Mac gets preemptive multitasking...

[Keda]

Misha-

So, I have the names, but not the explanations right? As I understand, OSX will use preemptive. The advantages are plain to see (one of the only things I like about windoze), but how can 'Illegally Operations' be avoided?

There is no reason that mouse and menu items couldn't be handled by cooperative multitasking. They just aren't. With single processor machines any appearance of having more than 1 process going on at the same time is just an illusion. No matter how preemptive one gets, the processor still has to switch back and forth between tasks.
Of course there is overhead associated with such switching... In a cooperative model, the applications themselves get to decide when switching is a good idea, while the preemptive model can seriously degrade performance by imposing willy nilly state changes on the machine irregardless of whether a Photoshop filter action or Word waiting for a keystroke is more processor intensive. The memory management advantages you hold out for preemptive multitasking could also be incorporated in a cooperative model, and in fact temporary memory allocations (process manager zone) have been available in on the Mac since before System 7. Communicating with external hardware also becomes more difficult with a preemptive System; how does an App know that another hasn't changed an external devices state when it was switched out ?
Why try to be good at a BAD THING ? ! ? !
That said, Long live OS X !

[pastusza]

The original question was why Windows was better at multitasking. As much as I hate to admit it, multitsking was kinda hacked into the system software, first with switcher (anyone still remember switcher) and then later with Multifinder. Windows has had multitasking since it's first inception (Windows 286/386). So Windows was essentially designed around multitasking, where the Mac had it inserted later. Windows was originally the OS/2 presentation manager ported to run on top of DOS, when OS/2 sales weren't too good. Since OS/2 did multitasking, so did Windows.

What's interesting is that the Lisa operating system had multitasking in it(preemptive, I believe), and Steve Jobs chose not to include it in the MacOS, because in 1983-84 this was not considered a desirable feature.

And so ends your computer history lesson for the day.

------------------
Andy Pastuszak
[email protected]

Misha wrote-

With preemptive multitasking (NT, 2000) you can have 4 processes going on at the same time... each uses as many resources as it needs/can.

Actually this is not correct. Whether you are using cooperative multitasking or pre-emptive multitasking the processor can only work on 1 task at a time. It is just that the amount of time devoted to each task is controlled by a high level process in pre-emptive multitasking rather than by the currently active process in cooperative multitasking. Pre-emptive simply provides a better user experience as well as a more efficient use of processor time.

Personally, I find that the Mac's multitasking usually performs about the same as the PC's. I don't pretend to have any inside information about how the Mac multitasks, but I understand the differences between preemptive and cooperative multitasking, and they both have advantages and disadvantages.

In cooperative multitasking, once an application gets the processor, it pretty much runs until it hits a breakpoint, at which point it returns control to the system. This pays off very well because when applications are idle (as most computer processes are) then they return control to the system immediately without wasting any clock cycles. However, when a cooperative app hangs, the rest of the machine hangs too, until the user breaks out to the operating system. And a poorly-written app can hog the processor by trying to get too much work done between breakpoints.

With preemptive multitasking, the system interrupts each app on a schedule. Even when a program hangs, the system will switch to the next app on schedule, so the other programs continue to run. This is usually seen as the best reason to use a preemptive scheme. However, there's a lot of overhead in swapping out machine states as the system rotates the processor through the different apps. Also, an idle program gets a full timeslice whether it needs it or not, which can create wasted clock cycles while other programs have work queued up.

Fortunately, the preemptive system usually allows the user to give higher priority to certain applications in the form of bigger, more frequent timeslices. Such a bias is often given to the current "foreground" app. It's important to note that while most preemptive systems have provisions for this kind of tuning, desktop users rarely adjust these settings, so it's hard to place much importance on it as a factor in choosing one scheme over the other.

As a systems person, I usually favor preemptive designs. But with an understanding of cooperative multitasking, I believe it to be adequate for single-user desktop systems, and hardly as inferior as most techies would suggest.

------------------
Rick Koch, MCSE
My personal computer is a Macintosh.

[This message has been edited by RickK (edited 12-31-1999).]

Actually, under a decent preemptive system, idle processes do *not* get a full timeslice, assuming they're written competently. Processes can call a sleep function, which will hand off the remainder of their timeslice to another process. Also, on any decent system, a process that is stuck waiting for something (hard drive, network, etc.) will lose its timeslice until it's ready to continue.

[cfoster611]

I think some of you guys are confusing memory protection and multitasking.
For light on this issue, I refer to the great hall of impartical mac info, MacKiDo.
Dojo:Scheduling Basics(intro to multitasking) http://www.mackido.com/Software/Scheduling.html
Dojo:What is Memory Protection http://www.mackido.com/Software/what...rotection.html
Myths:Stability http://www.mackido.com/Myths/stability.html


[This message has been edited by cfoster611 (edited 12-31-1999).]

[Jablabla]

The Mac OS has cooperative threading and its bad. Only one process at a time can execute the toolbox code. That is, the tool box is not reentrant. So, one process can execute the code at a time.

Usually good Mac programs yield to each other. Program A gets time then yield to program B. And vice versa. It appears they are both running at the same time. Thus, they all run and everyone is in harmony. But then one program comes along and does not yield. The system then appears stuck. For example the one program that the windows guy did as a quick port.

In a preemtive OS the OS forces each program to yield. So, one badly coded program can't screw up the entire system. UNIX and Windows are preemptive systems. The Mac is not.

Cooperative threading also makes it difficult to write 3rd party multimedia software. Since, if another program does not yield often your video will skip or audio will gap. Thats why they usually will recommend not running other programs at the same time. Guess QT can get around this because they have the keys to the OS itself.

So, for OS X they are rewriting the toolbox to make it reentrant and calling it Carbon. All Mac apps that link against carbon will get preemptive tasking! Ya Boy!

The people who usually tout cooperative threading are typically old mac die hards. Just tell them to goto hell.

[Paul Crawford]

Hi all:

Just my penny's worth... I agree wholeheartedly with those who're pointing out the distinction between memory allocation/protection and task/process/thread scheduling. These two issues are indeed largely independent.

OK, in terms of scheduling... As for whether WinNT (or Win2000 beta) is "good" at multitasking compared to Mac OS 9, your mileage may vary depending on your specific tasks. As others have mentioned, it is true that the great Achilles heel of cooperative scheduling is the fact that the entire OS can be brought to a halt by any thread/process which fails to call GetNextEvent (or any other of the routines that "yield"), including threads within the OS itself. However, a preemptive algorithm is not necessarily a panacea either; as others have also pointed out, the yielding problem can creep into preemptive schemes, precisely as a result of "fine tuning" for performance reasons.

Anyone who has ever programmed more than a couple of concurrent threads in Windows NT 4 knows that achieving robust performance involves taking great care in setting each thread's priority level, etc. (And let's not even get into other related API issues such as the possibility of resource deadlock due to poorly-written semaphores or critical sections, etc., especially regarding DLL entry point routines.) It's also important to avoid running anything in the Win16-compatibility (WOW) layer, as far as possible. The WOW layer is supposed to be an independent subsystem, but in practice a rebellious cooperative task can still bring NT to its knees. (This is similar to the old problem in Win9x where the GDI layer was not preemptive; any task that failed to exit properly from its Paint Event handler would also lock up the entire Win9x system.)

Which brings us to another interesting issue, viz., task levels. Not all tasks are fully preemptive in NT. Poorly written tasks that spend most of their time running at interrupt level (drivers, etc.) can also reduce the NT kernel to tears. As long as the kernel allows certain non-kernel tasks to run in so-called "supervisor" mode, NT cannot claim to have a fully preemptive scheduler. Unfortunately, some of these evils are necessary in the name of performance or backward compaibility with older drivers; for instance, who wants to deny a video driver uninterrupted/accelerated access to VRAM during critical screen blits, or to deny a card driver uninterrupted DMA access to RAM for a critical bus I/O operation, regardless of how buggy these drivers may be?

Only time will tell whether the forthcoming Mac OS X Client (and its Mach kernel + BSD Unix shell) will avoid some of the mistakes made by other desktop OSs. However, the long list of fixed and outstanding issues in the current Mac OS X Server would give anyone pause. For example, see Apple's own TIL, #60124 [Mac OS Compatibility (MacOS.app or the "Blue Box") v2.2 Release Notes], or #59005 [About Mac OS X Server 1.0-2 Update].

As Apple, Microsoft, Sun, AT&T, U.C. Berkeley and others can testify, it's not so trivial to write a multitasking scheduler that is both stable and responsive across a wide range of tasks, at all task levels. Recall that, after decades of thorough debugging, even IBM's rock-solid mainframe OS (OS/390 or MVS) is not totally immune to problems. Well, as a longtime Mac user & programmer (ever since the Mac 128K back in 1984), I can only wish Apple all the best in the world in their efforts to develop & ship a solid Mac OS X Client.

[This message has been edited by Paul Crawford (edited 01-02-2000).]

In response to the original question (why the MacOS isn't good at multitasking):

The MacOS uses cooperative multitasking, which was "good enough" years ago when they started writing the thread manager. Cooperative multitasking works just fine in most cases, except one: it's possible, even easy, for a single process (application, for example) to halt the entire system.

In preemptive multitasking, that's not so easy (although it's still possible). Preemptive multitasking works by allowing a single "master" process (a process manager, or the operating system itself) to tell other processes when to start and when to stop and wait for other processes. This way, if one process hangs up, the rest are able to continue uninterrupted.

In cooperative multitasking, each process has to specifically relinquish control of the processor.

The reason the MacOS isn't fully preemptive is simply because it would be a rather incredibly difficult task to rip the heart out of the operating system and replace it with a new one all at once without breaking compatibility with a lot of applications (which users always have a fit about).

Instead, Apple has been gradually wedging preemptive multitasking into the OS. The time manager, for example, allows a process to preemptively execute small pieces of code, and it has existed (mostly unused) since at least 7.5.

The new file dialogs you see in 8.5 and above are a step towards preemptive multitasking; in preemptive multitasking, you can't have dialogs that prevent the user from switching to another process, like the old ones did.

All versions of MacOS X are fully preemptive, although the "blue box" (which is designed to run the old 8.x stuff) isn't preemptive "inside" of itself. Which means that when you start up your "8.5 Finder" in X, any application that you run in the 8.5 Finder can cause the entire 8.5 Finder and any processes it started within itself to hang up. X will allow you to simply kill the 8.5 Finder and start up a new one.

There's neat stuff coming; a little patience will ensure that we get to maintain compatibility along the way.

[dbogdan]

Excuse me for a moment here, folks, but I think I've suffered as case of severe TMI ("too much information").

The question *seemed* simple enough; the answers left me swimming in a wash of terminology and various spins of the concept of "multitasking."

Cooperative vs. Preemptive, multitasking is multitasking in my book. Thanks everyone for sharing their insight and knowledge. I think I just passed "Multitasking 101 for Dummies" by reading all the posts ;-)

So now to throw a little gas on the fire I'm gonna' ask this little bit of info. I recently downloaded a shareware program called "Peek-A-Boo," which from what I can gather from the various posts above accomplishes some sort of enforced "Pre-Emptive Multitasking." within the Mac OS. I've used it to allocated more system resources to my running SETI@home on my iMac, and "souping up" the performance of RealPlayer G2 and Quicktime 4.03 when they're running alongisde other programs. It seems to have stabilized my overall system performance, and I notice a significant increase in performance in the various programs when they're running.

Am I just on some sort of self-induced delusion about this program and what it's doing, or am I correct in asserting that Peek-A-Boo seems to be enforcing a more orderly multitasking paradigm upon and alongside of my Mac OS (which by the way is OS9)?

If anyone can jump in here and clarify for me/us what Peek-A-Boo is doing and how it relates to Cooperative Multitasking or Preemptive Multitasking, I'd be very grateful. We've all heard so much hoopla about the Multitasking thing that I'd love to shoot through the smoke to get to the truth.

By the way...

In all honesty, I *thought* that the Mac OS had been multitasking (preemtively or cooperatively) wonderfully for years...


------------------

[Jablabla]

One more thing...some might suggest interrupt time is similiar to thread preemption. That is, a program can set up an interrupt handler that gets called at a specific time interval.

The program can set flags and do some processing at interrupt time. But you cannot move memory. And you cannot call most toolbox calls. Since, the tools box calls might move memory. They are not reentrant.

So, programs are extremeley limited to what they can do at interrupt time. And ultimately, are limited to the execution of the cooperative thread which can be blocked by another un-cooperative thread.

[Paul Crawford]

Hi again:

Here's another penny's worth, regarding the 'Peek-a-Boo' software mentioned by dbogdan...

First, sorry to be taking up so much bandwidth, but I'd like to provide just a little more background info & clarification from Apple regarding Mac OS's "official" multitasking capabilities, at least as far as my imperfect knowledge goes. [Please bear with me as I'll try to keep this brief, but multitasking is unfortunately quite a complex topic. :-( ] As Cattywampus and others have noted, Apple has indeed been introducing preemptive multitasking capabilities into recent Mac OS releases (originally with an eye toward the short-lived "Copland" OS, but these days looking ahead instead to Mac OS X Client). In the current Mac OS schema, the preemptive multitasking feature (for scheduled tasks) and the MultiProcessing feature (for multiple CPUs) are very closely intertwined. According to Apple, even if only one CPU is available, the MultiProcessing (MP) API nevertheless allows the OS to perform preemptive scheduling for any tasks that are created programmatically via the MP API; however, all other normal processes/tasks still run cooperatively within a single "Mac OS task" that is itself preemptively scheduled just like any other MP task. [BTW, Apple does provide good conceptual overviews of Mac OS's multitasking environments, both cooperative and preemptive; e.g., see Inside Macintosh: Processes / Chapter 1 - Introduction to Processes and Tasks and Adding Multitasking Capability to Applications Using Multiprocessing Services.] Finally, note that if (in the cooperative model) we do insist on using a low-level driver to simulate preemptive scheduling, it is actually possible for an interrupt-level routine to perform normal task-level processing, albeit in a roundabout way; see Apple's TechNote #1033.

Whew, now that the official stuff is (mostly) out of the way, let's take a look at "unofficial" preemptive multitasking capabilities, such as those implemented by the Peek-a-Boo application and its companion 'PaB Special Extension' extension... Well, without disassembling the code (or peeking at it via ResEdit), only the author really knows for sure. ;-) Hmmm, even in the cooperative model, I suppose it is possible to adjust the "time slices" (sleep intervals) for each task. There are at least two ways to do so:-

• Use the standard GetNextEvent (GNE) filter mechanism. A GNE filter would allow, say, an extension task to override the event records that other tasks receive from the two major standard event-handling API routines � viz., 'WaitNextEvent' and 'GetNextEvent'. In combination with a separate (and complicated) re-timing mechanism, this may be enough to do the trick. (For details on GNE filters, see Apple's TechNote #1060.)
  
• Patch 'WaitNextEvent' itself (only if we're really brave!), so as to be able to directly manipulate any requested sleep intervals. (Actually, according to ResEdit, Peek-a-Boo may be taking this second approach.) Note that 'WaitNextEvent' not only retrieves events for the current task but also internally allows the Process Manager to assign time to other tasks. ['WaitNextEvent' receives four parameters, the third of which specifies a sleep interval during which the Process Manager can schedule other tasks; for detailed semantics, see Inside Macintosh: Macintosh Toolbox Essentials / Chapter 2 - Event Manager / Using the Event Manager / Processing Events.]

There have also been other utilities that perform similar pseudo-preemptive tricks; e.g., old standbys such as Menu Tasker 2.0.1 or Respond! 1.0.1. Unfortunately, neither utility works properly with Mac OS 8.5 or later, but source files are available for the latter utility. From a brief examination of Respond!'s sources, we can see that it installs a GetNextEvent filter proc, along with dynamically-patched versions of standard Toolbox/API routines such as 'MenuSelect', 'DragWindow', 'DragGrayRgn', etc. In turn, these patched routines call a local 'Multitask' function which simply calls 'WaitNextEvent' to give background time to other tasks (not to worry, the author did remember to detect GNE filter re-entrancy).

Another possible approach to simulating preemptive scheduling might be to make use of the new nanokernel (introduced in Mac OS 8.6). I don't know anthing about it, but perhaps it can be used to force tasks to be periodically blocked/unblocked?

BTW, I tend to agree with dbogdan's observation that the Mac OS does a fairly good job of multitasking (assuming we have well-behaved programs!); I personally think that the lack of memory protection is responsible for at least as many problems (the infamous 'Type 2' errors, etc.) as can be blamed on the cooperative model's limitations. Anyway, 'nuff said... Like a good little cooperative task, I'll now gladly yield to others. :-)

[This message has been edited by Paul Crawford (edited 01-10-2000).]

[Jablabla]

Interesting thoughts about patching event manager traps GetNextEvent and WaitNextEvent.

Most Mac programs only have 1 main loop that processes the events and typically have the WaitNextEvent/GetNextEvent call in it. But what if the badly written program falls into a loop that does not have a GetNextEvent,
WaitNextEvent or yield call in it? I bet the OS gets stuck. Same problem.

And it gets worse. What if the bad program's loop does not call a tool box call? There is no place to patch. There is no place to put in the yield.

If one is writing programs that will be carbon compatable then you are not allowed to patch traps anyway. So, patching hurts future compatability.

Interestingly Apple's Java VM (MRJ) emulates a preemptive system. So, for the most part loops written in Java will yield under MRJ. Though, they do caution you to put sleeps in the loops if they are tight. I think MRJ's the way to go.

Wow! Thank all of you for posting the extensive amount of info...Hopefully those who don't understand have a better idea now(including me), or else never ask a question like this and wait quietly for OS X... ...

------------------
-----------------------
quantum computers are the ultimate future of processing power!

[Paul Crawford]

Hi yet again,

Yes, I know I promised to yield/sleep for a substantial interval, but the scheduler woke me up and I couldn't resist tossing in a few more comments... Sincere apologies to the original poster, antdesign, if these ramblings are slightly off-topic. :-)

I agree that willy-nilly global patching is an all-too-seductive way of life that perhaps deserves to die a slow (quick?) death, in the name of the Holy Grail of Stability. The moral of the story is that it's probably wise to not become too enamored of extensions like the 'Peek-a-Boo' companion INIT. ;-) As Jablabla indicated, global-patch�happy INITs will be persona non grata in Mac OS X Client, or at least strictly confined to the "Blue Box" compatibility layer.

Regarding Java... Apple does state (in TechNote #1163 for Mac OS 8.6) that MRJ 2.1.1 introduced a "substantial" reimplementation of MRJ's "internal preemptive threading package". I'm no Java expert, so I'm not sure exactly what this means... Do MRJ threads now have the status of MultiProcessing (MP) threads, which are independently scheduled tasks (although they�re rather restricted in that they can directly use only the small subset of thread-safe API routines, which rules out most of the Toolbox)? Or, is MRJ still tied to the Thread Manager's older notion of preemptive threads, which cannot actually be scheduled unless their cooperative host process gets execution time via the Process Manager? If it's the latter case, then we'd be pretty much back to square one...

I'd love to learn whether MRJ allows MP-style preemptive threads today, under classic Mac OS 8.x/9.x (as opposed to Mac OS X Server), but I'm currently too lazy/Java-challenged to write my own test code... I tried searching in the older MRJ SDK 2.1 docs & source files, but couldn't find anything relevant. I also tested the sample Blink applet via the latest Apple Applet Runner 2.1.4, but holding down a menu still brought it to a grinding halt. (I guess that, just as with an MP thread, an MRJ thread can be truly preemptive only if it uses thread-safe API routines exclusively?)

[Jablabla]

Its my understanding MRJ emulates a prepemtive system. The VM executes the byte code. I suppose the byte code is more granural than tool box calls in a typical mac app. Therefore, they have more chances to yield.

Unless the Java virtual machine calls a toolbox call. So, they put locks around the toolbox calls because the toolbox is not reintrant. Same cooperative thread problem.

Now older Java uses AWT. AWT uses the OS to draw the gui. So, AWT on the Mac would use toolbox calls to draw the gui. So, there would possibly be blocking when calling the toolbox.
Which might lead to deadlock.

Swing uses lightweight components. The components draw themselves only through Java. There is no relience on the native OS to draw. So, the gui is consistent accross different platforms. But the trade off is slower performance. Hmm...g4 accelereation...

Anyway, the patch happy inits are trying to emulate a premtive system. Just they have to deal with bigger chunks of code. Not little byte code chunks. So, thier premptive emulation is worse than the Java VMs emulation.

Just my hunch.

[Jablabla]

This link is interesting:
http://developer.apple.com/technotes/tn/tn1153.html

I'm still not sure if the VM itself is preemptive.

[Jablabla]

"This is because MRJ 2.1
threads aren�t really pre-emptive -- they just pretend to be, by time-slicing Java code. They will not
pre-empt while running native code, including the Toolbox. Any individual Toolbox call will run as long
as it wants without any other Java threads getting time, so there�s no danger of another thread re-entrantly
calling the Toolbox."

[Paul Crawford]

Hi guys:

Yeah, I'd seen that TN #1153 (Thread-Safe Toolbox Access From MRJ) also... The interesting thing to me was that it pre-dated the subsequent TN #1163 (Mac OS 8.6) by about three months or so. It's the latter TN's tantalizing mention of the "substantial reimplementation" of MRJ threads in Mac OS 8.6 which prompted my speculations...

The earlier TN #1153 implied that, in the older versions of MRJ (2.1 and earlier), the JVM was still operating within the traditional cooperative model, at least if we view the JVM as the "glue" layer between Java byte code and the Mac OS Toolbox's raw ("native") 680x0/PPC instructions, by way of the host application (as illustrated in Programming with JManager for MRJ 2.1). I think that this compromise had less to do with the granularity of Java byte code versus native code, and much more to do with the non-reentrancy issues that you pointed out before.

Despite the statements made in the later TN #1163 about the more recent versions of MRJ (2.1.1-2.1.4), it seems that the same issues would also affect MRJ 2.1.x's Swing. Isn't it true that an applet's GUI drawing operations must always end up being implemented via the OS/Toolbox routines, regardless of whether these operations are initiated from a JVM/AWT layer or from a "purer" Java layer?

This is why I suspect that even the modern "reimplemented" MRJ threads are still not true MP-style threads. Although MP-style threads are restricted, they are said to remain fully preemptive across at least a small subset of thread-safe Toolbox routines. [On yet another side note, the MP documentation also leads me to believe that the mysterious "nanokernel" and the Mac OS 8.6/9.0 Task Manager (in an MP context) may actually be one and the same.]

It's my impression that even the modern MRJ threads are *never* preemptive across *any* native code at all, whether it's thread-safe or not. But, as I said before, I'd love to learn otherwise. It just might prompt me to absorb much more about MRJ's internals than I had ever planned to at this stage, although I'm not sure that's necessarily a good thing... Like all tasks, I do need my sleep intervals. ;-)

Regards,

--Paul


[This message has been edited by Paul Crawford (edited 01-12-2000).]

[Jablabla]

No I don't think all gui drawing has to be done through the tool box. Ultimately the gui is just an image. So, the porgram just needs to write to a chunk of memory. Then blit the image to the screen.

Just as long as it does not move that memory..he..he..not sure.

Plus, with swing you can switch the entire gui look from metal,motif or mac with with a line of code. Even during runtime. Though, due to legal reasons swing is not allowed be run in its windows gui mode on non windows platforms like the Mac. Wonder how this jives with Aqua?

the Mac OS can do multiple task's all at the same time but the must be small Application's
like running multiple mov's with simple text and Quick draw. . big application's like photoshop are pig's! they want all the cpu power. the small application's can multitask no problem on my 9600/200/603e.
p.s. enough ram help's.

[Paul Crawford]

Hi again,

Regarding the use of offscreen pixmaps & drawing directly to the screen... Actually, even screen blitting is done via ToolBox calls -- e.g., the 'CopyBits' workhorse routine. :-) The only way around this would be to bypass the Toolbox and write directly to VRAM via a video driver or some other interrupt-level code (as indeed is done by certain games that directly access graphics firmware). Supposedly, direct VRAM access is *not* the approach being taken by the modern MRJ JVM (how could it properly share screen real estate with Process Manager tasks that are using the GUI Toolbox)?

On the other hand, the old MRJ 2.1 approach of blindly locking around *all* Toolbox calls would completely eliminate any hope of preemptive behavior for Swing/GUI Java applets. Time-slicing Java byte code wouldn't help in that case, as this would be a native code issue. So, unless the new MRJ 2.1.x's "substantially reimplemented" preemptive threads are in fact hijacking the host machine's RAM/VRAM firmware, they *must* somehow be dealing with the non-threadsafe Toolbox problem. If modern MRJ threads are not adopting the nanokernel/MP approach, then what technique are they using to implement even limited preemptive scheduling across threadsafe Toolbox calls?

[BTW, I should mention that I have an ulterior motive of sorts. ;-) I'm currently trying to decide whether to continue investing my work in native Carbon versus cross-platform Java. Perhaps the best solution is both (i.e., Mac OS 10's Cocoa subsystem)? Also, if enough people are interested in this topic, perhaps we should move the discussion to a new thread, and avoid cluttering up this one...]

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 01-16-2000).]

Does anyone honestly notice a difference between a Windows Box and a Macintosh box trying to multitask?

Windows doesn't have true premptive multitasking because Windows is to stupid to make a distinction between important tasks and tasks that can wait.

Win95 sets "Give priority to front application" as a default. Which as far as i've seen makes it about as responsive as the Macintosh. Ie. The front app gets the cycles.

mind you, if you have 30 apps running on a Mac the ones in the back of the line arn't going to get any cycles, but then again if you have 30 apps running on a windows a Pentium isn't going to be able to drive them all at the same time.