Листинг 3.2.Непреднамеренная передача наружу ссылки на защищённые данные
class some_data {
int а;
std::string b;
public:
void do_something();
};
class data_wrapper {
private:
some_data data;
std::mutex m;
public :
template
void process_data(Function func)
(1) Передаем
{ │
"защищенные"
std::lock_guard l(m);│
данные поль-
func(data); ←┘
зовательской
}
функции
};
some_data* unprotected;
void malicious_function(some_data& protected_data) {
unprotected = &protected_data;
}
data_wrapper x;
void foo
(2) Передаем
{ │
вредоносную
x.process_data(malicious_function); ←┘
функцию
unprotected->do_something(); ←
(3) Доступ к "защищенным"
}
данным в обход защиты
В этом примере функция-член process_data
выглядит вполне безобидно, доступ к данным охраняется объектом std::lock_guard
, однако наличие обращения к переданной пользователем функции func
(1)означает, что foo
может передать вредоносную функцию malicious_function
, чтобы обойти защиту (2), а затем вызвать do_something()
, не захватив предварительно мьютекс (3).
Здесь фундаментальная проблема заключается в том, что мы не сделали того, что собирались сделать: пометить все участки кода, в которых имеется доступ к структуре данных, как взаимно исключающие . В данном случае мы забыли о коде внутри foo()
, который вызывает unprotected->do_something()
. К сожалению, в этом стандартная библиотека С++ нам помочь не в силах: именно программист должен позаботиться о том, чтобы защитить данные мьютексом. Но не всё так мрачно — следование приведенной ниже рекомендации выручит в таких ситуациях. Не передавайте указатели и ссылки на защищенные данные за пределы области видимости блокировки никаким способом, будь то возврат из функции, сохранение в видимой извне памяти или передача в виде аргумента пользовательской функции .
Хотя описанная только что ситуация — самая распространенная ошибка при защите разделяемых данных, перечень подводных камней ей отнюдь не исчерпывается. В следующем разделе мы увидим, что гонка возможна даже, если данные защищены мьютексом.
3.2.3. Выявление состояний гонки, внутренне присущих интерфейсам
Тот факт, что вы пользуетесь мьютексами или другим механизмом для защиты разделяемых данных, еще не означает, что гонок можно не опасаться, — следить за тем, чтобы данные были защищены, все равно нужно. Вернемся снова к примеру двусвязного списка. Чтобы поток мог безопасно удалить узел, необходимо предотвратить одновременный доступ к трем узлам: удаляемому и двум узлам но обе стороны от него. Заблокировав одновременный доступ к указателям на каждый узел но отдельности, мы не достигнем ничего по сравнению с вариантом, где мьютексы вообще не используются, поскольку гонка по-прежнему возможна. Защищать нужно не отдельные узлы на каждом шаге, а структуру данных в целом на все время выполнения операции удаления. Простейшее решение в данном случае — завести один мьютекс, который будет защищать весь список, как в листинге 3.1.
Однако и после обеспечения безопасности отдельных операций наши неприятности еще не закончились — гонки все еще возможны, даже для самого простого интерфейса. Рассмотрим структуру данных для реализации стека, например, адаптер контейнера std::stack
, показанный в листинге 3.3. Помимо конструкторов и функции swap()
, имеется еще пять операций со стеком: push()
заталкивает в стек новый элемент, pop()
выталкивает элемент из стека, top()
возвращает элемент, находящийся на вершине стека, empty()
проверяет, пуст ли стек, и size()
возвращает размер стека. Если изменить top()
, так чтобы она возвращала копию, а не ссылку (в соответствии с рекомендацией из раздела 3.2.2), и защитить внутренние данные мьютексом, то и тогда интерфейс уязвим для гонки. Проблема не в реализации на основе мьютексов, она присуща самому интерфейсу, то есть гонка может возникать даже в реализации без блокировок.
Листинг 3.3. Интерфейс адаптера контейнера std::stack
template >
class stack {
public:
explicit stack(const Container&);
explicit stack(Container&& = Container());
template explicit stack(const Alloc&);
template stack(const Container&, const Alloc&);
template stack(Container&&, const Alloc&);
Читать дальше