Sono diversi thread su diverse istanze di JavascriptSerializer o JavascriptDeserializer thread safe

Question

Sto cercando una risposta definitiva qui.

Secondo the documentation i metodi statici pubblici di JavascriptSerializer sono thread-safe ma i metodi non-statici no.

È garantito che per i metodi pubblici non statici di questa classe diverse istanze di esecuzione di thread diversi sono thread-safe (ovvero che non esistono risorse statiche private che potrebbero violare la sicurezza dei thread)? Sono particolarmente i metodi per serializzare e deserializzare in JavascriptSerializer e JavascriptDeserializer a cui sono interessato, ma vorrei conoscere la risposta in generale.

Ciò significa che se il thread A viene eseguito solo sull'istanza A e sul thread B viene eseguito solo sull'istanza B esiste una garanzia definitiva di sicurezza del thread dei metodi pubblici non statici in tale scenario?

Answer 1

Per ricapitolare la domanda: È possibile utilizzare istanze discrete di JavaScriptSerializer su thread diversi con un massimo di un thread che interagisca con una particolare istanza?

Sto cercando una risposta definitiva qui.

Non posso dartelo. Tuttavia, (come probabilmente sapete) il messaggio di sicurezza del thread nella documentazione è estremamente generico e appare quasi ovunque (un'eccezione è rappresentata dai tipi per cui viene gestita la concorrenza).

Aneddot: non sono a conoscenza di alcun tipo che memorizza lo stato interno condiviso che non è thread-safe. È come chiedere se è possibile utilizzare due diverse istanze di uno List o XmlDocument su due thread differenti; il quadro sarebbe del tutto inutile se non fosse possibile.

JavaScriptSerializer è pensato per essere istanziato più volte su più thread come farà un server web (il threading ASP.Net è piuttosto complesso, ma più istanze di tipi sono certamente create e invocate su thread diversi). Il framework MVC utilizza internamente JavaScriptSerializer, quindi è chiaro che il team intende utilizzarlo in un ambiente Web multi-thread.

Una rapida vista della sorgente decompilata non mostra uno stato interno condiviso. Come nota @usr, non vi è alcuna garanzia di coerenza nell'implementazione interna. Tuttavia, sembrerebbe altamente improbabile che ciò cambierebbe per i motivi sopra citati.

Tutto ciò detto, lo JSON.net library è spesso considerato un'alternativa superiore per la serializzazione JSON (de) per le sue prestazioni e flessibilità.

Answer 2

Non è garantita la sicurezza del thread perché solo la documentazione può garantire che. Ma non è così.

Non è possibile testare la sicurezza del filetto. Gli errori di threading possono essere visualizzati solo sotto carico o in produzione.

Anche l'implementazione può cambiare in qualsiasi momento. Installa un aggiornamento di Windows, un service pack o una nuova versione e le interruzioni di codice.

Per quanto mi riguarda, questa è una risposta definitiva - non puoi fare affidamento su di essa. Inoltre, non vedo perché creare regolarmente un'istanza nuova sarebbe un problema anche per piccole quantità di dati. La deserializzazione è molto più intensiva della CPU rispetto all'istanziazione di un singolo oggetto. Creare un oggetto (piccolo) è estremamente economico.

Answer 3

Se tipo statico contiene pericoloso stato privato

è come bomba a orologeria. Immagino che nessuno lo faccia.