Quelle est la signification des mots asynchrone et synchrone en informatique?

Si vous google la signification des mots, vous obtiendrez ce qui suit:

• Asynchrone: non existant ou existant en même temps .

• Synchrone: existant ou se produisant en même temps .

Mais il semble qu’ils soient utilisés pour transmettre le sens opposé en programmation ou en informatique:

Attribut asynchrone HTML signifie que le script sera exécuté dès son téléchargement, même si le code HTML est toujours en cours d'analyse ou de téléchargement, ce qui signifie que les processus, le script et le code HTML, existent et se produisent simultanément.

Ces termes sont-ils utilisés pour transmettre le sens opposé en informatique ou est-ce que je manque le sens?

Je voudrais vous donner une réponse qui est directement liée aux définitions que vous avez trouvées. Lorsqu'une tâche T1 commence une deuxième tâche T2, cela peut se produire de la manière suivante:

Synchrone: existant ou se produisant en même temps.

T2 est donc garanti pour être démarré et exécuté dans la tranche de temps de T1 . T1 "attend" la fin de T2 et peut continuer le traitement par la suite. En ce sens, T1 et T2 apparaissent "au même moment" (pas "en parallèle", mais dans un intervalle de temps contigu).

Asynchrone: non existant ou existant en même temps.

Le temps d'exécution de T2 n'est donc plus lié à T1. Il peut être exécuté en parallèle, une seconde, une minute ou plusieurs heures plus tard, et T2 peut encore s'exécuter une fois que T1 est terminé (ainsi, pour traiter un résultat de T2, une nouvelle tâche T3 peut être requise). En ce sens, T1 et T2 ne se "produisent pas en même temps (intervalle)".

Bien sûr, je suis d’accord, les définitions littérales semblent ambiguës lorsque nous voyons que les opérations asynchrones sont aujourd’hui souvent utilisées pour créer des exécutions parallèles.

Je trouve que la meilleure façon de comprendre cela est la suivante:

• Synchrone: Nous savons quand cela se produira (cela se produit lorsque cet autre code se termine).
• Asynchrone: Nous ne savons pas quand cela se produira.

Remarque: Bien que nous puissions programmer le code pour qu'il soit exécuté à une heure donnée, nous ne savons pratiquement pas quand cela se produira, car il peut être retardé - même en ignorant les modifications apportées à l'horloge système - car le système est occupé à autre chose. En outre, même si nous avions la garantie que cela se produirait exactement à une heure donnée, nous ne savons pas exactement où se déroulera l’exécution de notre programme à ce moment-là. Donc, non, le code prévu pour l'heure n'est pas synchrone.

Veuillez noter que dans le développement logiciel, nous dirons, par exemple, qu’une tâche est asynchrone et qu’elle est isolée. Cependant, si vous voulez définir si vous voulez que cela se produise au même moment, vous devez avoir au moins quelque chose avec lequel comparer la tâche.

De nombreuses plates-formes peuvent effectuer à la fois le parallélisme et le changement de tâche, certaines ont un parallélisme limité, d'autres ne peuvent pas faire de parallélisme et se basent uniquement sur le basculement de tâche ... De plus, certaines plates-formes ne peuvent pas interrompre une tâche et doivent les terminer avant d'exécuter une tâche différente. ... Les tâches asynchrones sont une abstraction sur tout cela, de sorte que le système peut décider comment exécuter les tâches pour la plate-forme donnée sans que le développeur s'en préoccupe (trop).

Il convient également de noter que nous pouvons conceptualiser, et généralement nous abstenons, obtenir une entrée externe sous forme de tâche asynchrone. Par exemple: obtenir du texte à partir d'une entrée utilisateur. Nous ne savons pas quand l'utilisateur va taper. Cela s'applique également à la lecture d'un stockage permanent, à la récupération de données sur le réseau ou à tout autre système externe.

À propos, bien que certaines choses soient fondamentalement asynchrones, nous pouvons généralement prétendre qu'elles ne le sont pas. Nous faisons cela en faisant en sorte que le logiciel bloque l'exécution en cours - et ne fasse rien d'autre - jusqu'à ce qu'elle soit terminée. Autrement dit, nous pouvons prendre quelque chose d’asynchrone et l’envelopper dans une API synchrone.

