Windows- and POSIX Threads
Writing a simple console program in C++ that does some computation, file input/output, and memory structure processing, and that also builds and runs under Windows and multiple UNIX flavors, is quite feasible – not too many #ifdef‘s are required. Unfortunately when things start scaling up and concurrent processing, i.e. threading, is required, one hits a brick wall.
Windows
Threads became popular with the 32-bit (and hybrid) versions of Windows – Windows NT 3.1 and Windows 95. It may be arguable whether threads were implemented in Windows or VMS first but I don’t find that very important. Here is an interesting article that compares Windows NT and VMS:
http://www.windowsitpro.com/Windows/Articles/ArticleID/4494/pg/1/1.html
What I do find important is that threading is a key point in Windows’s architecture. Threads have been carefully designed and implemented for performance. And I bet the majority of the threading code worldwide is written against Windows threads.
Programming against Windows threads has one caveat – initializing the CRT (C Runtime) library in Visual C++. The CRT library has been around ever since the Microsoft C compiler was released for MS-DOS. It uses internal buffers for some of its functions. During the port to 32-bit Windows, those global buffers have been converted to thread local storage as an easy way to achieve thread safety. Now the problem is that every thread that uses CRT must initialize its own thread local storage. Therefore CRT provides its own thread creation functions that supersede the native Win32 calls and do the initialization internally. For a similar reason, MFC exposes its own thread creation API but I won’t bother with it since MFC is not portable.
POSIX
The UNIX community’s response to Windows threads has been a standard specification known as POSIX Threads or Pthreads. Here is a link to the standard itself:
http://standards.ieee.org/reading/ieee/interp/1003-1c-95_int/index.html
and another link that provides a more readable interpretation of the spec:
http://www.llnl.gov/computing/tutorials/pthreads/
RedHat and SuSE (and perhaps most Linux distributors as well) ship an implementation called LinuxThreads with their 2.4 kernel distributions:
http://pauillac.inria.fr/~xleroy/linuxthreads/
which is replaced by NPTL in the 2.6 kernel distributions:
http://en.wikipedia.org/wiki/NPTL
It even turns out RedHat has an implementation of Pthreads for Windows:
http://sources.redhat.com/pthreads-win32/
Portable Threading Code
Conceptually the two sets of APIs – Win32 and Pthreads are pretty close. However the function signatures are by far different. One option is to always program against the Pthread API but there is a good chance to lose the native Win32 threading performance. Furthermore, both APIs are plain C, and as a C++ programmer I would like to program against a class library.
So I implemented such a class library that resolves to Win32/CRT threads under Windows and to Pthreads otherwise. I called it MSDK. The code that wraps the platform APIs is minimal. MSDK implements well-known synchronization primitives plus some new ones. It also implements some well-known threading patterns. Plus classes for building portable services. And that will be the topic of my next post.
