如果我的应用程序以Windows为目标并且已经在其中某些部分使用了并发运行时。在ConcRT任务之外，使用ConcRT同步结构(concurrency:critical_section)比标准库实现(std::mutex)有什么优点/缺点？ (例如，同步WinAPI异步回调或管理dll导出函数之间的数据访问)
MSDN的<mutex>文档声明它基于ConcRT，但这是否意味着内部互斥使用Critical_section，因此在所有情况下均较慢，因此仅在可移植性方面具有优势？
或者，相反，critical_section是专为与ConcRT调度程序一起使用而设计的，当与OS线程一起使用时，这是一个很大的替代方法吗？
附言这个问题涉及并发运行时中的所有同步结构(critical_section，reader_writer_lock和event)。
我还忽略了WinAPI的CRITICAL_SECTION，MUTEX，SRW和其他，假定它们是最快，最轻便的解决方案(但不是最漂亮的)。
最佳答案
我必须将std:mutex更改为concurrency::critical_section，因为它的行为实际上有所不同:当互斥锁阻塞时，它只是阻塞，而当critical_section阻塞时，ConcRT将启动/重用新线程(如果有)。就我而言，由于这种差异，我在进行切换之前失去了很多并行性。
请参见http://msdn.microsoft.com/en-us/library/ff601929.aspx，“在可能时使用协作同步构造”
关于c++ - ConcRT同步结构与标准库，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18263937/