TRTLCriticalSection i zakleszczenia

Witam
Stosunkowo często w pewnym projekcie korzystam z wątków i co za tym idzie z sekcji krytycznych. Niestety od niedawna dochodzi do za kleszczeń tzn. aplikacja się zawiesza i tyle co o niej wiadomo. Problem jest nie do odtworzenia u mnie - być może kwestia szczęścia, ale zastanawiam się czy jest jakaś możliwość dowiedzenia się jaka sekcja krytyczna czeka za długo?
Do głowy przyszło mi coś takiego - logowanie każdego locka i unlocka do pliku jeśli program się zawiesi będę wiedział gdzie ostatni raz aplikacja utknęła jednak ilość sekcji krytycznych jest dość spora i wolałbym zachować to rozwiązanie na koniec jeśli nie będzie lepszej alternatywy.
Korzystam tutaj z TRTLCriticalSection i problem jest prawdopodobnie przy EnterCriticalSection podczas gdy inny wątek czeka na zakończenie obecnego (zresztą każdy kto wie co to zakleszczenie powinien wiedzieć z czym mam problem), niestety "na oko" jest to trudno wyśledzić. Zatem istnieje jakiś sposób wyłuskać info gdzie utknął program? lub ustawienie jakiegoś timeout'a po którym mógłbym to jakoś logować i zamknąć aplikację?

jesli jest tam tez glowny watek, to sprobuj MadExcept. Zaznacz tam "Main thread freeze checking" i bedziesz mial wiecej infa.

Może zrób swoją klasę: TmyRTLCriticalSection która dziedziczy po ...
Dalej to chyba nie muszę tłumaczyć :D

@mca64 Zainstalowałem MadExcept w opcjach zaznaczyłem "Check for frozen main thread --> freeze timeout 5 sec." Napisałem sobie prostą aplikację w której występuje zakleszczenie sekcji krytycznych jednak żadnej reakcji. Podejrzewam, że musi się też zawiesić główny formularz (jeśli zawieszę główną formę np. sleep'em MadExcept reaguje i tworzy raport). Raport jest w bardzo czytelnej formie więc jeśli zadziała to na pewno się przyda.
Odpaliłem moją aplikację główną i teraz czekam aż się wysypie...
Wyczytałem też, że nie powinno się używać synchronize gdy jest się w sekcji krytycznej i to może być problemem bo tak robiłem jednak osoba, która tak napisała nie uzasadniła dlaczego -,-. Jak będą jakieś postępy dam znać.

bys musial wkleic kod, to cos sie wymysli

szopenfx napisał(a):

Wyczytałem też, że nie powinno się używać synchronize gdy jest się w sekcji krytycznej i to może być problemem bo tak robiłem jednak osoba, która tak napisała nie uzasadniła dlaczego -,-.

Po mojemu to logiczne jak wejdziesz do sekcji krytyczniej to kod zostaje wykonany do czasu jej opuszczenia bez przełączania się na inne wątki a Synchonize właśnie to robi i raczej tu jest problem.

szopenfx napisał(a):

... jednak osoba, która tak napisała nie uzasadniła dlaczego -,-. Jak będą jakieś postępy dam znać.
Synchronize czeka na wątek główny.

Dzięki MadExcept namierzyłem klasę, która powodowała freez aplikacji i pomogło użycie Synchronize poza sekcją krytyczną (tzn. do tej pory problem się nie powtórzył). Teraz przenoszę pozostałe takie miejsca w kodzie (które nie powodowały zawieszki) - lepiej dmuchać na zimne :P
Główna formatka jest u mnie odpowiedzialna za komunikację po TCP/IP (komponenty TClientSocket/TServerSocket tryb NonBlocking) pewnie przez to dochodziło do zakleszczenia, gdy nowe "obrobione" pakiety chciały skorzystać z zablokowanej klasy choć pewności nadal nie mam.