Hacker News Reader

Comment by Patient0 | Hacker News Reader

Oh man, now that lock free programming is such a hot topic I am dreading the code about to be written by people "teaching themselves" about it!

"This algorithm is much faster now that I've used some lock free programming techniques I just read about!!!"

Code that works correctly on x86 but fails intermittently on another processor. It's like a nightmare unfolding...

View on HN

Code that works correctly on that particular programmer's x86 machine, you mean. "Works great on my PC at home and at work" does not necessary imply "Works great on the 64 CPU production machine in the datacenter".

This stuff is terrifying.

All the more reason to do our best to organize and share correct information about it.

Yes and at least the article makes it pretty clear just how complicated and subtle the issues are.

Shouldn't atomics behave similarly across all platforms? I am thinking of the GCC builtin atomics [1].

What sort of code are you thinking about? Even lower-level / non-abstracted atomics and memory fences that are specific to a particular architecture? I actually did run into code like this for a MIPS-based CPU and we converted the code to using the GCC builtins for portability. Funny thing is that the next hardware architecture toolchain wasn't GCC-based, so there was no benefit... we had to make wrappers for the atomics... and hunt down some absurd bugs related to L2 cache writebacks and mem fences. It was an exercise in how long I could stick with a problem... some serious hunting and staring at debug output / hex dumps..

[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins....

Reply on news.ycombinator.com