Qual è il significato delle parole asincrone e sincrone nell'informatica?

Se vai su Google il significato delle parole otterrai quanto segue:

• Asincrono: non esistente o presente allo stesso tempo .

• Sincrono: esistente o esistente allo stesso tempo .

Ma sembra che siano usati per trasmettere il significato opposto nella programmazione o nell'informatica:

L'attributo asincrono HTML significa che lo script verrà eseguito non appena viene scaricato anche se l'HTML sta ancora analizzando o scaricando, il che significa che entrambi i processi, lo script e l'HTML, esistono e si verificano contemporaneamente per me.

Questi termini sono usati per indicare il significato opposto nell'informatica o mi manca il punto?

Vorrei darti una risposta direttamente correlata alle definizioni che hai trovato. Quando un'attività T1 avvia una seconda attività T2, può avvenire nel modo seguente:

Sincrono: esistente o esistente allo stesso tempo.

Quindi T2 è garantito per essere avviato ed eseguito all'interno della fascia oraria di T1 . T1 "attende" la fine di T2 e può continuare l'elaborazione successivamente. In questo senso, T1 e T2 si verificano "contemporaneamente" (non "in parallelo", ma in un intervallo di tempo contiguo).

Asincrono: non esistente o presente allo stesso tempo.

Quindi il tempo di esecuzione di T2 non è ora correlato a T1. Può essere eseguito in parallelo, può accadere un secondo, un minuto o diverse ore dopo e T2 può ancora funzionare quando T1 è terminato (quindi per elaborare un risultato di T2, potrebbe essere necessario un nuovo task T3). In questo senso, T1 e T2 non "si verificano contemporaneamente (intervallo)".

Naturalmente, sono d'accordo, le definizioni letterali sembrano ambigue quando si vede che le operazioni asincrone al giorno d'oggi sono spesso utilizzate per creare esecuzioni parallele.

Trovo che il modo migliore per capirlo sia il seguente:

• Sincrono: sappiamo quando accadrà (succede quando termina questo altro codice).
• Asincrono: non sappiamo quando accadrà.

Nota: mentre possiamo programmare l'esecuzione del codice in un determinato orario, in pratica non sappiamo quando accadrà, perché può essere ritardato - anche ignorando i messaggi di errore con l'orologio di sistema - perché il sistema è impegnato a fare qualcos'altro. Inoltre, anche se avessimo la garanzia che accadrà esattamente in un determinato orario, non siamo sicuri di dove sarebbe l'esecuzione del nostro programma in quel momento. Quindi, no, il codice programmato per l'ora non è sincrono.

Si noti che nello sviluppo del software diremo, ad esempio, che un'attività è asincrona come qualcosa che riguarda l'attività in isolamento. Tuttavia, se si desidera definirlo in termini di occorrenza allo stesso tempo o non è necessario disporre di almeno qualcos'altro a cui confrontare l'attività.

Molte piattaforme possono fare sia il parallelismo che il cambio di attività, alcune hanno un parallelismo limitato, alcune non possono affatto fare il parallelismo e si basano solo sul cambio di attività ... Inoltre, alcune piattaforme non sono in grado di interrompere un'attività e devono averle completate prima di eseguirne un'altra ... Le attività asincrone sono un'astrazione su tutto ciò, in modo tale che il sistema può decidere come eseguire le attività per la piattaforma data senza che lo sviluppatore si preoccupi (troppo).

Vale anche la pena notare che possiamo concettualizzare e di solito astrarre, ottenendo input esterni come attività asincrona. Ad esempio: ottenere testo dall'input dell'utente. Non sappiamo quando l'utente digiterà. Questo vale anche per la lettura da una memoria permanente, il recupero di dati sulla rete o qualsiasi altro sistema esterno.

A proposito, nonostante alcune cose siano fondamentalmente asincrone, di solito possiamo fingere che non lo siano. Lo facciamo facendo in modo che il software blocchi l'esecuzione corrente e non faccia altro fino a quando non viene completato. Cioè, possiamo prendere qualcosa di asincrono e avvolgerlo in un'API sincrona.

Un'API asincrona ti consentirà di continuare l'esecuzione nonostante l'operazione richiesta non sia stata completata, mentre una sincrona no. E da lì si ottiene l'idea asincrona - nel software - significa che si verificano contemporaneamente (simultaneamente).

