Замок в свойствах, хороший подход?

Question

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

Когда клиент подключается, создается класс Client, где каждый клиент имеет свою переменную «A».

Иногда клиент не вызывает метод так:

Client selectedClient SelectOtherClientClassByID(sentID); 

selectedClient.A=5; 

Нет проблем до сих пор с этим, даже когда 5 классов делали в то же время (Threadpool), но я думал, что о добавлении замки A свойств ?

Как:

A { 
    get { return mA; } 
    set { 
     // use lock here for settting A to some value 
    }  
} 

Будет ли в порядке?

Answer 1

Вам необходимо использовать блокировки в BOTH get and set. Этот замок должен быть одним и тем же объектом. Например:

private object mylock = new object(); 

public int A { 

    get { 
    int result; 
    lock(mylock) { 
    result = mA; 
    } 
    return result; 
    } 

    set { 
    lock(mylock) { 
     mA = value; 
    } 
    } 
} 

Answer 2

Это очень редко, когда все, что вам нужно, это просто установить одно свойство. Чаще всего selectedClient.A = 5 будет частью гораздо большей логической операции, которая включает в себя несколько присвоений/оценок/и т. Д. Во время этой операции вы предпочтете, чтобы selectedClient был в состоянии согласованности и не вводил взаимоблокировки/условия гонки. Таким образом, это будет гораздо лучше, чтобы выставить SyncRoot свойства в вашем Client класса и замок на том, что из вызывающего кода:

Client selectedClient = GetClient(...); 

lock(selectedClient.SyncRoot) 
{ 
    selectedClient.A = 5; 
    selectedClient.B = selectedClient.A * 54; 
} 

Answer 3

Блокировка доступа к свойствам внутри аксессоров может привести к фиктивным результатам. Для примера, рассмотрим следующий код:

class C { 
    private object mylock = new object(); 

    public int A { 

     get { 
     int result; 
     lock(mylock) { 
     result = mA; 
     } 
     return result; 
     } 

     set { 
     lock(mylock) { 
      mA = value; 
     } 
     } 
    } 
} 
C obj = new C; 
C.A++; 

(да, я скопировал его из первого ответа) Существует состояние гонки здесь! Операция «C.A ++» фактически требует двух отдельных доступов к A, один для получения значения, а другой - для установки обновленного значения. Ничто не гарантирует, что эти два доступа будут выполняться вместе, без переключения контекста между ними. Классический сценарий состояния гонки!

Итак, остерегайтесь! Не стоит помещать блокировки внутри аксессуаров, блокировки должны быть явно получены, как и предыдущий ответ (хотя он не обязательно должен быть с SyncRoots, любой объект будет делать)