Une API asynchrone vous permettra de continuer l'exécution même si l'opération demandée n'est pas terminée, mais pas synchrone. Et à partir de là, l’idée asynchrone - dans le logiciel - signifie qu’elle se produit au même moment (simultanée).

Il est à noter que l'asynchrone n'implique pas la concurrence. Dans certains cas, la plateforme peut uniquement exécuter la tâche asynchrone une fois la tâche en cours terminée. Ce serait séquentiel (bien que l'ordre d'exécution de la tâche asynchrone ne soit pas nécessairement garanti), ne serait pas concurrente (il n'y a pas de chevauchement dans les périodes d'exécution), mais serait asynchrone.

Au fait, sur certaines plates-formes, le système peut décider d’aligner la tâche asynchrone et de l’exécuter ainsi comme une opération synchrone (dans l’hypothèse où cela est possible, cela n’est pas viable pour toutes les tâches).

Encore une fois, asynchrone signifie simplement que vous ne savez pas quand cela se produira.

Vous pouvez également être intéressé par La différence entre une exécution «simultanée» et «parallèle»? .

Asynchrone: non existant ou existant en même temps.

Synchrone: existant ou se produisant en même temps.

L'attribut async signifie que le script sera exécuté dès qu'il sera téléchargé, même si le code HTML est toujours en cours d'analyse, ce qui signifie que les deux processus existent simultanément pour moi.

C'est en effet déroutant!

Considérons plutôt les significations de synchronisé et non synchronisé . Deux choses sont synchronisées si le minutage de l'un dépend de l'autre et non synchronisées si leur minutage est indépendant.

Dans votre exemple de flux de travail asynchrone, il se passe deux choses: l'exécution de script et l'analyse HTML. Ces deux choses ne sont pas synchronisées . la synchronisation de l'opération d'exécution et la synchronisation de l'opération d'analyse ne dépendent pas l'une de l'autre. Si nous rendions le flux de travail synchrone , les opérations deviendraient synchronisées . Disons que l'exécution ne commence pas avant la fin de l'analyse.

Mais il est important de réaliser qu’il existe en réalité trois possibilités:

• l'exécution et l'analyse sont vraiment non synchronisées; ils peuvent tous deux se produire à tout moment et dans n'importe quel ordre, tout ce qui est le plus efficace.
• l'exécution et l'analyse sont synchronisées; Par exemple, la CPU ne fait rien en attendant la fin de l’E / S.
• l'exécution et l'analyse sont synchronisées, mais pendant que nous attendons que l'E / S soit terminée, la CPU est autorisée à effectuer un autre travail, puis à revenir et à effectuer l'analyse une fois le téléchargement terminé .

Une fois que vous comprenez cela, l'objectif des workflows asynchrones dans les langages de programmation courants devient plus clair:

• Les flux de travail asynchrones nous aident à mettre en œuvre efficacement des opérations à latence élevée, car nous ne sommes pas contraints de commander à temps des éléments non liés. Si l'analyse est liée à une latence élevée et à des entrées / sorties et que l'exécution du script est liée à une latence élevée et à une unité centrale, nous pouvons obtenir un gain en désynchronisant totalement ou partiellement ces opérations.

• L' awaitopérateur dans des langues telles que C # est l'opération de commande sur les flux de travail asynchrones. Une attente est une attente asynchrone ; il est un point où nous exprimons une relation d'ordre entre deux parties d'un flux de travail asynchrone, et dire qu'il y a un « arrive avant la » relation entre le code avant l'await et le code après vous attendent. Voici comment nous mettons en œuvre la troisième option .

Si cela n’est que trop abstrait, imaginez des exemples concrets. Lorsque vous envoyez une lettre (opération liée à une latence élevée pour les E / S), vous pouvez toujours effectuer un travail gourmand en ressources processeur (devoirs de maths, par exemple) en attendant de recevoir une réponse à votre lettre. Les opérations de faire vos devoirs de maths et de lire votre courrier ne sont pas synchronisées.

Mais supposons maintenant que vous envoyiez une lettre et que la réponse contienne un numéro dont vous avez besoin pour calculer vos impôts. Désormais, vous ne pouvez plus utiliser le processeur (calcul de vos taxes) tant que l'opération d'E / S n'est pas terminée. Mais vous pouvez toujours tondre la pelouse pendant que vous attendez . C'est un flux de travail asynchrone qui a exprimé une relation temporelle entre ses parties.