Vale la pena notare che asincrono non implica la simultanea. In alcuni casi, la piattaforma può eseguire l'attività asincrona solo dopo che l'attività corrente è stata completata. Sarebbe sequenziale (sebbene l'ordine di esecuzione dell'attività asincrona non sia necessariamente garantito), non sarebbe concorrente (non vi sono sovrapposizioni nei periodi di esecuzione), ma sarebbe asincrono.

Oh, a proposito, in alcune piattaforme il sistema può decidere di incorporare l'attività asincrona e quindi eseguirla proprio come un'operazione sincrona (supponendo che sia possibile, che non è praticabile per ogni attività).

Ancora una volta, asincrono significa solo che non sai quando accadrà.

Potresti anche essere interessato a La differenza tra esecuzione "simultanea" e "parallela"? .

Asincrono: non esistente o presente allo stesso tempo.

Sincrono: esistente o esistente allo stesso tempo.

L'attributo asincrono significa che lo script verrà eseguito non appena viene scaricato anche se l'html sta ancora analizzando, il che significa che entrambi i processi esistono contemporaneamente per me.

Questo è davvero confuso!

Considera invece i significati di sincronizzato e non sincronizzato . Due cose sono sincronizzate se i tempi di uno dipendono dall'altro e non sincronizzati se i loro tempi non sono correlati.

Nel tuo flusso di lavoro asincrono di esempio, abbiamo due cose: l'esecuzione di script e l'analisi html. Queste due cose non sono sincronizzate ; i tempi dell'operazione di esecuzione e i tempi dell'operazione di analisi non dipendono l'uno dall'altro. Se rendessimo sincrono il flusso di lavoro , le operazioni diventerebbero sincronizzate . Ad esempio, l'esecuzione non inizia fino a quando l'analisi non è definitivamente terminata.

Ma è importante rendersi conto che in realtà ci sono tre possibilità qui:

• l'esecuzione e l'analisi sono veramente non sincronizzate; entrambi possono accadere in qualsiasi momento e in qualsiasi ordine, qualunque sia la più efficiente.
• l'esecuzione e l'analisi sono sincronizzate; ad esempio, la CPU non fa nulla durante l'attesa del completamento dell'I / O.
• l'esecuzione e l'analisi sono sincronizzate, ma mentre stiamo aspettando il completamento dell'I / O, alla CPU è permesso fare altro lavoro, quindi tornare e fare l'analisi dopo il completamento del download .

Una volta capito, lo scopo dei flussi di lavoro asincroni nei linguaggi di programmazione popolari diventa più chiaro:

• I flussi di lavoro asincroni ci aiutano a implementare le operazioni ad alta latenza in modo efficiente perché non siamo costretti a ordinare cose non correlate nel tempo. Se l'analisi è ad alta latenza e I / O associato, mentre l'esecuzione di script è ad alta latenza e legata alla CPU, possiamo ottenere una vittoria annullando la sincronizzazione totale o parziale di tali operazioni.

• L' awaitoperatore in lingue come C # è l'operazione di ordinazione su flussi di lavoro asincroni. Un'attesa è un'attesa asincrona ; è un punto in cui esprimiamo un rapporto ordinamento tra due parti di un flusso di lavoro asincrono, e dire che v'è un "avviene prima" relazione tra il codice prima della await e il codice dopo l'attendono. Ecco come implementiamo la terza opzione .

Se è tutto troppo astratto, pensa ad alcuni esempi del mondo reale. Quando invii una lettera, un'operazione I / O ad alta latenza, puoi comunque fare un lavoro ad alta intensità di CPU - diciamo i compiti di matematica - mentre aspetti di ricevere una risposta alla tua lettera. Le operazioni di fare i compiti di matematica e leggere la posta non sono sincronizzate.

Supponiamo ora che tu invii una lettera e che la risposta contenga un numero necessario per le tasse. Ora non è possibile eseguire il lavoro della CPU, calcolando le tasse, fino al completamento dell'operazione di I / O. Ma puoi ancora falciare il prato mentre aspetti . Questo è un flusso di lavoro asincrono che ha espresso una relazione temporale tra le sue parti.

Sono un ingegnere elettrico e ci siamo occupati di circuiti sincroni e asincroni (porte logiche).

