TweetFollow Us on Twitter

Spring 91 - THREADS ON THE MACINTOSH

THREADS ON THE MACINTOSH

MICHAEL GOUGH

[IMAGE p06-22_Gough_text_html1.GIF]

Threads are a great way to improve the performance and simplify the design of programs. Apple's Advanced Technology Group developed a Threads Package to implement this programming technique on the Macintosh. This article explains how you can use this package to incorporate threads in your own code.

The idea for the Threads Package arose during the design phase of some scientific visualization software, when we discovered that some of the applications we were working on needed a way to juggle several simultaneous activities. It quickly became clear that the Macintosh run-time environment posed some serious obstacles to anyone wanting to implement threads on the Macintosh. With some effort, we were able to come up with workarounds that made the use of threads with the Macintosh OS relatively painless.

These workarounds are the main subject of this article. After briefly introducing the purpose and mechanics of threads in general, the article presents some specific details of the Macintosh threads implementation as it currently stands. A summary of the functions in the Threads Package appears at the end of the article. The Threads Package itself and several simple example programs can be found on the Developer Essentials disc for this issue.

The Threads Package was developed as a means to an end, and it's by no means the last word on threads for the Macintosh. We welcome any suggestions you may have for improvements.

WHAT THREADS DO

Suppose you want to write an AppleLink ®-like communications program. You'd like to write the program so that while it's downloading a file, it can also print an existing file and allow the user to write a new message. A typical program can perform only one of these functions at a time, displaying the watch cursor until the task is completed. What's needed is some technique for allowing the program to perform these tasks concurrently.

Programmers have often tried to achieve concurrency through the use of idle procs. For your communications program, for instance, you could write the downloading, printing, and text entry tasks as idle procs. While the download procedure is executing, it could regularly call a printing idle proc to send a few lines of a message to the printer. The download procedure could also periodically call an editing procedure to allow the user to enter text for a new message in a window.

But think of the tremendous effort involved in writing the program so that it can switch among these tasks. Every task would have to save variables each time it returns so that it could resume where itleft off. Most complex functions would not be able to contain deep levels of nesting because that would make it impossible to freely return to the caller at any time. In fact, you'd have to divide most functions into inconveniently small chunks so that you could juggle between them. The net result is that the modularity of your program would be destroyed, and you'd have a tremendous programming headache on your hands.

Threads are a much better technique for achieving concurrency than idle procs. When your program uses threads, it's like a mind that can have several trains of thought simultaneously. A program using idle procs, in contrast, is like a mind with a single train of thought that must constantly interrupt itself to attend to side issues.

Note that there's a difference between multithreaded programs and multitasking systems. Multitasking is the ability to run more than one application at once, but each application can still only do one thing at a time. In other words, concurrency is happening at the system level. A multithreaded application performs concurrent tasks within the same program; concurrency happens at the program level. Of course, it's possible to have a multitasking environment in which threaded programs run.

HOW THREADS WORK

When writing multithreaded code, you must let go of old ideas about how the machine executes your program. Instead of a single program counter marching through your code, in a sense you now have many. While the idea of multiple program counters may sound complex, you don't have to relearn programming. You just need to be aware that the main train of execution in a program is itself a thread and that all threads must relinquish control to each other. You also have to remember to share globals and heap objects that you used to access exclusively.

Here's a sample program that shows how simple it is to use threads. The program is a modified version of the ever-popular SillyBalls. Unmodified, the program opens a window and draws colored balls into it until the main event loop detects that the mouse button is down. This new version forks a thread that beeps while the balls are being drawn.

main()
{
    ThreadHandle beepThread;

    Initialize();

/* The InitThreads call initializes the Threads Package, converting
   the original thread of execution into a swappable thread. */

    InitThreads(nil, false);

/* This code forks a thread that beeps 30 times, and then quits. */

    if (InNewThread(&beepThread, kDefaultStackSize))
        {
        long i;
        for (i=0; i<30; i++)
            {
            SysBeep(120);
            Yield();
            }
        EndThread(beepThread);
        }

/* Here's the main event loop. The only change is the new call to
   Yield. */

    do 
        {
        Yield();
        NewBall();
        } while (!Button());

/* This call to ExitThreads waits for all threads to die before allowing
   the program to terminate. */

    ExitThreads();
}

The InitThreads call is made at the beginning of the program. It initializes threads and converts the original thread into something that can be swapped by the Threads Package. Once this call is made, you can fork other threads.

