Apprendimento della programmazione asincrona [chiuso]

La programmazione asincrona non bloccata guidata dagli eventi sembra essere di gran moda. Ho una comprensione concettuale di base di cosa significhi tutto ciò. Tuttavia, ciò che non sono sicuro è quando e dove il mio codice può trarre vantaggio dall'essere asincrono o da come rendere IO bloccante, non bloccante. Sono sicuro di poter semplicemente utilizzare una libreria per farlo, ma sono più interessato a concetti più approfonditi e ai vari modi per implementarlo da solo.

Ci sono libri completi / definitivi o altre risorse su questo argomento (come GoF for Design Patterns o K&R for C, tldp per cose come bash)?

(Nota: non sono sicuro che questa sia effettivamente una domanda identica alla mia domanda sulla programmazione guidata dagli eventi di apprendimento )

La programmazione asincrona è molto più una filosofia che un semplice trucco di programmazione. Mentre la tua ultima domanda ha attirato risposte principalmente sugli aspetti della programmazione e la mia risposta è stata un solitario disconnesso per essere principalmente teorico, sto cercando di darti una nuova prospettiva basandosi sulla stessa linea ma spiegazioni piuttosto che semplici riferimenti.

Questo riguarda alcuni fondamenti del perché e del come della programmazione asincrona.

Supponiamo che tu vada in una panetteria (e supponendo che la torta sarà preparata dopo l'ordine) - hai due scelte, o scegli di aspettare fino a quando la torta è pronta oppure dai l'ordine e torna a casa e raccogli più tardi quando è pronto. Il primo (wait) è un metodo sincrono e successivamente è un metodo asincrono . Inutile dire che questo esempio fornisce un buon riferimento perché dovresti usare metodi asincroni su sincroni.

La programmazione basata su eventi è solo uno dei modi in cui i sistemi asincroni possono essere costruiti e non è solo un utile modello di progettazione, ma piuttosto un modello architettonico. Sto elencando i casi in cui questa teoria viene utilizzata in un modo praticamente utile, sperando che possa portare un po 'di chiarezza

1. Uno dei primi esempi di sistemi asincroni è il sistema Unix IO. Sebbene lo sappiamo read(), write()e anche le select()chiamate bloccano il flusso del programma, ma all'interno del sistema operativo, sono asincrone, ovvero il kernel generalmente sa che il dispositivo a blocchi (noto anche come disco rigido) impiegherà del tempo per riempire il buffer, fino a quando la CPU è libera da quel rispettivo thread e quindi il thread viene parcheggiato come (non pronto). Consultare 1. Moris Bach "La progettazione del sistema operativo Unix"

2. Un altro esempio più comune è la maggior parte dei framework dell'interfaccia utente. Qui, tutti i clic dell'utente vengono prima inviati tramite un controller che a sua volta richiama la rispettiva applicazione. La cosa importante è che tali richiamate non dovrebbero far attendere le richiamate altrimenti il ​​sistema si bloccherà. La richiamata dal controller dell'interfaccia utente ai back-end è in genere asincrona se comporta un'elaborazione pesante.

3. Un altro buon esempio di programmazione asincrona (come puro modello di progettazione) è Active Object. Un oggetto attivo è uno che ha il proprio thread privato in modo tale da poter mantenere molte richieste in una coda ed eseguire uno per uno. Fare riferimento a questo documento: oggetto attivo . Questo modello è ampiamente utilizzato dal software Enterprise ai framework mobili. Le piattaforme popolari Java / EJB e .NET consentono l' invocazione del metodo asincrono locale o remoto che essenzialmente consente agli oggetti normali di diventare oggetti attivi. Gli oggetti attivi erano presenti in Symbian: oggetti attivi nel sistema operativo Symbian di Aapo Haapanen (vedi anche: Oggetti attivi in ​​Symbian ). Questo è ora presente anche inAndroid ).

4. Oltre all'oggetto attivo, lo stesso autore Douglas C. Schmidt , ha prodotto un numero di altre opere che sono altri parallelismi con l'oggetto attivo e sono anche i modelli asincroni. Guarda questo Event Handling Patterns e un libro completo è disponibile sul suo libro Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects - V2

5. Quando un determinato oggetto deve restituire l'API, mentre si lavora in background per eseguire effettivamente il lavoro, la consueta metodologia è quella di avere un sistema multi-thread per raggiungere questo obiettivo. I sistemi threaded sono presenti ovunque da C (posix), C ++ ( boost ) a Java, C # e così via. L'oggetto attivo è essenzialmente solo un'astrazione che può nasconderlo. Scopri perché le implementazioni di oggetti attivi sono preferibili rispetto ai thread nudi. Un'altra buona lettura .

6. Ma questo concetto va oltre i thread o gli oggetti all'interno di un'applicazione per diventare asincrono. Uno dei migliori utilizzi è nei sistemi distribuiti in cui due applicazioni non devono necessariamente attendere l'una per l'altra per il coordinamento. Buon vecchio (o non così buono, qualunque sia il modo in cui lo guardi) RPC era sincrono. [ovviamente, ci sono anche altri RPC asincroni ]. Ma le alternative moderne come il Middleware orientato ai messaggi sono veramente asincrone per buoni motivi.

7. Ultimo ma potrebbe essere il più interessante, è la programmazione degli agenti che può beneficiare del modello di comunicazione asincrono .

Mentre la programmazione asincrona sembra sexy ma crea la sua 'complessità tra cui:

• framework per il passaggio del valore di ritorno
• sovraccarico aggiuntivo di comunicazione
• ulteriore necessità di sincronizzare costrutti
• possibilità di deadlock, corse ecc. se le cose non vanno bene.

... e così via.

Dovrebbe essere sempre usato solo per ragioni autentiche.

Quindi, quando si dovrebbe usare il modello asincrono? Quando dovresti mettere un thread in background e consentire al chiamante di passare in modo asincrono? Ecco alcune buone regole per il pollice quando si applica (ma non è completo)

1. Quando il sistema desidera applicare una conversazione con risorse serie rigorose: ad esempio, si desidera mantenere un numero fisso assoluto di thread. Il modello asincrono impone al sistema di implementare la coda.

2. Quando il chiamante deve fare "altre cose utili da fare" è davvero genuino. Tante volte, l'altro thread, anche se sbloccato, non farà nulla di utile e si aggira attorno al polling per i risultati. Questo in effetti può richiedere più CPU rispetto al modello sincrono di base.

3. Quando hai bisogno di livelli più alti di affidabilità nei sistemi distribuiti. (consultare Middleware orientato ai messaggi ).