Рассмотрим, например, моделирование класса банковских счетов, который поддерживает одновременные депозиты и снятие средств из нескольких мест (возможно, «Привет, мир» многопоточного программирования).

Здесь компонент является моделью концепции<Callable>.

I C++11 (Boost) одновременное выполнение компонента получается с помощью<std::thread>(<boost::thread>):

boost::thread thread1(S);

где<S>— модель<Callable>. Смысл этого выражения заключается в том, что исполнение<S()>будет происходить одновременно с текущей нитью исполнения, исполняющей выражение.

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

class BankAccount;
BankAccount JoesAccount;
void bankAgent()
{
    for (int i =10; i>0; --i) {
        //...
        JoesAccount.Deposit(500);
        //...
    }
}
void Joe() {
    for (int i =10; i>0; --i) {
        //...
        int myPocket = JoesAccount.Withdraw(100);
        std::cout << myPocket << std::endl;
        //...
    }
}
int main() {
    //...
    boost::thread thread1(bankAgent); // start concurrent execution of bankAgent
    boost::thread thread2(Joe); // start concurrent execution of Joe
    thread1.join();
    thread2.join();
    return 0;
}

Время от времени<bankAgent>вносит 500 долларов в<JoesAccount>.<Joe>аналогичным образом снимает 100 долларов со своего счета. Эти слова обозначают, что<bankAgent>и<Joe>исполняются одновременно.

Приведенный выше пример хорошо работает, если компоненты<bankAgent>и<Joe>не имеют доступа<JoesAccount>одновременно. Однако нет никакой гарантии, что этого не произойдет. Мы можем использовать mutex, чтобы гарантировать эксклюзивный доступ к каждому банку.

class BankAccount {
    boost::mutex mtx_;
    int balance_;
public:
    void Deposit(int amount) {
        mtx_.lock();
        balance_ += amount;
        mtx_.unlock();
    }
    void Withdraw(int amount) {
        mtx_.lock();
        balance_ -= amount;
        mtx_.unlock();
    }
    int GetBalance() {
        mtx_.lock();
        int b = balance_;
        mtx_.unlock();
        return b;
    }
};

Выполнение операций<Deposit>и<Withdraw>больше не сможет обеспечить одновременный доступ к балансу.

Мутекс — простой и основной механизм получения синхронизации. В приведенном выше примере относительно легко убедиться, что синхронизация работает правильно (при отсутствии исключения). В системе с несколькими одновременными объектами и несколькими общими объектами может быть трудно описать синхронизацию с помощью мутексов. Программы, которые интенсивно используют мутексы, трудно читать и писать. Вместо этого мы введем ряд общих классов для обработки более сложных форм синхронизации и связи.

С идиомой RAII мы можем многое упростить, используя расширенные замки. В приведенном ниже коде конструктор охранника блокирует пропущенный объект<mtx_>, а деструктор охраны разблокирует<mtx_>.

class BankAccount {
    boost::mutex mtx_; // explicit mutex declaration 
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ -= amount;
    }
    int GetBalance() {
        boost::lock_guard<boost::mutex> guard(mtx_);
        return balance_;
    }
};

Идиома блокировки на уровне объекта не охватывает все богатство модели резьбы. Например, приведенная выше модель довольно зашла в тупик, когда вы пытаетесь координировать транзакции с несколькими объектами. Тем не менее, блокировка на уровне объекта полезна во многих случаях, и в сочетании с другими механизмами может обеспечить удовлетворительное решение многих проблем с резьбовым доступом в объектно-ориентированных программах.

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

Этот подход достаточно прост в реализации и имеет привлекательную простоту. К сожалению, «простое» иногда может превратиться в «упрощенческое».

Внутренняя блокировка недостаточна для многих реальных задач синхронизации. Представьте, что вы хотите реализовать транзакцию по выводу банкоматов с классом BankAccount. Требования простые. Транзакция банкомата состоит из двух выводов - один для реальных денег и один для комиссии в размере 2 долларов США. Эти два вывода должны быть в строгой последовательности, то есть между ними не может существовать никакой другой транзакции.

Очевидная реализация является неустойчивой:

void ATMWithdrawal(BankAccount& acct, int sum) {
    acct.Withdraw(sum);
    // preemption possible
    acct.Withdraw(2);
}

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

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

