By: dmsc (no.more.delete@this.spam.please), December 6, 2014 4:12 am
Room: Moderated Discussions
Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on December 6, 2014 2:20 am wrote:
> > the compiler reducing the optimization possibilities. Having native atomics in C/C++ helps with that too.
>
> atomics are too low level for my use cases, but I have to confess that I still
> have to study (and maybe port my code to) the new C++ synchronization classes
>
> do you know if there is an equivalent to my example (using critical sections
> for locks) in the new C++ standard, I see there is std::lock_guard but it's based
> on std::mutex, so seems to map to Windows mutexes which is way too slow
>
At least GCC uses its own abstraction "gthread", which wraps pthread to implement std::mutex, on Linux ends up using futex, that should be as fast as windows CITICAL_SECTION.
On windows it's more complicated, as GCC stil tries to generate winxp compatible code, so it assumes no critical section support. That would probably change, as for example boost::mutex wraps critical sections on windows.
> > the compiler reducing the optimization possibilities. Having native atomics in C/C++ helps with that too.
>
> atomics are too low level for my use cases, but I have to confess that I still
> have to study (and maybe port my code to) the new C++ synchronization classes
>
> do you know if there is an equivalent to my example (using critical sections
> for locks) in the new C++ standard, I see there is std::lock_guard but it's based
> on std::mutex, so seems to map to Windows mutexes which is way too slow
>
At least GCC uses its own abstraction "gthread", which wraps pthread to implement std::mutex, on Linux ends up using futex, that should be as fast as windows CITICAL_SECTION.
On windows it's more complicated, as GCC stil tries to generate winxp compatible code, so it assumes no critical section support. That would probably change, as for example boost::mutex wraps critical sections on windows.