Энтони Уильямс - Параллельное программирование на С++ в действии. Практика разработки многопоточных программ

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.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&);

template stack(stack&&, const Alloc&);

bool empty() const;

size_t size() const;

T& top();

T const& top() const;

void push(T const&);

void push(T&&);

void pop();

void swap(stack&&);

};

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

Если экземпляр stack не является разделяемым, то нет ничего страшного в том, чтобы проверить, пуст ли стек с помощью empty(), а затем, если стек не пуст, вызвать top()для доступа к элементу на вершине стека:

stack s;

if (!s.empty()) ← (1)

{

int const value = s.top(); ← (2)

s.pop(); ← (3)

do_something(value);

}

Такой подход в однопоточном коде не только безопасен, но и единственно возможен: вызов top()для пустого стека приводит к неопределенному поведению. Но если объект stackявляется разделяемым, то такая последовательность операций уже не безопасна, так как между вызовами empty() (1)и top() (2)другой поток мог вызвать pop()и удалить из стека последний элемент. Таким образом, мы имеем классическую гонку, и использование внутреннего мьютекса для защиты содержимого стека ее не предотвращает. Это следствие дизайна интерфейса.

И что же делать? Поскольку проблема коренится в дизайне интерфейса, то и решать ее надо путем изменения интерфейса. Но возникает вопроса — как его изменить? В простейшем случае мы могли бы просто декларировать, что top()возбуждает исключение, если в момент вызова в стеке нет ни одного элемента. Формально это решает проблему, но затрудняет программирование, поскольку теперь мы должны быть готовы к перехвату исключения, даже если вызов empty()вернул false. По сути дела, вызов empty()вообще оказывается ненужным.

Внимательно присмотревшись к показанному выше фрагменту, мы обнаружим еще одну потенциальную гонку, на этот раз между вызовами top() (2)и pop() (3). Представьте, что этот фрагмент исполняют два потока, ссылающиеся на один и тот же объект sтипа stack. Ситуация вполне обычная: при использовании потока для повышения производительности часто бывает так, что несколько потоков исполняют один и тот же код для разных данных, и разделяемый объект stackидеально подходит для разбиения работы между потоками. Предположим, что первоначально в стеке находится два элемента, поэтому можно с уверенностью сказать, что между empty()и top()не будет гонки ни в одном потоке. Теперь рассмотрим возможные варианты выполнения программы.