Безопасность использования потоков и библиотек

Климан (Klieman), Шах (Shah) и Смаалдерс (Smaalders) утверждали:

«Функция или набор функций могут сделать поток безопасным или реентерабельным (повторно-входимым), если эти функции могут вызываться не одним, а несколькими потоками без предъявления каких бы то ни было требований к вызывающей части выполнить определенные действия»(1996)

При разработке многопоточного приложения программист должен обеспечить безопасность параллельно выполняемых функций. Мы уже обсуждали безопасность функций, определенных пользователем, но без учета того, что приложение часто вызывает функции из системных библиотек или библиотек, созданных сторонними производителями. Одни такие функции и/или библиотеки безопасны для потоков, а другие — нет. Если функция небезопасна, это означает, что в ней используется хотя бы одна статическая переменная, осуществляется доступ к глобальным данным и/или она не является реентерабельной.

Известно, что статические переменные поддерживают свои значения между вызовами функции. Если некоторая функция содержит статические переменные, то для ее корректного функционирования требуется считывать (и/или изменять) их значения. Если же к такой функции будут обращаться несколько параллельно выполняемых потоков, возникнут условия «гонок». Если функция модифицирует глобальную переменную, то каждый из нескольких потоков, вызывающих функцию, может попытаться модифицировать эту глобальную переменную. Возникновения условий «гонок» также не миновать, если не синхронизировать множество параллельных доступов к глобальной переменной. Например, несколько параллельных потоков могут выполнять функции, которые устанавливают переменную errno. Для некоторых потоков, предположим, эта функция не может выполниться успешно, и переменная errno устанавливается равной сообщению об ошибке [10], в то время как другие потоки выполняются успешно. Если реализация компилятора не обеспечивает потоковую безопасность поддержки переменной errno, то какое сообщение получит поток при проверке состояния переменной errno?

Блок кода считается реентерабельным, если его невозможно изменить при выполнении. Реентерабельный код исключает возникновение условий «гонок» благодаря отсутствию ссылок на глобальные переменные и модифицируемые статические данные Следовательно, такой код могут совместно использовать несколько параллельных потоков или процессов без риска создать условия «гонок». Стандарт POSIX определяет ряд реентерабельных функций. Их легко узнать по наличию «суффикса» присоединяемого к имени функции. Перечислим некоторые из них:

getgrgid_r()

getgrnam_r()

getpwuid_r()

sterror_r()

strtok_r()

readdir_r()

rand_r()

ttyname_r()

Если функция получает доступ к незащищенным глобальным переменным, содержит статические модифицируемые переменные или нереентерабельна, то такая функция считается небезопасной для потока. Системные библиотеки или библиотеки созданные сторонними производителями, могут иметь различные версии своих стандартных библиотек. Одна версия предназначена для однопоточных приложений, а другая — для многопоточных. Если предполагается разрабатывать многопоточное приложение, программист должен использовать многопоточные версии нужной ему библиотеки. Некоторые среды требуют не компоновки многопоточных приложений с многопоточной версией библиотеки, а лишь определения макросов, что позволяет объявить реентерабельные версии функций. Такое приложение будет затем компилироваться как безопасное для выполнения потоков.

Во всех ситуациях использовать многопоточные версии функций попросту невозможно. В отдельных случаях многопоточные версии конкретных функций недоступны для данного компилятора или среды. Иногда один интерфейс функции не в состоянии сделать ее безопасной. Кроме того, программист может столкнуться с увеличением числа потоков в среде, которая изначально использовала функции, предназначенные для функционирования в однопоточной среде. В таких условиях обычно используются мьютексы. Например, программа имеет три параллельно выполняемых потока. Два из них, thread1 и thread2, параллельно выполняют функцию funcA(), которая не является безопасной для одновременной работы потоков. Третий поток, thread3, выполняет функцию funcB (). Для решения проблемы, связанной с функцией funcA (), возможно, достаточно заключить в защитную оболочку мьютекса доступ к ней со стороны потоков threadl и thread2:

thread1 thread2 thread3

{ { {

lock() lock() funcB()

funcA() funcA() }

unlock() unlock()

} }

При реализации таких защитных мер к функции funcA () в любой момент времени может получить доступ только один поток. Но проблемы на этом не исчерпываются. Если обе функции funcA() и funcB() небезопасны для выполнения потоками, они могут обе модифицировать глобальные или статические переменные. И хотя потоки thread1 и thread2 используют мьютексы для функции funcA (), поток thread3 может выполнять функцию funcB одновременно с любым из остальных потоков. В такой ситуации вполне вероятно возникновение условий «гонок», поскольку функции funcA () и funcB () могут модифицировать одну и ту же глобальную или статическую переменную.

Проиллюстрируем еще один тип условий «гонок», возникающих при использовании библиотеки i ostream. Предположим, у нас есть два потока, А и В, которые выводят данные в стандартный выходной поток, cout, который представляет собой типа ostream. При использовании операторов " > > " и " < < " вызываются методы объекта cout. Вопрос: являются ли эти методы безопасными? Если поток A от правляет сообщение «Мы существа разумные» объекту stdout, а поток В отправляет сообщение «Люди алогичные существа», то не произойдет ли «перемешивание» выходных данных, в результате которого может получиться сообщение вроде такого- " Мы Люди существа алогичные разумные существа»? В некоторых случаях безопасные для потоков функции реализуются как атомные. Атомные функции — это функции, ко торые, если их выполнение началось, не могут быть прерваны. Если операция " > > " для объекта cout реализована как атомная, то подобное «перемешивание» не произойдет. Если есть несколько обращений к оператору " > > ", то они будут выполнены последовательно. Сначала отобразится сообщение потока А, а затем сообщение потока В или наоборот, хотя они вызвали функцию вывода одновременно. Это — пример преобразования параллельных действий в последовательные, которое обеспечит безопасность выполнения потоков. Но это не единственный способ обезопасить функцию. Если функция не оказывает неблагоприятного эффекта, она может смешивать свои операции. Например, если метод добавляет или удаляет элементы из структуры, которая не отсортирована, и этот метод вызывают два различных потока, то перемешивание их операций не даст неблагоприятного эффекта.

Если неизвестно, какие функции из библиотеки являются безопасными, а какие -нет, программист может воспользоваться одним из следующих вариантов действий.

• Ограничить использование всех опасных функций одним потоком.

• Не использовать безопасные функции вообще.

• Собрать все потенциально опасные функции в один набор механизмов синхронизации.

Еще один вариант — создать интерфейсные классы для всех опасных функций, которые должны использоваться в многопоточном приложении, т.е. опасные функции инкапсулируются в одном интерфейсном классе. Такой интерфейсный класс может быть скомбинирован с соответствующими объектами синхронизации с помощью наследования или композиции и использован специализированным классом. Такой подход устраняет возможность возникновения условий «гонок».