[amadvance]

In truth, I prefer using explicit lock and unlock operations like in C programming. The visibility of these operations aids in understanding the interdependencies within the code.

[pavlov]

I could understand this argument against the RAII-style destructor unlock, but this lambda approach seems actually better in the visibility sense since the mutex access is a separately indented block.

[amadvance]

It's obviously subjective, but it looks like as any other indented block. Named "lock" and "unlock" operations are more explicit to me.

Another potential disadvantage, is that you lose the possibility to control the unlock order, when you have multiple nested locks.

[gpderetta]

An indented scope (that starts with a scoped_lock or some appropriately named function) is more explicit than lock/unlock calls interspersed in the code.

std::scoped_lock allows locking multiple locks.

[snozolli]

this lambda approach seems actually better in the visibility sense since the mutex access is a separately indented block.

When I'm writing multithreaded code, the first line of any block containing a RAII lock is the lock. Any subsection of code that needs another lock gets its own block.

[gpderetta]

I don't trust explicit lock and un lock operations abstractions in C, I always use inline asm to acquire and release my locks.

[cozzyd]

I don't trust asm. I write an array of machine code and execute that each time I want to lock and unlock a lock.

[MontagFTB]

In C++, RAII locking/unlocking also handles exceptions thrown across the lock seamlessly. Otherwise all lock work would have to be try/catch wrapped and handled correctly.

[loeg]

> Otherwise all lock work would have to be try/catch wrapped and handled correctly.

Alternatively, you could ensure your codebase does not use exceptions. (Which is common for "C-style" programmers like GP.)

[xeyownt]

Also the C construct is easy to understand. Whereas the template one is yet another challenge to test your knowledge of C++.