Je suis ingénieur électricien et nous avons traité des circuits logiques synchrones et asynchrones (portes logiques).

Supposons que vous ayez une porte AND (ou n'importe quelle porte), qui a deux entrées et une sortie.

S'il est asynchrone, il mettra à jour sa sortie au moment où l'une des entrées change de telle manière que la sortie change. Voici comment votre exemple a fonctionné - le programme que vous avez mentionné.

Toutefois, si cette porte est également associée à une horloge (par exemple, une onde carrée d’une période de 1 seconde), où elle se met à jour au rythme de chaque seconde, l’onde carrée passe de basse à haute, elle est synchrone. Il est lié à la fréquence de l'horloge. C'est donc synchrone. Vous pouvez connecter cette horloge à de nombreux circuits, qui fonctionneraient en synchronisme. Si votre programme vérifiait seulement s'il était lu pour s'exécuter toutes les secondes, il serait également synchronisé.

Imaginez deux satellites en orbite autour de la Terre.

• Le satellite A a une période de rotation autour de la Terre telle que pour chaque rotation complète de la planète, le satellite a fait le tour de la Terre plus ou moins d’une fois .
• Le satellite B a une période de rotation autour de la Terre telle que pour chaque rotation complète de la planète, le satellite a fait le tour de la Terre exactement une fois .

Le satellite B, dans l'exemple ci-dessus, est en orbite géosynchrone, comme défini par

ayant une période de rotation synchrone avec celle de la rotation de la Terre.

On ne soutient pas que le satellite A est géosynchrone simplement parce qu’il "existe ou se produit en même temps" que la planète. En fait, le satellite B lui-même n’est pas ce qui est pertinent non plus, mais bien la période de rotation qui est synchronisée avec la période de rotation de celle de la Terre. Il ne s'agit pas de l'existence simultanée des objets; il s'agit de la relation entre les objets. Tenez cette pensée.

Supposons que je vous dise que deux threads d'un système fonctionnent en même temps. Le thread A (TA) récupère les données pour le processus A et le thread B (TB) récupère les données pour le processus B. Je vous demande, "Est-ce que TA et TB sont asynchrones?". Votre réponse serait: "Comment pourrais-je savoir? Je n'ai pas à voir le code qui les a appelés dans leurs processus respectifs." Ce à quoi je répondrais dans ma tentative d'être difficile, "Mais je vous dis que TA et TB courent définitivement en même temps."

Et vous, être tout à fait l'individu intelligent, répondriez, « Encore une fois - ils peuvent être en cours d' exécution en même temps , mais je n'ai pas la moindre idée si elles sont en cours d' exécution de manière asynchrone en ce qui concerne leurs processus respectifs qui les invoquaient TA et TB en cours d' exécution de manière asynchrone. L'autre fait vraiment cela n’a aucun sens car ils ne sont pas issus du même processus. "

Nous devrions donc maintenant avoir l’intuition que l’existence d’une relation est ce qui est pertinent ici, et pas seulement l’existence de ces deux fils eux-mêmes. Quand une méthode est exécutée de manière asynchrone, ce que nous disons, c'est que l'exécution de cette méthode "n'a pas besoin d'exister ou de se produire en même temps" que l'exécution de la méthode qui l'a appelée. Prenons l'exemple suivant:

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

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

    await DoThatAsync();

    CheckThat();
}

Dans notre discussion sur les satellites précédemment, "il ne s'agit pas de l'existence simultanée des objets, mais de la relation entre les objets". Il ne s'agit pas de l'existence d'une méthode appelante et de la méthode invoquée. il s'agit de l'existence d'une relation entre l'exécution de l'invocateur et l'exécution de l'invoqué. Si nous examinons nos threads système et trouvons que cela a DoThatAsync()été appelé mais qu'il ne s'exécute pas, peut-être qu'il attend le planificateur ou une autre E / S, cela ne signifie pas nécessairement que la méthode d'appel Invoker()n'est pas en cours d'exécution - il y a du travail à faire être en train de faire. Bien sûr, c'est peut-être sur le point d' awaitarriver DoThatAsync(), mais ce n'est pas garanti. Ce n'est pas vrai des autres fonctions une fois qu'elles ont été appelées - si elles s'arrêtent,Invoker()s'arrête - peu importe quoi. Ceci est garanti. L'exécution entre la Invoker()méthode synchrone et invoquée "existe ou se produit en même temps".