In this example, execution from the original thread enters the InNewThread procedure. Two threads leave the procedure, but at different times. The original thread goes in and is cloned before coming out. A new thread now exists, but it hasn't started execution yet. InNewThread tests whether the current thread's ID is that of the new thread, beepThread, and returns a Boolean indicating the result of this test. It's essentially supplying an answer to the question "Am I running the new thread?" Since the original thread is still the current thread, it returns from InNewThread with a value of false, thus skipping over the code contained in the IF block. It continues execution by entering the main event loop, drawing balls, and calling the Yield function. Each time it calls Yield, it politely gives control to other threads that may want time to execute.

On the first call to Yield, the newly cloned thread returns from the call to InNewThread with a value of true, indicating that this is the new thread and not the original. The new thread enters the block of code associated with the IF statement and begins executing the loop, which beeps and yields 30 times. Each call to Yield exchanges control with the main event loop. The new thread lives out its life within the confines of the IF block. After completing its task, it calls EndThread and dies.

The conditions for terminating these two threads are different: the beeping thread ends after 30 iterations; the original thread ends when the user presses the mouse button. The call to ExitThreads at the end of the program ensures that all threads have completed before the program terminates.

SEMAPHORES

With multiple threads running around in your program, it's possible for them to get in each other's way. The Threads Package provides a semaphore mechanism to help you manage this problem. The problem occurs when two threads compete for a resource. Two threads that are executing at the same time may each want exclusive use of the same device, file, or memory location.

To deal with this situation, you assign a semaphore to control access to this resource. Then, when you write the thread that uses the resource, you always make sure that the thread "grabs" the semaphore. After you're done with the resource, you "release" the semaphore.

What happens if a thread tries to grab a semaphore that has already been grabbed? The thread goes to sleep, waiting in a queue associated with the semaphore. When the semaphore does become available, the sleeping thread wakes up with control of the semaphore, completely unaware that it had to wait in the queue. It continues executing code as usual, and releases the semaphore when it's done, thus giving other threads an opportunity to use the resource.

Below is a small example program that demonstrates the behavior of semaphores. It's very similar to the first example, except that the beeping thread grabs a semaphore before beeping 4 times and then releases it. A call to Yield was inserted within this inner loop just to demonstrate that even though there is a call to Yield in the loop, no balls are drawn during this time. This is because the code that draws the balls grabs the semaphore too. When it gets control of the semaphore, it draws 20 balls before letting go. After you release a semaphore, you still have to call Yield before other threads will get control.

main()
{
    ThreadHandle    beepThread;
    SemaphoreHandle aSemaphore;

    Initialize();

/* The InitThreads call initializes the Threads Package, converting
   the original thread of execution into a swappable thread. */

    InitThreads(nil, false);
    aSemaphore = NewSemaphore();

/* Fork the beeping thread. */

    if (InNewThread(&beepThread, kDefaultStackSize))
        {
        long i,j;
        Yield();
        for (i=0; i<10; i++)
            {

/* Grab the semaphore, beep 4 times, and release the semaphore. */

            GrabSemaphore(aSemaphore);
            for (j=0; j<4; j++)
                {
                SysBeep(120);
                Yield();
                }
            ReleaseSemaphore(aSemaphore);
            }
        EndThread(beepThread);
        }


/* Here's the main event loop. */

    do
        {
        long j;
        Yield();

/* Grab the semaphore, draw 20 balls, and release the semaphore. */

        GrabSemaphore(aSemaphore);
        for (j=0; j<20; j++)
            {
            NewBall();
            Yield();
            }
        ReleaseSemaphore(aSemaphore);
        
        } while (!Button());

/* This call to ExitThreads waits for all threads to die before
   allowing the program to terminate. */

    ExitThreads();
}

IMPLEMENTING THREADS ON THE MACINTOSH

After examining the ramifications of implementing threads in the Macintosh run-time environment, we identified three serious problems:
  • non-reentrant Toolbox and application code
  • Toolbox use of memory between the stack and the heap
  • segment unloading

Although the Threads Package minimizes the impact of these problems, you must still deal with some special coding issues when writing programs that use threads.

NON-REENTRANT TOOLBOX AND APPLICATION CODE
When you develop code that uses threads, it's important to write reentrant code. This is a fancy way of saying that your threads must not interfere with each other. A common way in which threads do interfere with each other is in the use--or misuse--of global variables.

The basic problem can be described as follows: Your thread is merrily running along, and it politely yields control to the other threads. When it gets control again, the other threads may have unexpectedly changed some global variables, causing your thread to crash and burn, or behave in an unexpected manner.

