< Previous PageNext Page > Hide TOC

Creating and Managing Threads

In Mac OS X, each process (application) is made up of one or more threads. Each thread represents a single stream of execution for the application's code. Every application starts with a single thread, which runs the application's main function. Applications can spawn additional threads, each of which executes the code of a specific function.

When an application spawns a new thread, that thread becomes an independent entity inside of the application's process space. Each thread has its own execution stack and is scheduled for runtime separately by the kernel. A thread can communicate with other threads and other processes, perform I/O operations, and do anything else you might need it to do. Because they are inside the same process space, however, all threads in a single application share the same virtual memory space and have the same access rights as the process itself.

This chapter provides an overview of the thread technologies available in Mac OS X and examples of how to use those technologies in your applications.

In this section:

About Mac OS X Threads
Creating a Thread
Creating POSIX Threads in a Cocoa Application
Configuring Threads
Terminating a Thread

About Mac OS X Threads

In Mac OS X, threads are a low-level way to facilitate multiple streams of execution in a single application. Although not as sophisticated as operation objects, threads are a common paradigm on most operating systems and so are familiar to most developers. The following sections describe the thread technologies available in Mac OS X and platform-specific information about those technologies.

Threading Technologies

Although the underlying implementation mechanism for threads in Mac OS X is Mach threads, you rarely (if ever) work with threads at the Mach level. Instead, you usually use the more convenient POSIX API or one of its derivatives. The Mach implementation does provide the basic features of all threads, however, including a preemptive execution model and the ability to schedule threads so they are independent of each other.

Table 3-1 lists the threading technologies you can use in your applications. This list does not cover thread-related technologies, such as NSOperation, which use threads internally to implement program concurrency. Those technologies are covered in other chapters of this document.

Mac OS X supports all of the standard features found in the POSIX threads implementation, including the following:

• Thread customization; see “Configuring Threads”

• Support for creating threads as joinable or detached; see “Setting the Detached State of a Thread”

• Per-thread storage; see “Configuring Thread-Local Storage”

• Support for thread cancellation semantics; see “Terminating a Thread”

Thread Costs

Threading has a real cost to your program (and the system) in terms of memory use and performance. Each thread in Mac OS X requires the allocation of memory in both the kernel memory space and your program’s memory space. The core structures needed to manage your thread and coordinate its scheduling are stored in the kernel using wired memory. Your thread’s stack space and per-thread data is stored in your program’s memory space. Most of these structures are created and initialized when you first create the thread—a process that can be relatively expensive because of the required interactions with the kernel.

Table 3-2 quantifies the approximate costs associated with creating a new user-level thread in your application. Some of these costs are configurable, such as the amount of stack space allocated for secondary threads. The time-based costs in particular are rough approximations and should be used only for relative comparisons with each other. Things like thread and lock creation times can vary greatly depending on processor load, the speed of the computer, and the amount of available system and program memory.

Another cost to consider when writing threaded code is the production costs. Designing a threaded application can sometimes require fundamental changes to the way you organize your application’s data structures. Making those changes might be necessary to avoid the use of synchronization, which can itself impose a tremendous performance penalty on poorly designed applications. Designing those data structures, and debugging problems in threaded code, can increase the time it takes to develop a threaded application. Avoiding those costs can create bigger problems at runtime, however, if your threads spend too much time waiting on locks or doing nothing.

Creating a Thread

Creating low-level threads is relatively simple. In all cases, you must have a function or method to act as your thread’s main entry point and you must use one of the available thread routines to start your thread. The following sections show the basic creation process for the more commonly used thread technologies. Threads created using these techniques inherit a default set of attributes, determined by the technology you use. For information on how to configure your threads, see “Configuring Threads.”

Using NSThread

There are two ways to create a thread using the NSThread class:

• Use the detachNewThreadSelector:toTarget:withObject: class method to spawn the new thread.

• Create a new NSThread object and call its start method. (Supported only in Mac OS X v10.5 and later.)

Both techniques create a detached thread in your application. A detached thread means that the thread’s resources are automatically reclaimed by the system when the thread exits. It also means that your code does not have to join explicitly with the thread later.

Because the detachNewThreadSelector:toTarget:withObject: method is supported in all versions of Mac OS X, it is more frequently used than the other technique. To detach a new thread, you simply provide the name of the method (specified as a selector) that you want to use as the thread entry point along with the object that defines that method and any data you want to pass to the thread. The following example shows a basic invocation of this method that spawns a thread using a custom method of the current object.

[NSThread detachNewThreadSelector:@selector(myThreadMainMethod:) toTarget:self withObject:nil];

Prior to Mac OS X v10.5, you used the NSThread class primarily to spawn threads. Although you could get an NSThread object and access some thread attributes, you could only do so from the thread itself after it was running. In Mac OS X v10.5, support was added for creating NSThread objects without a running thread. This support made it possible to get and set various thread attributes prior to starting the thread. It also made it possible to use that thread object later to refer to the running thread.