Exemples concrets

J'aimerais ajouter quelques exemples concrets et les connecter au monde du génie logiciel. Premièrement, considérez quelque chose qui, j'espère, correspond à votre définition intuitive de "synchrone": le clignotement de lucioles , dans certaines circonstances. Deuxièmement, considérons la course de relais olympique 4x100 féminin . Troisièmement, considérez ce vieux trope des films militaires: "Hommes, synchronisez vos montres!"

Maintenant, réfléchissons à ce qui se passe. Commençons par observer que toutes ces choses sont des processus ou des entités étendues dans le temps . Cela n'a pas de sens de dire qu'un bol est "synchrone" et que le rock est "asynchrone". Deuxièmement, il faut être deux pour danser le tango . Vous ne pouvez pas dire que "un coureur est sync". Sync avec quoi? Enfin, pour que deux processus puissent agir en même temps, à moins qu’ils aient déjà exactement la même fréquence et la même phase, il faut attendre l’un ou l’autre .

Une analyse

Lorsque la définition du dictionnaire indique que deux entités synchronisées "se produisent ou existent en même temps", cela s'aligne très bien sur le concept de la lumière émise par les lucioles. Malheureusement, dire que la lumière est "synchronisée" est une façon bâclée de dire que les processus d’éclairage de la luciole sont synchronisés.

Alors, comment un groupe de lucioles, qui n’ont vraisemblablement pas été guidées par Apple SmartWatch et NTP, parviennent-elles à flasher leurs arrières en même temps? Eh bien, c'est assez facile s'ils ont le moyen de définir un tempo cohérent et peuvent y apporter de petits ajustements. Ils clignotent simplement, et si plus de personnes clignotent juste après eux, ils ralentissent (augmentent le délai), alors que si plus de personnes clignotent juste avant eux, ils accélèrent (diminuent le délai). Ils peuvent donc utiliser un processus de retour simple pour parvenir essentiellement au même tempo et à la même phase. L'observation importante ici est de noter qu'ils réalisent la synchronie en attendant le bon moment pour clignoter .

La course 4x100 est intéressant parce que vous voyez les deux formes de synchronisation de processus en action: les coureurs au sein d' une équipe sont synchronisés, tandis que les coureurs des équipes différentes sont « async ». Le deuxième coureur du relais doit attendre que le premier coureur entre dans la zone de transfert . Le transfert est un événement synchrone entre ces deux coureurs. Cependant, les coureurs dans les différentes voies ne s’inquiètent pas de ce qui se passe dans une autre voie , et très certainement ne ralentissent pas et ne font pas leurs transferts de manière synchronisée. Chaque piste de coureurs est asynchrone les uns par rapport aux autres. Là encore, nous voyons que la synchronisation implique l'attente, contrairement à l'asynchronisme.

Enfin, les soldats d'une compagnie (peloton, équipe de tir, etc.) doivent synchroniser leurs montres pour pouvoir attaquer l'ennemi en même temps . Il se peut que certains soldats arrivent à leurs positions avant d’autres, ou aient la possibilité de tirer plus rapidement sur l’ennemi. Mais une attaque simultanée est généralement plus efficace qu'une attaque au hasard en raison de l'élément de surprise. Donc, pour parvenir à la synchronie, beaucoup de soldats doivent attendre le temps imparti pour agir.

Caractéristique déterminante

Pourquoi cette insistance sur l'attente? Eh bien, c’est parce que l’attente est la caractéristique qui distingue les processus synchrones des processus asynchrones. Si vous avez deux processus dont vous ne connaissez rien, vous devez, par défaut, supposer qu'ils sont asynchrones. Par exemple, une livraison de colis et une ambulance ne sont probablement pas synchronisées. Pour démontrer que deux processus sont en fait synchronisés, vous devez trouver un moment très spécial dans le temps: le point de synchronisation .