Supponiamo che tu abbia una porta AND (o qualsiasi porta), che ha due ingressi e un'uscita.

Se è asincrono, aggiornerà il suo output nel momento in cui uno qualsiasi degli input cambia in modo tale che l'output cambi. Ecco come ha funzionato il tuo esempio: il programma che hai citato.

Tuttavia, se quel cancello ha anche un orologio (ad esempio un'onda quadrata di periodo di 1 secondo) ad esso collegato, dove si aggiorna sul battito di ogni secondo, poiché l'onda quadrata passa da bassa ad alta, è sincrona. È legato alla frequenza dell'orologio. Quindi è sincrono. Potresti collegare quell'orologio a molti circuiti e funzionerebbero al ritmo dell'altro - sincronizzati. Se il tuo programma verificava solo se veniva letto per essere eseguito ogni secondo, sarebbe anche sincronizzato.

Immagina due satelliti in orbita attorno alla Terra.

• Il satellite A ha un periodo di rotazione attorno alla Terra tale che per ogni rotazione completa del pianeta, il satellite ha girato la Terra più o meno di una volta .
• Il satellite B ha un periodo di rotazione attorno alla Terra tale che per ogni rotazione completa del pianeta, il satellite ha girato attorno alla Terra esattamente una volta .

Il satellite B nell'esempio sopra è in orbita geosincrona come definito da

avere un periodo di rotazione sincrono con quello della rotazione terrestre.

Non si sostiene che il satellite A sia geosincrono semplicemente perché "esiste o si verifica [s] allo stesso tempo" del pianeta. In effetti, il satellite B stesso non è nemmeno ciò che è rilevante - ciò che è rilevante è il periodo di rotazione che è sincronizzato con il periodo di rotazione con quello della Terra. Non si tratta dell'esistenza simultanea degli oggetti; riguarda la relazione tra gli oggetti. Mantieni questo pensiero.

Supponiamo che ti dica che due thread su un sistema sono in esecuzione contemporaneamente. Il thread A (TA) sta recuperando i dati per il processo A e il thread B (TB) sta recuperando i dati per il processo B. Ti chiedo "TA e TB sono asincroni?". La tua risposta sarebbe: "Come potrei saperlo? Devo vedere il codice che li ha invocati nei rispettivi processi." Al che avrei replicato nel mio tentativo di essere ingannevole, "Ma ti sto dicendo che TA e TB stanno decisamente correndo allo stesso tempo."

E tu, essendo un individuo abbastanza intelligente, risponderesti: "Ancora una volta - potrebbero essere in esecuzione contemporaneamente ma non ho idea se stanno funzionando in modo asincrono rispetto ai loro rispettivi processi che li hanno invocati. TA e TB che funzionano in modo asincrono l'una con l'altra fanno davvero non ha senso perché non sono stati generati dallo stesso processo. "

Quindi ormai dovremmo ottenere alcune intuizioni sul fatto che l'esistenza di una relazione è ciò che è rilevante qui, non solo l'esistenza di questi due fili stessi. Quando un metodo viene eseguito in modo asincrono, ciò che stiamo dicendo è che l'esecuzione di quel metodo " NON ha bisogno di esistere o verificarsi contemporaneamente" dell'esecuzione del metodo che lo ha invocato. Prendi il seguente esempio:

func Invoker() {
    DoThis();
    DoThatAsync();

    var foo = CheckThis();
    ... do some work ...
    CheckThat(foo);

    await DoThatAsync();

    CheckThat();
}

Dalla nostra discussione sui satelliti in precedenza, "Non si tratta dell'esistenza simultanea degli oggetti; si tratta della relazione tra gli oggetti". Non si tratta dell'esistenza di un metodo di invocazione e del metodo invocato; riguarda l'esistenza di una relazione tra l'esecuzione dell'invocatore e l'esecuzione dell'invocato. Se abbiamo esaminato i nostri thread di sistema e abbiamo scoperto che DoThatAsync()era stato invocato ma non era in esecuzione, forse è in attesa sullo scheduler o su qualche altro I / O, ciò non significa necessariamente che il metodo di invocazione Invoker()non sia in esecuzione - c'è lavoro che potrebbe star facendo. Certo, potrebbe essere al punto di awaiting DoThatAsync(), ma questo non è garantito. Questo non è vero per le altre funzioni dopo che sono state invocate: se si fermano,Invoker()si ferma - non importa quale. Questo è garantito L'esecuzione tra il Invoker()metodo sincrono e invocato "esiste o si verifica contemporaneamente".

Esempi concreti

Vorrei aggiungere alcuni esempi del mondo reale e collegarli al mondo dell'ingegneria del software. Innanzitutto, considera qualcosa che spero corrisponda alla tua definizione intuitiva di "sincrono": il lampeggiamento di lucciole , in alcune circostanze. In secondo luogo, considerare staffetta 4x100 femminile gara . Terzo, considera quel vecchio trofeo dei film militari: "Uomini, sincronizzate i vostri orologi!"

Ora, pensiamo a cosa sta succedendo. Cominciamo osservando che tutte queste cose sono processi o entità estese nel tempo . Non ha senso dire che una ciotola è "sincrona" e che il rock è "asincrono". In secondo luogo, ci vogliono due per il tango . Non si può dire che "un corridore è sincronizzato". Sincronizzare con cosa? Infine, affinché due processi facciano qualcosa contemporaneamente, a meno che non abbiano già la stessa identica frequenza e fase, uno o entrambi devono attendere .

Analisi

Quando la definizione del dizionario dice che due entità sincronizzate "si presentano o esistono allo stesso tempo", si allinea molto bene al concetto di luce delle lucciole. Sfortunatamente, dire che la luce è "sincronizzata" è un modo sciatto di dire che i processi di illuminazione della lucciola sono sincronizzati.

Quindi, come può un gruppo di lucciole, che presumibilmente non hanno Apple SmartWatch e NTP per guidarli, riuscire a far lampeggiare le loro estremità posteriori allo stesso tempo? Bene, è abbastanza facile se hanno un mezzo per impostare un tempo coerente e possono fare piccoli aggiustamenti. Lampeggiano semplicemente e se più persone lampeggiano subito dopo di loro, rallentano (aumentano il ritardo), mentre se più flash subito prima di loro, accelerano (diminuiscono il ritardo). Quindi possono usare un semplice processo di feedback per arrivare essenzialmente allo stesso tempo e fase. L'importante osservazione qui è notare che raggiungono la sincronia aspettando il momento giusto per lampeggiare .

La gara 4x100 è interessante perché vedete entrambe le forme di tempistica del processo in azione: i corridori all'interno di una squadra sono sincronizzati, mentre i corridori di squadre diverse sono "asincroni". Il secondo corridore nel relè deve attendere fino a quando il primo corridore entra nella zona di trasferimento . Il passaggio è un evento sincrono tra quei due corridori. Tuttavia, i corridori in corsie diverse non si preoccupano di ciò che sta accadendo in un'altra corsia , e sicuramente non rallentano e eseguono le loro mani in sincronia. Ogni corsia di corridori è asincrona l'una rispetto all'altra. Ancora una volta, vediamo che la sincronizzazione implica l'attesa, mentre l'asincronia no.

Infine, i soldati di una compagnia (plotone, squadra dei pompieri, ecc.) Devono sincronizzare i loro orologi in modo da poter attaccare il nemico allo stesso tempo . È possibile che alcuni soldati arrivino alle loro posizioni prima di altri o abbiano l'opportunità di sparare prima sul nemico. Ma un attacco simultaneo è generalmente più efficace di un attacco casuale a causa dell'elemento sorpresa. Quindi, per raggiungere la sincronia, molti soldati devono attendere il tempo stabilito per agire.

Definizione delle funzionalità

Perché questa enfasi sull'attesa? Bene, è perché aspettare è la caratteristica che distingue i processi sincroni da quelli asincroni. Se hai due processi di cui non sai nulla, per impostazione predefinita dovresti supporre che siano asincroni. Ad esempio, molto probabilmente una consegna del pacco e un'ambulanza che guidano non sono sincronizzate. Al fine di dimostrare che due processi sono, infatti, sincronizzato, è necessario trovare un momento molto speciale nel tempo: il punto di sincronizzazione .

Un corriere che consegna un pacco e un'ambulanza che porta qualcuno in ospedale generalmente non condividono alcun punto nel tempo che identifichiamo come "punto di sincronizzazione". D'altra parte, le lucciole che lampeggiano all'unisono hanno un punto di sincronizzazione ogni volta che lampeggiano, i corridori di staffetta hanno un punto di sincronizzazione ogni volta che passano il testimone e i soldati hanno un punto di sincronizzazione quando lanciano il loro attacco. Se riesci a identificare uno o più punti di sincronizzazione, i processi sono sincronizzati . Questo dovrebbe essere facile da capire, perché "syn-" è un prefisso greco che significa "con" o "insieme", e "chrono" è la radice greca per "tempo". "Sincronizzato" significa letteralmente "allo stesso tempo",

confini

Si noti che la "sincronizzazione" non si applica necessariamente all'intera durata di uno o entrambi i processi. Direi che si applica solo al "tempo di attesa fino ai punti di sincronizzazione inclusi". Pertanto, due processi possono operare in modo asincrono fino a quando non raggiungono uno stato in cui devono comunicare, quindi si sincronizzano, si scambiano informazioni e successivamente continuano in modo asincrono. Un semplice esempio è incontrare qualcuno per un caffè. Ovviamente, l'incontro è un punto di sincronizzazione (o molti, piuttosto), e il fatto che due persone arrivino a quel punto dimostra la sincronia. Tuttavia, non diremmo che, poiché due persone si sono incontrate per un caffè, quelle due vite umanesono "sincronizzati". Può darsi che sia stato l'unico istante nella loro vita che hanno incontrato, e tutto il resto che fanno è altrimenti indipendente.

Non è nemmeno il caso che incontri accidentali dimostrino la sincronia. Se due sconosciuti si incrociano per strada, il fatto che si trovino in un determinato luogo in qualche momento non dimostra sincronia. Né il fatto che una persona sia seduta su una panchina ad aspettare l'autobus, mentre un'altra passa di soppiatto. I processi sono sincroni solo quando si incontrano per uno scopo .

Connessione software

Ora, pensiamo a un compito fondamentale nel software: leggere da un file. Come probabilmente saprai, l'archiviazione di massa è in genere da migliaia a milioni di volte più lenta della cache o della memoria principale. Per questo motivo, i sistemi operativi e le librerie dei linguaggi di programmazione generalmente offrono operazioni di I / O sincrone e asincrone. Ora, anche se il tuo programma ha un solo thread, dovresti pensare al sistema operativo come un "processo separato" ai fini di questa discussione.

Sync

Quando si effettua una "lettura I / O sincrona", il thread deve attendere che i dati siano disponibili, a quel punto continua. Questo è molto simile a un corridore a staffetta che consegna il testimone al prossimo corridore, ma immagina invece un relè con solo due corridori che percorrono tutto il tracciato, e anche il secondo corridore restituisce il primo.

In questo caso, il thread del programma e il processo di I / O del sistema operativo non "stanno accadendo (agendo) contemporaneamente", quindi sembra strano affermare che questi processi sono "sincronizzati". Ma questo è il modo sbagliato di vederlo! È come dire: "I corridori di una squadra staffetta non corrono contemporaneamente, quindi non sono sincronizzati". In effetti, entrambe le affermazioni sono sbagliate! I corridori di una squadra di staffette lo fanno e devono correre allo stesso tempo, ma solo in un momento molto specifico: la consegna del testimone. In effetti, è solo questo momento speciale durante la gara che ci convince che le squadre di staffette sono sincronizzate per cominciare! Se consideriamo la richiesta e la risposta I / O come "il testimone",

D'altra parte, se pensiamo a qualcosa come l'analisi agli elementi finiti su un supercomputer, vediamo che migliaia di processi devono funzionare in blocco per aggiornare un enorme stato globale. Anche se alcuni nodi completano il loro lavoro per un determinato intervallo di tempo prima di altri, devono tutti attendere il completamento del passaggio di tempo perché i risultati si propagano ai vicini attraverso lo spazio. Questo tipo di sincronizzazione è come le lucciole: tutti gli attori svolgono lo stesso tipo di attività.

Varietà di processo

Per questo motivo, possiamo inventare alcuni termini per aiutarci a capire che ci sono tre tipi di cose: "sincronia omogenea", "sincronia eterogenea" e "sincronia sequenziale". Quindi, quando gli attori svolgono simultaneamente lo stesso compito (FEA, lucciole), sono "omogenei". Quando eseguono compiti diversi contemporaneamente (soldati che corrono contro gattonare contro il nuoto verso le loro destinazioni, fisica contro suono contro thread di intelligenza artificiale in un gioco), sono "eterogenei". Quando eseguono i compiti uno alla volta, sono "sequenziali" (relè, blocchi I / O). Possono sembrare molto diversi, ma condividono una proprietà essenziale: tutti i tipi di attori si esibiscono in attesa di assicurarsi che tutti arrivino al punto di sincronizzazione contemporaneamente. tra punti di sincronizzazione o "eseguire la stessa azione" è irrilevante per la proprietà della sincronicità.

Le pipeline di rendering in una GPU sono sincrone perché devono tutti finire il frame insieme e iniziare un nuovo frame insieme. Sono omogenei perché svolgono gli stessi tipi di lavoro e sono tutti attivi insieme. Ma il loop di gioco principale di un server e i thread di I / O bloccanti che elaborano l'input remoto sono eterogenei perché svolgono tipi di lavoro molto diversi e alcuni dei thread di I / O non faranno nulla, perché non tutti vengono utilizzate le connessioni. Anche così, sono sincronizzati, perché devono condividere lo stato atomicamente (un giocatore non deve vedere un aggiornamento parziale del mondo di gioco, né il server deve vedere solo un frammento dell'input del giocatore).

