by Jeff Clites <online@mactech.com>
In our previous column we began coverage of a set of technologies that I'm calling the "New Basics," in recognition that "the things that every programmer should know" are changing, and as they change we're converging on a set which is the same for all programmers-there are no longer different sets for different platforms. This is in part because the fundamental, low-level differences between operating systems are shrinking, and in part because the focus is shifting toward technologies which are new to all platforms, and which are being embraced by all platforms as they emerge. We also noted that this is leading to a sort of impromptu cooperation, and companies like IBM which used to be archetypal bad guy are now great sources of information for Macintosh programmers who are new to the Unix side of computing. Our first New Basic was XML, which is the most-hyped technology of the day, and is likely to dominate information interchange for some time to come. This month we are going to take a look at threading-both how it will be conceptually different under Mac OS X than under Mac OS 9, and how it will be more important there as well.
Most Macintosh developers will be accustomed to a "cooperative" environment, where an application has exclusive use of the processor (and other system resources) until it explicitly yields control to other waiting processes. Threading under Mac OS 9 is also typically cooperatively scheduled, so that threads within a single application have to explicitly yield for other threads to proceed. This type of scheduling simplifies certain issues surrounding concurrent access to memory and system resources, but it can be difficult for a developer to know how often, and when, to yield the processor in order to provide the best overall system performance. Also, the majority of the Toolbox is not thread safe, so that you have to be very careful about the types of operations you perform outside of the main thread. As a result, under Mac OS 9 applications tend to be single-threaded if at all possible.
Under Mac OS X, as under other Unix-based operating systems, both processes and threads are scheduled preemptively, so that the kernel makes all scheduling decisions and a thread or process can be interrupted at any time. From the point of view of a programmer, this means that you can never be sure that two operations within your application will take place without another process interrupting. The benefit of this approach is that you never has to explicitly code time-consuming sections of your application to yield the processor in order to prevent freezing the user's system for long periods, and you can perform blocking I/O operations in a thread and know that other threads and processes will happily proceed while yours is waiting for data to be read transferred. This simplifies many uses of threads, but introduces complications of its own: you have to guard critical sections of code and data from concurrent access if they are going to be used by multiple threads (even reading data from a variable cannot be assumed to be an atomic operation), and you can't assume that the state of the system has not changed from one line of code to the next (for instance, it isn't reliable to check for the existence of a file and then try to open it as a separate step, because the file could be deleted in between the two operations, even if they occur back-to-back within your program). Preemptive scheduling requires a certain paranoia on the part of the programmer, but it leads to an overall more responsive and reliable system, and it allows simple applications to be written simply, without worrying that they might accidentally hijack the processor. And of course, threading makes it possible for a single application to take advantage of multiple processors on systems which have them, and in fact on such systems two threads within a single application can be executing at literally the same time.
The fundamental threading library under Mac OS X is POSIX Threads, or Pthreads for short. This will be new to veteran OpenStep programmers as well as to classic Macintosh programmers, as Mac OS X Server and previous NeXT-derived operating systems used a different threading library, called Cthreads. The big benefit of Pthreads is that applications using them should be portable to other POSIX-compliant operating systems (if the rest of the code is portable, of course), and this will make it that much easier to bring standard Unix tools and applications over to the Macintosh. For most applications it won't be necessary to use the Pthreads library directly, as Cocoa has its own threading facilities which provide a higher-level view and insulate the programmer from the details of the underlying threading library. Even so, the conceptual model remains the same, and Macintosh programmers which are new to preemptive threading will benefit from the wealth of information there is available on POSIX threading. Also, if you plan to develop (or port) more traditional Unix-style applications you will need to know about the lower-level libraries in more detail.
A good starting point is the article How to program with threads on SunWorld Online, which talks about programming with threads in general, and the advantages that they offer. Next, IBM's developerWorks site has a series of articles which cover POSIX threads specifically. Like many of their articles, these are written with a Linux audience in mind, but most of the information is nevertheless relevant, as POSIX is explicitly cross platform. These articles will give you a good feel for the issues involved, and point out the potential complexities of using threads.
After you've gotten a handle on the major concepts, you'll want to find more in-depth coverage of the details of using Pthreads. There are several online tutorials which can help. In particular, Getting Started With POSIX Threads is a brief tutorial which will help solidify some key points, and then you can move on to more comprehensive coverage in Multi-Threaded Programming With POSIX Threads and POSIX Threads Programming, both of which are quite thorough.
If you are curious about other issues surrounding threading, you should check the comp.programming.threads FAQ. Also, if you are interested in the different possible strategies for actually implement a threading library, the Navy has an article which covers the strengths and weaknesses of three different approaches. Finally, you may want to visit the Programming POSIX Threads web site, which has pointers to further information.
There are several books about Pthreads, and I always find it helpful to have a detailed printed reference to augment all of the web-based information. Programming with POSIX Threads by David R. Butenhof (ISBN: 0-201-63392-2) is my favorite and is often recommended by others, but there are several alternatives available, including Pthreads Programming (ISBN: 1-56592-115-1) and Multithreaded Programming With Pthreads (ISBN: 0136807291). Take a look and see which one suites you the best.
Now you should be up to speed on basic number two. Keep your eye on this column in coming months, because we're not done with the New Basics yet!