Un livreur qui dépose un colis et une ambulance qui dépêche quelqu'un à l'hôpital ne partage généralement pas les points de temps que nous identifions comme un "point de synchronisation". D'autre part, les lucioles clignotant à l'unisson ont un point de synchronisation chaque fois qu'elles clignotent, les relais ont un point de synchronisation chaque fois qu'elles passent le relais, et les soldats ont un point de synchronisation lorsqu'ils lancent leur attaque. Si vous pouvez identifier un ou plusieurs points de synchronisation, les processus sont synchronisés . Cela devrait être facile à comprendre, car "syn-" est un préfixe grec qui signifie "avec" ou "ensemble", et "chrono" est la racine grecque du mot "temps". "Synchronisé" signifie littéralement "en même temps",

Limites

Notez que la "synchronisation" ne s'applique pas nécessairement à toute la durée de vie de l'un ou des deux processus. Je dirais que cela ne concerne que "le temps d’attente jusqu’au point de synchronisation compris". Ainsi, deux processus peuvent fonctionner de manière asynchrone jusqu'à ce qu'ils atteignent un état où ils doivent communiquer, puis ils se synchronisent, échangent des informations et poursuivent ensuite de manière asynchrone. Un exemple simple est de rencontrer quelqu'un pour un café. De toute évidence, la réunion est un point de synchronisation (ou plusieurs, plutôt), et le fait que deux personnes y arrivent témoigne du synchronisme. Cependant, nous ne dirions pas que, parce que deux personnes se sont rencontrées pour prendre un café, ces deux vies humainessont "synchronisés". C’est peut-être le seul moment de leur vie qu’ils ont rencontré et tout ce qu’ils font est par ailleurs indépendant.

Il n’est pas vrai non plus que des rencontres accidentelles démontrent une synchronie. Si deux étrangers se croisent dans la rue, le fait qu'ils se trouvent à un moment donné ne prouve pas le synchronisme. Le fait qu’une personne soit assise sur un banc et attende l’autobus ne l’est pas non plus. Les processus ne sont synchrones que lorsqu'ils se rencontrent dans un but précis .

Connexion de logiciel

Penchons-nous maintenant sur une tâche fondamentale du logiciel: lire à partir d’un fichier. Comme vous le savez probablement, le stockage de masse est généralement des milliers, des millions de fois plus lent que le cache ou la mémoire principale. Pour cette raison, les systèmes d'exploitation et les bibliothèques de langages de programmation offrent généralement des opérations d'E / S synchrones et asynchrones. Maintenant, même si votre programme n'a qu'un seul thread, vous devriez considérer le système d'exploitation comme un "processus séparé" aux fins de cette discussion.

Sync

Lorsque vous effectuez une "lecture E / S synchrone", votre thread doit attendre que les données soient disponibles, puis il continue. Cela ressemble beaucoup à un coureur de relais qui passe le relais au prochain coureur, mais imaginons plutôt un relais avec seulement deux coureurs faisant tout le tour de la piste, et le deuxième coureur revenant également au premier.

Dans ce cas, votre thread de programme et le processus d'ES du système d'exploitation ne se produisent pas en même temps, il est donc étrange de dire que ces processus sont "synchronisés". Mais ce n'est pas la bonne façon de voir les choses! C'est comme si on disait: "Les coureurs d'une équipe de relais ne courent pas en même temps, ils ne sont donc pas synchronisés." En fait, les deux déclarations sont fausses! Les coureurs sur une équipe de relais font et doivent fonctionner en même temps, mais seulement à un moment très précis: la main hors du bâton. En fait, ce n'est que ce moment privilégié de la course qui nous convainc que les équipes de relais sont synchronisées pour commencer! Si nous considérons la demande d’entrée / sortie et la réponse comme "le témoin",

D'autre part, si nous pensons à quelque chose comme l'analyse par éléments finis sur un superordinateur, nous voyons que des milliers de processus doivent fonctionner en bloc pour mettre à jour un état global massif. Même si certains nœuds terminent leur travail pour un pas de temps donné avant les autres, ils doivent tous attendre que le pas de temps se termine car les résultats se propagent aux voisins à travers l'espace. Ce type de synchronisation ressemble aux lucioles: tous les acteurs effectuent le même type de tâche.

Variété de processus

