Имеет ли смысл разделять эти назначения в одной области, чтобы один и тот же lock_guard не занимал все переменные?
True.Действительно, ваша интуиция верна.
Какие могут быть преимущества или недостатки для такого типа структуры кода?
Однако такую ситуацию нельзя предсказать с оченьограниченный фрагмент кода.Лучшее предложение здесь - выполнить некоторые тесты.
Некоторые важные аспекты, которые я лично учел бы:
- тип
shared_var0
? - время блокировкимьютекс> время для завершения
SomeFunctionTakingSameTime1
?
Как вы сказали, если ваши функции SomeFunctionTakingSameTime0
и SomeFunctionTakingSameTime1
займут значительное количество времени, затем разделите на дваразные области видимости могут помочь максимизировать пропускную способность.
Как правило, критическая секция (т. е. область, в которой вы удерживаете блокировку) должна быть как можно короче.
Конечно, как и все, есть компромисс.Операции lock
/ unlock
не являются бесплатными.
int shared;
lock(mutex);
shared = 1;
unlock(mutex);
lock(mutex);
shared = 2;
unlock(mutex);
Конечно, это глупый пример.Но это показывает критический аспект в операции захвата блокировки.Операция присваивания в этом примере намного дешевле, чем двойная блокировка мьютекса!Более того, это предотвратит некоторые оптимизации компилятора (назначение shared = 1
может быть полностью удалено - с семантической точки зрения -).
Заключение, если тип shared_var0
и shared_var1
является фундаментальным(int
, float
и т. Д.) Вы даже можете рассмотреть возможность сохранить их в std::atomic
и полностью избежать мьютексов.