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