Let's illustrate this problem with a realistic example. Suppose you want two windows in your application, and you want to have some drawing going on in each of them simultaneously. Naturally, you would start two threads that draw in the two respective windows. Unfortunately, when you run the program, you find that both of the threads end up drawing in the same window.

What happened? The first thread sets its grafPort to the grafPort of the first window. When the first thread yields control to the second thread, the second thread changes the grafPort to point to its window. Finally, when the first thread gets control again, the grafPort is still pointing to the second window.

You might attempt to solve this problem by placing code that saves and restores your grafPort before and after your call to Yield. This approach may appear to work, but watch out! There may be other calls to the Yield function in routines that your thread is calling. You would have to make sure your save-and-restore code surrounds every one of these calls as well. This would be cumbersome, to say the least.

A safer solution to the reentrancy problem is simply to write reentrant code from the beginning. In other words, just don't misuse global variables. But alas, millions of lines of code have already been written for the Macintosh with globals galore. The Macintosh Toolbox itself is on the whole non- reentrant. For instance, in the above example, the grafPort global is referenced not just in the application but in the Toolbox itself. It would be unrealistic to expect reentrancy problems in Toolbox and application code to vanish overnight.

To get around all this, the Threads Package provides an innovation called customizable swapping behavior. To understand how this behavior works, you must first know a little bit about the thread structure.

The thread structure contains additional fields for the custom procedures that the Threads Package uses to control a thread. Figure 1 illustrates these fields.

You implement the customizable swapping behavior by writing custom routines that carefully set up a thread's globals when the thread swaps in and save these values before the thread swaps out. You assign these routines to the fields in the thread structure, so that the Threads Package can automatically call these routines for you when it does the actual swapping. This enables you to getcontrol at the critical times.

Here's how the customizable swapping feature works. Normally when you create a thread, the Threads Package assigns default swapping and context-preserving functions to the thread. If you want to use all these defaults, just call the InNewThread routine to launch a thread. To use customizable swapping, you create the thread object yourself, customize it, and then launch it. Note that you must always be sure to call the corresponding default routine from within your custom routine.

[IMAGE p06-22_Gough_text_html2.GIF]

* Don't alter this pointer. In practice we've found that you don't need to override fSwapOut.

Figure 1 Customizable Routines in the Thread Structure

Remember, you don't necessarily have to use this customizable swapping technique to juggle all of your global variables. Some globals are really fixed values and don't change when your program switches threads. You only have to worry about the globals that other threads are going to change.

The following sample program demonstrates how to customize the swapping behavior of threads. Notice that there are now two ball-drawing threads. They manage to use the same global variable, gBallSize, to draw balls of different sizes. If we assume that this global is used by the NewBall procedure to determine the size of the ball, and that you don't have control over the implementation of NewBall, then you must have a way to juggle the global's value. This example shows you how to do just that:

pascal void MyCopyContext(ThreadHandle theThread)
{
    (**theThread).fUserBytes[0] = gBallSize ;
    TCopyContext(theThread);
}

pascal void MySwapIn(ThreadHandle theThread)
{
    gBallSize = (**theThread).fUserBytes[0] ;
    TSwapIn(theThread);
}

main()
{
    ThreadHandle ballThread;
    ThreadHandle mainThread;

    Initialize();

/* Create and customize the main thread. InitThreads will start
   it. */

    mainThread = NewThread(kDefaultStackSize);
    (**mainThread).fCopyContext = &MyCopyContext;
    (**mainThread).fSwapIn = &MySwapIn;
    InitThreads(mainThread, false);

/* Create, customize, and start the ball thread. */

    ballThread = NewThread(kDefaultStackSize);
    (**ballThread).fCopyContext = &MyCopyContext;
    (**ballThread).fSwapIn = &MySwapIn;
    StartThread(ballThread);
    if (InThread(ballThread))
        {
        long i;
        gBallSize = 100;
        for (i=0; i<100; i++)
            {
            NewBall();
            Yield();
            }
        EndThread(ballThread);
        }
/* Here's the main event loop. */

    gBallSize = 20;
    do 
        {
        Yield();
        NewBall();
        } while (!Button());


/* This call to ExitThreads waits for all threads to die before
   allowing the program to terminate. */

    ExitThreads();
}

Note that this example uses procedure pointers. As always with procedure pointers, make sure that they're A5 relative so that they can be dereferenced from another segment. In this case, the Threads Package will be calling your procedures at the critical moments before swapping in and swapping out. My preferred technique for ensuring that procedure pointers are A5 relative is to put the procedure in its own segment, separate from the routine that's generating the reference to it.

