Concurrent C++11 - Which toolchains can be used?

Question

I use <thread> <atomic> <mutex> etc heavily in my code, which includes several lock-free algorithms. I am targeting (eventually) a linux environment. I've been developing with the Visual Studio 2011 Beta, which while lacking horribly in other C++11 features, seems to be the only toolchain that implements the concurrent features.

See c++ 11 support here:

• Clang 3+
• GCC 4.7
• MSVC 11

Now if the others simply lack a library containing the c++ 11 concurrent features, I can easily use just::thread, however both clang and gcc answer "no" to the c++11 memory model, which at least visual c++ seems to support. I'm not exactly sure what the effect of this would be - probably optimizing away of apparently side effect free code, among other erroneous things.

If for now I completely avoid optimized builds and compile only debug builds without optimizations enabled - is it reasonable to use the Clang or GCC toolchain?

Answer 1

GCC 4.7 status

C++ memory model work is ongoing and scheduled for completion in the next GCC release. GCC 4.7 has now been released, so this is what you can expect from it.

• Full atomic implementation for supported lock free instructions. All the atomic operations have been implemented with the new __atomic builtins, and most targets reflect the memory model parameter in the code which is generated. Optimizations will not move shared memory operations past atomic operations, so the various happens relationships are honoured.
• When lock free instructions are not available (either through hardware or OS support) atomic operations are left as function calls to be resolved by a library. Due to time constraints and an API which is not finalized, there is no libatomic supplied with GCC 4.7. This is easily determined by encountering unsatisfied external symbols beginning with _atomic*.
• Should a program require library assistance, a single C file sample implementation is available to be compiled and linked in with the client program to resolve these external function calls using a locked implementation. Download sample libatomic
• C++ templates fully support arbitrary sized objects, althought the previously mentioned libatomic.c file may be required to satisfy some user defined classes. If a class maps to the same size as a supported lock-free integral type, then lock-free routines will be used as well.
• Bitfields are not compliant with the memory model. That is to say that they may introduce load or store data races due to whole word accesses when reading or writing.
• Optimizations have not been fully audited for compliance, although some work has been done. Some optimizations may introduce new data races which were not present before. The number of known cases are small, and testing for compliance is not trivial. If anyone encounters a case where an optimization introduces a new data race, please open a bugzilla case for it so it can be addressed.

---

Support in LLVM seems to be further along: http://llvm.org/releases/3.0/docs/Atomics.html

It's hard to tell to what degree this is actually used in clang though. It seems like <atomic> basically works for some types. I'm getting compiler assertions for other types saying that the atomic type was unexpected, which gives a bit of confidence for the types it does work with.

Answer 2

I have used gcc-4.7 on 64 bit linux and windows with success. std::thread etc. works perfect on linux even with gcc-4.6.
On windows gcc-4.7 (mingw64) has some minor issues, memory leaks with destructors of std::condition_variable AFAIR.