The simple way to initialize an NSThread object is to use the initWithTarget:selector:object: method. This method takes the exact same information as the detachNewThreadSelector:toTarget:withObject: method and uses it to initialize a new NSThread instance. It does not start the thread, however. To start the thread, you call the thread object’s start method explicitly, as shown in the following example:

NSThread* myThread = [[NSThread alloc] initWithTarget:self

                                        selector:@selector(myThreadMainMethod:)

                                        object:nil];

[myThread start];

If you have an NSThread object whose thread is currently running, one way you can send messages to that thread is to use the performSelector:onThread:withObject:waitUntilDone: method of almost any object in your application. Support for performing selectors on threads (other than the main thread) was introduced in Mac OS X v10.5 and is a convenient way to communicate between threads. The messages you send using this technique are executed directly by the other thread as part of its normal run-loop processing. (Of course, this does mean that the target thread has to be running in its run loop, but that is a relatively straightforward matter; see “Run Loop Management.”) You may still need some form of synchronization when you communicate this way, but it is still simpler than setting up communications ports between the threads.

For a list of other thread communication options, see “Setting the Detached State of a Thread.”

Using POSIX Threads

Mac OS X provides C-based support for creating threads using the POSIX thread API. This technology can actually be used in any type of Mac OS X application (including Cocoa applications) and might be more convenient if you are writing your software for multiple platforms. The POSIX routine you use to create threads is called, appropriately enough, pthread_create.

Listing 3-1 shows two custom functions for creating a thread using POSIX calls. The LaunchThread function creates a new thread whose main routine is implemented in the PosixThreadMainRoutine function. The new thread is created as a detached thread in the following example. The default attribute set for POSIX results in the creation of joinable threads. Marking the thread as detached gives the system a chance to reclaim the resources for that thread immediately when it exits.

Listing 3-1  Creating a thread in C

#include <assert.h>

#include <pthread.h>

// The thread entry point routine.

void* PosixThreadMainRoutine(void* data)

{

    // Do some work here.

    return NULL;

}

void LaunchThread()

{

    // Create the thread using POSIX routines.

    pthread_attr_t  attr;

    pthread_t       posixThreadID;

    assert(!pthread_attr_init(&attr));

    assert(!pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED));

    int     threadError = pthread_create(&posixThreadID, &attr, &PosixThreadMainRoutine, NULL);

    assert(!pthread_attr_destroy(&attr));

    if (threadError != 0)

    {

         // Report an error.

    }

}

If you add the code from the preceding listing to one of your source files and call the LaunchThread function, it would create a new detached thread in your application. Of course, new threads created using this code would not do anything useful. The threads would launch and almost immediately exit. To make things more interesting, you would need to add code to the PosixThreadMainRoutine function to do some actual work. To ensure that a thread knows what work to do, you can pass it a pointer to some data at creation time. You pass this pointer as the last parameter of the pthread_create function.

To communicate information from your newly created thread back to your application’s main thread, you need to establish a communications path between the target threads. For C-based applications, there are several ways to communicate between threads, including the use of ports, conditions, or shared memory. For long-lived threads, you should almost always set up some sort of interthread communications mechanism to give your application’s main thread a way to check the status of the thread or shut it down cleanly when the application exits.

Using NSObject to Spawn a Thread

In Mac OS X v10.5 and later, all objects have the ability to spawn a new thread and use it to execute one of their methods. The performSelectorInBackground:withObject: method creates a new detached thread and uses the specified method as the entry point for the new thread. For example, if you have some object (represented by the variable myObj) and that object has a method called doSomething that you want to run in a background thread, you could could use the following code to do that:

[myObj performSelectorInBackground:@selector(doSomething) withObject:nil];

The effect of calling this method is the same as if you called the detachNewThreadSelector:toTarget:withObject: method of NSThread with the current object, selector, and parameter object as parameters. The new thread is spawned immediately using the default configuration and begins running. Inside the selector, you must configure the thread just as you would any thread. For example, you would need to set up an autorelease pool (if you were not using garbage collection) and configure the thread’s run loop if you planned to use it. For information on how to configure new threads, see “Configuring Threads.”

Using Other Threading Technologies

Although the POSIX routines and NSThread class are the recommended technologies to use for creating low-level threads, Mac OS X does include other C-based technologies. Of these, the only other one you might consider using is Multiprocessing Services, which is itself implemented on top of POSIX threads. Multiprocessing Services was developed originally for earlier versions of Mac OS and was later made available for Carbon applications in Mac OS X. If you have existing code that uses this technology, you can continue to use it, although you should also consider porting your thread-related code to POSIX.

