ConcRT同步结构VS标准库

如果我的应用程序面向Windows和已经使用并发运行时在它的一些部分。是否有使用ConcRT任务之外超过标准库的实现（std::mutex）ConcRT同步结构（concurrency:critical_section）的任何优点/缺点？（例如同步WinAPI的异步回调或DLL的导出函数之间管理数据的访问）ConcRT同步结构VS标准库

，它是基于ConcRT，但它意味着，在内部互斥使用CRITICAL_SECTION，因此在所有情况下要慢，的 <mutex>状态

MSDN文档因而给出仅在便携性方面有优势？
或者相反，critical_section是专门为使用ConcRT调度程序而设计的，并且在与OS线程一起使用时是一个巨大的矫枉过正？

P.S.这个问题涉及在并发运行时的所有同步结构（CRITICAL_SECTION，reader_writer_lock &事件）。
我也离开了WinAPI的的CRITICAL_SECTION，MUTEX，SRW等，假设他们是最快，最轻的解决方案（但不是最漂亮的）。

来源

2013-08-16 Andrew S

“*慢，因此在所有情况下*”是什么让那个必要吗？仅仅因为它是一个抽象并不意味着它更慢。 –

我以为这是可能的原因可能会比较慢。另外，如您所述，我还没有找到任何证据。 –

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

见http://msdn.microsoft.com/en-us/library/ff601929.aspx，“使用合作同步结构可能时”

来源

2013-08-16 07:02:03 Dix

但它的“协作线程模式”适用于OS线程或它仅适用于“任务”？还要考虑在代码之外生成被阻塞的线程的情况（例如，当您在dll中的代码是从多线程进程中调用的，并且您想要锁定它对单个资源的访问时） –

ConcRT同步结构VS标准库

回答

相关问题