If my application targets Windows and already uses Concurrency Runtime in some of it's parts. Is there any advantages/disadvantages of using ConcRT synchronization structures (concurrency:critical_section) over standard library implementation (std::mutex) outside of ConcRT tasks? (e.g. Synchronizing WinAPI async callbacks or managing data access between exported functions of dll)
MSDN documentation of <mutex> states that it is based on ConcRT, but does it mean that internally mutex uses critical_section and therefore slower in all situations, thus gives advantage only in portability?
Or, conversely, critical_section is designed specifically for using with ConcRT scheduler and is a huge overkill, when used with OS threads?
P.S. This question concerns all sync structures in Concurrency Runtime (critical_section, reader_writer_lock & event).
Also I left out WinAPI's CRITICAL_SECTION, MUTEX, SRW and other, assuming them as the fastest and lightest solutions (but not prettiest).
I had to change my std:mutex to concurrency::critical_section because it actually behaves differently: when a mutex blocks it simply blocks, when a critical_section blocks ConcRT will start/reuse a new thread (if available). In my case I lost a lot of parallelism due to this difference before I made the switch.
See http://msdn.microsoft.com/en-us/library/ff601929.aspx, "Use Cooperative Synchronization Constructs When Possible"