c++ - ConcRT synchronization structures vs Standard Library -

if application targets windows , uses concurrency runtime in of it's parts. there advantages/disadvantages of using concrt synchronization structures (concurrency:critical_section) on 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 based on concrt, mean internally mutex uses critical_section , therefore slower in situations, gives advantage in portability?
or, conversely, critical_section designed using concrt scheduler , huge overkill, when used os threads?

p.s. question concerns sync structures in concurrency runtime (critical_section, reader_writer_lock & event).
left out winapi's critical_section, mutex, srw , other, assuming them fastest , lightest solutions (but not prettiest).

i had change std:mutex concurrency::critical_section because behaves differently: when mutex blocks blocks, when critical_section blocks concrt start/reuse new thread (if available). in case lost lot of parallelism due difference before made switch.

see http://msdn.microsoft.com/en-us/library/ff601929.aspx, "use cooperative synchronization constructs when possible"