Async

Consideriamo ora una "lettura I / O asincrona". Quando il programma invia una richiesta al sistema operativo per leggere un po 'di dati dalla memoria, la chiamata ritorna immediatamente . Ignoriamo i callback e concentriamoci sul polling. In generale, il momento in cui i dati sono disponibili per il tuo programma non corrispondono ad alcun momento speciale per quanto riguarda il thread del tuo programma. Se il tuo programma non sta aspettando esplicitamente i dati, il thread non saprà nemmeno esattamente quando si verificherà quel momento. Scoprirà solo che i dati sono in attesa al successivo controllo.

Non esiste un orario di incontro speciale in cui il sistema operativo e il thread del programma accettano di consegnare i dati. Sono come due navi che passano di notte. L'asincronia è caratterizzata da questa assenza di attesa. Ovviamente, il thread del programma finirà spesso per attendere l'operazione di I / O, ma non è necessario. Può tranquillamente continuare a fare altri calcoli mentre si sta verificando l'I / O fetch e controllare solo in seguito quando ha un momento da perdere. Naturalmente, una volta terminato il recupero dei dati, il sistema operativo non si ferma nemmeno in attesa. Mette semplicemente i dati in un posto conveniente e continua la sua attività. In questo caso, è come se il programma consegnasse il testimone al sistema operativo, e il sistema operativo riapparisse in seguito, lascia cadere il testimone a terra insieme ai dati e esce dalla pista. Il programma potrebbe essere in attesa o meno di ricevere la consegna.

