ConcRT同步结构与标准库

Question

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

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

P.S。此问题涉及并发运行时中的所有同步结构（critical_section，reader_writer_lock＆amp; event） 我还遗漏了WinAPI的CRITICAL_SECTION，MUTEX，SRW等，假设它们是最快最轻的解决方案（但不是最漂亮的）。

Answer 1

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

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