void ATMWithdrawal(BankAccount& acct, int sum) {
    boost::lock_guard<boost::mutex> guard(acct.mtx_); 1
    acct.Withdraw(sum);
    acct.Withdraw(2);
}

Обратите внимание, что код выше не компилируется, поле<mtx_>является частным. У нас есть две возможности:

Мы можем добавить эти функции явно.

class BankAccount {
    boost::mutex mtx_;
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ -= amount;
    }
    void lock() {
        mtx_.lock();
    }
    void unlock() {
        mtx_.unlock();
    }
};

или наследование от класса, который добавляет эти блокируемые функции.

<basic_lockable_adapter>класс помогает определить<BankAccount>класс как

class BankAccount
: public basic_lockable_adapter<mutex>
{
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<BankAccount> guard(*this);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<BankAccount> guard(*this);
        balance_ -= amount;
    }
    int GetBalance() {
        boost::lock_guard<BankAccount> guard(*this);
        return balance_;
    }
};

Код, который не компилируется, становится

void ATMWithdrawal(BankAccount& acct, int sum) {
    boost::lock_guard<BankAccount> guard(acct);
    acct.Withdraw(sum);
    acct.Withdraw(2);
}

Обратите внимание, что теперь Acct блокируется Withdraw после того, как он уже был заблокирован охраной. При запуске такого кода происходит одна из двух вещей.

Поскольку<boost::mutex>не является рекурсивным, мы должны использовать его рекурсивную версию<boost::recursive_mutex>.

class BankAccount
: public basic_lockable_adapter<recursive_mutex>
{
    // ...
};

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

class BankAccount
    : public basic_lockable_adapter<boost:mutex> {
    int balance_;
public:
    void Deposit(int amount) {
        balance_ += amount;
    }
    void Withdraw(int amount) {
        balance_ -= amount;
    }
};

Очевидно, что подход блокировки, застрахованный абонентом, имеет проблему безопасности. Код реализации BankAccount является конечным и легкодоступным, но существует неограниченное количество клиентского кода, который манипулирует объектами BankAccount. При разработке приложений важно различать требования, предъявляемые к ограниченному и неограниченному коду. Если ваш класс предъявляет чрезмерные требования к неограниченному коду, это обычно признак того, что инкапсуляция находится вне окна.

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

Так что же делать? В идеале класс банковского счета должен делать следующее:

Давайте сделаем полезное наблюдение: Всякий раз, когда вы блокируете банковский счет, вы делаете это с помощью объекта<lock_guard<BankAccount>>. Поворачивая это утверждение, где бы ни было<lock_guard<BankAccount>>, где-то есть также запертый<BankAccount>. Таким образом, вы можете думать об объекте<lock_guard<BankAccount>>как о разрешении.<lock_guard<BankAccount>>У вас есть право на определенные вещи.<lock_guard<BankAccount>>объект не должен быть скопирован или псевдоним (это не передаваемое разрешение).

Чистый эффект заключается в том, что в любой точке вашего кода доступ к<lock_guard<BankAccount>>объекту гарантирует, что<BankAccount>заблокирован. (Вы не знаете точно, какая<BankAccount>заблокирована, однако, вопрос, который мы рассмотрим в ближайшее время.)

Теперь давайте сделаем несколько улучшений шаблона класса<lock_guard>, определенного в Boost. Нить. Назовем улучшенную версию<strict_lock>. По сути, роль<strict_lock>заключается только в том, чтобы жить на стеке в качестве автоматической переменной.<strict_lock>должен придерживаться политики некопирования и неалия.<strict_lock>отключает копирование, делая конструктора копий и оператора присваивания частными.

template <typename Lockable>
class strict_lock  {
public:
    typedef Lockable lockable_type;
    explicit strict_lock(lockable_type& obj) : obj_(obj) {
        obj.lock(); // locks on construction
    }
    strict_lock() = delete;
    strict_lock(strict_lock const&) = delete;
    strict_lock& operator=(strict_lock const&) = delete;
    ~strict_lock() { obj_.unlock(); } //  unlocks on destruction 
    bool owns_lock(mutex_type const* l) const noexcept // strict lockers specific function 
    {
      return l == &obj_;
    }
private:
    lockable_type& obj_;
};

Молчание иногда может быть громче слов — то, что запрещено делать с<strict_lock>, так же важно, как и то, что вы можете сделать. Давайте посмотрим, что вы можете и что вы не можете сделать с<strict_lock>.

