RogerV
RogerV

Reputation: 3866

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

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.

Upvotes: 16

Views: 12677

Answers (5)

Ivan
Ivan

Reputation: 11

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.

Upvotes: 0

pankajt
pankajt

Reputation: 7874

I will bet on ZThread

Simple API, easier to use than PThreads and FREE

Upvotes: 0

gbjbaanb
gbjbaanb

Reputation: 52689

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:

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.

Upvotes: 16

Andrew Grant
Andrew Grant

Reputation: 58804

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 :)

Upvotes: 12

Stack Overflow is garbage
Stack Overflow is garbage

Reputation: 248199

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.

Upvotes: 5

Related Questions