3 ms·
Presumably you are familiar with Boehm's famous "Threads Cannot be Implemented as a Library" [1]. Meanwhile, pthreads require heavyweight OS involvement and imp
by jedbrown 14y ago
Presumably you are familiar with Boehm's famous "Threads Cannot be Implemented as a Library" [1]. Meanwhile, pthreads require heavyweight OS involvement and implementing a simple spinlock requires inline assembly or non-portable compiler builtins. There is still no widely-used portable library of atomics (the Linux kernel is the most complete I know of, but their atomic support isn't trivial to extract for use outside the kernel, and it was only written for one compiler (gcc)). I'm definitely looking forward to stdatomic.h. Unfortunately, compilers are already mis-applying [2] the macros that are supposed to be available for determining the presence of thread and atomic support, so, as usual, configure tests are needed for everything.
[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
- kev009 14y agoWidely used, not yet.. but meet http://concurrencykit.org/ http://concurrencykit.org/
- jedbrown 14y agoThat's an interesting project, but it doesn't qualify as portable yet since it's currently entirely dependent on gcc inline assembly syntax and doesn't support a number of important architectures, including ARM. Thanks for sharing though, I'll keep an eye on it.
- kev009 14y agoIt is _portable_. It's not intensively _ported_ yet: Archs: Power, SPARCv9, x86, x86-64 Compilers: gcc, clang, icc, suncc Adding a wildly different compiler shouldn't be the end of the world but it would need some build sys work and a new compiler wrapper. Samy was focusing on a few archs that help debug the code. I got him access to the GCC build farm, but the ARM boxes there were fairly weak when I remember. Access to good hardware might help him move it along.