Multithreading in modern C++(modernescpp.com)
modernescpp.com
Multithreading in modern C++
http://www.modernescpp.com/index.php/multithreading-in-modern-c
40 comments
Am I missing something, or is this article virtually content-free?
You are not missing anything.
Wait, the domain is called "modernescpp.com", that's Moderns Cpp... not Modern Cpp.
Wow, that's not good....
Wow, that's not good....
That's intentional as it is a translation of a German blog:
> Because the roots of my blogs are in German, I will continue to call him Modernes C++. That is not by mistake.
http://www.modernescpp.com/index.php/warum-einen-blog-zu-mod...
Not saying it's a good decision...
> Because the roots of my blogs are in German, I will continue to call him Modernes C++. That is not by mistake.
http://www.modernescpp.com/index.php/warum-einen-blog-zu-mod...
Not saying it's a good decision...
I'd would say that even in German, the brand was pretty well established: http://www.amazon.de/Modernes-Design-Programmierung-Entwurfs...
Assuming in German C++ is neuter, and referred to with the das article, Modernes Cpp is correct and singular.
No, I totally get that it is a German variant of the English expression "Modern C++", but you have a fair bit of overlap with a very well established brand in the C++ community...
It is.
> German C++ is neuter
neuter, was that intentional?
neuter, was that intentional?
Hover over the n here: https://en.wiktionary.org/wiki/Plus#German
It's been five years (and two standard revisions). Can we stop calling C++11 a new standard?
Standards are not adopted overnight. C++11 is still, effectively, a "new" standard.
I realize that many projects haven't made the switch, and in some cases they have good reasons to be cautious. And I realize that many programmers aren't familiar with the various changes, even after five (or more) years to catch up.
But that doesn't change the age of the standard, or the fact that C++14 was published, and the Committee is finishing up C++17. At some point it's silly to call C++11 "new." "Unfamiliar," sure, but not "new." It reminds me of Larry Wall's talk ( http://www.wall.org/~larry/pm.html ) "Do you know when New College was founded. Any guesses? New College was new in 1379."
But that doesn't change the age of the standard, or the fact that C++14 was published, and the Committee is finishing up C++17. At some point it's silly to call C++11 "new." "Unfamiliar," sure, but not "new." It reminds me of Larry Wall's talk ( http://www.wall.org/~larry/pm.html ) "Do you know when New College was founded. Any guesses? New College was new in 1379."
The industry is still in the process of adopting it. My workplace only switched over six months ago. (That had been annoying, as I picked it up in roughly 2013, and it was hard to unlearn the new habits when I started working here.)
My recollection is that C99 took roughly ten years to go from "the new thing" to "normal".
My recollection is that C99 took roughly ten years to go from "the new thing" to "normal".
Tell that to embedded system guys still having to deal with C++98, not even C++03.
Really depends on where you go. In our office, we use C++11 functionality in our AVR chips.
So I had been looking at threading for an embedded system recently.
I found Intel's Thread Building Blocks [1] which looked exactly like what I wanted.
Unfortunately, there are some long-standing issues with the ARM port, to the point that the included unit tests take a long time and/or crash on ARM (in this case it was on a Nvidia Jetson TK1).
If I had more time and expertise, I'd have tried to debug that further.
So is there anything else in that direction I should be looking at?
[1] https://software.intel.com/en-us/intel-tbb/
I found Intel's Thread Building Blocks [1] which looked exactly like what I wanted.
Unfortunately, there are some long-standing issues with the ARM port, to the point that the included unit tests take a long time and/or crash on ARM (in this case it was on a Nvidia Jetson TK1).
If I had more time and expertise, I'd have tried to debug that further.
So is there anything else in that direction I should be looking at?
[1] https://software.intel.com/en-us/intel-tbb/
1: Which ARM? (Designing for a Cortex M0+ is entirely different from an M3 is from ...)
2: What are your design contraints? (Do you have hard-real time requirements? If so, you're probably going to want to use the primitives that come with the RTOS (QNX/Green Hills Integrity/all-the-major-players have their own method of "IPC/threading/whatever you want to call it" and it's usually an Erlang-esque message passing component.)
3: I'm presuming you're going for automotives, in which case lol, TBB rules but you'll never get ISO 26262 certification using it. If it's for an entertainment thinger just use QNX like everyone else.
4: "Unit tests take a long time and/or crash.." I'm sure the TK1 has ETM (which is better than bondout chips, seriously).
Just look at this[1] (then get your manager to bring me in as a consultant - it pains me to hear you have "long-standing issues with an ARM port" and the way your team-lead thinks he can solve it is with unit tests). "Long time to load which sometimes fails entirely" is a race condition. Insure++ is the "Coverity" for embedded (just as expensive, just as wonderful).
[1] http://i.imgur.com/wcqlon7.png -- how your team lead should be actually debugging embedded components. If you give me more details re: your system/functional/integration requirements, I can likely tell you in which direction to move though.
2: What are your design contraints? (Do you have hard-real time requirements? If so, you're probably going to want to use the primitives that come with the RTOS (QNX/Green Hills Integrity/all-the-major-players have their own method of "IPC/threading/whatever you want to call it" and it's usually an Erlang-esque message passing component.)
3: I'm presuming you're going for automotives, in which case lol, TBB rules but you'll never get ISO 26262 certification using it. If it's for an entertainment thinger just use QNX like everyone else.
4: "Unit tests take a long time and/or crash.." I'm sure the TK1 has ETM (which is better than bondout chips, seriously).
Just look at this[1] (then get your manager to bring me in as a consultant - it pains me to hear you have "long-standing issues with an ARM port" and the way your team-lead thinks he can solve it is with unit tests). "Long time to load which sometimes fails entirely" is a race condition. Insure++ is the "Coverity" for embedded (just as expensive, just as wonderful).
[1] http://i.imgur.com/wcqlon7.png -- how your team lead should be actually debugging embedded components. If you give me more details re: your system/functional/integration requirements, I can likely tell you in which direction to move though.
It was a ARM Cortex-A15 SoC. And we're going to have to use regular threads.
Just look at this[1] (then get your manager to bring me in as a consultant - it pains me to hear you have "long-standing issues with an ARM port" and the way your team-lead thinks he can solve it is with unit tests). "Long time to load which sometimes fails entirely" is a race condition. Insure++ is the "Coverity" for embedded (just as expensive, just as wonderful).
I think you misunderstand.
The platform already shipped with TBB. However, when I recompiled TBB from source, the unit tests that came with TBB (which are just peachy on my desktop) took either a long time to run, or crashed. I didn't have to write any unit tests myself.
Before doing any hardcore debugging, I looked around a little and found this:
https://software.intel.com/en-us/forums/intel-threading-buil...
Which still doesn't seem to be fixed correctly in the latest release. That's from 2013, hence the 'long standing issues'. I gave up on TBB before spending much time on it.
Just look at this[1] (then get your manager to bring me in as a consultant - it pains me to hear you have "long-standing issues with an ARM port" and the way your team-lead thinks he can solve it is with unit tests). "Long time to load which sometimes fails entirely" is a race condition. Insure++ is the "Coverity" for embedded (just as expensive, just as wonderful).
I think you misunderstand.
The platform already shipped with TBB. However, when I recompiled TBB from source, the unit tests that came with TBB (which are just peachy on my desktop) took either a long time to run, or crashed. I didn't have to write any unit tests myself.
Before doing any hardcore debugging, I looked around a little and found this:
https://software.intel.com/en-us/forums/intel-threading-buil...
Which still doesn't seem to be fixed correctly in the latest release. That's from 2013, hence the 'long standing issues'. I gave up on TBB before spending much time on it.
Got you - inherited a codebase from someone else - worked fine on your x86(-64/whatever), tried it against your ARM, intermittent failures.
Seems compiling with the -O0 flag fixed some issues for a few chaps, worth a shot I'd imagine, though you've seemed to completed your alternate implementation for the ARM platform.
Alternatively, the TBB errors seem to be when using a gcc deriv that depends on GNU as. Now VS can build ARM binaries (at least, ARM LE bins). It'd be interesting to see if that solves the problem.
What did you end up using instead of TBB? Stock Pthreads/pth? Or did you go with something lighter? Regardless, next time you have to write for embedded stuff hopefully you have a new tool in your belt that'll save you from frustration :)
Seems compiling with the -O0 flag fixed some issues for a few chaps, worth a shot I'd imagine, though you've seemed to completed your alternate implementation for the ARM platform.
Alternatively, the TBB errors seem to be when using a gcc deriv that depends on GNU as. Now VS can build ARM binaries (at least, ARM LE bins). It'd be interesting to see if that solves the problem.
What did you end up using instead of TBB? Stock Pthreads/pth? Or did you go with something lighter? Regardless, next time you have to write for embedded stuff hopefully you have a new tool in your belt that'll save you from frustration :)
Has nothing to do with the topic, but nevertheless a short comment on (3):
Not really, QNX is quite on the decline here. I know more than 2 major OEMs (and their suppliers) which switched to Linux. I still know some QNX users, but overall Linux looks like the more common thing fur current projects. WinCE was also a major candidate some years ago, but it's now mostly discontinued (no new Windows for Automotive version).
Not really, QNX is quite on the decline here. I know more than 2 major OEMs (and their suppliers) which switched to Linux. I still know some QNX users, but overall Linux looks like the more common thing fur current projects. WinCE was also a major candidate some years ago, but it's now mostly discontinued (no new Windows for Automotive version).
Shoot, I have been working on an article describing the C11/C++11 memory model for many months, but it looks like he's going to beat me to it! Oh well, there can be 2 (or 3, or 4... :)
Is algorithmen the plural for algorithm?
I think this is a translation error. The article is possibly an English translation of an article that was originally written in German. Algorithmen is the plural for algorithm in German.
The entire page is a translation of blog articles that already exist in German.
http://www.grimm-jaud.de/index.php/blog/multithreading-in-mo...
Dozens of follow up articles are on the blog in German.
http://www.grimm-jaud.de/index.php/blog
The Author has published several German books on C++
http://www.grimm-jaud.de/
I have never read any of the books or blog posts, so can't say anything on the quality.
http://www.grimm-jaud.de/index.php/blog/multithreading-in-mo...
Dozens of follow up articles are on the blog in German.
http://www.grimm-jaud.de/index.php/blog
The Author has published several German books on C++
http://www.grimm-jaud.de/
I have never read any of the books or blog posts, so can't say anything on the quality.
Apparently you can become famous by proof-reading this guy's articles:
http://www.modernescpp.com/index.php/for-the-proofreaders-an...
oO
oO
German Humor.
Probably more interesting is to read cppreference's examples on std::thread: http://en.cppreference.com/w/cpp/thread/thread
Also, the technical specification for parallel STL algorithms might make interesting reading: https://isocpp.org/files/papers/P0024R2.html
Also, the technical specification for parallel STL algorithms might make interesting reading: https://isocpp.org/files/papers/P0024R2.html
C++ was supposed to be portable.
When you add a layer of threading, networking, etc. you are starting to commit to specifics of operating systems.
It's fine to keep this at a library level, and promote that library to be an standard on specific platforms. But C++ should not get tainted with OS specifics.
It's fine to keep this at a library level, and promote that library to be an standard on specific platforms. But C++ should not get tainted with OS specifics.
On the contrary having a big runtime is what makes a language portable by abstracting it from OS specific APIs.
I only care about OS specific code when using C or C++, not any other language with richer runtimes.
Actually, C's runtime is called UNIX and is packaged as POSIX for non-UNIX OSes.
Any C or C++ developer that wants "portable" code needs to litter their code with #ifdefs, for any dependency not on the standard library.
I only care about OS specific code when using C or C++, not any other language with richer runtimes.
Actually, C's runtime is called UNIX and is packaged as POSIX for non-UNIX OSes.
Any C or C++ developer that wants "portable" code needs to litter their code with #ifdefs, for any dependency not on the standard library.
i'm pretty sure they're talking about adding these "layers" at the C++ stdlib level, not at the language level. So it will remain portable.
The next article should be interesting!
Is this a joke about unending C++ standards with each one promising more and more cool features people patiently wait for and then when it's finalized it turns out that the coolest/most useful stuff got delayed again?
This is what sprung to mind anyway.
This is what sprung to mind anyway.
Herb Sutter addresses this issue in his latest post: https://herbsutter.com/2016/03/11/trip-report-winter-iso-c-s...
I agree, it feels like not a lot, but when you look at the standardization process I think it's safe to say that healthy progress has been made on most if not all the promises made.
I agree, it feels like not a lot, but when you look at the standardization process I think it's safe to say that healthy progress has been made on most if not all the promises made.
I wish I was that clever.
[deleted]
Why is this on the front page? Completely void of meaningful content. It just throws around some cpp standards :/
Wow