scoped_lock的析构函数怎么理解？cppreference会不会出错？

Question

 ~scoped_lock()
  { std::apply([](auto&... __m) { (__m.unlock(), ...); }, _M_devices); }

如何理解[](auto&... __m) { (__m.unlock(), ...);？我不明白 lambda 中的 ...，我不知道这个实现如何以相反的顺序释放互斥量。

正如@HolyBlackCat所说，
(__m.unlock(), ...)表示(__m1.unlock(),(__m2.unlock(), (__m3.unlock(), (...))))，但没有实现逆序解锁

在cppreference.com中：

When control leaves the scope in which the scoped_lock object was created, the scoped_lock is destructed and the mutexes are released, in reverse order.

我做了如下实验来证实这一点：

#include <chrono>
#include <iostream>
#include <mutex>
#include <thread>

class mymutex : public std::mutex {
 public:
   void lock() {
     std::mutex::lock();
     std::cout << "mutex " << _i << " locked" << std::endl;
   }
  mymutex(int i): _i(i){}
   bool try_lock() {
    bool res = std::mutex::try_lock();
    if (res) {
      std::cout << "mutex " << _i << " try locked" << std::endl;
    }
    return res;
   }
  void unlock() {
    std::mutex::unlock();
    std::cout << "mutex " << _i << " unlocked" << std::endl;
  }
 private:
  int _i;
};

class Speaking {
 private:
  int a;
  mymutex my1;
  mymutex my2;
  mymutex my3;

public:
  Speaking() : a(0), my1(1), my2(2), my3(3){};
  ~Speaking() = default;
  void speak_without_lock();
  void speak_with_three_lock();
};

void Speaking::speak_without_lock() {
  std::cout << std::this_thread::get_id() << ": " << a << std::endl;
  a++;
}

void Speaking::speak_with_three_lock() 
{
  std::scoped_lock<mymutex, mymutex, mymutex> scoped(my1, my2, my3);
  speak_without_lock();
}

int main() {
  Speaking s;

  s.speak_with_three_lock();

  return 0;
}

mutex 1 locked
mutex 2 try locked
mutex 3 try locked
1: 0
mutex 1 unlocked
mutex 2 unlocked
mutex 3 unlocked

那么cppreference是不是出错了？

Answer 1

我认为 cppreference.com 在这个细节上是不正确的。 C++17 说：

~scoped_lock();

Effects: For all i in [0, sizeof...(MutexTypes)), get(pm).unlock()

这意味着释放锁的顺序与获取锁的顺序相同。

请注意，为了防止死锁，没有必要以与获取锁相反的顺序释放锁 - 只需要始终以相同的顺序获取锁。

scoped_lock的析构函数怎么理解？cppreference会不会出错？

How to understand destructor of scoped_lock?Does cppreference make a mistake?

c++

scoped-lock

c++17