Net framework 5, а также среды Visual Studio 2012 и C#

Глава.21 .Автоматическое.управление.памятью.(уборка.мусора)
с неуправляемым кодом, им гарантирован особый подход со стороны CLR. Вот 
пример:
using System;
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;
internal static class SomeType {
[DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")] 
// Этот прототип неустойчив к сбоям
private static extern IntPtr CreateEventBad(
IntPtr pSecurityAttributes, Boolean manualReset, 
Boolean initialState, String name); 
// Этот прототип устойчив к сбоям
[DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")]
private static extern SafeWaitHandle CreateEventGood(
IntPtr pSecurityAttributes, Boolean manualReset, 
Boolean initialState, String name);
public static void SomeMethod() {
IntPtr handle = CreateEventBad(IntPtr.Zero, false, false, null);
SafeWaitHandle swh = CreateEventGood(IntPtr.Zero, false, false, null);
}
} 
Обратите внимание, что прототип метода 
CreateEventBad
возвращает 
IntPtr
, то 
есть он возвращает дескриптор в управляемый код. Подобного рода взаимодействия 
с неуправляемым кодом неустойчивы к сбоям. После вызова метода 
CreateEventBad
(создающего системный ресурс события) возможна ситуация, когда исключение 
ThreadAbortException
появляется до присвоения дескриптора переменной 
handle
. 
В таких редких случаях в управляемом коде образуется утечка системного ресурса. 
И событие можно закрыть только одним способом — завершив процесс.
Класс 
SafeHandle
устраняет эту потенциальную утечку ресурсов. Обратите 
внимание, что прототип метода 
CreateEventGood
возвращает 
SafeWaitHandle
, 
а не 
IntPtr
. При вызове метода 
CreateEventGood
CLR вызывает Win32-функцию 
CreateEvent
. Когда эта функция возвращает управление управляемому коду, CLR 
«знает», что 
SafeWaitHandle
является производным от 
SafeHandle
. Поэтому CLR 
автоматически создает экземпляр класса 
SafeWaitHandle
, передавая ему полученное 
от метода 
CreateEvent
значение дескриптора. Обновление объекта 
SafeWaitHandle
и присвоение дескриптора происходят в неуправляемом коде, который не может 
быть прерван исключением 
ThreadAbortException
. В результате в управляемом 
коде не может возникнуть утечка этого системного ресурса. А в итоге объект 
SafeWaitHandle
удаляется уборщиком мусора и вызывается его метод финализации, 
обеспечивающий освобождение памяти.
И наконец, классы, производные от 
SafeHandle
, гарантируют, что никто не 
сможет воспользоваться возможными брешами в системе безопасности. Проблема 
в том, что один из потоков может попытаться использовать системный ресурс, осво-

---

583
Освобождение.ресурсов.при.помощи.механизма.финализации
бождаемый другим потоком. Это называется атакой с повторным использованием 
дескрипторов. Класс 
SafeHandle
предотвращает это нарушение безопасности благо-
даря подсчету ссылок. В нем определено закрытое поле, исполняющее роль счетчика. 
Когда производному от 
SafeHandle
объекту присваивается корректный дескриптор, 
счетчик приравнивается к 1. Всякий раз, когда производный от 
SafeHandle
объект 
передается как аргумент неуправляемому методу, CLR автоматически увеличивает 
значение счетчика на единицу. Когда неуправляемый метод возвращает управление 
управляемому коду, CLR уменьшает значение счетчика на ту же величину. Напри-
мер, вот как выглядит прототип Win32-функции 
SetEvent
:
[DllImport("Kernel32", ExactSpelling=true)]
private static extern Boolean SetEvent(SafeWaitHandle swh);
При вызове этого метода и передаче ему ссылки на объект 
SafeWaitHandle
CLR 
увеличивает значение счетчика перед вызовом и уменьшает значение счетчика 
сразу после вызова. Разумеется, операции со счетчиком выполняются способом, 
безопасным по отношению к потокам. Как это повышает безопасность? Если другой 
поток попытается освободить системный ресурс, оболочкой которого является объ-
ект 
SafeHandle
, CLR узнает, что это ему не разрешено, потому что данный ресурс 
используется неуправляемой функцией. Когда функция вернет управление про-
грамме, значение счетчика будет приравнено к 0 и ресурс освободится.
При написании или вызове кода, работающего с дескриптором (например, 
IntPtr
), к нему можно обратиться из объекта 
SafeHandle
, но подсчет ссылок при-
дется выполнять явно с помощью методов 
DangerousAddRef
и 
DangerousRelease
объекта 
SafeHandle
. Обращение к исходному дескриптору происходит через метод 
DangerousGetHandle
.
Нельзя не упомянуть о классе 
CriticalHandle
, также определенном в про-
странстве имен 
System.Runtime.InteropServices
. Он работает точно так же, 
как и 
SafeHandle
, но не поддерживает подсчет ссылок. В 
CriticalHandle
и про-
изводных от него классах безопасность принесена в жертву повышению произво-
дительности (за счет отказа от счетчиков). Как и у 
SafeHandle
, у 
CriticalHandle
есть два производных типа — 
CriticalHandleMinusOneIsInvalid
и 
CriticalHand
leZeroOrMinusOneIsInvalid
. Так как Microsoft отдает предпочтение безопасности, 
а не производительности системы, в библиотеке классов нет типов, производ-
ных от этих двух классов. Используйте типы, производные от 
CriticalHandle
, 
только когда высокая производительность необходима и оправдывает некоторое 
ослабление защиты.