Commenti Un lettore di in un articolo che ho scritto sulla programmazione asincrona di Entity Framework trasformato in un interessante dibattito sul ruolo della programmazione asincrona nel mondo moderno (interessante per me, in ogni caso). Back in the day, che ho usato per raccontare gli sviluppatori che il modo più sicuro per creare un bug che non avrebbero mai essere in grado di rintracciare era quello di scrivere quello che eravamo abituati a chiamare "applicazioni multi-threaded." Ho dato seminari sulla progettazione di applicazioni multi-threaded, dove, perversamente, ho passato i primi cinque minuti per spiegare perché non si dovrebbe fare multi-threading a meno che non si doveva assolutamente. E poi, naturalmente, mi piacerebbe andare a casa e scrivere applicazioni multi-threaded per i miei clienti: fare come dico, non come faccio io.
Ovviamente, i processori multi-core ei nuovi strumenti asincroni in. NET Framework hanno cambiato l'ambiente tremendamente. Ma ho scoperto durante la discussione che penso ancora di programmazione asincrona come qualcosa che si fa quando si hanno problemi specifici nell'applicazione che solo la programmazione asincrona risolverà. Nel mio modello mentale, vorrei scrivere il mio codice sincrono, vedere dove ho avuto problemi di reattività, e quindi riscrivere le parti della applicazione per utilizzare codice asincrono (che, a volte, potrebbe innescare alcune modifiche architettoniche alla domanda). Solo se potevo vedere i problemi reattività di anticipo dovrei iniziare a scrivere codice asincrono. Ma ero sempre facendo come alternativa alla mia modalità predefinita: la scrittura di codice sincrono.
I commentatori hanno contestato che, effettivamente dire che (in molti casi) la programmazione asincrona dovrebbe essere la scelta di default dello sviluppatore. Come un lettore sottolineato, un thread bloccato può richiedere fino a un megabyte di memoria mentre è al minimo. Integrare la programmazione asincrona in grado di eliminare quella perdita.
Naturalmente, vi è una questione di sapere se vi preoccupate che megabyte: per circa $ 10.000, posso ottenere un server con 256 gigabyte di RAM - che è più di un quarto di un milione di quei megabyte che stavamo preoccuparsi di salvataggio. Il chargeback a pieno carico per un programmatore di computer potrebbe inghiottire che diecimila dollari in un paio di giorni; quindi se il programmatore sta spendendo molto tempo "extra" per salvare la strana megabyte, non ha senso fiscale.
Ma ecco il punto: se i costi di scrivere il codice in modo asincrono dall'inizio è "banale" (per citare un altro lettore), non dovrei essere iscritto in modo asincrono dall'inizio? Non avrebbe bisogno di acquistare server e mentre il costo incrementale per il tempo sviluppatore iscritto async dall'inizio potrebbe non essere zero, potrebbe facilmente essere trascurabile.
Si tratta di un potente argomento. Non credo che ci sono ancora (Vedo ancora gli strumenti asincroni come è facile fare la programmazione asincrona quando ho bisogno di farlo ), ma mi può venire in giro. Ho ancora preoccupo per quei bug non è mai rintracciare, però. L'eccezione EF solleva quando si esegue più processi asincroni sullo stesso contesto mi sembra essere il tipo di problema che non si sarebbe verificato durante lo sviluppo, ma potrebbe sollevare la sua ripugnante testa in produzione, per esempio. Ma io possa essere preoccupante inutilmente.
Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java
Nessun commento:
Posta un commento