ConcRT 同步结构与标准库

Question

如果我的应用程序以 Windows 为目标并且已经在它的某些部分使用了并发运行时。在 ConcRT 任务之外，与标准库实现 (std::mutex) 相比，使用 ConcRT 同步结构 (concurrency:critical_section) 是否有任何优点/缺点？ （例如同步 WinAPI 异步回调或管理 dll 导出函数之间的数据访问）

<mutex> 的 MSDN 文档指出它基于 ConcRT，但这是否意味着内部互斥体使用critical_section，因此在所有情况下都较慢，因此仅在可移植性方面具有优势？
或者相反，critical_section 是专门为与 ConcRT 调度程序一起使用而设计的，并且在与 OS 线程一起使用时是一个巨大的过度杀伤力？

附：这个问题涉及并发运行时中的所有同步结构（critical_section、reader_writer_lock 和 event）。
我也忽略了 WinAPI 的 CRITICAL_SECTION、MUTEX、SRW 和其他，假设它们是最快和最轻的解决方案（但不是最漂亮的）。

Answer 1

我不得不将我的 std:mutex 更改为 concurrency::critical_section 因为它实际上表现不同：当互斥锁阻塞时它只是阻塞，当一个critical_section 阻塞时 ConcRT 将启动/重用一个新线程（如果可用）。就我而言，在我进行切换之前，由于这种差异，我失去了很多并行性。

参见http://msdn.microsoft.com/en-us/library/ff601929.aspx，“尽可能使用协作同步构造”