Thread Performance Analysis
Volume Number: 13
Issue Number: 1
Column Tag: Toolbox Techniques
Preempting the Mac
By Fabrizio Oddone, Torino, Italy
How to use preemptive threads and how well
This article focuses on the little known facts about the Thread Manager, an interesting
and useful part of the MacOS. I assume that the reader is already familiar with the
relevant Thread Manager documentation listed in the Bibliography.
Why Preemptive Threads?
One widely heard complaint against the MacOS is its supposed lack of preemptive
multitasking, dubbed also "true" multitasking by the lovers of George Boole. The
Thread Manager provides this "longed for" capability, but a number of gotchas, like
the ones listed below, have steered developers away from adopting its most attractive
features.
• You cannot call most of the Toolbox from within a preemptive thread.
• Preemptive threads use only half of the CPU power available to the
application (the other half is reserved to cooperative threads.)
• Preemptive threads are not available on PowerMacs.
• There is no system-supported semaphore API. (The library enclosed with
the Apple SDK is 680x0 only.)
I am going to examine each of these gripes' one by one, but before delving into the
details, I would like to warn you against one very nasty Thread Manager bug. You must
take this bug into account if you are willing to make use of preemptive threads in your
application.
One Word of Caution
Thread Manager versions earlier than 2.1 had a "feature" that made preemptive
threads practically unusable [Bechtel, 1995]. Preemptive threads did not preempt
after the first threaded application launched in Threads 2.0.1. This was fixed.
Apple, in their infinite wisdom, does not tell us how to detect the fundamental bug fix.
The Universal Headers 2.1 lack the relevant information as well. (I cannot comment
upon the newer 2.1.1 headers because Apple does not make them available for
download.) We lucky Gestalt Selectors List dwellers (thanks to Rene G.A. Ros for
maintaining the mail list) have figured out a tentative answer.
Listing 1: Gestalt.c
GestaltCheck
// Checks whether a reliable Thread Manager is installed. This routine
should deliver
// TRUE if you can safely call the Thread Manager API, FALSE
otherwise.
Boolean GestaltCheck(void)
// preemptive scheduler fix present?
gestaltSchedulerFix = 3
Boolean pThreads = false;
if (TrapAvailable(_Gestalt)) {
if (Gestalt(gestaltThreadMgrAttr, &Gresp) == noErr) {
pThreads = (Gresp & (1L << gestaltThreadMgrPresent)) &&
(Gresp & (1L << gestaltSchedulerFix));
}
}
// If we are compiling for the Code Fragment Manager, check whether we
can
// successfully call the library. The gestaltThreadsLibraryPresent bit
is not correctly set
// sometimes, so we don't rely on it.
#if GENERATINGCFM
if (pThreads)
if (NewThread == (void *)kUnresolvedCFragSymbolAddress)
pThreads = false;
#endif
return pThreads;
}
Since preemptive threads do not work as expected under outdated Thread Managers and
a fixed version is freely available, your best bet is requiring the bug fix at all times.
This is not official Apple gospel, so you will have to take my word for it.
Cannot Call the Toolbox Forever, I Guess
Many developers usually surrender, maybe hoping that Copland will improve matters.
Unfortunately, as far as I know, Copland's preemptive processes remains subject to
the very same limitation. The Toolbox and older applications will run cooperatively,
sharing the same address space. Only specifically written applications not calling the
Toolbox may be entitled to run preemptively in a separate, protected address space.
The moral of the story, as always, is to keep the user interface code (using the
Toolbox) clearly separated from the actual code (not relying on the Toolbox). If you
manage to run preemptively under the Thread Manager today, chances are that you will
run with little or no effort, preemptively and safely, under Copland. Also, keep the
parts shared by the preemptive thread and the host application to a minimum and
clearly documented. Currently, a thread has complete access to the application memory
and globals, whereas a Copland process may not, due to protected memory.
Half of the CPU?
The Thread Manager 2.0 documentation states that Preemptive threads are not
required to make yield calls to cause a context switch, although they certainly may,
and they share 50% of their CPU time with the currently executing cooperative
thread. However, calling yield from a preemptive thread is desirable if that thread is
not currently busy.
This paragraph has given birth to a catastrophic superstition - that any calculation
will run at half the speed if assigned to a preemptive thread, all else being inactive.
Thorough tests clearly demonstrate that the facts are different and somewhat
surprising. I grabbed the Apple sample code implementing the Dhrystone benchmark
and I modified it in order to use either preemptive threads or cooperative threads.
(CW7 Gold Reference: MacOS System Extensions: Thread Manager 2.1: Sample
Applications: 68k Examples: Traffic Threads.)
Our main event loop is structured like that shown in Listing 2.
Listing 2: EventLoop.c
EventLoop
// This is our simple event loop. If you are calculating and need to
use the CPU as much // as possible, pass
a zero sleep time. If the Mac is executing only your calculations and
// you pass X ticks, those X ticks are
actually lost. Remember to reset the sleep
// parameter to a reasonable value (usually CaretTime if a blinking
cursor is visible)
// when your application is idle again.
void EventLoop(void)
EventRecord event;
do {
if (WaitNextEvent(everyEvent, &event, 0UL, nil)) {
DoEvent(&event);
// this is a "busy" cooperative loop, waiting for the preemptive
thread to finish; useful // to evaluate whether
the CPU is evenly scheduled between the main cooperative
// thread and the preemptive thread
#if _TESTBALANCE
while (gDhrystoneDone == false) ;
#endif
}
// the else clause is executed when no events are pending; since
we want to give
// preference to the calculating thread, we explicitly tell the
scheduler; if you are // using many
calculating threads keep them in a list, in order to yield to each
(void) YieldToThread(gDhrystoneThreadID);
// stuff used to update the window and the log file removed
gDhrystoneDone = false;
(void) SetThreadState(gDhrystoneThreadID, kReadyThreadState,
kNoThreadID);
}
}
}
while ( gQuit == false );
}
We want to evaluate how much time the Mac actively spends calculating, so we start by
ensconcing a proper frame of reference. Since we are probing the Operating Systems
behavior, but we want our findings independent of the relative speed of each Mac
model, we set each Mac maximum performance level equal to 1.0 (one). With
"maximum performance level" we mean the one obtained executing the test calculation
within a cooperative thread, that never yields the CPU. It is better to explain the