BankAccount myAccount("John Doe", "123-45-6789");
strict_lock<BankAccount> myLock(myAccount); // ok

extern strict_lock<BankAccount> Foo(); // compile-time error
extern void Bar(strict_lock<BankAccount>); // compile-time error

// ok, Foo returns a reference to strict_lock<BankAccount>
extern strict_lock<BankAccount>& Foo();
// ok, Bar takes a reference to strict_lock<BankAccount>
extern void Bar(strict_lock<BankAccount>&);

Все эти правила были введены в действие с одной целью - обеспечение того, что владение<strict_lock<T>>является достаточно надежной гарантией того, что

Теперь, когда у нас такой строгий<strict_lock>, как мы можем использовать его силу в определении безопасного, гибкого интерфейса для банковского счета? Идея заключается в следующем:

Небольшой код стоит 1000 слов, как говорится, так вот новый класс банковского счета:

class BankAccount
: public basic_lockable_adapter<boost::mutex>
{
    int balance_;
public:
    void Deposit(int amount, strict_lock<BankAccount>&) {
        // Externally locked
        balance_ += amount;
    }
    void Deposit(int amount) {
        strict_lock<BankAccount> guard(*this); // Internally locked
        Deposit(amount, guard);
    }
    void Withdraw(int amount, strict_lock<BankAccount>&) {
        // Externally locked
        balance_ -= amount;
    }
    void Withdraw(int amount) {
        strict_lock<BankAccount> guard(*this); // Internally locked
        Withdraw(amount, guard);
    }
};

Теперь, если вы хотите воспользоваться преимуществами внутренней блокировки, вы просто звоните<Deposit(int)>и<Withdraw(int)>. Если вы хотите использовать внешнюю блокировку, вы блокируете объект, построив<strict_lock<BankAccount>>, а затем звоните<Deposit(int, strict_lock<BankAccount>&)>и<Withdraw(int,strict_lock<BankAccount>&)>. Например, вот функция<ATMWithdrawal>, реализованная правильно:

void ATMWithdrawal(BankAccount& acct, int sum) {
    strict_lock<BankAccount> guard(acct);
    acct.Withdraw(sum, guard);
    acct.Withdraw(2, guard);
}

Эта функция имеет лучшее из обоих миров — она достаточно безопасна и эффективна одновременно.

Стоит отметить, что<strict_lock>быть шаблоном дает дополнительную безопасность по сравнению с прямым полиморфным подходом. В таком дизайне банковский счет будет происходить из интерфейса Lockable.<strict_lock>манипулирует ссылками Lockable, поэтому нет необходимости в шаблонах. Такой подход является обоснованным, однако он обеспечивает меньше гарантий времени компиляции. Наличие объекта<strict_lock>говорит только о том, что какой-то объект, полученный из Lockable, в настоящее время заблокирован. В этом случае<strict_lock<BankAccount>>будет лучше, чем<BankAccount>.

Там есть ласковое слово - я упомянул, что вывод банкоматов достаточно безопасен. На самом деле это небезопасно, потому что нет никакого принуждения, чтобы объект<strict_lock<BankAccount>>блокировал соответствующий объект банковского счета. Система типа гарантирует, что некоторый объект банковского счета заблокирован. Например, рассмотрим следующую фальшивую реализацию ATMWithdrawal:

void ATMWithdrawal(BankAccount& acct, int sum) {
    BankAccount fakeAcct("John Doe", "123-45-6789");
    strict_lock<BankAccount> guard(fakeAcct);
    acct.Withdraw(sum, guard);
    acct.Withdraw(2, guard);
}

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

Важно понимать, что может быть реализовано в системе типа C++ и что должно быть реализовано во время выполнения. Механизм, который мы установили до сих пор, гарантирует, что какой-то объект банковского счета заблокирован во время звонка<BankAccount::Withdraw(int, strict_lock<BankAccount>&)>. Мы должны обеспечить во время выполнения точно, какой объект заблокирован.

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

Во-первых, давайте уберем злобу с дороги. C — язык, требующий от программиста большого внимания и дисциплины. C++ добился определенного прогресса, спросив немного меньше из них, в то же время доверяя программисту. Эти языки не связаны со злобой (как, например, Java). В конце концов, вы можете сломать любой дизайн C/C++, просто используя оттенки «соответствующим образом» (если в этом контексте уместно соответствующее слово).

