Portability of pthreads-win32 over various windows compilers

Question

I\'m using pthreads-win32 to allow threading support for windows.

I have a cross platform project that uses pthreads and I want to make it work on windows with various c

Answer 1

Surprised that nobody has suggested Intel's Thread Building Blocks. They're very active and support virtually everything, with the newest release being less than two weeks ago, and C++0x features if you use a compliant compiler.

http://software.intel.com/en-us/intel-tbb/#sysreq

Answer 2

Well, paxdiablo has apparently summed it up here. But from my past experience with this library, I can add a couple of things here.

Firstly, I had used a subset of the library's functions with MSVC 2008 without any problems whatsoever.

Secondly, some of my colleagues have got it going on the x86_64 (with MSVC2008 and MinGW). They haven't faced any issue either after many a cycles of beta and QA testing. Though I haven't tested it myself so can't be very sure on this one.

So by the looks of the things, it might be fit for use. The only caveat here is that if you find any issue you will be at the mercy of a not-so active mailing list (or perhaps you may want to get your hands dirty with the source code or something like that).

Answer 3

Can't say for certain and this may not be what you want to hear but, given that the last release is dated 2006, I'd be very wary of using this in the latest compilers. It may work but it's probably going to be up to you to get it going. There seems to be a lot of discussion about getting it working in Cygwin and MinGW but precious little for MSVC, and nothing I can find beyond MSVC2005.

Also, if you examine the CVS archives, there are precious few files that have been updated in the last year (most are two to five years ago). The couple that are dated less than a year ago have the description "Comments and code style changes" which leads me to believe none of the meat of the product has been under active development for a while.

Now maybe I'm wrong and this is just an incredibly well-written, stable product but my inner nature is more likely to conclude it's one of the bazillions of good ideas that have gone by the wayside.

And, having a look at the mailing lists, there are only seven messages posted in the first five months of 2010 (the earliest of which has been unanswered for four months) and only 59 for the whole of 2009. Colour me sceptical but that doesn't seem like a massively vibrant support community.

There seems to be a patch for 64-bit Windows (see here in the 2010 archives) but, again, this appears to have problems which are unanswered since February and it only mentions support for MinGW:

... this patch (a bit rough and need some final cleaning up and some extension to the test run makefile for allowing CROSS here) enables pthread to be build for the x86_64-pc-mingw32 target.

This is not the sort of thing I'd be using for my mission-critical software.

And I know you stated that you're not interested in re-inventing the wheel but you can implement multi-reader locks and condition variables from the more basic primitives quite easily - I even had a multi-reader scheme that solved the write starvation problem in a way that almost got me a patent (not that I agree with software patents but my employer insists they're valuable).

And if the only wheel you have has half its spokes missing and is horribly bent out of shape, you may just need to reconsider :-)

In any case, Vista and Server2k8 introduced both condition variables and slim reader/writer locks. Thread-local storage has been around since Win2k. I know that won't help if you still need to support XP but I'd be looking to the future.

And since you seem to have defined portability as "Windows-only", and all the features you want are available in the current versions, I'm not sure I see an advantage to sticking with pthreads. If you wanted portability to POSIX, yes, but that doesn't seem to be the case here.