Threading
Volume Number: 10
Issue Number: 11
Column Tag: Essential Apple Technology
Related Info: Process Manager
Threading Your Apps 
Tying it all together
By Randy Thelen, Apple Computer, Inc.
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
About the Author
Randy Thelen - Randy (sometimes known as Random) is the kind of Apple
engineer who just keeps coming up with wacky ideas that just might work. In his
spare time, he's been playing with Threads way too much, and was last seen listening to
They Might Be Giants while excitedly showing off fast, color, bit-shuffling code.
Tying it all together
The Thread Manager is a system software extension which allows applications to
have multiple threads of execution. With multiple threads of execution you can easily
move the processing of relatively lengthy operations into the background thus creating
a more responsive application for your users. In this article we’ll learn what the
terminology is, we’ll explore the programming model you’ll want to employ to make
best use of threads, and we’ll examine the application programming interface (API).
The Threads Manger extension version 2.0.1 (68K and PowerPC based threads)
is available for distribution with your application from Apple for $50 (through
APDA) and it is built in to System 7.5. Further, Apple’s future O/S endeavors will be
threaded. If you employ a threaded model in current application structure, it will
carry over transparently (or requiring only minor API changes) to the next
generation system software.
A few words from the man. Without using any names (Eric Anderson), there’s
this Smart Guy™ over here at Apple who was instrumental in actually packaging the
Threads Manager for shipment. He wrote the following paragraphs for developers (I
felt it fitting to enclose them in this article for you):
“The Thread Manager is the current MacOS solution for lightweight con current
processing. Multithreading allows an application process to be broken into simple
subprocesses that proceed con currently in the same overall application context.
Conceptually, a thread is the smallest amount of processor context state necessary to
encapsulate a computation. Practically speaking, a thread consists of a register set, a
program counter, and a stack. Threads have a fast context switch time due to their
minimal context state requirement and operate within the application context which
gives threads full application global access. Since threads are hosted by an application,
threads within a given application share the address space, file access paths and other
system resources associated with that application. This high degree of data sharing
enables threads to be ‘lightweight’ and the context switches to be very fast relative to
the heavyweight context switches between Process Manager processes.
“An execution context requires processor time to get anything done, and there can
be only one thread at a time using the processor. So, just like applications, threads
are scheduled to share the CPU, and the CPU time is scheduled in one of two ways. The
Thread Manager provides both cooperative and preemptive threads. Cooperative
threads explicitly indicate when they are giving up the CPU. Preemptive threads can be
interrupted and gain control at (most) any time. The basis for the difference is that
there are many parts of the MacOS and Toolbox that can not function properly when
interrupted and/or executed at arbitrary times. Due to this restriction, threads using
such services must be cooperative. Threads that do not use the Toolbox or OS may be
preemptive.
“Cooperative threads operate under a scheduling model similar to the Process
Manager, wherein they must make explicit calls for other cooperative threads to get
control. As a result, they are not limited in the calls they can make as long as yielding
calls are properly placed. Preemptive threads operate under a time slice scheduling
model; no special calls are required to surrender the CPU for other preemptive or
cooperative threads to gain control. For threads which are compute-bound or use
MacOS and Toolbox calls that can be interrupted, preemptive threads may be the best
choice; the resulting code is cleaner than if partial results were saved and control then
handed off to other threads of control.”
That said, let’s make it clear early on that preemptive threads are not supported
on the PowerMacintosh at this time and therefore developers are strongly encouraged
to use cooperative threads. (In reality, this hasn’t posed much of a problem for most
developers, given the number of restrictions for preemptive threads.)
Programming Model
In this section, we’ll discuss how to structure your program. Here’s a block
diagram of a basic application:
WNE Loop is, of course, that block of code which you cycle through more rapidly
than GetCaretTime() ticks expire. Right? If not, that’s one of the first things we’ll
learn about the Threads programming model. It’s actually possible to cycle through
your event loop more quickly, giving your customer a more responsive computer.
A thread is, of course, the center piece of this article.
Yielding is the process of giving up the CPU for some period of time. As Eric
mentioned in his paragraphs was that preemptive threads are yielded inherently by a
timer interrupt; they do not yield. Cooperative threads yield. They call
YieldToAnyThread(). When we examine the API, we’ll see this call. For now, let’s
just remember that yielding is the process of asking the Thread Manager to find the
thread of execution which should execute next.
The circular shapes represent the looping nature of a thread. As it turns out, not
all threads loop. Some follow some series of steps: A, B, C, ..., etc. Those threads, if
they take a long time, should be making asynchronous I/O calls with yield calls where
SyncWait would normally execute. For example,
/* 1 */
AsyncFileManagerCall( &pb);
while( pb.ioResult > 0)
YieldToAnyThread();
In our block diagram, we find the two steps most programs have: the
initialization and the WaitNextEvent loop. The WNE loop looks something like this
(code snippet from Sprocket, courtesy of Dave Falkenburg - thanks Dave, let’s do
lunch real soon):
/* 2 */
Boolean gDone = false;
Boolean gMenuBarNeedsUpdate = false;
long gRunQuantum = GetCaretTime();
long gSleepQuantum = 3;
RgnHandle gMouseRegion = nil;
Boolean gHasThreadManager = false;
void MainEventLoop(void)
{
EventRecord anEvent;
unsigned long nextTimeToCheckForEvents = 0;
while (!gDone)
{
if (gHasThreadManager)
YieldToAnyThread();
if (gMenuBarNeedsUpdate)
{
gMenuBarNeedsUpdate = false;
DrawMenuBar();
}
if ((gRunQuantum == 0) ||
(TickCount() > nextTimeToCheckForEvents))
{
nextTimeToCheckForEvents = TickCount() + gRunQuantum;
(void) WaitNextEvent( everyEvent, &anEvent,
gSleepQuantum, gMouseRegion);
HandleEvent(&anEvent);
}
}
}
Immediately we find two things: PowerMacintosh WaitNextEvent “smarts” and
support for the Thread Manager. The WNE “smarts” is simply a mechanism for
throttling the frequency with which WaitNextEvent is called on a PowerMacintosh.
(The issue here, if you’re not already familiar with it, is that WNE invokes a context
switch from PowerPC code to 68K emulation and if the application calls WNE too
frequently then performance goes into the proverbial toilet.)
The Thread Manager support is, as you can see, petty. (There was, one would
hope, the appropriate check for the presence of the Thread Manager. We’ll see that
code in a couple pages.)
The Toolbox trap YieldToAnyThread() uses trap number $ABF2 (which goes by
the name ThreadDispatch, and gets a selector in D0). If we glance back at our block
diagram, we see that the Toolbox trap YieldToAnyThread() calls into the Thread
Manager. It yields the CPU to one of the other threads of execution within the program
context. Each thread is then responsible for calling YieldToAnyThread() frequently
enough that two things will happen: one, the cursor, if you’ve got one, will blink with
reasonable consistency; second, you’ll want events (mouse downs, etc.) to be handled
pretty quickly.
With regard to the insertion point blinking, the rule of thumb here really varies:
if you’ve got an arbitrary number of threads (potentially greater than
GetCaretTime()’s smallest value), you’ll want to yield before a tick expires; if you’ve
only got a few threads, you may want to time your processing using the same kind of
TickCount() > someQuantum algorithm as what Dave’s done above.
Regarding events, there is something very important you should be familiar
with. The Thread Manager will check to see if any events are pending for the
application each time a thread yields. If there are events (or there is an event), the
thread that gets time next is the main thread. If the main thread then yields without
processing the event (or all events), another thread is executed, but upon the next
yield, the main thread will then get time again. It’s an algorithm that ensures two
things: first, the main thread gets time often enough to handle incoming events as
quickly as threads yield, and second, events are not “starved” (threads are always
hungry for CPU time).
Obviously these over-simplified rules won’t work for everybody. Hopefully,
after you’ve read the bulk of these articles, you’ll get some feel for where to begin
your experimentation for coming up with a processing time model that works best for
your application and thread requirements.
Your application will create these threads whenever it’s appropriate to do so. In
SortPicts (one of the apps included on the source disk and online sites this month), for
example, a thread is created when a window is opened. In ThreadBrot (a threaded
Mandelbrot, also on disk and online), threads are created as rectangles within the
complex number plane are halved (it’s a divide-and-conquer algorithm) until some
lower bound rectangle size is reached - recursive algorithms must always have a base
case. In Steve Sisak’s article next month, we’ll see threads created for sending
AppleEvents - who’d a thunk it? In short, you’re free to create threads during the
execution of your program whenever your process is given time by the process
manager. In fact, you can preallocate threads into a pool (which the Thread Manager
will maintain for you) and then you can spawn new threads of execution during
preemptive threads or during interrupts (remember, in 68K land your A5 world must
be set correctly; for PowerPC applications, you must make this call from PowerPC
code - or the Threads Manager will crash your application).
API
There are only a couple of calls you need to know about: NewThread,
YieldToAnyThread. With these two calls, you could make your programs amazingly
responsive. With other calls we’ll discuss, you can do much more.
/* 3 */
FUNCTION NewThread (threadStyle: ThreadStyle;
threadEntry: ThreadEntryProcPtr;
threadParam: LONGINT;
stackSize: Size;
options: ThreadOptions;
threadResult: LongIntPtr;
VAR threadMade: ThreadID):OSErr;
You’ll call NewThread whenever you wish to create a new thread of execution.
threadStyles are kPreemptiveThread and kCooperativeThread. Again, unless you’re
writing a program for use only on a 68K machine, you’ll want to limit yourself to
kCooperativeThread.
Your threadEntry is the address of the function which will get executed when the
thread is first executed. You should remember that this entry point will be called only
once for your thread. From then on, when you call YieldToAnyThread, your thread will
continue execution from the instruction immediately following the yield call.
The threadParam is passed to your thread when it is first called. This allows you
to pass a value or the address of an arbitrarily-large data structure to your thread.
The stackSize field defines the size that you believe to be adequate to maintain
context switch information, satisfy Toolbox stack requirements, and fulfill your
thread’s stack needs. If you pass zero for this field, you will get the default stack size.
(You can inspect this size by calling GetDefaultThreadStackSize, and you can set it by
calling SetDefaultThreadStackSize.)
Referenced by (9):