Figure 2 illustrates how we've customized the thread for the sample program above. [IMAGE p06-22_Gough_text_html3.GIF]

Figure 2 Customizing a Thread

TOOLBOX USE OF MEMORY BETWEEN THE STACK AND THE HEAP
Most threads implementations involve keeping a separate stack in the heap for each thread. They do their context swapping by altering the stack pointer and the stack base; the data on the stack never moves. Unfortunately, there are some routines in the Macintosh Toolbox that assume the stack remains in the same place, not in the heap.

One of the primary design goals of the Threads Package was Toolbox compatibility, so here's the solution we chose. It's a given that there is only one stack and all threads must share the use of this stack. However, since a thread needs to maintain its unique stack data and protect it from being clobbered by other threads, each thread needs to keep this data safe when it doesn't have control of the stack. The way a thread does this is by creating its own unique storage area in the heap. The Threads Package's context-swapping strategy moves data between the stack and the heap with the BlockMove instruction. As a thread swaps out, its context is moved to the heap. As a thread swaps in, its context is moved from the heap into the application's stack area.

The context-swapping code is written in such a way that interrupts can function as usual, and of course you can call Toolbox routines as usual. The heap storage associated with a thread's stack can and will grow dynamically as necessary, since it's free to move around in memory while it's not running.

Swap time using this strategy is 500 microseconds for a stack size of 256 bytes running on an SE/30. Your mileage may vary.

You must be careful not to pass pointers to stack objects between threads, since such pointers are not valid unless the associated thread is swapped in. One subtle way that this problem occurs is in the use of parameter blocks associated with asynchronous I/O. Such parameter blocks should not be allocated on the stack because the I/O operation may complete when the wrong thread is swapped in.

SEGMENT UNLOADING
When you write threaded programs for the Macintosh, you must never unload a code segment unless you're certain that there is no thread that has entered that code segment and has not yet left. In some cases, you can be sure that there's no way for a thread to yield control while it's in a specific code segment. For example, if you have some code that does some computation that stands on its own, you can be reasonably certain that there's no way for it to call other code that could result in a Yield. In cases like this, it's safe to unload the segment as usual.

We looked at several mechanisms for overcoming this problem and found that the most promising design involves unloading segments at GrowZone time. Here's how this could work: The system could call the GrowZone routine when you need more memory in the current heap zone. Since the whole idea behind unloading code segments is to free up memory, we thought that this would be a good place to

unload segments. The trick is to make sure that your GrowZone routine only unloads segments that are not needed by any thread. To ensure this, you could augment the thread structure to include linked-list pointers that would allow your custom GrowZone procedure to traverse a list of all threads (even sleeping threads) in one pass. During the traversal, GrowZone would scan the stack of each thread, looking for anything resembling a return address. If it found a return address, the associated code segment would be "needed." When all the stacks were scanned, GrowZone would simply unload all of the unneeded code segments.

THE THREADS API

Here's a description of all the routine and data structures provided by the Threads Package.

THE THREAD STRUCTURE
The API functions all access a thread through its handle. The thread structure as it's defined in the Threads.h file is as follows:

struct Thread 
{
    struct Thing    fThing;       // Linked-list stuff.
    ThreadType      fType;        // Obsolete. 
    ThreadState     fState;       
                         // Running,pending,blocked,sleeping,ended.
    Boolean         fLocked;      // Obsolete.
    Handle          fStack;       // The storage for the stack data.
    ThreadProc      fCopyContext; 
                         // Copy current context and store in fStack.
    ThreadProc      fSwapIn;      
                         // Called to context-swap a thread in.
    ThreadProc      fSwapOut;    
                  // Calls fSchedule, then fSwapIn on the nextThread.
    ThreadProc      fFree;        // Called to dispose of the thread.
    ScheduleProc    fSchedule;    
            // Queue this thread (if necessary), return the next one.
    long    fUserBytes[8];        // For user use.
};

INITIALIZING THE THREADS PACKAGE

pascal void InitThreads(ThreadHandle mainThread, Boolean usesFPU);

This routine initializes the Threads Package. The first parameter is the handle of the main thread, which has been customized with specific swapping behavior. If you don't need customized swapping behavior for the main thread, pass nil. The second parameter indicates whether you want to swap floating-point registers. If you pass a value of true, they'll be swapped. Of course, the Threads Package is smart enough to know that some machines don't support FPUs, in which case it ignores a value of true.

