Weak Reference

Weak Reference Internals

Weak references are tracked in short weak reference and long weak reference tables. Weak references are not created on the managed heap, but are entries in the short weak reference or long weak reference tables. Both tables are initially empty.

Each entry in the short weak reference table is a reference to a managed object on the heap. When garbage collection occurs, objects referenced in the short weak reference table that are not strongly rooted are collectable. The related slot in the table is set to null. References to finalizable objects that are being collected are moved from the finalization to the FReachable queue.

Entries in the long weak reference table are evaluated next. Long weak references are weak references that track an object through finalization. This allows the resurrection of a weakly referenced object. Objects referenced in the long weak reference table that are not strongly rooted are collectable.

Weak Reference Class

Table 14-1 lists the important members of the WeakReference class.

Critical Finalization Objects

Conditions can prevent a finalizer from running, and critical cleanup code might not execute. Resource leakage and other problems can occur when critical finalization code is abandoned. .NET Framework 2.0 introduces critical finalizable objects to ensure that critical finalizers run. The CLR is more diligent about executing finalizers in critical finalizer objects. Conditions that can prevent a normal finalizer from running, such as a forcible thread abort or an unload of the application domain, do not affect a critical finalizer. This is especially an issue in environments that host the CLR, such as Microsoft SQL Server 2005. A CLR host can asynchronously interrupt a managed application, which can strand important finalizers.

During garbage collection, critical finalizers run after the normal finalizers.

Critical finalizer objects are derived from the CriticalFinalizerObject, which is located in the System.Runtime namespace. The finalizer runs uninterrupted in a Constrained Execution Region (CER).

Constrained Execution Region

CER is a region of reliable code that is guaranteed to run. Even an asynchronous exception will not prevent the region from executing to completion. Within the CER, developers are constrained to certain actions. This is a shortlist of some of the actions that should be avoided in a CER:

• Boxing

• Unsafe code

• Locks

• Serialization

• Calling unreliable code

• Actions likely to cause an asynchronous exception

In a CER, the CLR delays an asynchronous exception until the region is exited. The CLR performs a variety of checks and does some preparation to ensure that code in the CER runs uninterrupted.

The RuntimeHelpers.PrepareConstrainedRegions static method places a subsequent catch, finally, or fault handler in a constrained region. The RuntimeHelpers class is in the System .Runtime.CompilerServices namespace. The PrepareConstrainRegions method call should immediately precede the try statement. The code in the try block is not reliable and can be interrupted. However, the related handler is within the CER and is uninterruptible.

Developers must make reliability assurances for code in a constrained region. The CLR does not strictly enforce the reliability constraints within the CER. Instead, the CLR relies on developer commitment, which is a reliability contract. Reliability contracts state the level of compliance for a method, class, or assembly. Set a reliability contract with the ReliabilityContractAttribute. This attribute is found in the System.Runtime.ConstrainedExecution namespace. The Reliability-ContractAttribute constructor has two parameters. The first parameter is the ConsistencyGuarantee property, which indicates the potential scope of corruption if an asynchronous exception occurs during execution. For example, Consistency.MayCorruptAppDomain means that an asynchronous exception can leave the application domain in an unreliable state. The second parameter is the Cer property, which is a completion guarantee for code in a CER region. Cer.Success is the highest guarantee and promises that the code will successfully complete when running in a CER, assuming valid input.

Here is an example of a CER region:

[ReliabilityContract(Consistency.WillNotCorruptState,
        Cer.Success)]
class ZClass {

    void MethodA() {
        RuntimeHelpers.PrepareConstrainedRegions();
        try {
        }
        finally {
            // CER Region
        }
    }

}

Stephen Toub authored a detailed and informative article on CERs called "Keep Your Code Running with the Reliability Features of the .NET Framework." It can be found at the following link: http://msdn.microsoft.com/msdnmag/issues/05/10/reliability/default.aspx

public sealed class PipeHandle :
    SafeHandleMinusOneIsInvalid
{

    private PipeHandle()
        : base(true)
    {

    }

    [ReliabilityContract(Consistency.WillNotCorruptState,
            Cer.Success)]
    protected override bool ReleaseHandle()
    {
        return CloseHandle(handle);
    }

    [DllImport("kernel32.dll")]
    extern public static bool CreatePipe(
        out PipeHandle hReadPipe,
        out PipeHandle hWritePipe,
        IntPtr securityAttributes,
        int nSize);

    [ReliabilityContract(Consistency.WillNotCorruptState,
           Cer.Success)]
    [DllImport("kernel32.dll")]
    public static extern bool CloseHandle(IntPtr handle);

}

public class AnonymousPipe
{

    public AnonymousPipe()
    {

        PipeHandle.CreatePipe(out readHandle, out writeHandle,
            IntPtr.Zero, 10);
        MessageBox.Show((readHandle.DangerousGetHandle())
            .ToInt32().ToString());

        MessageBox.Show((writeHandle.DangerousGetHandle())
            .ToInt32().ToString());
    }

    private PipeHandle readHandle = null;
    private PipeHandle writeHandle = null;
}

Managing Unmanaged Resources

Managed code often relies on unmanaged resources. The unmanaged resource is typically accessible through a managed wrapper. The MyDevice program is an unmanaged application that emulates a hardware device. DeviceWrapper is a managed wrapper for the MyDevice unmanaged resource. This is the code for the DeviceWrapper class:

public sealed class MyDevice
{
    static private int count = 0;

    public MyDevice()
    {
        obj = new MyDeviceLib.DeviceClass();
        ++count;
    }

    private MyDeviceLib.DeviceClass obj;

    public void Open()
    {
        obj.OpenDevice();
    }

    public void Close()
    {
        obj.CloseDevice();
    }

    public void Start()
    {
        obj.StartCommunicating();
    }

    public void Stop()
    {
        obj.StopCommunicating();
    }

    ~MyDevice()
    {
        // resource released
        --count;
    }
}

public MyDevice()
{
    GC.AddMemoryPressure(40000);
    obj = new MyDeviceLib.DeviceClass();
    ++count;
}

~MyDevice()
{
    GC.RemoveMemoryPressure(40000);
    // resource released
    --count;
}

public sealed class MyDevice
{
    static private HandleCollector track=
        new HandleCollector("devices", 3,5);

    static private int count = 0;

    public MyDevice()
    {
        GC.AddMemoryPressure(40000);
        track.Add();
        obj = new MyDeviceLib.DeviceClass();
        ++count;
        MessageBox.Show("Device count: " + count.ToString());
    }

    private MyDeviceLib.DeviceClass obj;
    public void Open()
    {
        obj.OpenDevice();
    }

    public void Close()
    {
        obj.CloseDevice();
    }

    public void Start()
    {
        obj.StartCommunicating();
    }

    public void Stop()
    {
        obj.StopCommunicating();
    }

    ~MyDevice()
    {
        GC.RemoveMemoryPressure(40000);

        track.Remove();
        // resource released
        --count;
    }
}