Схема полезна, потому что вероятность того, что программист забудет о какой-либо блокировке, намного больше, чем вероятность того, что программист запомнит о блокировке, но заблокирует неправильный объект.

Использование<strict_lock>позволяет проверять время компиляции наиболее распространенного источника ошибок и время выполнения менее частой проблемы.

Давайте посмотрим, как обеспечить блокировку соответствующего объекта банковского счета. Во-первых, мы должны добавить функцию участника в шаблон класса<strict_lock>. Функция<boolstrict_lock<T>::owns_lock(Lockable*)>возвращает ссылку на заблокированный объект.

template <class Lockable> class strict_lock {
    ... as before ...
public:
    bool owns_lock(Lockable* mtx) const { return mtx==&obj_; }
};

Во-вторых, BankAccount должен использовать эту функцию сравнения заблокированного объекта с этим:

class BankAccount {
: public basic_lockable_adapter<boost::mutex>
    int balance_;
public:
    void Deposit(int amount, strict_lock<BankAccount>& guard) {
        // Externally locked
        if (!guard.owns_lock(*this))
            throw "Locking Error: Wrong Object Locked";
        balance_ += amount;
    }
// ...
};

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

Теперь предположим, что BankAccount вообще не использует собственную блокировку, а имеет только нить-нейтральную реализацию:

class BankAccount {
    int balance_;
public:
    void Deposit(int amount) {
        balance_ += amount;
    }
    void Withdraw(int amount) {
        balance_ -= amount;
    }
};

Теперь вы можете использовать BankAccount как в однопоточном, так и в многопоточном приложениях, но в последнем случае вам необходимо обеспечить собственную синхронизацию.

Скажем, у нас есть класс AccountManager, который удерживает и управляет объектом банковского счета:

class AccountManager
: public basic_lockable_adapter<boost::mutex>
{
    BankAccount checkingAcct_;
    BankAccount savingsAcct_;
    ...
};

Давайте также предположим, что, по замыслу, AccountManager должен оставаться заблокированным при доступе к своим членам. Вопрос в том, как мы можем выразить это ограничение дизайна с помощью системы типа C++? Как мы можем заявить: «У вас есть доступ к этому объекту банковского счета только после блокировки его родительского объекта управления счетом?»

Решение заключается в использовании небольшого шаблона моста<externally_locked>, который контролирует доступ к банковскому счету.

template <typename  T, typename Lockable>
class externally_locked {
    BOOST_CONCEPT_ASSERT((LockableConcept<Lockable>));
public:
    externally_locked(T& obj, Lockable& lockable)
        : obj_(obj)
        , lockable_(lockable)
    {}
    externally_locked(Lockable& lockable)
        : obj_()
        , lockable_(lockable)
    {}
    T& get(strict_lock<Lockable>& lock) {
#ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (!lock.owns_lock(&lockable_)) throw lock_error(); //run time check throw if not locks the same
#endif
        return obj_;
    }
    void set(const T& obj, Lockable& lockable) {
        obj_ = obj;
        lockable_=lockable;
    }
private:
    T obj_;
    Lockable& lockable_;
};

<externally_locked>маскирует объект типа T и фактически обеспечивает полный доступ к этому объекту через функции получения и набора членов при условии, что вы передаете ссылку на<strict_lock<Owner>>объект.

Вместо того, чтобы делать<checkingAcct_>и<savingsAcct_>типа<BankAccount>,<AccountManager>держит объекты типа<externally_locked<BankAccount, AccountManager>>:

class AccountManager
    : public basic_lockable_adapter<boost::mutex>
{
public:
    typedef basic_lockable_adapter<boost::mutex> lockable_base_type;
    AccountManager()
        : checkingAcct_(*this)
        , savingsAcct_(*this)
    {}
    inline void Checking2Savings(int amount);
    inline void AMoreComplicatedChecking2Savings(int amount);
private:
    externally_locked<BankAccount, AccountManager> checkingAcct_;
    externally_locked<BankAccount, AccountManager> savingsAcct_;
};

Модель такая же, как и раньше - для доступа к объекту банковского счета, замаскированного<checkingAcct_>, нужно позвонить<get>. Чтобы позвонить<get>, вам нужно передать его<strict_lock<AccountManager>>. Единственное, о чем вы должны позаботиться, это не держать указателей или ссылок, которые вы получили, позвонив<get>. Если вы это сделаете, убедитесь, что вы не используете их после уничтожения strict_lock. То есть, если вы называете скрытые объекты, вы возвращаетесь из режима «компилятор заботится об этом» в режим «вы должны обратить внимание».

