[Mingw-users] What thread library to use?

Hi !

I think that what you're looking for are POSIX-thread (aka pthreads), allmost every *nix operating system provide an implementation. AFAIK MinGW provides a wrapper for pthreads (win-pthreads if i remember well). However i don't know flags to be passed to linker (probably -pthread or -lpthread).

Regards,
Romain

John Pote <***@o2.co.uk> wrote:

Hello,
Have been using Mingw recently to restore my 'C' skills on a PC rather
than the microcontrollers I usually code for. (My PC is XP Professional)

I want to add threads to my application and would appreciate suggestions
as to apprepriate thread library(s) to use. Does one come with the
normal Mingw distro? Is there a library/API that runs with Windows, xNIX
and or Mac OS X? It would be nice to think that the same code could run
on all three major OSs.

Any help appreciated,
Regards,
John

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.Â Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

Kyle Ketterer

2014-04-07 12:33:28 UTC

If C++ is possible for you, definitely look at Boost.Thread. Boost.Thread
with ASIO is some pretty powerful stuff.

For C, OpenMP is what you want.

Eli Zaretskii

2014-04-07 15:56:49 UTC

Date: Mon, 07 Apr 2014 11:59:42 +0100
I want to add threads to my application and would appreciate suggestions
as to apprepriate thread library(s) to use. Does one come with the
normal Mingw distro? Is there a library/API that runs with Windows, xNIX
and or Mac OS X? It would be nice to think that the same code could run
on all three major OSs.

Windows provides its own native thread APIs, so you could use them.

Keith Marshall

2014-04-07 18:47:49 UTC

Windows provides its own native thread APIs, so you could use them.

If I were writing for MS-Windows only, or if I were willing to write the
code differently for individual platforms, then that would be my choice
too. However, since the OP has expressed a preference for code which
may be expected to compile, unchanged, for disparate platforms, pthreads
may be a more attractive choice -- since GCC itself demands pthreads
support, for multi-processor aware (libgomp) applications, we do
provide, of necessity, a pthreads implementation for use with MinGW, as
an alternative to native Windows threads.

Another responder has suggested Boost threads (for C++); that's
certainly an option which may be worthy of consideration, but it's an
option which we do not directly support here, so you would need to seek
further advice elsewhere. This same responder also suggested OpenMP,
(for C, although it may be equally suitable for C++); AFAIK, that's just
another way of saying "pthreads", (because libgomp is GCC's
implementation of OpenMP, and libgomp uses pthreads).

--
Regards,
Keith.

Eli Zaretskii

2014-04-07 19:47:28 UTC

Date: Mon, 07 Apr 2014 19:47:49 +0100

Windows provides its own native thread APIs, so you could use them.

Suit yourself, but I find pthreads to have "issues". E.g., Guile
compiled with pthreads hangs when it tries to start one more thread.
So my advice is still to go native, it's not like hiding Windows
thread APIs behind some wrappers is hard. Portable APIs are great
when the ports are dependable; unfortunately IME pthreads are not.

K. Frank

2014-04-07 21:33:42 UTC

Hello Eli!

Date: Mon, 07 Apr 2014 19:47:49 +0100

Date: Mon, 07 Apr 2014 11:59:42 +0100
I want to add threads to my application and would appreciate suggestions
as to apprepriate thread library(s) to use.
...

Windows provides its own native thread APIs, so you could use them.

...
we do
provide, of necessity, a pthreads implementation for use with MinGW, as
an alternative to native Windows threads.

I would be curious to know which windows port of pthreads (and which
version) you have had trouble with.

Keith Marshall

2014-04-07 23:43:05 UTC

Date: Mon, 07 Apr 2014 19:47:49 +0100
From: Keith Marshall

Date: Mon, 07 Apr 2014 11:59:42 +0100
From: John Pote
I want to add threads to my application and would appreciate suggestions
as to apprepriate thread library(s) to use.
...

Windows provides its own native thread APIs, so you could use them.

...
we do
provide, of necessity, a pthreads implementation for use with MinGW, as
an alternative to native Windows threads.

Suit yourself, but I find pthreads to have "issues". E.g., Guile
compiled with pthreads hangs when it tries to start one more thread.
So my advice is still to go native, ...

It's not a matter of suiting myself; I do tend to favour the native
APIs, for my own applications. I was merely pointing out that pthreads
may be a better fit, given the OPs stated preference for a consistent
cross platform API. Of course, if the OP does choose this option, he
should take note of various limitations, and feature omissions, as noted
in the pthreads-w32 source distribution.

Post by Eli Zaretskii
... it's not like hiding Windows thread APIs behind some wrappers
is hard. Portable APIs are great when the ports are dependable;
unfortunately IME pthreads are not.

