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

Золотой стандарт поддержки многопоточности в контейнерах STL (которым руководствуется большинство разработчиков) был определен компанией SGI и опубликован на ее web-сайте, посвященном STL [21]. Фактически в нем сказано, что в лзшем случае можно надеяться на следующее:

безопасность параллельного чтения. Несколько потоков могут одновременно читать содержимое контейнера, и это не помешает его правильной работе. Естественно, запись в контейнер при этом не допускается;

безопасность записи в разные контейнеры. Несколько потоков могут одновременно производить запись в разные контейнеры.

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

Многопоточное программирование считается сложной задачей, и многие программисты желают, чтобы реализации STL изначально обеспечивали полную потоковую безопасность. Это избавило бы их от необходимости самостоятельно синхронизировать доступ. Конечно, это было бы очень удобно, однако добиться этой цели очень сложно. Рассмотрим несколько способов реализации полной потоковой безопасности контейнеров:

блокировка контейнера на время вызова любой функции;

блокировка контейнера в течение жизненного цикла каждого возвращаемого итератора (например посредством вызова begin или end);

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

Рассмотрим следующий фрагмент, который ищет в vector<int> первое вхождение числа 5 и заменяет его нулем:

vector<int> v:

vector<int>;.-iterator first5(find(v.begin().v.end().5)): Строка 1

if (firsts != v.endO) { Строка 2

*first5 = 0; Строка 3

В многопоточной среде существует вероятность того, что другой поток изменит содержимое v сразу же после выполнения строки 1. Если это произойдет, сравнение firsts с v.end в строке 2 становится бессмысленным, поскольку содержимое v будет не тем, каким оно было в конце строки 1. Более того, такая проверка может привести к непредсказуемым результатам, поскольку третий поток может перехватить управление между строками 1 и 2 и сделать fi rst5 недействительным (например, при выполнении вставки вектор может заново выделить память, вследствие чего все

В среде программистов данный термин (англ. mutex) встречается также в варианте мутекс . Примеч. ред.

итераторы данного вектора станут недействительными. За подробностями о перераспределении памяти обращайтесь к совету 14). Присваивание *first5 в строке 3 тоже небезопасно, поскольку между строками 2 и 3 другой поток может удалить элемент, на который указывает (или, по крайней мере, указывал раньше) итератор f i rst5.

Ни одно из описанных выше решений с блокировкой не решает этих проблем. Вызовы begi п и end в строке 1 сразу возвращают управление, сгенерированные ими итераторы остаются действительными только до конца строки, а f i nd тоже возвращает управление в конце строки.

Чтобы этот фрагмент был потоково-безопасным, блокировка v должна сохраняться от строки 1 до строки 3. Трудно представить, каким образом реализация STL могла бы автоматически придти к такому выводу. А если учесть, что использование примитивов синхронизации (семафоров, мьютексов и т. д.) обычно сопряжено с относительно высокими затратами, еще труднее представить, каким образом реализация могла бы сделать это без значительного снижения быстродействия по сравнению с программами, которым априорно известно, что в строках 1-3 с v будет работать только один программный поток.

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

vector<int> v: getMutexFor(v);

vector<i nt>::iterator fi rst5(find(v.begin(),v.end(). 5));

if (firsts != v.endO) { Теперь эта строка безопасна

*first5 = 0: И эта строка тоже

releaseMutexFor(v);

В другом, объектно-ориентированном, решении создается класс Lock, который захватывает мьютекс в конструкторе и освобождает его в деструкторе, что сводит к минимуму вероятность вызова getMutexFor без парного вызова releaseMutexFor. Основа такого класса (точнее, шаблона) выглядит примерно так:

tempiate<typename Container> Базовый шаблон для классов, class Lock{ захватывающих и освобождающих мьютексы

public; для контейнеров; многие технические

детали опущены

Lock(const Containers container)

:c(container)

getMutexFor(с); Захват мьютекса в конструкторе

-Lock О {

releaseMutexFor(c); Освобождение мьютекса в деструкторе

private;

const Containers с;

Концепция управления жизненным циклом ресурсов (в данном случае - мьютексов) при помощи специализированных классов вроде Lock рассматривается в любом серьезном зебнике C+-I-. Попробуйте начать с книги Страуструпа (Stroustrup) The С++ Programming Language* [7], поскольку именно Страуструп популяризировал эту идиому, однако информацию также можно найти в совете 9 Моге Effective С++ . Каким бы источником вы ни воспользовались, помните, что приведенный выше класс Lock урезан до абсолютного минимума. Полноценная версия содержала бы многочисленные дополнения, не имеющие никакого отношения к STL. Впрочем, несмотря на минимализм, приведенная версия Lock вполне может использоваться в рассматриваемом примере:

vector<int> V:

{ Создание нового блока

Lock<vector<int> > 1ock(v): Получение ньютекса

vector<int>::iterator fi rst5(find(V.begi п(),V.end().5)); if (firsts != V.endO) { *first5 = 0:

} Закрытие блока с автоматическим

освобождением ньютекса

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

Более того, решение, основанное на классе Lock, лзше защищено от исключений. С++ гарантирует уничтожение локальных объектов при возникновении исключения, поэтому Lock освободит мьютекс, даже если исключение произойдет при использовании объекта Lock. При использовании парных вызовов getMutexFor/ releaseMutexFor мьютекс не будет освобожден, если исключение происходит после вызова getMutexFor, но перед вызовом releaseMutexFor.

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