Is PThread a good choice for multi-platorm C/C++ multi-threading program?

Question

Been doing mostly Java and smattering of .NET for last five years and haven't written any significant C or C++ during that time. So have been away from that scene for a while.

If I want to write a C or C++ program today that does some multi-threading and is source code portable across Windows, Mac OS X, and Linux/Unix - is PThread a good choice?

The C or C++ code won't be doing any GUI, so won't need to worry with any of that.

For the Windows platform, I don't want to bring a lot of Unix baggage, though, in terms of unix emulation runtime libraries. Would prefer a PThread API for Windows that is a thin-as-possible wrapper over existing Windows threading APIs.

ADDENDUM EDIT:

Am leaning toward going with boost:thread - I also want to be able to use C++ try/catch exception handling too. And even though my program will be rather minimal and not particularly OOPish, I like to encapsulate using class and namespace - as opposed to C disembodied functions.

Answer 1

Nope, pthreads aren't normally available on Windows. (There are a few attempts at implementing it, but it's not supported by the OS directly, at least.)

If you're writing C++, Boost is, as usual, the answer. Boost.Thread has a portable (and safer) threading library.

In C, the simplest solution is probably to wrap write a common wrapper for both pthreads and the Windows threading API.

Answer 2

Well, pthreads is the old posix standard for writing threaded programs. Its the lowest level threading routines, so its a good choice for cross-platform threading.

However, there are alternatives:

• boost::thread - an STL style threading library
• Intel's Thread Building Blocks
• OpenMP - both these are a higher-level way of writing threaded apps without needing to do any threading calls.

As the latter are all fully supported on all platforms, (pthreads requires a bit of compiler settings as its only part of Windows posix subsystem, unless you want to use Pthreads-w32), then perhaps the latter ones are a better choice. boost::threads are more like a threading library, the other 2 are high-level ways of achieving parallelism without needing to code 'threads', they allow you to write loops that run concurrently automatically (subject to common-sense conditions)

Boost::thread is not a C compatible library though.

edit: cross-platform abilities of the above:

Intel TBB is cross-platform (Windows*, Linux*, and Mac OS* X), supports 32-bit and 64-bit applications and works with Intel, Microsoft and GNU compilers.

OpenMP depends on the compiler you want to use, but GCC and/or Intel compilers have supported OpenMP Windows, Linux and MacOS.

Answer 3

If you need your code to be truly portable then it may be best to stay away from the various libraries that scatter the internet. At some point you'll find a platform they don't support and will then have to create your own branch.

This is also not a hard problem to solve and can be a good exercise for creating cross-platform code.

I'd suggest you create a class, e.g. CThread, that has separate .cpp implementations for each platform and a pure-virtual execute() function that is called after your thread is constructed/run.

That allows all of your thread-creation and sleep/shutdown/priority code to be implemented using the most appropriate API for the platform. You may also need a header (e.g. ThreadTypes.h) that contains defines/typedefs for each platform.

E.g.

// ThreadTypes.h
#if defined(PLATFORM_WIN) || defined(PLATFORM_XBOX)
  typedef DWORD ThreadID
#elif defined(PLATFORM_PS3)
  // etc etc
#endif

This is how I have written all my cross-platform threading code for platforms such as PC/PS2/PS3/360/Wii. It is also a good pattern to follow for things like mutex's and semaphores, which if you have threads you're certain to need at some point :)

Answer 4

I will bet on ZThread

Simple API, easier to use than PThreads and FREE

Answer 5

Have a look at ting also: http://code.google.com/p/ting/

It is cross platform between Windows and Linux. No Mac OS support yet.