- PVSM.RU - https://www.pvsm.ru -
Наверняка, многие слышали, а кто-то встречал на практике, такие слова, как взаимные блокировки(deadlock) и гонках(race condition). Эти понятия относятся к разряду ошибок в использовании concurrency. Если я задам вам вопрос, что такое дедлок, вы с большой вероятностью без доли сомнения начнете рисовать классическую картинку дедлока или его представление в псевдокоде. Что-то вроде этого:
Эту информацию мы получаем в институте, можно найти в книжках и статьях на просторах интернета. Такой дедлок с использованием, например, двух мьютексов, во всей своей красе можно встретить в коде. Но в большинстве случаев не все так просто, и не каждый может увидеть классический паттерн ошибки в коде, если он представлен не в привычном виде.
Рассмотрим класс, в котором нас интересуют методы StartUpdate, CheckAndUpdate и Stop, используется C++, код максимально упрощен:
std::recursive_mutex m_mutex;
Future m_future;
void Stop()
{
std::unique_lock scoped_lock(m_mutex);
m_future.Wait();
// do something
}
void StartUpdate()
{
m_future.Wait();
m_future = Future::Schedule(std::bind(&Element::CheckAndUpdate, this),
std::chrono::milliseconds(100);
}
void CheckAndUpdate()
{
std::unique_lock scoped_lock(m_mutex);
//do something
}
На что следует обратить внимание в представленном коде:
Теперь проанализируем всю полученную информацию и составим картинку:
Принимая во внимание два представленных выше факта, нетрудно сделать вывод, что попытка захвата рекурсивного мьютекса в одной из функций приведет к ожиданию освобождения мьютекса, если он уже был захвачен в другой функции, поскольку колбэк CheckAndUpdate всегда выполняется в отдельном потоке.
На первый взгляд ничего подозрительного, относящегося к дедлоку нет. Но если быть повнимательнее, то все сводится к нашей классической картинке. Когда начинает выполняться функциональный объект, мы как бы неявно захватываем ресурс m_future, колбэк напрямую
ассоциируется с m_future:
Порядок действий, приводящих к дедлоку, таков:
Вот и все: поток, выполняющий вызов Stop, ждет завершения выполнения CheckAndUpdate, а другой поток в свою очередь не может продолжить работу, пока не захватит мьютекс, который уже захвачен упомянутым ранее потоком. Вполне себе классический дедлок. Пол дела сделано – обнаружена причина проблемы.
Вот такой незамысловатый пример с неочевидным дедлоком легко сводится к паттерну этой ошибки. Напоследок хочу пожелать вам писать надежный и потокобезопасный код!
Автор: Анастасия
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/310441
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/442448/?utm_source=habrahabr&utm_medium=rss&utm_campaign=442448
Нажмите здесь для печати.