Parallelismo

Quando contrassegniamo una funzione come "asincrona" nel software, spesso significa che vogliamo il parallelismo . Ma ricorda che il parallelismo non implica la sincronia . Le lucciole sono un buon esempio, perché anche loro hanno mostrato un comportamento sincrono e asincrono. Mentre la maggior parte delle mosche lampeggiava all'unisono, molte erano ovviamente stonate con il resto del gruppo e lampeggiavano in modo più casuale. Le mosche potrebbero aver agito simultaneamente , ma non erano tutte sincronizzate .

Ora, quando contrassegniamo un codice come "asincrono", sembra divertente, perché implica che il resto del codice non così contrassegnato sia "sincronizzazione". Che cosa vuol dire, anche? Non abbiamo insistito sul fatto che la "sincronizzazione" richiedesse due al tango? Ma cosa succede se stiamo parlando dell'esecuzione del codice in un singolo thread? In questo caso, dobbiamo fare un passo indietro e pensare a un programma come una sequenza di stati e transizioni tra quegli stati. Un'istruzione in un programma provoca una transizione di stato. Possiamo considerarlo come un "micro-processo" che inizia e termina con l'affermazione. I punti di sequenza definiti dal linguaggio sono, in effetti, i punti di sincronizzazione di questi "micro-processi". E quindi, possiamo visualizzare un thread singolo,