Pour cette raison, nous pouvons inventer quelques termes pour nous aider à voir qu'il y a trois sortes de choses qui se passent: "synchronie homogène", "synchronie hétérogène" et "synchronie séquentielle". Ainsi, lorsque les acteurs effectuent la même tâche simultanément (FEA, lucioles), ils sont "homogènes". Lorsqu'ils exécutent simultanément différentes tâches (soldats qui courent ou rampent ou qui nagent vers leur destination, la physique, le son ou les fils d'IA dans un jeu), ils sont "hétérogènes". Lorsqu'ils effectuent des tâches une à une, ils sont "séquentiels" (relais, bloqueurs d'E / S). Ils peuvent sembler très différents, mais ils partagent une propriété essentielle: tous les types d’acteurs en attendent pour s’assurer que tout le monde arrive au point de synchronisation en même temps. entre les points de synchronisation ou "effectuer la même action" est sans rapport avec la propriété de synchronicity.

Les pipelines de rendu dans un GPU sont synchrones car ils doivent tous terminer l’image ensemble et en commencer une nouvelle. Ils sont homogènes parce qu'ils font le même genre de travail et ils sont tous actifs ensemble. Mais la boucle de jeu principale d'un serveur et les threads d'E / S bloquants qui traitent les entrées distantes sont hétérogènes car ils effectuent des types de travail très différents, et certains des threads d'E / S ne feront rien du tout, car tous les connexions sont utilisées. Même dans ce cas, ils sont synchronisés, car ils doivent partager l'état de manière atomique (un joueur ne doit pas voir une mise à jour partielle du monde du jeu, ni le serveur ne doit voir qu'un fragment de son entrée).

Async

Considérons maintenant une "lecture asynchrone d'E / S". Lorsque votre programme envoie une demande au système d'exploitation pour lire un bit de données de la mémoire, l'appel retourne immédiatement . Ignorons les rappels et concentrons-nous sur la scrutation. En général, le moment où les données sont disponibles pour votre programme ne correspond à aucun instant particulier en ce qui concerne le fil de votre programme. Si votre programme n'attend pas explicitement les données, le thread ne saura même pas exactement quand ce moment se produira. Il ne découvrira que les données sont en attente lors de la prochaine vérification.

Il n’ya pas d’heure de réunion spéciale où le système d’exploitation et le fil de programmation s’entendent pour transmettre les données. Ils sont comme deux navires qui passent dans la nuit. L'asynchronisme est caractérisé par cette absence d'attente. Bien entendu, le thread de programme finit souvent par attendre l'attente de l'opération d'E / S, mais ce n'est pas nécessaire. Il peut continuer à effectuer d'autres calculs alors que l'extraction d'E / S est en cours, et ne vérifie que plus tard s'il a un moment à perdre. Bien sûr, une fois que le système d’exploitation a fini de récupérer les données, il n’attend pas non plus. Il met simplement les données à un endroit pratique et traite de son activité. Dans ce cas, c’est comme si le programme passait le témoin au système d’exploitation, lequel revenait plus tard, lâchait le témoin au sol avec les données et quittait la piste. Le programme peut attendre ou ne pas attendre pour recevoir le transfert.

Parallélisme

Lorsque nous marquons une fonction comme "asynchrone" dans un logiciel, cela signifie souvent que nous voulons du parallélisme . Mais rappelez-vous que le parallélisme n'implique pas la synchronie . Les lucioles en sont un bon exemple, car elles ont également présenté un comportement synchrone et asynchrone. Alors que la plupart des mouches ont clignoté à l'unisson, beaucoup étaient manifestement en désaccord avec le reste du groupe et ont flashé plus au hasard. Les mouches agissaient peut-être simultanément , mais elles n'étaient pas toutes synchronisées .

Désormais, lorsque nous marquons du code "asynchrone", cela semble drôle, car cela implique que le reste du code non marqué est "sync". Qu'est ce que ça veut dire? N'avons-nous pas insisté sur le fait que la "synchronisation" nécessitait le tango à deux? Mais que se passe-t-il si nous parlons d’exécution de code dans un seul thread? Dans ce cas, nous devons prendre du recul et penser à un programme comme une séquence d'états et de transitions entre ces états. Une instruction dans un programme provoque une transition d'état. Nous pouvons penser à cela comme à un "micro-processus" qui commence et finit par la déclaration. Les points de séquence définis par le langage sont en fait les points de synchronisation de ces "micro-processus". Et ainsi, nous pouvons voir un seul thread,

L'intégrité du langage de programmation garantit que les mises à jour d'état n'interfèrent pas entre les instructions et les points de séquence définissent des limites entre lesquelles le compilateur n'est pas autorisé à effectuer des optimisations observables. Par exemple, l'ordre d'évaluation des expressions dans une instruction peut être indéfini ou sous-spécifié, ce qui donne au compilateur la liberté d'optimiser l'instruction de différentes manières. Mais au moment où l'instruction suivante commence, le programme doit être dans un état bien défini, si le PL est correct.

A présent, nous devrions clairement comprendre ce que nous entendons par "asynchrone". Cela signifie exactement que le contrat de synchronisation implicite dans un bloc de code est exempté pour le bloc asynchrone. Il est permis de mettre à jour l'état du programme indépendamment, sans les garanties de sécurité normalement inhérentes au modèle de calcul séquentiel (uniquement cohérent, synchrone). Bien entendu, cela signifie que nous devons faire particulièrement attention à ne pas détruire l'état du programme de manière incohérente. Cela signifie généralement que nous introduisons une synchronie explicite limitée pour assurer la coordination avec le bloc asynchrone. Notez que cela signifie que le bloc asynchrone peut être à la fois asynchrone et synchrone! Mais rappelant que la synchronisation indique simplement l’existence d’un point de synchronisation, nous ne devrions avoir aucune difficulté à accepter cette notion.

Les instructions SIMD , comme AVX , sont un moyen d’y réfléchir . Voici quelques exemples de leur utilisation.

Les instructions SIMD synchronisées vous permettent d'effectuer plusieurs calculs exactement au même moment , dans le même thread, en exécutant une seule instruction sur plusieurs données.

Le multithreading asynchrone vous permet de faire plusieurs calculs à des moments "probablement" "quelque peu" "similaires".

Combinez ceci avec les définitions suivantes:

Adjectif synchrone syn · chro · nous | \ Siŋ-krə-nəs, sin-

1: passe, existant ou survenant à exactement en même temps [Souligné]

Adjectif asynchrone asyn · chro · nous | \ (ˌ) à-ˈsiŋ-krə-nəs, -ˈsin- \

1: [...]: pas synchrone

Une analogie qui m'a fait comprendre la différence entre Sync vs Async vs Multi-threaded est celle d'un cuisinier dans la cuisine.

Imaginez que vous faites des pâtes. Vous avez trois étapes:

1. Faire bouillir et égoutter les pâtes
2. Préparer la sauce
3. Mélanger les pâtes et la sauce

Méthode synchrone Dans un scénario synchrone, une seule personne (thread) effectue tout le travail en séquence. D'abord, vous faites bouillir les pâtes et vous restez là à les regarder bouillir. Ensuite, vous le vider et le mettre de côté. Ensuite, vous préparez la sauce. Lorsque la sauce est prête, vous prenez les pâtes, mélangez-les à la sauce et votre plat est prêt. Le problème ici est que c'est inefficace. Comme vous travailliez séquentiellement de manière synchrone, vous ne pouviez pas travailler sur la sauce pendant que les pâtes étaient en ébullition. Cela vous a fait perdre du temps et vos pâtes ont refroidi pendant la préparation de la sauce.

Méthode asynchrone. Dans ce scénario, il n'y a toujours qu'un seul fil, mais pendant que les pâtes sont en ébullition, vous allez faire votre sauce. Lorsque les pâtes sont bouillies, vous devez called-backfaire de la sauce pour l'égoutter, puis vous devez à called-backnouveau finir la sauce. C’est plus efficace à présent, car vous avez gagné du temps et vos pâtes n’ont pas attendu si longtemps pour la sauce.

Méthode multithread. Maintenant, imaginez que vous engagez un nouveau cuisinier. Maintenant, vous avez deux cuisiniers (fils). Pendant que l'un des cuisiniers prépare des pâtes, le deuxième cuisinier prépare la sauce. Est-ce nécessaire dans ce scénario? Non, car faire des pâtes est assez simple pour être efficace avec la méthode asynchrone. Et gérer plusieurs cuisiniers est une surcharge supplémentaire. Mais si vous préparez des plats plus compliqués ou plusieurs plats à la fois, plusieurs cuisiniers sont utiles.

Une bonne question et des termes qui sont souvent utilisés de différentes manières et qui créent de la confusion.

Ma réponse est que ces termes sont relatifs - et ce qu’ils sont par rapport au programme principal qui s’exécute (ou parfois à un thread).

Ces termes spécifient quelque chose à propos du fonctionnement interne et de la synchronisation d’un programme, qu’il s’agisse d’envoyer ou de recevoir des messages de manière bloquante (sync) ou non bloquante (asynchrone). Si un thread (le principal) est bloqué par l'envoi ou la réception, il s'agit de "sync" et s'il est interrompu d'une manière ou d'une autre, il est "async". Pour rappel, ces termes concernent des implémentations qui fonctionnent à la fois (régulièrement) et gèrent les événements.

(IMHO, bien sûr) une fois qu'un message est sur le fil, il n'y a pas une telle chose comme sync vs async. Dans la messagerie, il y a un expéditeur et un destinataire, chacun d'entre eux peut avoir une implémentation synchrone ou asynchrone indépendante de l'autre - mais une fois qu'un message est sur le réseau, il ne s'agit que d'un message, non plus synchrone ou asynchrone. Nous pouvons classer un message en tant que demande ou réponse ou message unidirectionnel, mais il est orthogonal à sync et async (qui indiquent si l'implémentation bloque en attente ou peut être interrompue d'une manière ou d'une autre).