Как правило, вы используете<externally_locked>, как показано ниже. Предположим, вы хотите выполнить атомный перевод с вашего расчетного счета на ваш сберегательный счет:

void AccountManager::Checking2Savings(int amount) {
    strict_lock<AccountManager> guard(*this);
    checkingAcct_.get(guard).Withdraw(amount);
    savingsAcct_.get(guard).Deposit(amount);
}

Мы достигли двух важных целей. Во-первых, декларация<checkingAcct_>и<savingsAcct_>дает понять считывателю кода, что эта переменная защищена блокировкой на Учетном Менеджере. Во-вторых, дизайн делает невозможным манипулирование двумя счетами без фактической блокировки банковского счета.<externally_locked>Это то, что можно назвать активной документацией.

Теперь представьте, что функция AccountManager должна взять<unique_lock>, чтобы уменьшить критические области. И в какой-то момент он должен получить доступ к<checkingAcct_>. Поскольку<unique_lock>не является строгой блокировкой, следующий код не компилируется:

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard(*this, defer_lock);
    if (some_condition()) {
        guard.lock();
    }
    checkingAcct_.get(guard).Withdraw(amount); // COMPILE ERROR
    savingsAcct_.get(guard).Deposit(amount);  // COMPILE ERROR
    do_something_else();
}

Нам нужен способ передачи права собственности с<unique_lock>на<strict_lock>во время работы с<savingsAcct_>, а затем восстановления права собственности на<unique_lock>.

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard1(*this, defer_lock);
    if (some_condition()) {
        guard1.lock();
    }
    {
        strict_lock<AccountManager> guard(guard1);
        checkingAcct_.get(guard).Withdraw(amount);
        savingsAcct_.get(guard).Deposit(amount);
    }
    guard1.unlock();
}

Для того, чтобы сделать этот код компилируемым, мы должны хранить ссылку на блокировку или<unique_lock<Lockable>>в зависимости от конструктора. Нам также нужно сохранить, какой тип ссылки мы сохранили, и в деструкторе вызвать либо блокируемый<unlock>или восстановить право собственности.

Мне это кажется слишком сложным. Другая возможность — определить вложенный строгий класс замка. Недостатком является то, что вместо одного строгого замка у нас есть два, и нам нужно либо дублировать каждую функцию, принимая<strict_lock>, либо создавать эти шаблоны функций. Проблема с функциями шаблонов заключается в том, что мы больше не пользуемся системой типа C++. Мы должны добавить некоторую статическую метафункцию, которая проверяет, что параметр Локера является строгой блокировкой. Проблема в том, что мы не можем проверить это или можем? Метафункция<is_strict_lock>должна быть специализирована разработчиком строгой блокировки. Мы должны верить в это "сур-условие". Преимущество заключается в том, что теперь мы можем управлять более чем двумя строгими замками без изменения нашего кода. Это очень мило.

Теперь мы должны сказать, что оба класса<strict_lock>.

template <typename Locker>
struct is_strict_lock : mpl::false_ {};
template <typename Lockable>
struct is_strict_lock<strict_lock<Lockable> > : mpl::true_ {}
template <typename Locker>
struct is_strict_lock<nested_strict_lock<Locker> > : mpl::true_ {}

Позвольте мне показать, как выглядит этот класс<nested_strict_lock>и как он влияет на класс<externally_locked>и функцию<AccountManager::AMoreComplicatedFunction>.

Первый<nested_strict_lock>класс будет хранить на временной блокировке<Locker>и передавать право собственности на замок конструктору. При разрушении он восстановит собственность. Обратите внимание на использование<lock_traits>и на то, что<Locker>должен иметь ссылку на mutex, в противном случае делается исключение.

template <typename Locker >
class nested_strict_lock
    {
      BOOST_CONCEPT_ASSERT((MovableLockerConcept<Locker>));
public:
    typedef typename lockable_type<Locker>::type lockable_type;
    typedef typename syntactic_lock_traits<lockable_type>::lock_error lock_error;
    nested_strict_lock(Locker& lock)
        : lock_(lock)  // Store reference to locker
        , tmp_lock_(lock.move()) // Move ownership to temporary locker 
    {
        #ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (tmp_lock_.mutex()==0) {
            lock_=tmp_lock_.move(); // Rollback for coherency purposes 
            throw lock_error();
        }
        #endif
        if (!tmp_lock_) tmp_lock_.lock(); // ensures it is locked 
    }
    ~nested_strict_lock() {
        lock_=tmp_lock_.move(); // Move ownership to nesting locker 
    }
    bool owns_lock() const { return true; }
    lockable_type* mutex() const { return tmp_lock_.mutex(); }
    bool owns_lock(lockable_type* l) const { return l==mutex(); }
