Zagnieżdżone niezrozumienie blokowania w języku C#?

Question

Czy ktoś może mi wyjaśnić, dlaczego potrzebujemy zagnieżdżonego blokowania?

spojrzenie na ten przykład:

lock (locker) 
    lock (locker) 
    lock (locker) 
     { 
     ... 
     } 

może ktoś proszę wyjaśnić (+ przykład będzie bardzo doceniane).

Answer 1

Czy ktoś może mi wyjaśnić, dlaczego potrzebujemy zagnieżdżonego blokowania?

Jest tylko problem, bo może masz zagnieżdżone (np wzajemnie rekurencyjne) zwraca się do metod, które wymagają, aby zablokować. Te metody muszą umożliwiać wywoływanie z zasobem już zablokowanym, ale nie mogą na nim polegać. Tak więc blokowanie zagnieżdżone to dozwolone, a nie potrzebne.

Kod, który wysłałeś (i książka, do której się odwołujesz) pokazuje, jak działa, redukując go do wbudowanego scenariusza. To nie jest "prawdziwy" kod.

Prosta zasada jest taka, że ​​wątek, który już jest właścicielem blokady, może ją ponownie zablokować, a liczba wyjść musi być zgodna z liczbą wejść, aby zwolnić blokadę.

Answer 2

W ogóle nie potrzebujesz zagnieżdżonego blokowania, o czym wspominasz.

Warto jednak podkreślić, że niektóre zamki mogą być zagnieżdżone. Sprawdź klasę ReaderWriterLockSlim, gdzie wprowadzasz jako blokadę odczytu, a następnie w tym zakresie, możesz uaktualnić ją do blokady zapisu.

EDIT: Jak Royi Namir zwraca uwagę, nazywając zagnieżdżone funkcje z których każdy ma swój własny zamek będzie koncepcyjnie produkować wspomniany scenariusz, ale sposób pytanie jest postawione, wygląda na to 3 zamki są wykonane w taki sam zakres, jeden po drugim, który ma mniej sensu.

Answer 3

Istnieją sytuacje, czy umiejętność umieszczania zamków w tym samym wątku jest bardzo praktyczna.

Załóżmy, że masz klasę z wieloma metodami. Załóżmy, że chcemy mieć bardzo prosty schemat blokowania takiego:

class A 
{ 
    public void MethodOne() 
    { 
     using (locker) 
     { 
      ...body... 
     } 
    } 

    public void MethodTwo() 
    { 
     using (locker) 
     { 
      ...body... 
     } 
    } 
} 

Teraz, jeśli MethodOne rozmowy MethodTwo, to masz impasu na początku MethodTwo, jeśli nie było reentrant zdolność blokowania na monitorze . Wątek po prostu zablokowałby się przez locker.

Na szczęście ten przykład działa tylko w .NET. Szafka "wie", który wątek zablokował ją i ile razy i pozwoli (tylko) na posiadanie wątku. Licznik służy do upewnienia się, że odblokowanie z perspektywy innych oczekujących wątków dzieje się tylko przy wychodzeniu z MethodOne, a nie przy wychodzeniu z MethodTwo. Jest to więc przykład użytecznego blokowania zagnieżdżonego.

Z drugiej strony przykład wspomniany w pytaniu wydaje się pochodzić z this book. Autorzy chcieli wyjaśnić, że zagnieżdżanie w gnieździe jest możliwe w.NET, automatycznie; ale ich przykładowy kod jest wymyślny i nie ma na celu pojawiać się w czyimś kodzie, chyba że próbuje dowiedzieć się, jak działa blokowanie pod maską.

Answer 4

Bezpośrednia odpowiedź na twoje pytanie brzmi: ty nie potrzebujesz zagnieżdżonego blokowania. Jednak kompilator pozwala na to, aby niektóre scenariusze były łatwiejsze do kodowania.

W przykładowym kodzie z pytaniem wewnętrzne zamki będą zawsze zawsze udane - ponieważ aby dostać się do wewnętrznego zamka, musisz już uzyskać zewnętrzny zamek. Twój wątek ma już blokadę na locker, więc wewnętrzna blokada "automatycznie" się powiedzie.

To nigdy nie jest konieczne i nie zapewnia dodatkowego bezpieczeństwa wątku.

Jednak w scenariuszach takich, jak te zamieszczone w odpowiedzi Jirki Hanika, zachowanie to oznacza, że ​​jeden bezpieczny w wątku element może zostać wywołany przez innego członka bezpiecznego dla wątków bez martwienia się o zakleszczenia.