Как правильно связать мьютекс с его данными?

нет ничего плохого в том, что деньги "в полете" на некоторое время. Сделайте это так:

Account src, dst;

dst.deposit(src.withdraw(400));

теперь просто сделайте каждый отдельный метод потокобезопасным, например

int Account::withdraw(int n)
{
    std::lock_guard<std::mutex> _(m_);
    balance -= n;
    return n;
}

Я предпочитаю использовать неинтрузивный класс-оболочку вместо загрязнения исходного объекта мьютексом и блокировки его при каждом вызове метода. Этот класс-оболочка (который я назвал Protected<T>) содержит объект user в качестве частной переменной. Protected<T> гранты дружбы в другой класс Locker<T>. Шкафчик принимает оболочку в качестве аргумента конструктора и предоставляет общедоступные методы доступа к объекту пользователя. Шкафчик также держит мьютекс оболочки запертым во время своей жизни. Итак, шкафчик lifetime определяет область, в которой можно безопасно получить доступ к исходному объекту.

на Protected<T> можно реализовать operator-> для быстрого вызова одного метода.

пример:

#include <iostream>
#include <mutex>


template<typename>
struct Locker;


template<typename T>
struct Protected
{
    template<typename ...Args>
    Protected(Args && ...args) :
        obj_(std::forward<Args>(args)...)
    {        
    }

    Locker<const T> operator->() const;
    Locker<T> operator->();

private:    
    friend class Locker<T>;
    friend class Locker<const T>;
    mutable std::mutex mtx_;
    T obj_;
};


template<typename T>
struct Locker
{
    Locker(Protected<T> & p) :
        lock_(p.mtx_),
        obj_(p.obj_)
    {
        std::cout << "LOCK" << std::endl;
    }

    Locker(Locker<T> && rhs) = default;

    ~Locker()
    {
        std::cout << "UNLOCK\n" << std::endl;
    }

    const T& get() const { return obj_; }
    T& get() { return obj_; }

    const T* operator->() const { return &get(); }
    T* operator->() { return &get(); }

private:    
    std::unique_lock<std::mutex> lock_;
    T & obj_;    
};


template<typename T>
struct Locker<const T>
{
    Locker(const Protected<T> & p) :
        lock_(p.mtx_),
        obj_(p.obj_)
    {
        std::cout << "LOCK (const)" << std::endl;
    }

    Locker(Locker<const T> && rhs) = default;

    ~Locker()
    {
        std::cout << "UNLOCK (const)\n" << std::endl;
    }

    const T& get() const { return obj_; }    
    const T* operator->() const { return &get(); }

private:    
    std::unique_lock<std::mutex> lock_;
    const T & obj_;
};


template<typename T>
Locker<T> Protected<T>::operator->()
{
    return Locker<T>(const_cast<Protected<T>&>(*this));
}


template<typename T>
Locker<const T> Protected<T>::operator->() const
{
    return Locker<T>(const_cast<Protected<T>&>(*this));
}

struct Foo
{
    void bar() { std::cout << "Foo::bar()" << std::endl; }
    void car() const { std::cout << "Foo::car() const" << std::endl; }
};

int main()
{
    Protected<Foo> foo;

    // Using Locker<T> for rw access
    {
        Locker<Foo> locker(foo);
        Foo & foo = locker.get();
        foo.bar();
        foo.car();
    }

    // Using Locker<const T> for const access
    {
        Locker<const Foo> locker(foo);
        const Foo & foo = locker.get();
        foo.car();
    }


    // Single actions can be performed quickly with operator-> 
    foo->bar();
    foo->car();
}

который генерирует этот вывод:

LOCK
Foo::bar()
Foo::car() const
UNLOCK

LOCK (const)
Foo::car() const
UNLOCK (const)

LOCK
Foo::bar()
UNLOCK

LOCK
Foo::car() const
UNLOCK

лично я являюсь поклонником LockingPtr парадигма (эта статья довольно устарела, и я лично не буду следовать всем ее советам):

struct thread_safe_account_pointer {
     thread_safe_account_pointer( std::mutex & m,Account * acc) : _acc(acc),_lock(m) {}

     Account * operator->() const {return _acc;}
     Account& operator*() const {return *_acc;}
private:
     Account * _acc;
     std::lock_guard<std::mutex> _lock;
};

и реализовать классы, которые содержат Account объект вроде этого:

class SomeTypeWhichOwnsAnAccount {
public:
     thread_safe_account_pointer get_and_lock_account() const {return thread_safe_account_pointer(mutex,&_impl);}

      //Optional non thread-safe
      Account* get_account() const {return &_impl;}

      //Other stuff..
private:
     Account _impl;
     std::mutex mutex;
};

указатели могут быть заменены умными указателями, если это подходит, и вам, вероятно, понадобится const_thread_safe_account_pointer (или даже лучше шаблон общего назначения thread_safe_pointer класс)

почему это лучше, чем мониторы (ИМО)?