CUSTOMIZING THREADS

pascal ThreadHandle NewThread(long stackSize);
Each thread structure has a number of fields that are procedure pointers. The Threads Package assigns default procedures to these fields when it creates a thread. You can create a custom thread by calling NewThread and changing the values of the procedure pointers before giving the thread a chance to run.

Here's a list of the procedure pointers that you can change in the thread structure:

ThreadProc fCopyContext;ThreadProc fSwapIn;
ThreadProc fSwapOut;
ThreadProc fFree;
ScheduleProc fSchedule;

When you change one of these procedure pointers in the thread structure, you're overriding the default behavior of a given thread. You will usually customize fCopyContext and fSwapIn to save and restore globals at the appropriate moments. If you need to deallocate data structures associated with the thread, you should override fFree, which is called when the thread dies.

If you're using the default behavior, don't forget to call the corresponding default procedure appropriately within your procedure. Here's a list of the default procedures:

pascal void TCopyContext(ThreadHandle);
pascal void TSwapIn(ThreadHandle);
pascal void TSwapOut(ThreadHandle);
pascal void TFree(ThreadHandle);
pascal ThreadHandle TSchedule(ThreadHandle); 


There is a handy place to store information in the thread structure, called fUserBytes. If you store handles there, be sure to deallocate them in your override of fFree.

pascal void StartThread(ThreadHandle theThread);
pascal Boolean InThread(ThreadHandle theThread);

Once you've created the thread with the call to NewThread and have customized it, you call StartThread, which clones the current stack and saves it in the newly created thread structure. The call to StartThread is typically followed by a call to InThread, which returns true if the specified thread is currently running. This call is embedded in an IF statement that you use to route the respective threads. The original thread jumps over the code in the IF statement, while the new thread enters this body of code.

CONVENIENCE ROUTINES

pascal Boolean InNewThread(ThreadHandle* theThread, 
    long stackSize);

The InNewThread function combines the features of NewThread, StartThread, and InThread. What's different about InNewThread is that it automatically launches a thread with the default swapping behavior and doesn't give you the opportunity to customize the thread. InNewThread returns a Boolean as does InThread, and returns a thread handle in the theThread parameter. You must supply a value for stackSize, which is the number of bytes initially allocated for this thread's stack. If the number you supply is too small, the Threads Package will automatically grow the block of memory that contains the stack. Nice, huh? So if you don't know or care what stack size you need, just pass in 0.

pascal ThreadHandle Spawn(ThreadHandle theThread,
pascal void (*threadProc)(ThreadHandle, long),
    long stackSize, long refCon);

The Spawn routine is for mutants who don't like fork semantics. You supply a thread handle, or nil if you want an uncustomized thread. You also supply a procedure pointer that points to a procedure containing code for the new thread to run. The new thread dies when it returns from your procedure. You also specify a stackSize and a refCon, which allows you to pass some context information to the new thread. The refCon field is usually a pointer or a handle to a memory block that contains parameters you want to pass in.

The distinguishing characteristic of spawn semantics is that the code for the new thread is separated from the code for the original thread. Some people are more comfortable when these things are separated, but passing parameters to initialize the new thread is more work. With fork semantics, all of your local variables are right there on the stack. You don't need to package them up in a record as you do with spawn semantics.

OTHER STUFF

pascal ThreadHandle GetCurrentThread();

The GetCurrentThread function returns the handle to the currently executing thread.

pascal void Yield();

The Yield function is called to explicitly give control to other threads. Yield is called implicitly through other routines like Sleep. (If the current thread is going to sleep, it had better yield control to a waking thread.)

STATES OF CONSCIOUSNESS

pascal void Sleep(ThreadHandle theThread);
pascal void Wake(ThreadHandle theThread);
pascal void EndThread(ThreadHandle theThread);

These routines allow you to alter a thread's state of consciousness. To put a thread to sleep, you simply call Sleep and pass it a thread handle. Usually, a thread will call Sleep to put itself to sleep, although there are some cases where this will be done by another thread. To wake a thread up, call Wake. To kill the thread, use EndThread.

THE THREADS ADVANTAGE

The Threads Package provides a nearly painless way for you to implement multiple threads of execution in your programs. All you need to learn is a handful of routines and a slightly new way of thinking about program execution. And you can gain a lot: easier, more intuitive program design; vastly simpler code; possible performance boosts; and, of course, that holy grail of Macintosh programmers, increased user satisfaction. It's a deal that's hard to refuse.

ACKNOWLEDGMENTS