"synchrone" signifie que deux événements se produisent en même temps - mais quels événements?

Lorsque nous disons "exécution synchrone", nous entendons que l'appelant et l'appelé s'exécutent (c'est-à-dire sur une pile) en même temps. C'est probablement le sens que vous recherchez.

Lorsque nous disons "porte logique synchrone", nous entendons que la porte logique est synchronisée avec l'horloge du processeur.

Lorsque nous parlons de "modèle synchrone" dans le contexte de systèmes distribués, nous entendons que tous les nœuds exécutent leurs programmes de manière verrouillée et que les messages envoyés à l'étape n arrivent au début de l'étape n + 1.

Lorsque la spécification du langage Java indique qu'un thread "se synchronise avec" un autre, cela signifie que les actions des différents threads se produisent "en même temps" (en ce qui concerne la relation "se passe avant"). Et quand ils disent que deux threads "synchronisent l'accès à un objet", ils signifient en fait que les threads se synchronisent l'un avec l'autre pour s'assurer qu'ils ne travaillent jamais sur l'objet en même temps.

... et je suis sûr que vous pourriez appliquer le mot dans encore plus de contextes, car "les choses se passent en même temps" est une idée assez générique :-)

Je pense que la clé de votre confusion peut être résumée par:

L'attribut async signifie que le script sera exécuté dès qu'il sera téléchargé même si le code HTML est toujours en cours d'analyse

