Dov'era "asincrono" tutti questi giorni? [chiuso]

Non è certo una novità, è proprio dove l'industria (non solo MS) ha fatto molti progressi ultimamente in termini di renderla più accessibile ai sub-genius.

Storicamente, la programmazione asincrona era più complicata e difficile, per esempio prendi in considerazione l'api socket asincrono in windows.

Con i nuovi strumenti e amp; astrazioni che escono, diventa più facile ogni giorno. Dai un'occhiata a com'è facile con node.js, per esempio.

Ti rendi conto che il primo A di AJAX è Asincrono, giusto? Questa è una delle sue fonti negli ultimi dieci anni. Le CPU multi-core possono essere un altro motivo per alcune di queste, poiché più thread possono essere gestiti contemporaneamente il problema della sincronizzazione che è in circolazione da un po ', vedi Two Generals 'Problem che aveva una prova scritta nel 1975.

Asynchrony in C # 5.0 parte Quattro: Non è magico ha questo punto che penso sia rilevante:

A number of people have asked me "so does this mean that the Task Asynchrony Pattern only works on UI threads that have message loops?" No. The Task Parallel Library was explicitly designed to solve problems involving concurrency; task asynchrony extends that work. There are mechanisms that allow asynchrony to work in multithreaded environments without message loops that drive user interfaces, like ASP.NET.

Quindi i punti sulla concorrenza sono rilevanti qui. Se si vuole suggerire che non è il caso, si prega di eseguire il backup di tale argomento in quanto la concorrenza sembra pertinente qui. Concederò che l'asincronia non è esattamente concorrenza.

Sembra simile a quello che alcuni dialetti Lisp chiamano futures , sebbene la restrizione sintattica (più alcuni dei link di discussione) implichi che lo stiano facendo tramite una trasformazione CPS locale (stile passaggio continuo).

Per quanto riguarda il motivo per cui ci vuole tanto tempo, se provi da una mentalità C / C ++, probabilmente pensi che "lo stack" sia reale ; ti aspetti che le variabili vivano lì, potresti addirittura creare dei puntatori alle cose allocate allo stack. Mentre in un linguaggio di livello superiore, pensate al contesto del programma (o continuazione ), che potrebbe vivere su "lo stack", ma potrebbe essere copiato o spostato quando il language runtime si sente come se implementasse cose come continuation di prima classe, thread leggeri, ricorsione profonda e ricorsione di coda adeguata su piattaforme ostili. Sembra che .NET stia semplicemente prendendo alcune delle tecniche sviluppate per implementare linguaggi di livello superiore e portarli, in modo conservativo, in C #.

I core multipli hanno reso asincrona una funzione linguistica molto più utile. Invece di essere semplicemente un modo di scambiare facilmente i compiti, è un modo semplice per avere più attività in corso allo stesso tempo. Il valore maggiore ha portato a un uso maggiore.

Inoltre, dal punto di vista del marketing, devi avere qualcosa di radicalmente nuovo quando rilasci una nuova versione di un prodotto. :)