2009-12-18 21 views
7

Nell'ultimo anno stavo lavorando su Java e flex. Durante la codifica flex, la maggior parte delle mie parti di codice sono state utilizzate per il lancio in quanto asincrona. Mi ha fatto pensare ai veri vantaggi e svantaggi dei linguaggi di esecuzione sincroni rispetto a quelli in esecuzione asincrona.Lingue sincrone e asincrone

Quali sono le aree in cui sono più forti rispetto ad altri e quali sono le aree che cadono?

+6

Come può un linguaggio essere asincrono? –

+0

@NSD: ciò che intende è che Flex non blocca mai: tutte le operazioni che potrebbero bloccare su altre piattaforme vengono implementate in modo asincrono. – Grokys

+3

Hai una definizione per "linguaggio di esecuzione sincrono"? Oppure stai semplicemente interpretando la natura guidata da eventi di Flex (che si trova anche in quasi tutte le altre API della GUI, incluso Java) come "asincrona"? – kdgregory

risposta

6

Ho trascorso la maggior parte dell'ultimo anno di programmazione in Silverlight, il che significa che ho passato molto tempo a riflettere (e a combattere) con gli stessi problemi che stai descrivendo.

In breve, come altri hanno sottolineato, la vera forza del modello asincrono è la sua capacità di creare sistemi robusti che interagiscono bene con il mondo reale. Nessuno potrebbe realisticamente utilizzare un'applicazione Silverlight (o Flash) se il thread dell'interfaccia utente si arrestasse ogni volta che sono necessari alcuni secondi prima che una chiamata al servizio web tornasse.

Il più grande svantaggio è che il codice risultante è complesso e difficile da risolvere. Cose come la gestione degli errori sono un PITA, ma le cose più fastidiose che ho dovuto affrontare sono il coordinamento delle risposte da più chiamate asincrone. Se, per esempio, hai bisogno di informazioni dalla chiamata A prima di effettuare la chiamata B, e hai bisogno di informazioni dalla chiamata B prima di effettuare la chiamata C (e così via), il codice risultante appare davvero sgradevole ed è suscettibile a tutti i tipi di strani effetti collaterali . Ci sono tecniche per far funzionare tutte queste cose, e anche ragionevolmente pulite, ma se vieni dal mondo sincrono (come lo ero io), è una curva di apprendimento significativa. (E non aiuta Microsoft a spingere gli eventi come il modo di gestire le chiamate WCF quando i callback, a mio parere, sono molto più puliti e meno suscettibili al genere di strani effetti collaterali di cui stavo parlando.)

(E sì, altre persone siano corrette nel dire che non è il linguaggio che è asincrona, quanto che i quadri particolari richiedono costruire il codice in modo asincrono -. Ma ottengo quello che vuoi dire)

Aggiornamento 2014.09.23 -

Ho lavorato molto di più con una varietà di framework asincroni da quando ho scritto la risposta sopra (come probabilmente tutti gli altri che hanno fatto qualsiasi codice web), e ho pensato di aggiungerne alcuni ulteriori note a caso:

  • Se stai usando un linguaggio come C# o F # che ha un supporto asincrono di prima classe, molto di questo diventa molto più semplice, almeno, una volta che ti giri nei bizzarri schemi async/await. Essere in grado di aggirarsi facilmente intorno a chiamate asincrone e avvolgere il tutto con un semplice try/catch, è sorprendente se hai mai dovuto farlo alla vecchia maniera.

  • Se non si utilizza un linguaggio con il supporto asincrono di prima classe, iniziare a utilizzare qualunque promise o future o task sostegno che il linguaggio non fornisce (ad esempio, JQuery di $.Deferred(), o angolare di $q.defer(). Quelli sono molto più pulito e fornisce una struttura migliore rispetto a quella che si ottiene normalmente con i callback

  • Il codice asincrono è fondamentale per la scrittura di sistemi scalabili lato server. Uno dei maggiori problemi con la realizzazione di una tipica scala di server Web è che inizia a esaurire i thread, almeno lo fa se dedica un thread per raggiungere la richiesta in arrivo. Se quel thread si blocca, perché è in attesa di un lungo eseguire la chiamata sincrona per finire, non è completamente disponibile per aiutare con qualsiasi altra cosa. Molto meglio è rendere il codice del tuo server web asincrono, in modo che quando stai aspettando una chiamata al DB per tornare, quel thread può andare a servire una mezza dozzina di altre richieste mentre il DB sta andando e facendo qualunque cosa sia il DB. A questo punto, per i sistemi altamente scalabili, async è l'unico gioco in città. (Basta chiedere a qualsiasi appassionato di Nodo.)

+0

Esiste qualche pratica per scrivere applicazioni nel framework basato sugli eventi? – Umesh

+0

Diciamo solo che le espressioni lambda sono il tuo nuovo migliore amico :-). A parte questo, penso che i modelli e le pratiche varieranno in larga misura da un quadro all'altro, a seconda dei vincoli che ti pongono. Ad esempio, nel mondo di Silverlight, ho trovato che aiuta notevolmente a racchiudere il pattern event-driven che Microsoft fornisce con un pattern callback-oriented (e di solito implemento il callback come espressione lambda). Questo rende estremamente più semplice seguire la logica dell'applicazione. Non ho fatto abbastanza Flex per sapere cosa è appropriato lì. –

