
Multithreading in modern C++ - ingve
http://www.modernescpp.com/index.php/multithreading-in-modern-c
======
jwilk
Am I missing something, or is this article virtually content-free?

~~~
cbsmith
Wait, the domain is called "modernescpp.com", that's Modern _s_ Cpp... not
Modern Cpp.

Wow, that's not good....

~~~
capote
Assuming in German C++ is neuter, and referred to with the _das_ article,
_Modernes Cpp_ is correct and singular.

~~~
77pt77
> German C++ is neuter

neuter, was that intentional?

~~~
iso-8859-1
Hover over the n here:
[https://en.wiktionary.org/wiki/Plus#German](https://en.wiktionary.org/wiki/Plus#German)

------
maxlybbert
It's been five years (and two standard revisions). Can we stop calling C++11 a
new standard?

~~~
2bitencryption
Standards are not adopted overnight. C++11 is still, effectively, a "new"
standard.

~~~
maxlybbert
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](http://www.wall.org/~larry/pm.html) ) "Do
you know when New College was founded. Any guesses? New College was new in
1379."

------
ansible
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/](https://software.intel.com/en-us/intel-tbb/)

~~~
iheartmemcache
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](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.

~~~
ansible
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...](https://software.intel.com/en-us/forums/intel-threading-building-
blocks/topic/495003)

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.

~~~
iheartmemcache
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 :)

------
haberman
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... :)

------
billpg
Is algorithmen the plural for algorithm?

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

~~~
jwilk
Apparently you can become famous by proof-reading this guy's articles:
[http://www.modernescpp.com/index.php/for-the-proofreaders-
an...](http://www.modernescpp.com/index.php/for-the-proofreaders-and-the-
curious-people)

oO

~~~
kuschku
German Humor.

------
72deluxe
Probably more interesting is to read cppreference's examples on std::thread:
[http://en.cppreference.com/w/cpp/thread/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](https://isocpp.org/files/papers/P0024R2.html)

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

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

------
chris_wot
The next article should be interesting!

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

~~~
matthewaveryusa
Herb Sutter addresses this issue in his latest post:
[https://herbsutter.com/2016/03/11/trip-report-winter-iso-
c-s...](https://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-
meeting/)

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.

------
educar
Why is this on the front page? Completely void of meaningful content. It just
throws around some cpp standards :/

------
known
Wow

