By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com), December 5, 2014 10:38 am
Room: Moderated Discussions
Konrad Schwarz (no.spam.delete@this.no.spam) on December 5, 2014 3:37 am wrote:
> This is why the monitor (mutex/condition variable) paradigm is so good:
> in the uncontended case, lock operations (should) reduce
> to not much more than an atomic check and lock of some sort.
No, a mutex needs to ensure that whatever happens within the lock/unlock pair is self-contained WRT other threads which means that - especially on weakly ordered architectures - you will need heavy-weight memory barriers both during acquisition (so that no memory operation after it is executed before the instruction that acquires the lock) and when unlocking (so that all previous memory operations are globally visible before the lock is released).
Atomic operations have their relatively common use cases and they can be a lot faster than locks.
> This is why the monitor (mutex/condition variable) paradigm is so good:
> in the uncontended case, lock operations (should) reduce
> to not much more than an atomic check and lock of some sort.
No, a mutex needs to ensure that whatever happens within the lock/unlock pair is self-contained WRT other threads which means that - especially on weakly ordered architectures - you will need heavy-weight memory barriers both during acquisition (so that no memory operation after it is executed before the instruction that acquires the lock) and when unlocking (so that all previous memory operations are globally visible before the lock is released).
Atomic operations have their relatively common use cases and they can be a lot faster than locks.