I would be curious to know which windows port of pthreads (and which
version) you have had trouble with.

As would I. While I do favour the native API for my own work, I'm not
aware of any complaints having been made previously, about the pthreads
implementation which we offer, (and which is required for our GCC-4.x to
support libgomp, and so provide multi-processor support.

Eli Zaretskii

2014-04-08 17:47:44 UTC

Date: Tue, 08 Apr 2014 00:43:05 +0100

Post by K. Frank
I would be curious to know which windows port of pthreads (and which
version) you have had trouble with.

As would I.

See my other message in this thread. I don't think this is a bug in
some particular version of pthreads-w32, though.

While I do favour the native API for my own work, I'm not aware of
any complaints having been made previously, about the pthreads
implementation which we offer, (and which is required for our
GCC-4.x to support libgomp, and so provide multi-processor support.

I debugged the problem quite a lot and published the details. You
should be able to find that in the archives of the Guile mailing list.
No one on the Guile list was able to suggest any ideas as to why the
hang could happen.

For all I know, this could be a problem specific to how Guile uses
pthreads. But note that the same code works flawlessly on GNU/Linux,
so -- and this is the important part for me -- pthreads is not really
a 100% reliable portable library, at least in this important use case.

Note that, when configured without threads, Guile compiles with MinGW
and works without any problems whatsoever.

Eli Zaretskii

2014-04-08 17:41:36 UTC

Date: Mon, 7 Apr 2014 17:33:42 -0400

Post by Eli Zaretskii
Suit yourself, but I find pthreads to have "issues". E.g., Guile
compiled with pthreads hangs when it tries to start one more thread.
So my advice is still to go native, it's not like hiding Windows
thread APIs behind some wrappers is hard. Portable APIs are great
when the ports are dependable; unfortunately IME pthreads are not.

I would be curious to know which windows port of pthreads (and which
version) you have had trouble with.

I used pthreads-w32 provided by the MinGW site (of course). At the
time (June 2013), the latest version there was
pthreads-w32-2.9.0-pre-20110507-2. I see that now there's a newer
version, pthreads-w32-2.9.1. But I don't think the version matters
here: a couple of weeks ago someone reported on the Guile list that he
tried to build the latest Guile with MinGW, I'm sure with the latest
pthreads-w32, and hit the same problem.

Matt D.

2014-04-08 21:38:30 UTC

Post by John Pote
Hello,
Have been using Mingw recently to restore my 'C' skills on a PC rather
than the microcontrollers I usually code for. (My PC is XP Professional)
I want to add threads to my application and would appreciate suggestions
as to apprepriate thread library(s) to use. Does one come with the
normal Mingw distro? Is there a library/API that runs with Windows, xNIX
and or Mac OS X? It would be nice to think that the same code could run
on all three major OSs.

Hi!

If you can use C++ (quite likely for a PC target), then `<thread>`
header is the standard (and thus cross-platform):
http://en.cppreference.com/w/cpp/thread
And, possibly more importantly, the `<future>` header -- in particular,
`std::async` is often a better tool for the job (like executing a
function in the background) than emulating the same functionality
manually via thread/create/join:
http://en.cppreference.com/w/cpp/thread/async

I would also add a very strong recommendation _AGAINST_ using
non-standard, platform-specific C-style APIs like PThreads in this
context -- these will not interoperate with standard C++ constructs
(like lambdas) seamlessly and will lose type-safety compared to standard
multithreading facilities (e.g., std::thread preserves types of function
arguments, while using pthreads requires you to drop to the
lowest-common-denominator (read: completely opt-out of the type system)
by using generic pointer / `void*`).

These platform-specific APIs are also (naturally) non-portable: note
that POSIX is just one platform among many, and limiting yourself to it
is hardly better than limiting yourself to, say, MFC/Win32 (which I
wouldn't recommend, either). In the end, it's bad practice that
unnecessarily limits the portability of your code and forces a
dependency (upon you and your potential users) on toolchains that happen
to support it.

// Naturally, PThreads are out of the running anyway, since you've
specified a requirement of "a library/API that runs with Windows, xNIX
and or Mac OS X?". PThreads do not fulfill this requirement.

If you're stuck with an ancient compiler that still doesn't respect the
standard, you can also use Boost.Thread, which is a practically a
drop-in replacement:
http://www.boost.org/libs/thread
That being said, there is a risk that a compiler with such a poor level
of standard support may also be buggy and/or unreliable in other ways
(IME, lack of updates and unpatched bugs often go together, of course
one can always gamble that "this time it's different") -- hence, I'd
perhaps consider not using such a compiler. Given that you're using a
PC, you have a wide variety of toolchains to choose from :-) -- hence,
there is absolutely no reason to limit yourself to
sub-optimal/non-standard/non-portable choices and suffer the consequences.

// Similarly, the latest C standard also supports multithreading, see
header |`<threads.h>|`: http://en.cppreference.com/w/c/thread
// Note, however, that the C standard makes this support optional (can
check via the ` __STDC_NO_THREADS__` macro).

Best regards,

Matt

Post by John Pote
Any help appreciated,
Regards,
John
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
MinGW-users mailing list
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/mingw-users

John Pote

2014-04-11 11:02:29 UTC

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. 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. API seems to be the same (as far as I've used it)
but the error messages and how you get them quite different. And since
handling errors can be a large and crucial part of an app.....

pthreads seems to be the way to go for the moment. 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

Post by Matt D.

Hi!
If you can use C++ (quite likely for a PC target), then `<thread>`
http://en.cppreference.com/w/cpp/thread
And, possibly more importantly, the `<future>` header -- in
particular, `std::async` is often a better tool for the job (like
executing a function in the background) than emulating the same
http://en.cppreference.com/w/cpp/thread/async
I would also add a very strong recommendation _AGAINST_ using
non-standard, platform-specific C-style APIs like PThreads in this
context -- these will not interoperate with standard C++ constructs
(like lambdas) seamlessly and will lose type-safety compared to
standard multithreading facilities (e.g., std::thread preserves types
of function arguments, while using pthreads requires you to drop to
the lowest-common-denominator (read: completely opt-out of the type
system) by using generic pointer / `void*`).
These platform-specific APIs are also (naturally) non-portable: note
that POSIX is just one platform among many, and limiting yourself to
it is hardly better than limiting yourself to, say, MFC/Win32 (which I
wouldn't recommend, either). In the end, it's bad practice that
unnecessarily limits the portability of your code and forces a
dependency (upon you and your potential users) on toolchains that
happen to support it.
// Naturally, PThreads are out of the running anyway, since you've
specified a requirement of "a library/API that runs with Windows, xNIX
and or Mac OS X?". PThreads do not fulfill this requirement.
If you're stuck with an ancient compiler that still doesn't respect
the standard, you can also use Boost.Thread, which is a practically a
http://www.boost.org/libs/thread
That being said, there is a risk that a compiler with such a poor
level of standard support may also be buggy and/or unreliable in other
ways (IME, lack of updates and unpatched bugs often go together, of
course one can always gamble that "this time it's different") --
hence, I'd perhaps consider not using such a compiler. Given that
you're using a PC, you have a wide variety of toolchains to choose
from :-) -- hence, there is absolutely no reason to limit yourself to
sub-optimal/non-standard/non-portable choices and suffer the consequences.
// Similarly, the latest C standard also supports multithreading, see
header |`<threads.h>|`: http://en.cppreference.com/w/c/thread
// Note, however, that the C standard makes this support optional (can
check via the ` __STDC_NO_THREADS__` macro).
Best regards,
Matt

K. Frank

2014-04-11 13:11:37 UTC

Hello John!

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

John Pote

2014-04-11 23:50:48 UTC

Thanks for the feedback and tips, most useful. My lack of C++ is proving
a general problem these days as so many embedded projects have used it.
Perhaps I should learn it. Anyway annotations below,

Post by K. Frank
Hello John!

Quit good or actually compliant? But if the semantics of the underlying
OS are different even a fully compliant compiler will produce code that
in some cases will behave differently on different OSs. I'm thinking
particularly of error conditions and their causes. It always seems to me
that the mark of a good application is how it handles fault conditions.
How I used to hate Windozes throwing up the uninformative message box
"missing dll". And for many apps much if not the majority of the code is
good (ie helpfull -- why did the problem occur) error handling.

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.

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

Isn't this an advantage? Any language can then be compliant with the
common OS standard.

Post by K. Frank
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.

If pthread_t is implimentation dependant, and isn't that the point of
using a typedef, then it is intended for passing info between the
library functions and should not be fiddled with. Assumptions, as my old
supervisor used to say, are dangerous things.

Post by K. Frank
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).

I used your ming-get version 0.6.2-beta-20131004-1 to install mingw but
could not find any pthreads files anywhere. Have downloaded them from
http://www.sourceware.org/pthreads-win32/.

Post by K. Frank
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.

Thanks for the tip, money's tight at the monent so I'll stick with my
old win32 desktop.

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
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
MinGW-users mailing list
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/mingw-users
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4355 / Virus Database: 3882/7330 - Release Date: 04/11/14

Emanuel Falkenauer

2014-04-11 23:25:35 UTC