I would like to thank Joe MacDougald for his Herculean contributions to the design and implementation of the Threads Package. Without his devoted effort, the Threads Package would not exist in its current form. Thanks to Tom Dowdy for the FPU register-swapping feature, and numerous other improvements. Thanks also to ATG researcher Jed Harris, who originally suggested threads as a solution to our problems. Jed helped a great deal with design issues, and some gnarly assembly code debugging. The swapping strategy that allows the Threads Package to be Macintosh Toolbox-compatible was suggested by Donn Denman. Thanks to P. Nagarajan, the first threads user. He dropped threads into his code virtually overnight, giving us valuable input that made it possible to steer the design and implementation.

Tom Saulpaugh made significant contributions to the current design of semaphores. Thanks, Tom. Thanks to Dave Harrison for reviewing an early version of the source code for threads. Thanks to Mitchell Gass for documenting an earlier version of the Threads Package. And thanks to my mentor Larry Tesler for supporting the development of the first version of threads, and suggesting the convenience functions.

Thanks x 106 to my editor Geta Carlson. We had a blast working together on this article, although we've never met in person. Thanks to Paul Snively for polishing the article and championing threads in DTS. Greg Anderson, C. K. Haun, Dave Johnson, and Dave Williams all contributed valuable suggestions that were incorporated. Thanks to Monica Meffert, Louella Pizzuti, and Caroline Rose for making the article happen. Finally, thanks to my managers Dave Leffler and Ron Metzker for putting up with me while I worked on this, and for supporting what this is leading up to.

WHY THREADS ARE IMPORTANT IN THE SYSTEM 7.0 ERA

Interprocess communication (IPC) is one of the most compelling reasons why threads are going to become increasingly important in the future. This became clear to a group of us working in Apple's Advanced Technology Group when we observed that a client and a server application communicating via IPC could easily get into a deadly embrace. A client would ask the server application a question and would wait for an answer before continuing. Unfortunately, sometimes the client would wait forever for the answer. What happened was that the server needed to ask its own question of the client before answering the client. However, the client was monitoring exclusively for a response to its question and would ignore the server's question. The client needed to answer the server's incoming question before it could get an answer to its own question. Both client and server would be stopped dead waiting for the other to respond. In a sense, the Threads Package exists because the problem described here was intractable without threads. The application must be both a client and a server. It must be able to simultaneously handle incoming questions and wait for incoming answers. Other approaches to doing this, such as idle procs, skirted the core of the problem and led to code complexity that was unmanageable. Idle procs push too much of the problem onto the application programmer, who already has enough to worry about.

The threads solution is even more important now that IPC has been integrated into the Macintosh OS in System 7.0. As more programmers will have access to IPC because of System 7.0, they will need this elegant method of achieving concurrency.

IDLE PROCS VERSUS THREADS

Idle procs have traditionally been used to approach thread-like functionality. This involves writing a piece of code to handle a particular task and installing it in a queue of things that get called periodically. Thereafter, the flow of control pulses through the routine, which can do some finite amount of work and then return, so that other idle procs can get pulsed.

This approach results in several gnarly coding problems. The most serious is that the pulsed routine, which is attempting to execute some algorithm, must return to its caller at inopportune moments. Imagine that you're marching through a deeply nested piece of code and you want to relinquish control when you reach a certain point. With the pulsing approach, you must return to the caller from deep within the nested code. You could put in a return statement, but the problem would be that when it's time to pick up where you left off, you would have to magically jump back into the code after the return statement on the next pulse. Obviously, this is not a simple thing to do when you have to bypass several layers of conditionals and loops.

The magic of the Threads Package is that it allows you to avoid these problems: you can leave a complex function and resume execution of it precisely where you left off. With idle procs, on the other hand, you're forced to completely redesign the algorithm. You must give the algorithm an "inside out" appearance: code that was in the most deeply nested part of the algorithm now appears near either the top or the bottom of the routine. You may even have to break your routine into several smaller functions that are run in sequence. But doing these things will negate the natural top-down structure of a routine. It's a mess.

THREADS IN USE TODAY

