'використання' твердження проти 'спробувати нарешті'

У мене є купа властивостей, для яких я буду використовувати блокування читання / запису. Я можу реалізувати їх або за try finallyдопомогою usingпункту, або речення.

В try finallyя б придбав замок до try, і відпустив в finally. У цьому usingреченні я б створив клас, який отримує замок у своєму конструкторі та звільняє у своєму методі Dispose.

Я використовую блокування читання / запису у багатьох місцях, тому я шукав шляхи, які можуть бути більш стислими, ніж try finally. Мені цікаво почути кілька ідей щодо того, чому той чи інший спосіб не рекомендується, або чому один може бути кращим за інший.

Спосіб 1 ( try finally):

static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
private DateTime dtMyDateTime_m
public DateTime MyDateTime
{
    get
    {
        rwlMyLock_m .AcquireReaderLock(0);
        try
        {
            return dtMyDateTime_m
        }
        finally
        {
            rwlMyLock_m .ReleaseReaderLock();
        }
    }
    set
    {
        rwlMyLock_m .AcquireWriterLock(0);
        try
        {
            dtMyDateTime_m = value;
        }
        finally
        {
            rwlMyLock_m .ReleaseWriterLock();
        }
    }
}

Спосіб 2:

static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
private DateTime dtMyDateTime_m
public DateTime MyDateTime
{
    get
    {
        using (new ReadLock(rwlMyLock_m))
        {
            return dtMyDateTime_m;
        }
    }
    set
    {
        using (new WriteLock(rwlMyLock_m))
        {
            dtMyDateTime_m = value;
        }
    }
}

public class ReadLock : IDisposable
{
    private ReaderWriterLock rwl;
    public ReadLock(ReaderWriterLock rwl)
    {
        this.rwl = rwl;
        rwl.AcquireReaderLock(0);
    }

    public void Dispose()
    {
        rwl.ReleaseReaderLock();
    }
}

public class WriteLock : IDisposable
{
    private ReaderWriterLock rwl;
    public WriteLock(ReaderWriterLock rwl)
    {
        this.rwl = rwl;
        rwl.AcquireWriterLock(0);
    }

    public void Dispose()
    {
        rwl.ReleaseWriterLock();
    }
}

З MSDN, використовуючи Statement (C # Reference)

Оператор using забезпечує виклик Dispose, навіть якщо виникає виняток під час виклику методів на об'єкті. Ви можете досягти того ж результату, помістивши об'єкт всередину блоку try, а потім викликавши Dispose у блоці нарешті; насправді саме так перекладається компілятором оператор using. Раніше приклад коду розширюється до наступного коду під час компіляції (зверніть увагу на додаткові фігурні дужки, щоб створити обмежений обсяг для об’єкта):

{
  Font font1 = new Font("Arial", 10.0f);
  try
  {
    byte charset = font1.GdiCharSet;
  }
  finally
  {
    if (font1 != null)
      ((IDisposable)font1).Dispose();
  }
}

Отже, це , по суті, той самий код, але з приємними автоматичними нульовими перевірками та додатковою сферою для вашої змінної . У документації також зазначено, що він "забезпечує правильне використання об'єкта IDisposable", тому ви також можете отримати ще кращу підтримку фреймворку для будь-яких неясних випадків у майбутньому.

Тож переходьте до варіанту 2.

Наявність змінної всередині області дії, яка закінчується відразу після того, як вона більше не потрібна, також є плюсом.

Я точно віддаю перевагу другому методу. Він є більш стислим на місці використання та менш схильним до помилок.

У першому випадку хтось, хто редагує код, повинен бути обережним, щоб нічого не вставити між викликом блокування Acquire (Read | Write) і спробою.

(Використання блокування читання / запису для окремих властивостей, подібних до цього, як правило, є надмірним. Однак їх найкраще застосовувати на набагато вищому рівні. Тут часто буває достатньо простого блокування, оскільки можливість суперечки, мабуть, дуже мала, враховуючи час утримання блокування для отримання блокування читання / запису - це більш дорога операція, ніж простий замок).

Розглянемо можливість того, що обидва рішення погані, оскільки вони маскують винятки .

A tryбез a, catchочевидно, має бути поганою ідеєю; див. MSDN щодо того, чому usingтвердження є також небезпечним.

Зверніть увагу, що зараз Microsoft рекомендує ReaderWriterLockSlim замість ReaderWriterLock.

Нарешті, зауважте, що в прикладах Microsoft використовуються два блоки спроби уловлення, щоб уникнути цих проблем, наприклад

try
{
    try
    {
         //Reader-writer lock stuff
    }
    finally
    {
         //Release lock
    }
 }
 catch(Exception ex)
 {
    //Do something with exception
 }

Просте, послідовне, чисте рішення - хороша мета, але припускаючи, що ви не можете просто використовувати lock(this){return mydateetc;}, ви можете переглянути підхід; з додатковою інформацією, я впевнений, що Stack Overflow може допомогти ;-)

