Quanto "usa e getta" è ReaderWriterLockSlim?

Question

Seguo principalmente lo schema IDisposable e per la maggior parte delle classi giustificato. Ma ReaderWriterLockSlim mi ha fatto dubitare della fattibilità dell'applicazione di tale modello. Tutto lo ReaderWriterLockSlim.Dispose fa chiudere alcuni handle di evento. Quindi, quanto è importante la classe Dispose con così poche risorse? In questo caso, non mi dispiacerebbe davvero se il GC dovesse aspettare un altro giro per finire i finalizzatori delle risorse non gestite.

Le conseguenze per l'applicazione del modello IDisposable sono considerevoli, tuttavia, ogni classe che utilizza una classe usa e getta ora deve implementare anche IDisposable. Nel mio caso particolare, sto implementando un wrapper per HashSet. Non mi aspetto particolarmente il requisito di disporre di tale oggetto perché, accidentalmente, utilizza un sincronizzatore che lo fa.

Ci sono motivi per non violare lo schema monouso in questo caso? Mentre sono ansioso, non lo farei in pratica, perché la violazione della coerenza è molto peggio.

Answer 1

Il problema con gli handle di sistema non gestiti è che handles come from a limited supply. Il GC non è a conoscenza di ciò.

Il consumo di memoria puro di un handle non è così grande. Nient'altro che un oggetto nella memoria del kernel e probabilmente una voce nella tabella hash da qualche parte.

Avete ragione nel dire che non è sufficiente dire: "È necessario sempre smaltire tutti gli oggetti monouso". Quella regola è troppo semplice. For example the Task class does not need to be disposed. Se sai cosa stai facendo, puoi prendere una posizione più sciolta riguardo allo smaltimento. Tieni presente che non tutti i membri del team potrebbero comprendere questo punto (ora puoi lasciare un link a questa risposta nel codice sorgente ...).

Se sei sicuro di non perdere molte maniglie, puoi farlo tranquillamente. Tieni presente che in condizioni marginali (carico, bug, ...) potresti perdere più di quanto avevi previsto causando problemi di produzione.

Answer 2

Se questo campo è staticyou don't need to dispose of it, esso (righty) avrà la stessa durata della propria applicazione. Vedo che non lo è, lascia andare.

Il modo corretto di gestire un IDisposable è di eliminarlo. Penso che abbiamo bisogno di una buona ragione per non farlo.

Utilizzare un altro blocco:

Penso che la cosa migliore da fare è quella di utilizzare Monitor o in un altro blocco, che avrà il vantaggio di semplificare il codice pure. ConcurrentDictionary e altre classi quadro sembrano adottare questo approccio.

Siete preoccupati per la trasmissione convoglia, ma non sono sicuro che questo sia stato risolto anche da ReaderWriterLockSlim, l'unica vera soluzione è quella di contenere meno blocchi e tenerli per meno tempo.

Non smaltire:

questo ha bisogno di una giustificazione. Puoi dimostrare i benefici prestazionali necessari qui?

Se si dispone di alcuni di questi oggetti di lunga durata, bene, non tutti gli articoli monouso sono ugualmente pesanti (non è come lasciare un documento word aperto), probabilmente lo farai franca. Come è stato sottolineato, qual è il punto di smaltimento di tutti questi millisecondi prima che l'applicazione si chiuda comunque.Credo che il distruttore di un IDisposable sia destinato a gestire situazioni in cui l'oggetto non è disposto, sebbene non si possa essere sicuri di quando o anche se viene chiamato.

Se si ha una lunga esperienza con molti usi di breve durata di questa classe, tuttavia, si possono incontrare dei problemi. Stai preparando le tue ipotesi sull'uso del tuo codice, fai attenzione.