Re: [Mingw-users] What thread library to use?

[K. F. <kfr...@gm...>]

Hello John!

On Fri, Apr 11, 2014 at 7:02 AM, John Pote <joh...@o2...> wrote:
> Thanks everyone for the replies. Sadly I've never gone down the C++ route so
> that's not an option for me. It would be interesting to know how compatible
> the C++ 'standard' libraries mentioned are across OSs and compilers, how
> much of a common denominator they impliment compared to the raw OSs APIs.

std::thread (and friends) are truly part of the C++ standard (as of C++11).
If you write standards-compliant code (e.g., no platform-specific extensions
or undefined behavior), then your code will be (by definition) portable across
standards-compliant implementations.  By now I think that many std::thread
implementations are quite good, so you can expect to get very good
compatibility across platforms.

> Write once run everywhere may be a bit of a pipe dream. I've found that the
> GCC docs about sockets are somewhat different to the Winsock docs.

But sockets are not part of the C++ standard.  Posix sockets and winsock
are admittedly different (although similar), so one has no expectation of
sockets code being cross-platform (and no language standard suggests
that it should be).

> ...
> pthreads seems to be the way to go for the moment.

Because you wish to stick with C, then pthreads will be your (most nearly)
cross-platform approach.  (If you were to use C++ then, as others have
recommended, std::thread would be the best choice.)

Note that pthreads is part of posix, and is a standard.  But it's an api
standard, and not part of any language standard (i.e., not part of the
C or C++ standard).  But linux and most (all?) versions of unix support
pthreads, as do third-party libraries on windows.

Be aware of one minor issue:  As I understand it, in pthreads (i.e., the
posix standard), pthread_t (e.g., the thing returned by pthread_self()) is
supposed to be an opaque handle to a thread.  But in linux and probably
all unix implementations, pthread_t is an integral type, and (as I understand
it) a lot of existing code that uses pthreads relies on pthread_t being an
integral type.

The pthreads library shipped with mingw (pthreads-win32) implements
pthread_t as a struct, and will therefore break some of the pthreads
code found in the wild (code that is presumably not compliant with the
posix pthreads standard).

This should not be a problem with your own code if you don't assume
that pthread_t is integral, but it could be a problem if you use a library
or code fragments that you copy form here or there.

I believe that winpthreads, the pthreads library shipped with mingw-w64
(Note that mingw-w64 is a separate project with a separate mailing list.)
does implement pthread_t as an integral type, and I believe this was one
of the motivations for developing winpthreads as an alternative to
pthreads-win32.

> I've just bought myself a
> Raspbarry PI to get some ARM/Linux experience so hopefully the API at least
> will cross over to the Raspberry pi in principle if not in all the details.
>
> Thanks again,
> John


Happy Multi-Threaded Hacking!


K. Frank