private:
    Locker& lock_;
    Locker tmp_lock_;
};

Функция<externally_locked>get теперь является функцией шаблона, принимающей Locker в качестве параметров вместо<strict_lock>. Мы можем добавить тест в режиме отладки, который гарантирует, что объект заблокирован.

template <typename  T, typename Lockable>
class externally_locked {
public:
    // ...
    template <class Locker>
    T& get(Locker& lock) {
        BOOST_CONCEPT_ASSERT((StrictLockerConcept<Locker>));
        BOOST_STATIC_ASSERT((is_strict_lock<Locker>::value)); // locker is a strict locker "sur parole" 
        BOOST_STATIC_ASSERT((is_same<Lockable,
                typename lockable_type<Locker>::type>::value)); // that locks the same type 
#ifndef BOOST_THREAD_EXTERNALLY_LOCKED_DONT_CHECK_OWNERSHIP  // define BOOST_THREAD_EXTERNALLY_LOCKED_NO_CHECK_OWNERSHIP if you don't want to check locker ownership
        if (! lock ) throw lock_error(); // run time check throw if no locked 
#endif
#ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (!lock.owns_lock(&lockable_)) throw lock_error();
#endif
        return obj_;
    }
};

Для этого необходимо, чтобы<AccountManager::AMoreComplicatedFunction>заменил<strict_lock>на<nested_strict_lock>.

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard1(*this);
    if (some_condition()) {
        guard1.lock();
    }
    {
        nested_strict_lock<unique_lock<AccountManager> > guard(guard1);
        checkingAcct_.get(guard).Withdraw(amount);
        savingsAcct_.get(guard).Deposit(amount);
    }
    guard1.unlock();
}

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_basic_lockable;// EXTENSION
  }
}

Некоторые алгоритмы на мутексах используют эту черту через SFINAE.

Эта черта является истинной, если параметр L соответствует.<Lockable>требования.

	Warning
	Если BOOST_THREAD_NO_AUTO_DETECT_MUTEX_TYPES определен, вам нужно будет специализироваться на этих чертах для моделей BasicLockable, которые вы можете создать.

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_lockable;// EXTENSION
  }
}

Некоторые алгоритмы на мутексах используют эту черту через SFINAE.

Эта черта является истинной, если параметр L соответствует.<Lockable>требования.

	Warning
	Если BOOST_THREAD_NO_AUTO_DETECT_MUTEX_TYPES определен, вам нужно будет специализироваться на этих чертах для моделей Lockable, которые вы можете построить.

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_mutex_sur_parole: false_type; // EXTENSION
    template<>
    class is_recursive_mutex_sur_parole<recursive_mutex>: true_type; // EXTENSION
    template<>
    class is_recursive_mutex_sur_parole<timed_recursive_mutex>: true_type; // EXTENSION
  }
}

<is_recursive_mutex_sur_parole>является<false_type>по умолчанию и является специализированным для обеспечения<recursive_mutex>и<timed_recursive_mutex>.

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

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_basic_lockable;// EXTENSION
  }
}

Эта черта является истинной_типом, если является_basic_lockable и является_recursive_mutex_sur_parole.

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_lockable;// EXTENSION
  }
}

Эти признаки истинны_типа, если он_блокируемый и является_рекурсивным_mutex_sur_parole.

Тип L::mutex_type обозначает mutex, который запирается этим замком.

Как семантический "гарантирует, что связанный мутекс запирается в течение срока службы замка. "не может быть описана синтаксическими требованиями а<is_strict_lock_sur_parole>черта должна быть специализирована пользователем, определяющим блокировку таким образом, чтобы верно было следующее утверждение:

is_strict_lock_sur_parole<L>::value == true

Следующие классы являются моделями<StrictLock>:

template <class Clock, class Duration>
unique_lock(shared_lock<mutex_type>&& sl,
            const chrono::time_point<Clock, Duration>& abs_time);