Roland Schwarz wrote:
Peter Dimov wrote:
Indeed, sorry for not paying attention. But the only point of locking a mutex is to be able to do that from two different threads at the same time. If you know that only one thread is accessing the scoped_lock at a time, you wouldn't need a scoped_lock in the first place.
Could you please provide an example where it is not possible to solve the problem with scoped_lock only? I simply cannot find one. Currently this would be the only "killer argument" for my proposed aggregate/POD type mutex. Therfore I am very interested in this.
The problem mainly arises when you have to implement an interface that has separate lock and unlock functions. class X { private: mutex mx_; public: void lock(); void unlock(); }; If you could change the interface of X and force its clients to use X::scoped_lock for locking, there wouldn't be a problem. But sometimes you can't; for example, you may be implementing a C API or a COM interface, and there is no way to impose scoped locks on their clients. If the entire program can be persuaded to use scoped locks, direct lock/unlock calls are probably never necessary (given movable locks, otherwise you can't return a lock from a function).