std :: lock_guard або std :: scoped_lock?

C ++ 17 представив новий клас блокування під назвою std::scoped_lock.

Судячи з документації, він схожий на вже існуючий std::lock_guardклас.

У чому різниця і коли я повинен її використовувати?

Це scoped_lockсуворо перевершена версія, lock_guardщо блокує довільну кількість мутексів відразу (використовуючи той самий алгоритм уникнення тупикової ситуації, що і std::lock). У новому коді ви повинні використовувати будь-коли scoped_lock.

Єдина причина lock_guardвсе ще існує - сумісність. Його не можна було просто видалити, оскільки він використовується в поточному коді. Більше того, виявилося небажаним змінювати своє визначення (від уніарного до варіатичного), оскільки це також є спостережуваним, а отже, і руйнуючим, зміною (але з певних технічних причин).

Єдина і важлива відмінність полягає в тому, що він std::scoped_lockмає варіативний конструктор, що приймає більше одного мютексу. Це дозволяє зафіксувати декілька мутексів у глухий кут, уникаючи способу, як ніби std::lockвони використовувалися.

{
    // safely locked as if using std::lock
    std::scoped_lock<std::mutex, std::mutex> lock(mutex1, mutex2);     
}

Раніше вам довелося зробити невеликий танець, щоб безпечно зафіксувати декілька файлів, використовуючи std::lockпояснення цієї відповіді .

Додавання блокування блоку полегшує використання та уникає пов'язаних з цим помилок. Ви можете вважати std::lock_guardзастарілим. Випадок єдиного аргументу std::scoped_lockможе бути реалізований як спеціалізація, і вам не доведеться побоюватися можливих проблем з продуктивністю.

GCC 7 вже має підтримку, std::scoped_lockяку можна побачити тут .

Для отримання додаткової інформації ви можете прочитати стандартний папір

Пізня відповідь і в основному у відповідь на:

Ви можете вважати std::lock_guardзастарілим.

У загальному випадку, коли потрібно заблокувати рівно один мютекс, std::lock_guardє API, який трохи безпечніше у використанні, ніж scoped_lock.

Наприклад:

{
   std::scoped_lock lock; // protect this block
   ...
}

Вищенаведений фрагмент, ймовірно, є випадковою помилкою запуску, оскільки він компілюється та не робить нічого. Кодер, ймовірно, означав:

{
   std::scoped_lock lock{mut}; // protect this block
   ...
}

Тепер він блокується / розблоковується mut.

Якщо lock_guardзамість помилки під час виконання використовувались у двох наведених вище прикладах, перший приклад - це помилка часу компіляції замість помилки під час виконання, а другий приклад має ідентичну функціональність як версія, яка використовує scoped_lock.

Тому моя порада - використовувати найпростіший інструмент для роботи:

1. lock_guard якщо вам потрібно заблокувати рівно 1 мьютекс для цілої області.

2. scoped_lock якщо вам потрібно заблокувати ряд мутексів, які не є рівно 1.

3. unique_lockякщо вам потрібно розблокувати в межах блоку (що включає використання з a condition_variable).

Ця рада зовсім НЕ означає , що scoped_lockповинен бути перероблений , щоб не приймати 0 семафорів. Існують дійсні випадки використання, коли бажано scoped_lockприймати різні параметри параметрів шаблону, які можуть бути порожніми. І порожній корпус нічого не повинен замикати.

І тому lock_guardне застаріло. scoped_lock і unique_lock може бути набором функціональних можливостей lock_guard, але цей факт - меч з двома острими. Іноді так само важливо, що тип не буде робити (конструкція за замовчуванням у цьому випадку).

Ось зразок і цитата від C ++ Concurrency in Action :

friend void swap(X& lhs, X& rhs)
{
    if (&lhs == & rhs)
        return;
    std::lock(lhs.m, rhs.m);
    std::lock_guard<std::mutex> lock_a(lhs.m, std::adopt_lock);
    std::lock_guard<std::mutex> lock_b(rhs.m, std::adopt_lock);
    swap(lhs.some_detail, rhs.some_detail);
}

vs.

friend void swap(X& lhs, X& rhs)
{
    if (&lhs == &rhs)
        return;
    std::scoped_lock guard(lhs.m, rhs.m);
    swap(lhs.some_detail, rhs.some_detail);
}

Існування std::scoped_lockозначає, що більшість випадків, коли ви використовували б std::lockраніше c ++ 17, тепер можна писати, використовуючи std::scoped_lock, з меншим потенціалом помилок, що може бути лише хорошою справою!