Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Multithreading Extensions for Mac OS 9? 18

Posted by Cliff from the now-this-would-be-a-good-thing dept.
P-Rod asks: "With Apple reportedly about to announce multiprocessor G4s, many have been asking why they'd do so before OS X is released, since OS 9 doesn't have the multithreading that OS X has. What about a multithreading extension? Apple has been really good at allowing newer products to work with older ones and vice versa. Apple's ultra-smooth transition to the PowerPC chip back in 1994 is a great example. So is the CarbonLib extension, which lets you run Carbonized OS X programs on OS 8.1 and up. Is a multithreading extension feasible?"
This discussion has been archived. No new comments can be posted.

Multithreading Extensions for Mac OS 9? More

Multithreading Extensions for Mac OS 9?

Comments Filter:

  • Re:MacOS multithreading/multiprocessing (Score:2)

    by Anonymous Coward

    For further details of the Apple Multiprocessing API, what calls can be made, what can't, and all the rest of the dirt, try this link (dates from 20 Mar this year, so it's not out of date).

    Technote 1071 [apple.com]

    Is it any surprise that the new (2.1) version of Multiprocessing services was released just before the MP G4's were previewed? I think not.

    Simon

  • Well, first of all, the extension would probably have to implement pre-emptive multitasking in order to provide threads...

    However, classic MacOS uses extra processors differently, essentially (as I recall) letting software that knows about the extra processor(s) take advantage of them by offloading tasks. For algorithms which are not easily parallizable, or programmers that are lazy, this makes some amount of sense -- it allows you to essentially devote a single processor to a single process, and use the other CPU for inconsequentials like displaying the results of the calculations.

    When the system was bought/built/ordered with a specific multiprocessor app in mind (like Photoshop), and a specific purpose, it can work OK. Of course, for end-to-end improvement and responsiveness, pre-emptive multitasking, threading, and SMP are all necessary.

    Since I'm not too familiar with it, hopefully someone else will come along and correct/inform me :)
  • Because it's in a seperate section, "Ask Slashdot." Only the 'big' Ask Slashdot questions get front-page status. All of them are available in the slashbox.

    For /. sections you're interested in, I recommend adding the slashbox for that section and removing the stories from your default page, so you see all of them precisely once on the page.
  • Daystar Genesis MP systems had up to four 200mhz ppc604 processors, The Umax S900, the PowerMac 9500 180MP and the Powermac 9600 200 MP each had two ppc604 processors. It was round about 4 years ago that MP MacOS machines started to ship. There was an extension and a photoshop plugin that allowed programs to take advantage of the extra CPUs.

    The MacOS can use multiple threads right now. Although it's all done through cooperative MT, it does (kind of) work. Through used hardware dealers you can still get MP CPU cards for older PCI macs.

    The bottom line is still this, the MacOS doesn't explicitly support SMP but extra processors can still be used for increased processing power.

    LK
  • Seriously OT, but I figure I should help a little here - a Performa 6116CD will not run LinuxPPC, YellowDog, or any of thos other derivatives - you are pretty much stuck with MkLinux [mklinux.org] as far as I know.

    This is because the 6116 is basically a Power Macintosh 6100 with a different software bundle, and the 6100 is a NuBus Mac, not a PCI Mac [yellowdoglinux.com].

    Sorry to say it, but you are out of luck with YDL and most other distros.

    -Smitty
  • Interesting you should mention that, as it is exactly the reason we still have one of those machines in existence. MacDNS.cait.org is our secondary DNS server, and also handles a little light FTP work for a project we didn't have the time to put elsewhere.

    MkLinux works fine, and I actuially prefer some of it's features to LinuxPPC. (Like the color-coded boot sequence thanks in part to Mach.)

    I certainly wouldn't recommend those machines as a high-traffic web server or anything, but they do make good machines for light serving because of their relatively compact size. Just remember to max out the RAM...

    -Smitty

  • MacOS supports both multithreading and multiprocessing [apple.com] using separate interfaces.

    The multithreading support is a hold-over from the pre-PowerPC days. It provides cooperatively scheduled threads and may only work for M68K code. The multiprocessing support is from the period immediately preceeding the return of Steve Jobs. It was introduced to support the PowerMac 9500/ 180MP [everymac.com] and 9600/ 200MP [everymac.com], which had 2 processors, but it can be used on single processor machines as well. Threads created using multiprocessing services are preemtively scheduled, unlike almost everything else (aside from vertical retrace [apple.com] routines) on MacOS.

    The downside of all three systems (thread manager, multiprocessing services, and vertical retrace manager) is that you are restricted in which OS calls are available to a thread/process/retrace routine. In general, you don't have access to certain parts of your applications memory space, you are not allowed to do anything which might cause memory to be allocated or rearranged[1] and you don't have much, if any, direct access to the GUI (you can calculate all kinds of stuff, but you can't interract with the user).

    What this all comes down to is that you can make use of multiple processors using current versions of MacOS (all versions after at least 7.6 support the multiprocessing services) but the MacOS itself doesn't make use of more than one processor: you need to write your application to specifically use multiple processors. However, you can run multiprocessing targeted applications on single processor machines without any problem.

    1. when MacOS finds that there isn't enough space to allocate a requested block of memory, it will try to rearrange stuff in memory to make enough room. Remember, MacOS dates from a time before transparant memory management in hardware
  • Why are some stories (like this) hidden and accessible only from "Search" page? Some appears on front page later, but some does not (I have not any section/author filters defined).
  • MacOS is not natively thread-aware, but Thread Manager was an attempt to create such processes. I really don't remember much about it - was a big thing back around 7.1 or so. This link [apple.com] seems to have documentation for dealing with it in 8 and 9.

    Hrmm...my browser seems to be caching a lot today :-(.

    ls: .sig: File not found.
  • I was pretty sure that MacOS 8/9 already supported multiprocessing, so I dug around the Apple site and uncovered these links:
  • I think there' confustion between multi-tasking, multi-threading and multi-processing.

    Pretty much, you can think of it like this:
    multi-tasking = talking and chewing gum
    multi-threading = holding a conversation while feeling someone up under the table with your feet
    multi-processing = having two brains.

    Multi-tasking came into the MacOS with Multifinder for System 6 and became integrated with the OS as of System 7. More than one application are open at once, but you only use one at a time.

    Multi-threading was adopted with System 7.5. Background processes and by virtue of the fact that a mail app can check in the background while you're reading a page in a browser. Don't confuse OS-level multi-threading with Finder's ability to multi-thread (SpeedDoubler for System 7.5 and integrated in MacOS 8).

    Multi-processing on the mac started with a few rare protoypes but became commercially available with the Daystar Genesis line of Mac clones. Since MacOS 8, multi--processing is supported but on an application level rather than system wide. Photoshop can make some use of a second processor, but with low efficiency. A system with two G4s - if properly assembled - wouldn't come near two G4 systems running separately.

    OSX should herald a very efficient multi-processing system and a wide availability of multiprocessor configurations. However, nothing short of a Finder rewrite (ala MacOS 8) would really do much to help.
  • Would MKLinux be a decent distro for a web or DNS server, or a possibly a light mail server?

    I'm the sysadmin for a student ACM chapter, and we're using mkLinux on a pair of old Macs for our DNS (including a fair number of domains owned by members). They're a bit on the slow side, but, hey, they're old macs. <g>

    One of them is also running a web server, with a very old and out of date webpage, here [128.220.223.232].
  • I don't know much about MacOS internals or Apple's hardware, but, AFAIK, Macs _do_ support multiple processes, right? (Hopefully this is a rhetorical question). Even if MacOS doesn't support threading at all, you'll probably get fairly significant benefits from SMP. For instance, you can run the OS on one CPU and PageMaker or Photoshop can take the whole of the other one. It wouldn't be as efficient as a well-threaded OS and applications, but you'll still get significant gains. Also, in order to help development of SMP MacOS X, it would probably be helpful to actually _have some of the hardware around to test it on.

    And last I checked, there is a well threaded and efficient OS [yellowdoglinux.org] for PowerPC and G3/G4.
  • Your link is dead; is this [yellowdoglinux.com] what you meant?

    I had thought that the MacOS multitasking, at least, was kind of a kludgey patch. Maybe I'm wrong, but the few times I've been on a Mac lately the only thing that happens when I try to multi-task is that it crashes.

    Threading, I'd have to say definitely not; and while MacOS supports multiple processes, it is truly a kludge that was added on as an afterthought.

    But....I just got a Performa 6116cd from a friend; I'm gonna go ahead now and try to put that there Yellow Dog on it; thanks for the lead! I can't wait to benchmark it against x86 boxen, since the tests I always see are skewed to the point of uselessness.

  • That's the best analogy I've heard all day. Also, possibly the sickest.

    Thanks!

  • Ahh, thanks for the tip... sigh. I was kind of wondering what I could do with the Performa. Any suggestions? Would MKLinux be a decent distro for a web or DNS server, or a possibly a light mail server?

    Anyways, thanks for letting me know! I'm glad I'm not off on some wild goose chase tonight... ;-)

  • Multithreading has been in the MacOS for a long time through a set of APIs called the "Thread Manager". The threads are cooperative, not preemptive. This means you must occasionally call YieldThread() to give time to other threads in the application or to the system. It works surprisingly well, provided all the apps on the machine make an effort to play nice with each other. A single greedy application can prevent any of the others from getting any time (excepting MP tasks, which are explained latter). One real advantage of cooperative threading is that you don't have the same kind of synchronization problems that you do with preemptive threads - a simple golbal variable to indicate a resource in use will suffice. On the other hand, giving other threads/processes time while waiting on I/O requires you to use asynchronous I/O techniques, which are not generally well-understood by most programmers. Preemptive threads and MP support have also been available (via the Multiprocessing APIs) for quite some time, with an important caveat. Until recently, few of the MacOS system calls were reentrant. A mechanism is provided in the API for indirectly calling important functions (disk i/o, etc.) but those were somewhat expensive to use. Still, data-intensive routines that could be parallelized got a big boost from using the MP APIs. MP threads (called "Tasks") are properly scheduled even if some of the cooperative apps/threads are being piggish about the processor(s). MP machines (boxes with more than one CPU) have been available off and on for a long time now, but that's another saga in itself. But only one processor was generally used unless some application decided to employ the MP APIs. Last week Apple demonstrated a two-processor G4 at the developers conference. It is still unknown when these beasts will actually ship. I just know I want one! MacOS X and the Carbon APIs mark a huge improvement in the OS. The kernel is Mach 3 and BSD 4.4. The old MacOS interfaces have been unburdened of much of the cruft from 16 years of evolution, and the surviving/mutated APIs are now dubbed "Carbon". They are reentrant, which means you can actually use the MP threads (aka Tasks) without jumping through hoops. Programmers who can't quite wrap their heads around the synchronization issues inherrant in preemptive-thread programming can still use the ThreadManager's cooperative threads. Regardless, all apps are preemptively scheduled and run in separate memory spaces, so Joe Shmoe's app can't interfere with Jane Shmane's apps.

Slashdot Top Deals

According to the latest official figures, 43% of all statistics are totally worthless.

Close