Instrukcja lock

Zaczynam pracować nad programami wątkowymi.
Nie wiem jak do końca działa metoda lock. Bo w internecie ciężko znaleźć mi precyzyjną odpowiedz.
Dlatego proszę, aby ktoś odpowiedział, na moje pytanie jak najprościej, abym już dłużej nie błądziła.

Załóżmy że 100x wywołuję metodę void (innej klasy), wewnątrz to której wykonują się czasowo długie obliczenia. A ciało tej metody jest opatrzone lock'iem
Załóżmy, że przy 50-tym razem wątek stara się wejść do metody, ale poprzedni wątek nie skończył swoich działań, dlatego wątek który starał się o wejście... (w miejsce kropek proszę wstaw co się z nim dzieje? czeka? kiedy się wykona? przepada? może zostać zagłodzony? trzeba kolejkować?)

Moje pytanie poboczne. Nie rozumiem, czemu jako argument lock'a podaję się, taką kolekcję?

private Object thisLock = new Object();

Proszę o pomoc :)

1. Jeśli się nie mylę to ten wątek czeka, aż poprzedni skończy pracę i dopiero wtedy rusza.
2. Ja to rozumiem tak, że jest to w stylu takiego "punktu zaczepienia". Mianowicie w jednym wątku edytujesz kolekcje, a w innym odczytujesz. Przez to możesz nie odczytać aktualnej kolekcji. Ale jeśli użyjesz tego "punktu zaczepienia" to metoda odpowiedzialna za odczytywanie zobaczy, że ten "punkt" jest obecnie używany i poczeka, aż zostanie zwolniony. Używa się zwykłego obiektu, bo on ma służyć tylko jako ten "punkt" i nie powoduje problemów.

Tutaj masz fajnie wyjaśnione: http://www.altcontroldelete.pl/artykuly/wielowatkowosc-w-c-synchronizacja-watkow-cz-1-lock-monitor-mutex-/

Mam nadzieję, że nigdzie się nie pomyliłem.

marta1995 napisał(a):

Moje pytanie poboczne. Nie rozumiem, czemu jako argument lock'a podaję się, taką kolekcję?

private Object thisLock = new Object();

Ale tu nie ma żadnej kolekcji...

Poczytaj o klasie Monitor, lock to tak naprawdę opakowany Monitor.
Co do:

private Object thisLock = new Object();

Nie jest to konieczność, ale chodzi zidentyfikowanie blokady, czasami potrzebujesz takiego samego locka w więcej niż jednej metodzie (jeśli te metody np. modyfikują wspólną kolekcję).

No ale klasa monitor działa zupełnie inaczej... tam jest try itp.
@Degusto sugeruje, że wątek czeka, ale czy tak jest na prawdę?
Bardzo mi zależy, bo program mi się wysypuje, a nie wiem co może być tego przyczyną. Programy wątkowe ciężko się debugują.

http://stackoverflow.com/questions/6029804/how-does-lock-work-exactly tu jest ładnie wyjaśnione

Właśnie na takie strony trafiałam, i dlatego zdecydowałam się napisać na forum.
Liczyłam, że ktoś będzie umiał mi konkretnie w jednym zdaniu objaśnić tego istotę.

@Degusto sugeruje, że wątek czeka, ale czy tak jest na prawdę?

Tak, wątek czeka.

private static readonly Object obj = new Object();

lock (obj)
{
    // critical section
}

In above code first thread enters critical section then it will lock obj and when other thread tries to enter then it will also try to lock obj which is already locked by first thread, I will have to wait for first thread to release obj. and when first will leave then other thread will lock obj and will enter to critical section.

Tu masz wyjaśnienie dlaczego lockujemy właśnie obiekt wewnętrzny a nie np. obiekt własny: http://stackoverflow.com/questions/251391/why-is-lockthis-bad

No ale klasa monitor działa zupełnie inaczej... tam jest try itp.
Działa zupełnie tak samo bo to jest to samo.

kod

lock (cośtam)
{
 // ....
}

jest skróconym zapisem tego:

Monitor.Enter(cośtam);
try
{
 // ....
}
finally
{
    Monitor.Exit(cośtam);
}