Я особисто якомога частіше використовую оператор C # "використання", але я роблю разом із ним кілька конкретних речей, щоб уникнути згаданих потенційних проблем. Проілюструвати:

void doSomething()
{
    using (CustomResource aResource = new CustomResource())
    {
        using (CustomThingy aThingy = new CustomThingy(aResource))
        {
            doSomething(aThingy);
        }
    }
}

void doSomething(CustomThingy theThingy)
{
    try
    {
        // play with theThingy, which might result in exceptions
    }
    catch (SomeException aException)
    {
        // resolve aException somehow
    }
}

Зверніть увагу, що я відокремлюю оператор "using" на один метод, а використання об’єкта (-ів) - на інший метод за допомогою блоку "try" / "catch". Я можу вкласти кілька таких "виразів" для пов'язаних об'єктів (я іноді заглиблююсь у свій робочий код на три-чотири).

У своїх Dispose()методах для цих користувацьких IDisposableкласів я ловлю винятки (але НЕ помилки) і реєструю їх (використовуючи Log4net). Я ніколи не стикався з ситуацією, коли будь-який із цих винятків міг вплинути на мою обробку. Потенційні помилки, як зазвичай, дозволяють розповсюджувати стек викликів і, як правило, завершують обробку відповідним повідомленням (повідомлення про помилку та стек).

Якби я якось зіткнувся з ситуацією, коли протягом цього могло статися значне виняток Dispose(), я б переробив цю ситуацію. Чесно кажучи, я сумніваюся, що це коли-небудь станеться.

Тим часом, масштаби та переваги очищення від "використання" роблять це однією з найулюбленіших функцій C #. До речі, я працюю на Java, C # та Python як на мої основні мови, багато-де-куди кидають сюди-туди, і "використання" є однією з найулюбленіших мовних особливостей навколо, оскільки це практична щоденна робоча коня .

Мені подобається 3-й варіант

private object _myDateTimeLock = new object();
private DateTime _myDateTime;

public DateTime MyDateTime{
  get{
    lock(_myDateTimeLock){return _myDateTime;}
  }
  set{
    lock(_myDateTimeLock){_myDateTime = value;}
  }
}

З двох ваших варіантів другий варіант є найчистішим і легшим для розуміння того, що відбувається.

"Купа властивостей" і блокування на рівні отримання та встановлення властивостей виглядає неправильно. Ваш замок занадто дрібний. У більшості типових об'єктів, ви хочете переконатися, що придбали блокування для доступу до кількох властивостей одночасно. Ваш конкретний випадок може бути іншим, але я сумніваюся в цьому.

У будь-якому випадку, придбання блокування при доступі до об’єкта замість властивості значно зменшить кількість коду блокування, який вам доведеться написати.

DRY каже: друге рішення. Перше рішення дублює логіку використання блокування, тоді як друге - ні.

Блоки Try / Catch, як правило, призначені для обробки винятків, тоді як використання блоків використовується для того, щоб об'єкт був утилізований.

Для блокування читання / запису спроба / уловлювання може бути найбільш корисною, але ви також можете використовувати обидва, наприклад:

using (obj)
{
  try { }
  catch { }
}

так що ви можете неявно зателефонувати своєму інтерфейсу IDisposable, а також зробити стислу обробку винятків.

Я думаю, що метод 2 був би кращим.

• Простіший та читабельніший код у ваших властивостях.
• Менш схильний до помилок, оскільки код блокування не потрібно переписувати кілька разів.

Хоча я погоджуюся з багатьма з вищезазначених коментарів, включаючи деталізацію блокування та сумнівну обробку винятків, питання полягає лише в підході. Дозвольте сказати вам одну велику причину, чому я віддаю перевагу використанню над спробою {} нарешті модель ... абстракція.

У мене є модель, дуже схожа на вашу, за одним винятком. Я визначив базовий інтерфейс ILock і в ньому запропонував один метод під назвою Acquire (). Метод Acquire () повернув об'єкт IDisposable, і, як результат, означає, що поки об'єкт, з яким я маю справу, має тип ILock, його можна використовувати для здійснення області блокування. Чому це важливо?

Ми маємо справу з багатьма різними механізмами блокування та поведінкою. Об’єкт блокування може мати певний час очікування, який працює. Ваша реалізація блокування може бути блокуванням монітора, блокуванням зчитувача, блокуванням запису або блокуванням віджиму. Однак, з точки зору абонента, все це не має значення, їм важливо, щоб контракт на блокування ресурсу був виконаний, і що блокування робить це відповідно до його реалізації.

interface ILock {
    IDisposable Acquire();
}

class MonitorLock : ILock {
    IDisposable Acquire() { ... acquire the lock for real ... }
}

Мені подобається ваша модель, але я б хотів приховати механіку блокування від абонента. FWIW, я виміряв накладні витрати на використання техніки порівняно з спробою остаточно, і накладні витрати на розподіл одноразового об'єкта матимуть між 2-3% накладних витрат.

