Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: