Действительно ли возможно реализовать ограниченный по объему, привязывают C#?

Для усиления ответа Timothy оператор блокировки действительно создает ограниченную по объему блокировку с помощью монитора. По существу это переводит во что-то вроде этого:

lock(_lockKey)
{
    // Code under lock
}

// is equivalent to this
Monitor.Enter(_lockKey)
try
{
     // Code under lock
}
finally
{
    Monitor.Exit(_lockKey)
}

В C# Вы редко используете dtor для этого вида шаблона (см. использование statement/IDisposable). Одна вещь, которую можно заметить в коде, является этим, если асинхронное исключение происходит между Монитором. Войдите и попытка, похоже, что монитор не будет выпущен. JIT на самом деле делает специальную гарантию этим если Монитор. Войдите сразу предшествует, попытка блокируются, асинхронного исключения не произойдет до блока попытки, таким образом гарантирующего выпуск.

Это верно, что Вы не знаете точно, когда dtor собирается работать..., но, если Вы реализуете интерфейс IDisposable и затем используете или блок 'использования' или вызов, 'Располагают ()' сами, у Вас будет место для помещения кода.

Вопрос: при высказывании "блокировки" Вы имеете в виду блокировку потока так, чтобы только один поток за один раз мог использовать объект? Как в:

lock (_myLockKey) { ... }

Разъяснитесь.

Для полноты существует другой способ достигнуть подобного эффекта RAII без использования using и IDisposable. В C# using обычно более ясно (см. также здесь еще для некоторых мыслей), но на других языках (например, Java), или даже в C#, если using не является соответствующим по некоторым причинам, полезно знать.

Это - идиома, названная, "Выполняются Вокруг", и идея состоит в том, что Вы называете метод, который делает пред и отправляет материал (например, блокировка/разблокирование Ваших потоков, или установка и фиксация / закрытие Вашего соединения с БД и т.д.), и Вы передаете в тот метод делегата, который реализует операции, Вы хотите произойти промежуточные.

например:

funkyObj.InOut( delegate{ System.Console.WriteLine( "middle bit" ); } );

В зависимости от того, что делает метод InOut, вывод мог бы быть чем-то как:

first bit
middle bit
last bit

Как я говорю, этот ответ для полноты только, предыдущих предложений using с IDisposable, а также lock ключевое слово, будут лучшими 99% времени.

Это - позор, который, в то время как .NET пошел далее, чем много других современных языков OO в этом, расценивает (я смотрю на Вас, Java), это все еще возлагает ответственность за RAII для работы над клиентским кодом (т.е. код, который использует using), тогда как в C++ деструктор будет всегда работать в конце объема.

Я был действительно побеспокоен фактом это using до разработчика, чтобы не забыть делать - в лучшем случае Вы получаете предупреждение, которое большинство людей никогда не потрудилось способствовать ошибке. Так, я играл с идеей как это - она вынуждает клиент, по крайней мере, ПОПЫТАТЬСЯ сделать вещи правильно. К счастью, и к сожалению, это - закрытие, таким образом, клиент мог все еще сохранить копию ресурса и попытаться использовать его снова позже - но этот код, по крайней мере, пытается продвинуть клиент в правильном направлении...

public class MyLockedResource : IDisposable
{
    private MyLockedResource()
    {
        Console.WriteLine("initialize");
    }

    public void Dispose()
    {
        Console.WriteLine("dispose");
    }

    public delegate void RAII(MyLockedResource resource);

    static public void Use(RAII raii)
    {
        using (MyLockedResource resource = new MyLockedResource())
        {
            raii(resource);
        }
    }

    public void test()
    {
        Console.WriteLine("test");
    }
}

Хорошее использование:

MyLockedResource.Use(delegate(MyLockedResource resource)
{
    resource.test();
});

Плохое использование! (К сожалению, это не может быть предотвращено...),

MyLockedResource res = null;
MyLockedResource.Use(delegate(MyLockedResource resource)
{
    resource.test();
    res = resource;
    res.test();
});
res.test();