L'integrità del linguaggio di programmazione garantisce che gli aggiornamenti di stato non interferiscano tra le istruzioni e i punti di sequenza definiscono i confini attraverso i quali al compilatore non è consentito effettuare ottimizzazioni osservabili. Ad esempio, l'ordine di valutazione delle espressioni all'interno di un'istruzione potrebbe essere indefinito o non specificato, dando al compilatore la libertà di ottimizzare l'affermazione in vari modi. Ma quando inizia la prossima affermazione, il programma dovrebbe essere in uno stato ben definito, se il PL stesso è valido.

Ormai dovrebbe essere chiaro cosa intendiamo per "asincrono". Significa esattamente che il contratto implicito di sincronia all'interno di un blocco di codice è esentato per il blocco asincrono. È consentito aggiornare lo stato del programma in modo indipendente, senza le garanzie di sicurezza normalmente implicate nel modello di calcolo sequenziale (sostanzialmente coerente, sincrono). Naturalmente, ciò significa che dobbiamo prestare particolare attenzione a non distruggere lo stato del programma con incoerenza. Questo di solito significa che introduciamo una sincronia limitata ed esplicita per coordinarci con il blocco asincrono. Nota che questo significa che il blocco asincrono può essere sia asincrono che sincrono in momenti diversi! Ma ricordando che la sincronizzazione indica semplicemente l'esistenza di un punto di sincronizzazione, non dovremmo avere problemi ad accettare questa nozione.

