我在我的代码中大量使用了<thread> <atomic> <mutex>等，其中包括几个无锁算法。我的目标（最终）是一个Linux环境。我一直在用Visual Studio 2011 Beta进行开发，虽然在其他C++ 11功能中缺少可怕的东西，但似乎是实现并发功能的唯一工具链。并行C++ 11 - 可以使用哪些工具链？
见C++ 11的支持位置：
现在，如果别人根本没有包含C++ 11并发提供图书馆，我可以轻松地使用just::thread，但是clang和gcc都对C++ 11内存模型回答“no”，至少visual C++似乎支持这个模型。我不确定这会产生什么样的影响 - 可能会优化掉显然无副作用的代码以及其他错误的东西。
如果现在我完全避免优化构建，并且仅编译调试构建而未启用优化 - 使用Clang或GCC工具链是否合理？
我在64位linux和windows上使用过gcc-4.7，并且成功。即使使用gcc-4.6，也可以在linux上完美工作。
在窗口gcc-4.7（mingw64）有一些小问题，内存泄漏与std::condition_variable AFAIR析构。
C++内存模型的工作正在进行中，预计在未来 GCC释放完成。 GCC 4.7现在已经发布，所以这就是你可以从中得到的结果 。
- 支持无锁指令的完整原子实现。所有的原子操作都已使用新的__atomic 内置函数实现，并且大多数目标都反映了生成的代码 中的内存模型参数。优化不会通过原子操作移动共享内存 操作，因此会发生各种不同的关系。
- 当无锁指令不可用（通过硬件或操作系统支持）时，原子操作留作函数调用 以由库解析。由于时间限制以及未定稿的API，GCC 4.7中没有提供libatomic。这是 很容易通过遇到不满意的外部符号 开始于_ 原子 *。
- 如果程序需要库支持，则可以编译一个C文件样本实现并将其与 客户端程序链接，以使用锁定的 实现解决这些外部函数调用。下载libatomic示例
- C++模板完全支持任意大小的对象，尽管前面提到的libatomic.c文件可能需要满足某些 用户定义的类。如果一个类映射到与无锁整数类型相同的大小，则也将使用无锁定例程。
- 位域不符合内存模型。也就是说，他们可能会在读或写时由于整个单词 的访问而引入加载或存储数据竞争。
- 尽管已完成一些工作，但未对合规性进行全面审核。一些优化可能引入之前不存在的新数据 。已知案例的数量为 很小，并且对合规性的测试不是微不足道的。如果有人遇到 这种优化引入了新数据竞争的情况，请打开一个 bugzilla案例，以便解决。
支持在LLVM似乎走得更远：http://llvm.org/releases/3.0/docs/Atomics.html
这很难说，到什么程度，这是在铛实际使用不过。看起来好像<atomic>基本适用于某些类型。我收到了其他类型的编译器断言，说其原子类型是意外的，这使得它可以处理的类型有点信心。
这看起来很有前途。我实际上倾向于clang，因为它似乎产生更多有用的错误消息 - 这对我来说是一个实质性的时间同步C++。有一个实验性的QtCreator使用clang来实现代码模型（完成，高亮，重构等）。我将尝试一下，因为我真的很想念我的visual studio + visual basic x on linux。 – Eloff 2012-04-09 00:04:25
我的猜测是，如果你使用'just :: thread'，它会正常工作。它使用原生的（Posix或Win32）原语来强制排序等事情，所以我认为编译器通常会因为失败而被严重破坏。 – 2012-04-07 15:51:49
你应该在你的列表中包含一个多线程相关标签，Anthony Williams经常在这里出现，所以如果你足够幸运，他会注意到。我认为他创建了'just :: thread'，以便它是跨平台的，所以我不会期望任何问题。 – 2012-04-07 17:13:30