Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
L'unica idea che mi è venuta in mente è che il blocco di sincronizzazione venga utilizzato nell'indexer per ottenere un item da un indice, ma in quel caso la protezione sarebbe così debole da rivelarsi completamente inutile
Secondo me sarebbe meglio se gli items si aggiornassero in "real time" seguendo la lista passata al costruttore.
In quel caso avrebbe molto più senso, o no?
Ultima modifica effettuata da il 11/09/2011 alle 14:46
credo che sia legata all'enumerazione, ad ogni modo basta dare in pasto la classe al reflector e vedi cosa è stato modificato dalla classe standard
comunque, anche l'accesso a dati readonly deve essere sincronizzato, possono verificarsi casi in cui anche le semplici letture concorrenti vadano in conflitto - HeDo - 11/09/11 16:15
L'utilità sta nel fatto che è thread-safe. Probabilmente evita che più thread accedano contemporaneamente, completando le richieste dei thread una alla volta, in modo da non creare conflitti.
thread 1 accede alla risorsa... a metà dell'accesso scade il suo timeslice e passa in esecuzione un altro thread, il quale si era fermato nello stesso punto in cui si è fermato thread 1. Thread 2 quindi modifica i dati e quando thread 1 passa di nuovo in esecuzione lavora con dei dati cambiati. - Qwertj - 11/09/11 16:13
lo spiega bene qui nel primo paragrafo http://totemslair.org/guide/viewchapter.php?guida=vb&id=88 - Qwertj - 11/09/11 16:14
si ok -.- quello che ha detto HeDo non differisce molto da quello che ti ho detto io... - Qwertj - 11/09/11 18:40
bè allora non capisco perchè non capivi che il conflitto poteva esserci in un'enumerazione - Qwertj - 12/09/11 09:04