Threads are currently in use in a product called Virtual User (APDA #M0987LL/A). This program uses a single machine, acting as the "user," to run software tests on many CPUs at once.

Virtual User used to wait until each test was done before starting something else on another test machine. That was slow, because all the testing machines were waiting for one of their siblings to finish something before getting anything to work on. Now, with threads, the controlling machine is happily juggling separate conversations with all of the testing machines simultaneously. The result is a dramatic boost in performance.

MICHAEL GOUGH is a designer in Apple's User Programming Group. We'd tell you what he's up to these days, but it's so secret we'd have to kill you if we did. Before coming to Apple, Michael worked at STX as a NASA contractor, designing scientific data visualization systems. He is best known as the designer and implementor of CDF, a "mini-database" that NASA uses to store data from dozens of spacecraft. Michael developed software used by NOAA's fleet of oceanographic vessels to map the ocean floor. He also worked as a contractor to the United Nations World Meteorological Organization, so if you have any problems with the weather, now you know who to blame. While he was there, he developed real-time satellite tracking and data ingest systems for the TIROS-N, GOES, and GMS spacecraft, and conducted training and installation in Beijing and Buenos Aires. In Beijing he used his knowledge of electronics, computer science, math, and Scotch tape to successfully complete the installation--just goes to show that you never quite know what the right tools for the job are going to be. (Here at Apple, we make sure he always has plenty of office supplies--just in case.) *

Thanks to Our Technical Reviewers C. K. Haun, Paul Snively, Dave Williams *

 
AAPL
$109.41
Apple Inc.
+2.67
MSFT
$45.74
Microsoft Corpora
+0.58
GOOG
$504.89
Google Inc.
+9.50

MacTech Search:
Community Search:

Software Updates via MacUpdate

Command-C 1.1.7 - Clipboard sharing tool...
Command-C is a revolutionary app which makes easy to share your clipboard between iOS and OS X using your local WiFi network, even if the app is not currently opened. Copy anything (text, pictures,... Read more
Tidy Up 4.0.2 - Find duplicate files and...
Tidy Up is a complete duplicate finder and disk-tidiness utility. With Tidy Up you can search for duplicate files and packages by the owner application, content, type, creator, extension, time... Read more
Typinator 6.3 - Speedy and reliable text...
Typinator turbo-charges your typing productivity. Type a little. Typinator does the rest. We've all faced projects that require repetitive typing tasks. With Typinator, you can store commonly used... Read more
GraphicConverter 9.5 - Graphics editor w...
GraphicConverter is an all-purpose image-editing program that can import 200 different graphic-based formats, edit the image, and export it to any of 80 available file formats. The high-end editing... Read more
Toast Titanium 12.0.1 - The ultimate med...
Toast Titanium goes way beyond the very basic burning in the Mac OS and iLife software, and sets the standard for burning CDs, DVDs, and now Blu-ray discs on the Mac. Create superior sounding audio... Read more
QuickBooks 2015 16.0.2.1422 R3 - Financi...
Save 20% on QuickBooks Pro for Mac today through this special discount link QuickBooks Pro 2013 helps you manage your business easily and efficiently. Organize your finances all in one place, track... Read more
Remotix 3.0.6 - Access all your computer...
Remotix is a fast and powerful application to easily access multiple Macs (and PCs) from your own Mac. Features: Complete Apple Screen Sharing support - including Mac OS X login, clipboard... Read more
BetterZip Quick Look Generator 1.5 - Let...
BetterZip Quick Look Generator lets you view the contents of compressed archives through OS X's Quick Look functions. Simply select an archive in the Finder, in Mail, or Spotlight and press the... Read more
Sandvox 2.9.3 - Easily build eye-catchin...
Sandvox is for Mac users who want to create a professional looking website quickly and easily. With Sandvox, you don't need to be a Web genius to build a stylish, feature-rich, standards-compliant... Read more
Pixelmator 3.3.1 - Powerful layer-based...
Pixelmator is a beautifully designed, easy-to-use, fast, and powerful image editor for OS X. It has everything you need to create, edit, and enhance your images. Pixelmator is a layer-based image... Read more

Latest Forum Discussions

See All

Hipstify Review
Hipstify Review By Jennifer Allen on December 17th, 2014 Our Rating: :: COOL FILTERSUniversal App - Designed for iPhone and iPad Add filters, quotes, and fancy frames to your images, thanks to Hipstify.   | Read more »
Mighty Smighties Gets Evolve Cards and N...
Mighty Smighties Gets Evolve Cards and New Worlds Posted by Jessica Fisher on December 17th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Duckie Deck Card Wars Review
Duckie Deck Card Wars Review By Amy Solomon on December 17th, 2014 Our Rating: :: STYLISH GAME OF CARDSUniversal App - Designed for iPhone and iPad Duckie Deck Card Wars adapts the classic card game War for use on devices, complete... | Read more »
PDF Office Review
PDF Office Review By Jennifer Allen on December 17th, 2014 Our Rating: :: CONVENIENT PDF EDITINGiPad Only App - Designed for the iPad Want to create your own PDF files? Import them from elsewhere? Adapt a web page into a PDF? PDF... | Read more »
The Out There: Ω Edition Update will be...
The Out There: Ω Edition Update will be Releasing in 2015, Bringing Better Graphics and Additional Content Posted by Jessica Fisher on December 17th, 2014 [ permalink ] | Read more »
Pinball Planet Pro (Games)
Pinball Planet Pro 1.02 Device: iOS Universal Category: Games Price: $2.99, Version: 1.02 (iTunes) Description: - Our missionWe've always loved to play pinball games but we noticed most modern pinball games are simulators for the... | Read more »
Ultrakam 4k. The Professional Camera App...
Ultrakam 4k. The Professional Camera App. 3.0 Device: iOS Universal Category: Photography Price: $9.99, Version: 3.0 (iTunes) Description: In March 2014, Ultrakam brought Film Resolution for iPhone for the first time ever and now is... | Read more »
Email+ (Business)
Email+ 1.0 Device: iOS Universal Category: Business Price: $2.99, Version: 1.0 (iTunes) Description: Send email, fast! | Read more »
Mayor it up in SimCity BuildIt, Out Now
Mayor it up in SimCity BuildIt, Out Now Posted by Jessica Fisher on December 16th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Crusaders Quest Review
Crusaders Quest Review By Jennifer Allen on December 16th, 2014 Our Rating: :: GOTTA HIRE EM ALLUniversal App - Designed for iPhone and iPad Hire as many heroes as possible in this fun at first but grind-heavy freemium RPG.   | Read more »

Price Scanner via MacPrices.net

Holiday sales continue: MacBook Pros for up t...
 B&H Photo has new MacBook Pros on sale for up to $300 off MSRP as part of their Holiday pricing. Shipping is free, and B&H charges NY sales tax only: - 15″ 2.2GHz Retina MacBook Pro: $1699... Read more
Google Search App For iOS Gets A Major Makeov...
Google has given iOS users an early Christmas present with a substantial update of it’s not-very-often-upgraded Google Search app. Google Search has been my go-to tool for Web searches since it was... Read more
ShopKeep Apple Pay And Chip Card Reader Avail...
ShopKeep, a cloud-based technology provider to more than 10,000 small business owners to manage retail shops and restaurants with iPads, has released its new Apple Pay and chip card reader. This... Read more
Holiday sale! 27-inch 5K iMac for $2299, save...
 B&H Photo has the 27″ 3.5GHz 5K iMac in stock today and on sale for $2299 including free shipping plus NY sales tax only. Their price is $200 off MSRP, and it’s the lowest price available for... Read more
Holiday Sale! 3.7GHz Quad Core Mac Pro availa...
 B&H Photo has the 3.7GHz Quad Core Mac Pro on sale for $2599 including free shipping plus NY sales tax only. Their price is $400 off MSRP, and it’s the lowest price for this model from any... Read more
iPhone 6 Number 3 Canadian Google Search Of 2...
CTVNews.ca reports that Apple’s iPhone 6 was the third highest-trending Google Canada search topic of 2014, exceeded only by Robin Williams largely after his death by suicide in August, and the FIFA... Read more
New iPad mini 3 Counter-Top & Wall Mount...
newMacgadgets has announced new secure all-acrylic displays for the iPad mini 3 (also works fine with the mini 2, last year’s iPad mini With Retina Display, and the original iPad mini). The new iPad... Read more
Holiday sales continue, MacBook Airs for up t...
B&H Photo has 2014 MacBook Airs on sale for up to $120 off MSRP, for a limited time, for the Thanksgiving/Christmas Holiday shopping season. Shipping is free, and B&H charges NY sales tax... Read more
B&H lowers price on 27-inch 3.2GHz iMac t...
B&H Photo has lowered their price on the 27″ 3.2GHz iMac, now on sale for $1629 including free shipping plus NY sales tax only. Their price is $170 off MSRP, and it’s the lowest price for this... Read more
15-inch 2.0GHz Retina MacBook Pro available f...
B&H Photo has lowered their price on leftover 2013 15″ 2.0GHz Retina MacBook Pros to $1499 including free shipping plus NY sales tax only. Their price is $500 off original MSRP. Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Project Manager / Business Analyst, WW *Appl...
…a senior project manager / business analyst to work within our Worldwide Apple Fulfillment Operations and the Business Process Re-engineering team. This role will work Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.