О вреде метода Thread.Abort

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

Давайте в качестве примера рассмотрим различные сопособы прекращения работы созданного вручную потока. Если вы начали знакомство с многопоточностью, с таких чудесных библиотек как WinAPI и не менее чудесных языков программирования как С и С++, то вы наверняка очень быстро поняли, что завершать выполнение потока с помощью вызова функции TerminateThread мягко говоря не стоит. Вызов функции TerminateThread гарантировано приводит к утечкам ресурсов, памяти, некорректному состоянию объектов ядра операционной системы и еще десятку других напастей, после которых корректное состояние приложения – мало вероятно. Вызов этой функции достаточно быстро завоевал дурную славу у разработчиков (благо даже в официальной документации на эту функцию в MSDN черным по английскому сказано, что вызывать ее не стоит) и большинству разработчиков пришлось искать другие способы завершения работы потока, начиная от уведомление рабочего потока с помощью событий (events), заканчивая применением булевого флага, который проверяется рабочим потоком и устанвливается в true для его завершения.

// Объявили поле в классе.
// В большинстве случаев ключевого слова volatile будет достаточно;
// это предотвратит переупорядочивания инструкций при доступе к этому полю
volatile bool threadRunning;
 
// И где-то в функции потока
while(threadRunning)
{
    // Основный цикл нового потока
}
 
// Теперь после старта потока выставляем threadRunning в true,
// а когда нам понадобится его завершить - установим его в false

«Управляемые» языки программирования и платформа .Net, подняли тот самый уровень абстракции, решив многие насущные проблемы разработчиков, но при этом добавили ложное чувство безопасности туда, где ее на самом деле нет. И речь в данном случае идет как раз о вызове метода Thread.Abort для прекращения работы потока. На форумах не редко можно встретить пример такого кода:

thread = new Thread(ThreadFunction);
thread.Start();
//...
thread.Abort();

После вызова метода Thread.Abort из другого потока, в целевом потоке генерируется исключение ThreadAbortException, которое по своей природе является асинхронным, а это значит, что оно может возникнуть практически в любой точке управляемого кода*. И даже несмотря на то, что с переходом на .Net Framework 2.0 количество «практически любых точек кода» несколько уменьшилось, и теперь невозможно прервать выполнение статического конструктора и блоков catch/finally, вероятность получения рассогласованного состояния приложения все еще весьма велика. Чтобы убедиться в этом, давайте рассмотрим несколько примеров.

Итак, предположим, что в нашей функции потока мы работаем с некоторым ресурсом (например, с файлом), и поскольку мы прочитали уйму умных книжек и не меньшее количество форумов, то мы знаем, что все ресурсы нужно использовать в блоке using, для их детерминированной очистки:

// Функция нового потока
void ThreadFunction()
{
    using (var file = File.OpenWrite(fileName))
    {
        // Записываем информацию в файл

    }
}

Однако этот код безопасен только с точки зрения исключений, возникающих внутри блока using, но не безопасен с точки зрения асинхронного исключения, которое может возникнуть практически где угодно. Чтобы убедиться в этом, достаточно вспомнить, во что этот код преобразуется компилятором.

var file = File.OpenWrite(fileName);
try
{
    // Записываем информацию в файл
}
finally
{
    if (file != null)
        ((IDisposable) file).Dispose();
}

А теперь скажите, что произойдет, если асинхронное исключение возникнет после выполнения конструктора и до присваивания ссылки на новый объект переменной file? В этом случае ресурс уже будет захвачен, без каких-либо шансов на детерминированное освобождение. Конечно, в случае работы с файлом, когда-то будет вызван метод завершения (a.k.a. finalizer) и файл закроется, но ведь вполне возможно, что ваше приложение содержит некоторую логику, рассчитывающую на то, что файл будет освобожден как можно скорее (ведь не просто так вы обернули его использование в блок using), и может «упасть» уже с синхронным исключением в совершенно другой части программы, которая рассчитывает на то, что файл уже будет закрыт.

Кроме того, даже библиотечные классы BCL не гарантируют согласованное состояние объектов при возникновении асинхронных исключений по очень простой причине: разработка кода безопасного с точки зрения асинхронных исключений задача практически невыполнимая. Так, например, в случае с файлом, вполне возможна ситуация, кода выполнение конструктора будет прервано после получения дескриптора файла, но до окончания выполнения конструктора. И вы можете себе только представить, насколько будет сложно определить, почему это вдруг нормально работающая критическая система начала вдруг падать раз в неделю или раз в месяц.

Другим потенциально опасным примером является использование оператора lock(syncRoot), который до появления .Net Framework 4.0 преобразовывался компилятором в следующий код [Lippert2009], [Duffy2007]:

var temp = syncRoot;
Monitor.Enter(temp);
try
{
    // тело блока lock
}
finally
{
    Monitor.Exit(temp);
}

Однако при компиляции без оптимизации, а также при компиляции на некоторых аппаратных платформах, между вызовом Monitor.Enter и блоком try компилятором C# или JIT компилятором могут вставляться пустые инструкции, что дает возможность «вклиниться» исключению ThreadAbortException. А это приведет к тому, что монитор не будет освобожден в блоке finally и навсегда останется в занятом состоянии, что, в свою очередь, приведет к дедлоку при любой последующей попытке его захвата.

Начиная с .Net Framework 4.0 эта ситуация наконец-то исправлена и оператор lock(syncRoot) разворачивается компилятором таким образом, чтобы вклиниться между захватом монитора и блоком try было невозможно, поскольку преобразуется компилятором следующим образом:

bool lockWasTaken = false;
var temp = syncRoot;
try
{
    Monitor.Enter(temp, ref lockWasTaken);
    {
        // тело блока lock
    }
}
finally
{
    if (lockWasTaken) 
        Monitor.Exit(temp);
}

Однако даже такая реализация не исключает возможности получения рассогласованного состояния ваших объектов, когда исключение возникнет внутри оператора lock в том месте, где вы совершенно этого не ждете. В результате чего ваша программа не «подвиснет», а просто начнет вести себя непредсказуемо, поскольку продолжит свою работу, когда ваши объекту будут находиться в промежуточном состоянии.

Подводя итог, нужно признать, что вероятность возникновения подобных проблем при использовании метода Thread.Abort достаточно мала, однако именно это делает подобные ошибки кошмаром для разработчика. И существуют случаи, когда вызов Thread.Abort является относительно безопасным (например, перед выгрузкой всего домена), но в любом случае стоит придерживаться более разумного способа завершения работы потока**, тем более что это не требует таких уж огромных усилий.

----------------
* ThreadAbortException не может возникнуть внутри статического конструктора, внутри блоков catch/finally, внутри constrained execution region или внутри неуправляемого кода.

** Использование того же самого булевого флага с модификатором volatile или маркеров отмены (Cancellation Tokens), если вы работаете с .Net Framework 4.0.

Дополнительные ссылки

1. [Duffy2005] Joe Duffy. Atomicity and asynchronous exception failures
2. [Duffy2007] Joe Duffy. Monitor.Enter, thread aborts, and orphaned locks
3. [Lippert 2009] Eric Lippert. Locks and exceptions do not mix
4. [Lippert 2010] Eric Lippert. Careful with that axe, part one
5. [Sells 2003]. Крис Селлз. Изучение ThreadAbortException с помощью Rotor