Я здивований, що ніхто не запропонував інкапсулювати спробу-нарешті в анонімні функції. Подібно до техніки створення екземплярів та розподілу класів за допомогою оператора using, це утримує блокування в одному місці. Я віддаю перевагу цьому лише тому, що волію прочитати слово "нарешті", аніж слово "утилізувати", коли думаю про звільнення замка.

class StackOTest
{
    private delegate DateTime ReadLockMethod();
    private delegate void WriteLockMethod();

    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            return ReadLockedMethod(
                rwlMyLock_m,
                delegate () { return dtMyDateTime_m; }
            );
        }
        set
        {
            WriteLockedMethod(
                rwlMyLock_m,
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private static DateTime ReadLockedMethod(
        ReaderWriterLock rwl,
        ReadLockMethod method
    )
    {
        rwl.AcquireReaderLock(0);
        try
        {
            return method();
        }
        finally
        {
            rwl.ReleaseReaderLock();
        }
    }

    private static void WriteLockedMethod(
        ReaderWriterLock rwl,
        WriteLockMethod method
    )
    {
        rwl.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwl.ReleaseWriterLock();
        }
    }
}

SoftwareJedi, у мене немає облікового запису, тому я не можу редагувати свої відповіді.

У будь-якому випадку, попередня версія не була дуже придатною для загального використання, оскільки блокування читання завжди вимагало поверненого значення. Це виправляє, що:

class StackOTest
{
    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            DateTime retval = default(DateTime);
            ReadLockedMethod(
                delegate () { retval = dtMyDateTime_m; }
            );
            return retval;
        }
        set
        {
            WriteLockedMethod(
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private void ReadLockedMethod(Action method)
    {
        rwlMyLock_m.AcquireReaderLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseReaderLock();
        }
    }

    private void WriteLockedMethod(Action method)
    {
        rwlMyLock_m.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseWriterLock();
        }
    }
}

Далі створюються методи розширення для класу ReaderWriterLockSlim, які дозволяють зробити наступне:

var rwlock = new ReaderWriterLockSlim();
using (var l = rwlock.ReadLock())
{
     // read data
}
using (var l = rwlock.WriteLock())
{
    // write data
}

Ось код:

static class ReaderWriterLockExtensions() {
    /// <summary>
    /// Allows you to enter and exit a read lock with a using statement
    /// </summary>
    /// <param name="readerWriterLockSlim">The lock</param>
    /// <returns>A new object that will ExitReadLock on dispose</returns>
    public static OnDispose ReadLock(this ReaderWriterLockSlim readerWriterLockSlim)
    {
        // Enter the read lock
        readerWriterLockSlim.EnterReadLock();
        // Setup the ExitReadLock to be called at the end of the using block
        return new OnDispose(() => readerWriterLockSlim.ExitReadLock());
    }
    /// <summary>
    /// Allows you to enter and exit a write lock with a using statement
    /// </summary>
    /// <param name="readerWriterLockSlim">The lock</param>
    /// <returns>A new object that will ExitWriteLock on dispose</returns>
    public static OnDispose WriteLock(this ReaderWriterLockSlim rwlock)
    {
        // Enter the write lock
        rwlock.EnterWriteLock();
        // Setup the ExitWriteLock to be called at the end of the using block
        return new OnDispose(() => rwlock.ExitWriteLock());
    }
}

/// <summary>
/// Calls the finished action on dispose.  For use with a using statement.
/// </summary>
public class OnDispose : IDisposable
{
    Action _finished;

    public OnDispose(Action finished) 
    {
        _finished = finished;
    }

    public void Dispose()
    {
        _finished();
    }
}

Насправді у вашому першому прикладі, щоб зробити рішення порівнянними, ви б також застосували їх IDisposableтам. Тоді ви зателефонуєте Dispose()з finallyблоку, замість того, щоб відпускати замок безпосередньо.

Тоді ви будете реалізовувати "яблука до яблук" (і MSIL) - так само (MSIL буде однаковим для обох рішень). Це, мабуть, хороша ідея використовувати usingчерез доданий масштаб і тому, що Framework забезпечить правильне використання IDisposable(останнє буде менш вигідним, якщо ви реалізуєте IDisposableсебе).

Дурний я. Існує спосіб зробити це ще простішим, зробивши заблоковані методи частиною кожного екземпляра (замість статичних, як у моєму попередньому дописі). Зараз я дійсно віддаю перевагу цьому, оскільки немає необхідності передавати `rwlMyLock_m 'якомусь іншому класу чи методу.

class StackOTest
{
    private delegate DateTime ReadLockMethod();
    private delegate void WriteLockMethod();

    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            return ReadLockedMethod(
                delegate () { return dtMyDateTime_m; }
            );
        }
        set
        {
            WriteLockedMethod(
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private DateTime ReadLockedMethod(ReadLockMethod method)
    {
        rwlMyLock_m.AcquireReaderLock(0);
        try
        {
            return method();
        }
        finally
        {
            rwlMyLock_m.ReleaseReaderLock();
        }
    }

    private void WriteLockedMethod(WriteLockMethod method)
    {
        rwlMyLock_m.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseWriterLock();
        }
    }
}