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?

Eulaeulachon

My immediate guess is that if you use just::thread, it'll work fine. It uses the native (Posix or Win32) primitives to enforce things like ordering, so I think a compiler would have to be pretty badly broken in general for it to fail. – Cowcatcher

You should probably include a multi-threaded related tag in your list, Anthony Williams regularly show up here, so if you are lucky enough he'll notice then. I think that he created just::thread so that it would be cross-platform, so I would not expect any issue. – Knack

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.

Dolan

This looks promising. I'm actually leaning toward clang because it seems to produce more helpful error messages - and that's a substantial time sync for me with c++. There's a experimental QtCreator that uses clang to implement the code model (completion, highlighting, refactorings, etc.) I'm going to give that a try, since I really miss my visual studio + visual assist x on linux. – Eulaeulachon

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.

Patty