What thread library to use?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

What thread library to use?

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.

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Romain Garbi
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 <[hidden email]> 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
[hidden email]

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:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Kyle Ketterer
In reply to this post by John Pote
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.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Eli Zaretskii
In reply to this post by John Pote
> Date: Mon, 07 Apr 2014 11:59:42 +0100
> From: John Pote <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Keith Marshall
On 07/04/14 16:56, Eli Zaretskii wrote:

>> Date: Mon, 07 Apr 2014 11:59:42 +0100
>> From: John Pote <[hidden email]>
>>
>> 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.

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.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Eli Zaretskii
> Date: Mon, 07 Apr 2014 19:47:49 +0100
> From: Keith Marshall <[hidden email]>
>
> On 07/04/14 16:56, Eli Zaretskii wrote:
> >> Date: Mon, 07 Apr 2014 11:59:42 +0100
> >> From: John Pote <[hidden email]>
> >>
> >> 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.
>
> 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.

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.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

K. Frank
Hello Eli!

On Mon, Apr 7, 2014 at 3:47 PM, Eli Zaretskii <[hidden email]> wrote:

>> Date: Mon, 07 Apr 2014 19:47:49 +0100
>> From: Keith Marshall <[hidden email]>
>>
>> On 07/04/14 16:56, Eli Zaretskii wrote:
>> >> Date: Mon, 07 Apr 2014 11:59:42 +0100
>> >> From: John Pote <[hidden email]>
>> >>
>> >> 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 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.

>From recollection, mingw (at least an older version) provided a copy
of pthreads-win32.  Is this the port you found buggy, and is the bug
you see a known issue?


Thanks for any info about this.


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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Keith Marshall
On 07/04/14 22:33, K. Frank wrote:

> On Mon, Apr 7, 2014 at 3:47 PM, Eli Zaretskii wrote:
>>> Date: Mon, 07 Apr 2014 19:47:49 +0100
>>> From: Keith Marshall
>>>
>>> On 07/04/14 16:56, Eli Zaretskii wrote:
>>>>> 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.

>> ... 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.

> From recollection, mingw (at least an older version) provided a copy
> of pthreads-win32.

Yes, this is the case.  It is today, and AFAIK always has been, an
unmodified copy from https://www.sourceware.org/pthreads-win32/, (with
their 2.9.1 release being our current offering).

--
Regards,
Keith.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Eli Zaretskii
In reply to this post by K. Frank
> Date: Mon, 7 Apr 2014 17:33:42 -0400
> From: "K. Frank" <[hidden email]>
>
> > 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.

> >From recollection, mingw (at least an older version) provided a copy
> of pthreads-win32.  Is this the port you found buggy, and is the bug
> you see a known issue?

Indeed, see above.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Eli Zaretskii
In reply to this post by Keith Marshall
> Date: Tue, 08 Apr 2014 00:43:05 +0100
> From: Keith Marshall <[hidden email]>
>
> > 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.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Matt P. Dziubinski
In reply to this post by John Pote
On 4/7/2014 12:59, John Pote 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.
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




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
[hidden email]

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: [hidden email]


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

John Pote
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

On 08/04/2014 22:38, Matt D. wrote:
On 4/7/2014 12:59, John Pote 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.
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



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
[hidden email]

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: [hidden email]

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

K. Frank
Hello John!

On Fri, Apr 11, 2014 at 7:02 AM, John Pote <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

Emanuel Falkenauer
Hello,

Just trying to contribute a piece of experience: we've been using
pthreads in Mingw since ages, both in 32 and 64 bits, and it works
extremely well for us (and we're in some rather serious multi-threaded
algorithms). I am extremely surprised a previous post mentioned "glitches".

All the best,

Emanuel


On 11-Apr-14 15:11, K. Frank wrote:

> Hello John!
>
> On Fri, Apr 11, 2014 at 7:02 AM, John Pote <[hidden email]> 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
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
>
> 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:[hidden email]?subject=unsubscribe


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: What thread library to use?

John Pote
In reply to this post by K. Frank
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,

On 11/04/2014 14:11, K. Frank wrote:

> Hello John!
>
> On Fri, Apr 11, 2014 at 7:02 AM, John Pote <[hidden email]> 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.
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.
> 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.
Isn't this an advantage? Any language can then be compliant with the
common OS standard.
>
> 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.
>
> 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/.

>
> 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
> [hidden email]
>
> 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:[hidden email]?subject=unsubscribe
>
>
> -----
> 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
>
>


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe