我在代码中大量使用<thread> <atomic> <mutex>等，其中包括几个无锁算法。我的目标是（最终）一个linux环境。我一直在开发Visual Studio 2011 Beta，虽然在其他C ++ 11功能中缺乏可怕性，但它似乎是实现并发功能的唯一工具链。
请参阅此处的c ++ 11支持：
现在，如果其他人只是缺少一个包含c ++ 11并发功能的库，我可以轻松使用just::thread，但是clang和gcc都对c ++ 11内存模型回答“否”，这至少是视觉效果c ++似乎支持。我不确定这会产生什么影响 - 可能会优化掉明显无副作用的代码，以及其他错误的东西。
如果现在我完全避免优化构建并且仅编译调试版本而不启用优化 - 使用Clang或GCC工具链是否合理？
答案 0 :(得分：4)
C ++内存模型工作正在进行中并计划在中完成 下一届GCC发布。 GCC 4.7现已发布，所以这就是你 可以期待它。
- 支持无锁指令的完全原子实现。所有原子操作都已使用新的__atomic实现 builtins，大多数目标反映了内存模型参数 生成的代码。优化不会移动共享内存 经过原子操作的操作，各种各样的事情发生了 关系很荣幸。
- 当无锁指令不可用时（通过硬件或OS支持），原子操作将保留为函数调用 由图书馆解决。由于时间限制和API 尚未最终确定，GCC 4.7没有提供libatomic。这是 很容易通过遇到不满意的外部符号来确定 以_ atomic *。
开头- 如果程序需要库帮助，可以使用单个C文件样本实现进行编译和链接 客户端程序使用锁定来解析这些外部函数调用 实现。下载样本libatomic
- C ++模板完全支持任意大小的对象，虽然前面提到的libatomic.c文件可能需要满足一些 用户定义的类。如果类映射到支持的大小相同 无锁积分类型，然后也将使用无锁定例程。
- 位域不符合内存模型。也就是说，由于整个单词，他们可能会引入加载或存储数据竞争 阅读或写作时访问。
- 虽然已完成一些工作，但尚未对合规性进行全面审核。一些优化可能会引入新数据 之前没有出现过的比赛。已知案件的数量是 很小，并且测试合规性并非易事。如果有人遇到 如果优化引入了新的数据竞争，请打开一个 bugzilla案例因此可以解决。
LLVM中的支持似乎更进一步：http://llvm.org/releases/3.0/docs/Atomics.html
很难说这实际上在clang中使用了多少程度。似乎<atomic>基本上适用于某些类型。我正在为其他类型获得编译器断言，说原子类型是意外的，这对它所使用的类型有一点信心。
答案 1 :(得分：1)
我在64位linux和windows上使用了gcc-4.7并取得了成功。即使使用gcc-4.6，std::thread等在Linux上运行也很完美
在Windows上gcc-4.7（mingw64）有一些小问题，内存泄漏与std::condition_variable AFAIR的析构函数。