我在代码中大量使用<thread> <atomic> <mutex>etc，其中包括几种无锁算法。我的目标是（最终）一个 linux 环境。我一直在使用 Visual Studio 2011 Beta 进行开发，虽然它在其他 C++11 功能中非常缺乏，但似乎是唯一实现并发功能的工具链。
在此处查看 c++ 11 支持：
现在，如果其他人只是缺少包含 c++ 11 并发功能的库，我可以轻松使用just::thread，但是 clang 和 gcc 都对 c++11 内存模型回答“否”，至少 Visual c++ 似乎支持. 我不确定这会产生什么效果——可能优化掉明显无副作用的代码，以及其他错误的东西。
如果现在我完全避免优化构建并且只编译没有启用优化的调试构建 - 使用 Clang 或 GCC 工具链是否合理？
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.
我在 64 位 linux 和 windows 上成功使用了 gcc-4.7。std::thread等即使使用 gcc-4.6 在 linux 上也能完美运行。
在 Windows 上 gcc-4.7 (mingw64) 有一些小问题，内存泄漏与std::condition_variableAFAIR 的析构函数。