For information on how to use Multiprocessing Services, see Multiprocessing Services Programming Guide.

Creating POSIX Threads in a Cocoa Application

Although the NSThread class is the main interface for creating threads in Cocoa applications, you are free to use POSIX threads instead if doing so is more convenient for you. For example, you might use POSIX threads if you already have code that uses them and you do not want to rewrite it. If you do plan to use the POSIX threads in a Cocoa application, you should still be aware of the interactions between Cocoa and threads and obey the guidelines in the following sections.

Protecting the Cocoa Frameworks

For multithreaded applications, Cocoa frameworks use locks and other forms of internal synchronization to ensure they behave correctly. To prevent these locks from degrading performance in the single-threaded case, however, Cocoa does not create them until the application spawns its first new thread using the NSThread class. If you spawn threads using only POSIX thread routines, Cocoa does not receive the notifications it needs to know that your application is now multithreaded. When that happens, operations involving the Cocoa frameworks may destabilize or crash your application.

To let Cocoa know that you intend to use multiple threads, all you have to do is spawn a single thread using the NSThread class and let that thread immediately exit. Your thread entry point need not do anything. Just the act of spawning a thread using NSThread is enough to ensure that the locks needed by the Cocoa frameworks are put in place.

If you are not sure if Cocoa thinks your application is multithreaded or not, you can use the isMultiThreaded method of NSThread to check.

Supporting Autoreleased Objects

If your code does not require garbage collection, and you plan to create Cocoa objects, each thread you create must have an autorelease pool. Creating an autorelease pool at the beginning of your thread’s main entry routine is a standard procedure regardless of which technology you use to create the thread. For more information, see “Memory Management in Threads.”

Mixing POSIX and Cocoa Locks

It is safe to use a mixture of POSIX and Cocoa locks inside the same application. Cocoa lock and condition objects are essentially just wrappers for POSIX mutexes and conditions. For a given lock, however, you must always use the same interface to create and manipulate that lock. In other words, you cannot use a Cocoa NSLock object to manipulate a mutex you created using the pthread_mutex_init function, and vice versa.

Configuring Threads

After you create a thread, and sometimes before, you may want to configure different portions of the thread environment. The following sections describe some of the changes you can make and when you might make them.

Configuring the Stack Size of a Thread

For each new thread you create, Mac OS X allocates a specific amount of memory in your process space to act as the stack for that thread. The stack manages the stack frames and is also where any local variables for the thread are declared. The amount of memory allocated for threads is listed in “Thread Costs.”

If you want to change the stack size of a given thread, you must do so before you create the thread. All of the threading technologies provide some way of setting the stack size, although setting the stack size using NSThread is available only in Mac OS X v10.5 and later. Table 3-3 lists the different options for each technology.

Memory Management in Threads

Because threads share the memory space of your process, memory management is usually the same for threads as it is for the rest of your program. In other words, you can continue to use malloc package or the Cocoa memory management techniques you would use in a single-threaded application.

If you are writing a Cocoa application, however, there is one additional aspect to threaded programming that you must handle. If your code uses the traditional reference counting model to retain and release objects, as opposed to using garbage collection, you must create an autorelease pool for each of your custom threads that uses Cocoa. You must always create an autorelease pool before performing any operation where the autorelease method of an object might be called. This usually means creating the NSAutoreleasePool object as the first step in your thread’s main entry routine and deleting it as the last step, as shown in the following example:

- (void)myThreadMainRoutine

{

    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    // Do thread work here.

    [pool release];

}

If your project requires the use of garbage collection, an autorelease pool is not necessary for secondary threads. If garbage collection is optional or not used, however, you must create one. The presence of an autorelease pool in a garbage-collected application is not harmful, and for the most part is simply ignored.

For more information on memory management and autorelease pools in Cocoa applications, see Memory Management Programming Guide for Cocoa.

Configuring Thread-Local Storage

Each thread maintains a dictionary of key-value pairs that can be accessed from anywhere in the thread. You can use this dictionary to store information that you want to persist throughout the execution of your thread. For example, you could use it to store state information that you want to persist through multiple iterations of your thread’s run loop.

Cocoa and POSIX store the thread dictionary in different ways, so you cannot mix and match calls to the two technologies. As long as you stick with one technology inside your thread code, however, the end results should be similar. In Cocoa, you use the threadDictionary method of an NSThread object to retrieve an NSMutableDictionary object, to which you can add any keys required by your thread. In POSIX, you use the pthread_setspecific and pthread_getspecific functions to set and get the keys and values of your thread.

Setting Up a Run Loop

When writing code you want to run on a separate thread, you have two options. The first option is to write the code for a thread as one long task to be performed with little or no interruption, and have the thread exit when it finishes. The second option is put your thread into a loop and have it process requests dynamically as they arrive. The first option requires no special setup for your code; you just start doing the work you want to do. The second option, however, involves setting up your thread’s run loop.

