W jaki sposób "disposable" to ReaderWriterLockSlim?

Question

Generalnie podążam za wzorcem IDisposable, a dla większości klas jest to uzasadnione. Ale ReaderWriterLockSlim zmusiło mnie do kwestionowania możliwości zastosowania takiego wzoru. Wszystko, co robi ReaderWriterLockSlim.Dispose, zamyka niektóre uchwyty zdarzeń. Jak ważna jest taka klasa z tak małą ilością zasobów? W tym przypadku nie miałbym nic przeciwko, gdyby GC musiał czekać na kolejną rundę, aby finalizatorzy niezarządzanych zasobów mogli dokończyć.

Konsekwencja zastosowania wzoru IDisposable jest znaczna, jednak każda klasa korzystająca z klasy jednorazowej musi teraz również wdrożyć IDisposable. W moim konkretnym przypadku implementuję wrapper dla HashSet. Nie spodziewam się w szczególności wymogu pozbywania się takiego obiektu, ponieważ przypadkowo używa on synchronizatora, który to robi.

Czy są jakieś powody, aby nie naruszać wzoru jednorazowego w tym przypadku? Chociaż jestem chętny, nie zrobiłbym tego w praktyce, ponieważ naruszenie spójności jest znacznie gorsze.

Answer 1

Problem z niezarządzanymi uchwytami systemu operacyjnego jest taki, że handles come from a limited supply. GC nie jest tego świadomy.

Zużycie czystej pamięci klamki nie jest tak duże. Nic więcej niż obiekt w pamięci jądra i prawdopodobnie hash table entry gdzieś.

Masz rację, ponieważ nie wystarczy powiedzieć: "Musisz zawsze zawsze pozbywać się wszystkich przedmiotów jednorazowego użytku". Ta zasada jest zbyt prosta. For example the Task class does not need to be disposed. Jeśli wiesz, co robisz, możesz przyjąć luźniejszą postawę dotyczącą utylizacji. Należy pamiętać, że nie wszyscy członkowie zespołu mogą zrozumieć ten punkt (teraz możesz zostawić link do tej odpowiedzi w kodzie źródłowym ...).

Jeśli masz pewność, że nie wyciekniesz wielu uchwytów, możesz to bezpiecznie zrobić. Należy pamiętać, że w skrajnych warunkach (obciążenie, błędy, ...) może nastąpić wyciek w ilości większej niż przewidywano, powodując problemy z produkcją.

Answer 2

Jeśli to pole to staticyou don't need to dispose of it, będzie ono (righty) miało takie samo życie jak aplikacja. Widzę, że nie, przejdźmy dalej.

Prawidłowym sposobem postępowania z IDisposable jest pozbycie się go. Myślę, że potrzebujemy dobrego powodu, aby tego nie robić.

pomocą drugiego zamka:

Myślę, że najlepszym rozwiązaniem jest użycie Monitor lub inny zamek, który będzie miał bonus uproszczenie kodu, jak również. ConcurrentDictionary i inne klasy szkieletowe wydają się stosować to podejście.

Martwisz się o blokadę, ale nie jestem pewna, czy uda się to rozwiązać przez ReaderWriterLockSlim, jedynym realnym rozwiązaniem jest trzymanie mniejszej ilości blokad i przytrzymywanie ich przez krótszy czas.

Nie wyrzucaj:

To wymaga uzasadnienia. Czy możesz tutaj zademonstrować potrzebne korzyści związane z wydajnością?

Jeśli masz kilka przedmiotów, które są długo żywe, dobrze, nie wszystkie materiały jednorazowego użytku są równie ciężkie (to nie jest tak, że pozostawiasz otwarty dokument), prawdopodobnie ujdzie ci to na sucho. Jak zostało wskazane, jaki jest sens pozbycia się wszystkich tych milisekund, zanim aplikacja i tak się zamknie.Wierzę, że destruktor IDisposable ma za zadanie radzić sobie z sytuacjami, w których obiekt nie jest usuwany, chociaż nie można mieć pewności, kiedy, a nawet jeśli jest to wywoływane.

Jeśli masz długowieczną apli kację z wieloma krótkotrwałymi zastosowaniami tej klasy, możesz wpaść w kłopoty. Spiekasz w swoich założeniach dotyczących użycia twojego kodu, po prostu bądź świadomy.