3

(Lasciando da parte la discussione di livello semantica vale a dire "sync/lingua asincrona")

"quadro" Un costruito su un "linguaggio" (qualunque esso sia) dovrebbe essere in grado di gestire questi casi (programma di sincronizzazione/asincrona flusso) per essere utile (leggi: $ saggio).

Gli idiomi asincroni sono appropriati ad ogni scala.

Su larga scala, le tecniche asincrone aiutano a costruire sistemi affidabili perché il mondo reale è comunque di natura asincrona. In altre parole, è necessario pensare in "pensieri asincroni" per far fronte a situazioni reali come guasti, perdite, ritardi, ecc.

Anche su una scala più piccola (ad es. Applicazione GUI), eventi (come "mouse i clic ") tendono ad essere" asincroni ". Naturalmente sono "serializzati" ad un certo punto (per essere processabili da un'applicazione che esegue un software) ma non cambiano il fatto che gli eventi (probabilmente) si sono verificati "in modo asincrono" per quanto riguarda il flusso del programma in domanda.

+0

Vero se si pensa a più casi di test in parallelo. Ma per quanto posso pensare, aiuteranno solo per i casi di test. Nella vita reale e tutto il "next what" dipende esclusivamente da "cosa sta succedendo adesso" o risultato di ciò. Quindi, come può essere asincrono diventare un risultato? – Umesh

+1

@Umesh: il "cosa sta succedendo ora" è una "sandbox" creata da eventi di "serializzazione" artificialmente. Si tratta di una "cornice di riferimento" (come la chiameremmo in fisica).Per quanto riguarda "come può essere asincrono diventare un risultato", devo dire che non ti sto seguendo. Per favore, ti interessa spiegare? – jldupont

+0

La tua spiegazione mi ha chiarito. Per favore dimentica la mia domanda. Grazie – Umesh

1

Penso che non si tratti della lingua, ma del framework.

Counter-caso in questione:

Durante la scrittura di 'Mac Classic' (MacOS 9 e precedenti) applicazioni in C (una lingua 'sincrona' se mai ve ne fosse uno), non si dispone di multithreading preventiva, quindi tutte le chiamate di sistema potenzialmente bloccanti hanno una controparte asincrona, in cui si riempie un blocco di dati con parametri che includono una funzione di callback. Quindi esegui la chiamata di sistema (che verrebbe restituita immediatamente) e il callback verrebbe chiamato in modo asincrono (in quello che viene chiamato 'livello di interruzione'). Non era raro che un callback facesse un'altra chiamata di sistema asincrona, creando un lungo thread in background che girava in modo asincrono con quello principale.

+0

Significa davvero un miglioramento delle prestazioni eseguendo le cose in parallelo e utilizzando l'hardware . Ma qual è il costo di ascoltare i callback dal thread principale. Hanno un lato migliore? – Umesh

+0

@Umesh: non si ascoltano i callback da un altro thread, il thread chiama direttamente il callback. L'overhead è uguale a qualsiasi altra chiamata di funzione. – tloach