Mac OS X provides built-in support for implementing run loops in every thread. Cocoa and Carbon start the run loop of your application’s main thread automatically, but if you create any secondary threads, you must configure the run loop and start it manually.

For information on using and configuring run loops, see “Run Loop Management.”

Setting the Detached State of a Thread

Most Mac OS X high-level thread technologies create detached threads by default. In most cases, detached threads are preferred because they allow the system to free up the thread’s data structures immediately upon completion of the thread. Detached threads also do not require explicit interactions with your program. The means of retrieving results from the thread is left to your discretion. By comparison, the system does not reclaim the resources for joinable threads until another thread explicitly joins with that thread, a process which may block the thread that performs the join.

You can think of joinable threads as akin to child threads. Although they still run as independent threads, a joinable thread must be joined by another thread before its resources can be reclaimed by the system. Joinable threads also provide an explicit way to pass data from an exiting thread to another thread. Just before it exits, a joinable thread can pass a data pointer or other return value to the pthread_exit function. Another thread can then claim this data by calling the pthread_join function.

If you do want to create joinable threads, the only way to do so is using POSIX threads. POSIX creates threads as joinable by default. To mark a thread as detached or joinable, modify the thread attributes using the pthread_attr_setdetachstate function prior to creating the thread. After the thread begins, you can change a joinable thread to a detached thread by calling the pthread_detach function. For more information about these POSIX thread functions, see the pthread man page. For information on how to join with a thread, see the pthread_join man page.

Setting the Thread Priority

Any new thread you create has a default priority associated with it. The kernel’s scheduling algorithm takes thread priorities into account when determining which threads to run, with higher priority threads being more likely to run than threads with lower priorities. Higher priorities do not guarantee a specific amount of execution time for your thread, just that it is more likely to be chosen by the scheduler when compared to lower-priority threads.

If you do want to modify thread priorities, both Cocoa and POSIX provide a way to do so. For Cocoa threads, you can use the setThreadPriority: class method of NSThread to set the priority of the currently running thread. For POSIX threads, you use the pthread_setschedparam function. For more information, see NSThread Class Reference or pthread_setschedparam man page.

Terminating a Thread

The recommended way to exit a thread is to let it exit its entry point routine normally. Although Cocoa, POSIX, and Multiprocessing Services offer routines for killing threads directly, the use of such routines is strongly discouraged. Killing a thread prevents that thread from cleaning up after itself. Memory allocated by the thread could potentially be leaked and any other resources currently in use by the thread might not be cleaned up properly, creating potential problems later.

If you anticipate the need to terminate a thread in the middle of an operation, you should design your threads from the outset to respond to a cancel or exit message. For long-running operations, this might mean stopping work periodically and checking to see if such a message arrived. If a message does come in asking the thread to exit, the thread would then have the opportunity to perform any needed cleanup and exit gracefully; otherwise, it could simply go back to work and process the next chunk of data.

One way to respond to cancel messages is to use a run loop input source to receive such messages. Listing 3-2 shows the structure of how this code might look in your thread’s main entry routine. (The example shows the main loop portion only and does not include the steps for setting up an autorelease pool or configuring the actual work to do.) The example installs a custom input source on the run loop that presumably can be messaged from another one of your threads; for information on setting up input sources, see “Configuring Run Loop Sources.” After performing a portion of the total amount of work, the thread runs the run loop briefly to see if a message arrived on the input source. If not, the run loop exits immediately and the loop continues with the next chunk of work. Because the handler does not have direct access to the exitNow local variable, the exit condition is communicated through a key-value pair in the thread dictionary.

Listing 3-2  Checking for an exit condition during a long job

- (void)threadMainRoutine

{

    BOOL moreWorkToDo = YES;

    BOOL exitNow = NO;

    NSRunLoop* runLoop = [NSRunLoop currentRunLoop];

    // Add the exitNow BOOL to the thread dictionary.

    NSMutableDictionary* threadDict = [[NSThread currentThread] threadDictionary];

    [threadDict setValue:[NSNumber numberWithBool:exitNow] forKey:@"ThreadShouldExitNow"];

    // Install an input source.

    [self myInstallCustomInputSource];

    while (moreWorkToDo && !exitNow)

    {

        // Do one chunk of a larger body of work here.

        // Change the value of the moreWorkToDo Boolean when done.

        // Run the run loop but timeout immediately if the input source isn't waiting to fire.

        [runLoop runUntilDate:[NSDate date]];

        // Check to see if an input source handler changed the exitNow value.

        exitNow = [[threadDict valueForKey:@"ThreadShouldExitNow"] boolValue];

    }

}

< Previous PageNext Page > Hide TOC