1. вы можете создать свой класс учетной записи, не думая о потокобезопасности; потокобезопасность является свойством объекта, который использует ваш класс, а не самого класса.
2. нет необходимости в рекурсивных мьютексах при вложении вызовов функций-членов в вашем классе.
3. вы четко документируете в своем коде, блокируете ли вы мьютекс или нет (и вы можете полностью предотвратить использование-без-блокировки, не реализуя get_account). Как get_and_lock() и get() функции сил вы думать о потокобезопасности.
4. при определении функций (global или member) у вас есть чистая семантика, чтобы указать, требует ли функция блокировки мьютекса объекта (просто передайте thread_safe_pointer) или является потокобезопасным агностиком (используйте Account&).
5. последнее, но не менее thread_safe_pointer имеет совершенно другую семантику от мониторов:

рассмотрим MyVector класс, который реализует потокобезопасность через мониторы и следующий код:

MyVector foo;
// Stuff.. , other threads are using foo now, pushing and popping elements

int size = foo.size();
for (int i=0;i < size;++i)
   do_something(foo[i]);

код ИМО, как это действительно плохо, потому что это заставляет вас чувствовать себя safe думая, что мониторы позаботятся о потокобезопасности для вас, в то время как здесь у нас есть состояние гонки, которое невероятно трудно обнаружить.

ваша задача-связать замок с Данные. В моих глазах, набивая mutex на объект в порядке. Вы можете пойти еще дальше, сделав объекты по существу в мониторы: блокировка для ввода члена функции, разблокировка при выходе.

Я считаю, что предоставление каждой учетной записи с собственной блокировкой в порядке. Он предоставляет четкий сигнал любому читателю вашего кода, который обращается к Account - это критическая секция.

недостатком любого решения, включающего одну блокировку на учетную запись, является то, что вы должны помнить о взаимоблокировке при написании кода, который одновременно управляет несколькими учетными записями. Но простой способ избежать этой проблемы-ограничить взаимодействие с одной учетной записью за раз. Это не только избегает потенциальных проблем взаимоблокировки, это также увеличивает параллелизм, так как вы не блокируете доступ к какой-либо другой учетной записи, пока текущий поток занят чем-то другим.

ваши опасения по поводу согласованного представления допустимы, но могут быть достигнуты путем регистрации операций, которые происходят с текущей транзакцией. Например, вы можете украсить свой deposit() и withdraw() операции с проводкой бревно.

class Account {
  void deposit(const Money &amount);
  void withdraw(const Money &amount);
public:
  void deposit(const Money &amount, Transaction& t) {
    std::lock_guard<std::mutex> _(m_);
    deposit(amount);
    t.log_deposit(*this, amount);
  }
  void withdraw(const Money &amount, Transaction& t) {
    std::lock_guard<std::mutex> _(m_);
    withdraw(amount);
    t.log_withdraw(*this, amount);
  }
private:
  std::mutex m_;
};

затем transfer - это протоколированием вывода и депозита.

void transfer (Account &src, Account &dest, const Money &amount,
               Transaction &t) {
  t.log_transfer(src, dest, amount);
  try {
    src.withdraw(amount, t);
    dest.deposit(amount, t);
    t.log_transfer_complete(src, dest, amount);
  } catch (...) {
    t.log_transfer_fail(src, dest, amount);
    //...
  }
}

обратите внимание, что идея журнала транзакций ортогональна тому, как вы решаете развернуть свои блокировки.

Я думаю, что ваш ответ-сделать, как вы предлагаете, и использовать std::lock (), но поместить его в функцию друга. Таким образом, вам не нужно публиковать учетную запись mutex. Функции deposit() и withdraw () не используются новой функцией friend и должны будут отдельно блокировать и разблокировать мьютекс. Помните, что функции friend не являются функциями-членами, но имеют доступ к частным членам.

typedef int Money;

class Account {
public:
  Account(Money amount) : balance(amount)
  {
  }

  void deposit(const Money& amount);
  bool withdraw(const Money& amount);

  friend bool transfer(Account& src, Account& dest, const Money& amount)
  {
     std::unique_lock<std::mutex> src_lock(src.m, std::defer_lock);
     std::unique_lock<std::mutex> dest_lock(dest.m, std::defer_lock);
     std::lock(src_lock, dest_lock);

     if(src.balance >= amount)
     {
        src.balance -= amount;
        dest.balance += amount;
        return true;
     }
     return false;
  }
private:
  std::mutex m;
  Money balance;
};

большинство решений имеют проблему, что данные хранятся общедоступными, таким образом, можно получить доступ к нему без блокировки блокировки.

есть способ исправить это, но вы не можете использовать шаблоны, и поэтому приходится прибегать к макросам. Гораздо приятнее реализовать на C++11 и вместо того, чтобы повторять все обсуждение здесь, я ссылаюсь на свою реализацию на:https://github.com/sveljko/lockstrap