Un modo di pensarci sono le istruzioni SIMD , come AVX . Ecco alcuni esempi di come vengono utilizzati.

Le istruzioni SIMD sincrone consentono di eseguire più calcoli nello stesso momento , nello stesso thread, utilizzando un'unica istruzione su più dati.

Mentre il multithreading asincrono consente di eseguire calcoli multipli in tempi "probabilmente" "piuttosto" "simili".

Combina questo con le seguenti definizioni:

synchronous aggettivo syn · chro · nous | \ ˈSiŋ-krə-nəs, ˈsin-

1: accadere, esistere o sorgere esattamente nello stesso momento [enfatizzare il mio]

asincrono aggettivo asyn · chro · nous | \ (ˌ) ā-ˈsiŋ-krə-nəs, -ˈsin- \

1: [...]: non sincrono

Un'analogia che mi ha fatto capire la differenza tra Sync vs Async vs Multi-thread è quella di un cuoco in cucina.

Immagina di fare la pasta. Hai tre passaggi:

1. Bollire e scolare la pasta
2. Prepara la salsa
3. Unire pasta e salsa

Metodo sincrono. Nello scenario sincrono c'è solo una persona (thread) che fa tutto il lavoro in sequenza. Prima fai bollire la pasta e stai lì a guardarla bollire. Quindi lo scarichi e lo metti da parte. Quindi prepari la salsa. Quando la salsa è pronta prendi la pasta, mescolala con la salsa e il tuo piatto è pronto. Il problema qui è inefficiente. Dato che stavi lavorando in sequenza in modo sincrono, non puoi lavorare sulla salsa mentre la pasta bolle. Quindi, ti ha fatto perdere tempo e la tua pasta si è raffreddata mentre veniva preparata la salsa.

Metodo asincrono. In questo scenario, c'è ancora un solo cuoco (filo), ma mentre la pasta bolle, vai a preparare la salsa. Quando la pasta è bollita, stai called-backfacendo la salsa per scolarla, e poi sei di called-backnuovo per finire la salsa. Questo è più efficiente ora, perché hai risparmiato tempo e la tua pasta non ha dovuto aspettare la salsa così a lungo.

Metodo multi-thread. Ora, immagina di assumere un nuovo cuoco. Ora hai due cuochi (discussioni). Mentre un cuoco fa la pasta, il secondo cuoco prepara la salsa. È necessario in questo scenario? No, perché fare la pasta è abbastanza semplice da essere efficiente con il metodo asincrono. E, gestire più cuochi è un ulteriore sovraccarico. Ma se stavi preparando un piatto più complicato o più piatti contemporaneamente, sono utili più cuochi.

Una buona domanda e termini che sono spesso usati in diversi modi che portano alla confusione.

La mia risposta è che questi termini sono relativi - e ciò a cui sono relativi è il programma principale che sta eseguendo (o talvolta un thread).

