Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Aggiornamento: novembre 2007
La classe ReaderWriterLockSlim consente a più thread di leggere contemporaneamente una risorsa, ma per scrivere nella risorsa è necessario che un thread attenda un blocco esclusivo.
All'interno dell'applicazione, è possibile utilizzare ReaderWriterLockSlim per effettuare la sincronizzazione cooperativa tra i thread che accedono a una risorsa condivisa. I blocchi vengono effettuati sullo stesso ReaderWriterLockSlim.
Come con qualsiasi meccanismo di sincronizzazione di thread, è necessario assicurasi che nessun thread ignori il blocco causato da ReaderWriterLockSlim. Un modo per assicurare che questo avvenga è progettare una classe che incapsuli la risorsa condivisa. Questa classe fornisce membri che accedono alla risorsa condivisa privata e che utilizzano un oggetto ReaderWriterLockSlim privato per la sincronizzazione. Si veda l'esempio di codice per la classe ReaderWriterLockSlim. ReaderWriterLockSlim è abbastanza efficiente da essere utilizzato per sincronizzare oggetti singoli.
Strutturare l'applicazione in modo da ridurre la durata delle operazioni di lettura e scrittura. Le operazioni di scrittura lunghe influiscono direttamente sulla trasmissione di dati poiché il blocco scrittura è esclusivo. Le operazioni di lettura lunghe bloccano i writer in attesa e, se anche un solo thread è in attesa dell'accesso in scrittura, verranno bloccati anche i thread che richiedono l'accesso in lettura.
.gif "Nota") Nota: |
|---|
.NET Framework presenta due blocchi in lettura/scrittura, ReaderWriterLockSlim e ReaderWriterLock. ReaderWriterLockSlim è consigliato per i nuovi progetti di sviluppo. ReaderWriterLockSlim è simile a ReaderWriterLock, ma possiede regole semplificate per la ricorsione e per l'aggiornamento e il downgrade dello stato del blocco. ReaderWriterLockSlim evita molti casi di potenziale deadlock. Inoltre, la prestazione di ReaderWriterLockSlim è significativamente migliore di ReaderWriterLock. |