Ce qu'il faut comprendre, c'est que cette phrase n'a pas de sens car elle décrit une situation impossible. Si le code HTML est toujours en cours d'analyse, le processus de téléchargement du script ne pourrait même pas commencer s'il est asynchrone.

En programmation, synchrone signifie:

Toutes les données qui vous intéressent existent déjà en mémoire au moment où vous exécutez votre logique

Asynchrone signifie:

Certaines des données qui vous intéressent n'existent pas encore et n'existent qu'à un moment donné.

En effet, c’est cet aspect non actuel de la programmation asynchrone qui déroute généralement les utilisateurs.

Comment les scripts sont normalement chargés si l'analyse HTML est suspendue, puis le script est téléchargé. Une fois le téléchargement du script terminé, il est exécuté, puis l'analyse HTML se poursuit. L'analyse HTML et l'exécution du script se déroulent au "même" moment (le même temps signifie ensemble, pas simultanément).

Comment les asyncscripts sont chargés si le HTML voit la balise script, puis se souvient de télécharger le script à l' avenir, mais continue à analyser. L'analyse HTML n'est pas suspendue pour le téléchargement du script. Plus tard , une fois l'analyse HTML terminée, tous les scripts asynchrones sont téléchargés et exécutés. L'analyse HTML et l'exécution du script ne se produisent pas en même temps (encore une fois, cela signifie ensemble, elles sont exécutées séparément).

Donc, pour résumer:

• Les scripts synchrones sont analysés avec le code HTML.

• Les scripts asynchrones sont analysés séparément à l'avenir.

Ainsi, la définition de la asyncpropriété ne signifie pas que le script est exécuté dès son téléchargement - cela est vrai pour les scripts synchrones et asynchrones. La définition de async est que l'analyse HTML n'attend pas le téléchargement du script .