Questi termini specificano qualcosa sull'operazione interna e sui tempi di un programma, se i messaggi vengono inviati o ricevuti in modo bloccante (sincronizzazione) o in modo non bloccante (asincrono). Se un thread (principale) viene bloccato inviando o ricevendo, si tratta di "sincronizzazione" e se in qualche modo è interrotto, allora è "asincrono". Per ribadire, questi termini riguardano implementazioni che funzionano (regolarmente) e gestiscono eventi.

(IMHO, ovviamente) una volta che un messaggio è sul filo, non c'è sincronizzazione o asincrono. Nella messaggistica c'è un mittente e un destinatario, ognuno di essi può avere un'implementazione di sincronizzazione o asincrona indipendente dall'altro - ma una volta che un messaggio è sul filo, è solo un messaggio, non più sincronizzato o asincrono. Possiamo classificare un messaggio come una richiesta o risposta o un messaggio a senso unico, ma che è ortogonale alla sincronizzazione e all'asincronizzazione (che si riferisce al fatto se l'implementazione sta bloccando l'attesa o può essere interrotta in qualche modo).

"sincrono" significa che due eventi si verificano contemporaneamente - ma quali eventi?

Quando diciamo "esecuzione sincrona", intendiamo che il chiamante e il chiamante stanno eseguendo (cioè nello stack) contemporaneamente. Questo è probabilmente il significato che stai cercando.

Quando diciamo "porta logica sincrona", intendiamo che la porta logica è sincronizzata con l'orologio della CPU.

Quando diciamo "modello sincrono" nel contesto di sistemi distribuiti, intendiamo che tutti i nodi eseguono i loro programmi in fase di blocco e che i messaggi inviati nel passaggio n sono garantiti per arrivare all'inizio del passaggio n + 1.

Quando la specifica del linguaggio Java afferma che un thread "si sincronizza con" un altro, significa che le azioni nei diversi thread si verificano "contemporaneamente" (rispetto alla relazione che accade prima). E quando dicono che due thread "sincronizzano l'accesso a un oggetto", in realtà significano che i thread si sincronizzano tra loro per garantire che non lavorino mai sull'oggetto allo stesso tempo.

... e sono abbastanza sicuro che potresti applicare la parola in ancora più contesti, perché "le cose accadono allo stesso tempo" è un'idea abbastanza generica :-)

Penso che la chiave della tua confusione possa essere riassunta da:

L'attributo asincrono indica che lo script verrà eseguito non appena viene scaricato anche se l'html sta ancora analizzando

La cosa da capire è che questa frase non ha senso perché descrive una situazione impossibile. Se l'HTML sta ancora analizzando, il processo di download degli script non inizierebbe nemmeno se è asincrono.

In programmazione, sincrono significa:

Tutti i dati a cui sei interessato esistono già nella memoria al momento dell'esecuzione della logica

Mentre asincrono significa:

Alcuni dei dati che ti interessano non esistono ancora ed esistono solo ad un certo punto in futuro

In effetti, è questo aspetto non presente della programmazione asincrona che di solito confonde le persone.

Il modo in cui gli script vengono normalmente caricati è quando l'analisi HTML viene messa in pausa, quindi lo script viene scaricato, quando il download dello script viene completato viene eseguito e quindi l'analisi HTML continua. L'analisi html e l'esecuzione dello script avvengono contemporaneamente "stesso" (stesso significato insieme, non simultaneo).

Come asyncvengono caricati gli script è che l'html vede il tag dello script e ricorda di scaricare lo script in futuro, ma continua ad analizzare. L'analisi html non è in pausa per il download di script. Successivamente , al termine dell'analisi html, tutti gli script asincroni vengono scaricati ed eseguiti. L'analisi html e l'esecuzione dello script non avvengono contemporaneamente (di nuovo, allo stesso tempo intendono insieme, in questo caso vengono eseguiti separatamente).

Quindi per riassumere:

• Gli script sincroni vengono analizzati insieme all'html.

• Gli script asincroni verranno analizzati separatamente in futuro.

Quindi la definizione della asyncproprietà non è che lo script venga eseguito non appena viene scaricato, questo vale sia per gli script sincroni che per quelli asincroni. La definizione di asincrono è che l'analisi HTML non attende il download dello script .