asynchrone vs non-bloquant

• asynchrone se réfère à quelque chose fait en parallèle , disons est un autre fil.
• Non-blocking fait souvent référence à polling , c'est-à-dire vérifier si une condition donnée est maintenue (la socket est lisible, l'appareil a plus de données, etc.)

comme vous pouvez probablement le voir de la multitude de réponses différentes (et souvent mutuellement exclusives), cela dépend de qui vous demandez. Dans certains domaines, les termes sont synonymes. Ou ils pourraient faire référence à deux concepts similaires:

• une interprétation est que l'appel fera quelque chose en arrière-plan essentiellement sans supervision afin de permettre au programme de ne pas être retenu par un long processus qu'il n'a pas besoin de contrôler. Jouer l'audio pourrait être un exemple - un programme pourrait appeler une fonction pour jouer (disons) un mp3, et à partir de ce point pourrait continuer à d'autres choses tout en laissant à L'OS pour gérer le processus de rendu de l'audio sur le matériel sonore.
• l'interprétation alternative est que l'appel fera quelque chose que le programme devra surveiller, mais permettra que la plus grande partie du processus se déroule à l'arrière-plan seulement en avisant le programme à des points critiques du processus. Par exemple, asynchrone le fichier IO peut être un exemple - le programme fournit un tampon au système d'exploitation pour écrire dans le fichier, et L'OS ne notifie le programme que lorsque l'opération est terminée ou qu'une erreur se produit.

dans l'un ou l'autre cas, l'intention est de permettre au programme de ne pas être bloqué en attendant un processus lent à compléter - comment le programme est censé répondre est la seule différence réelle. Quel terme désigne ce qui change également de programmeur programmeur, la langue de langue, ou plate-forme à plate-forme. Ou les Termes peuvent renvoyer à des concepts complètement différents (comme l'utilisation de synchrones/asynchrones en relation avec la programmation de thread).

désolé, mais je ne crois pas qu'il y ait une seule bonne réponse qui soit globalement vraie.

replaçant cette question dans le contexte de L'ino et de l'INO.2 en java 7, async IO est un pas de plus que le non-blocking. Avec les appels java NIO non-bloquants, on définirait tous les canaux (SocketChannel, ServerSocketChannel, FileChannel, etc) comme tels en appelant AbstractSelectableChannel.configureBlocking(false) . Après le retour de ces appels IO, cependant, vous aurez probablement encore besoin de contrôler les vérifications comme si et quand lire/écrire à nouveau, etc.

Par exemple,

while (!isDataEnough()) {
    socketchannel.read(inputBuffer);
    // do something else and then read again
}

Avec l'api asynchrone de java 7, ces contrôles peuvent être réalisés de manière plus polyvalente. Une des 2 façons est d'utiliser CompletionHandler . Notez que les deux appels read ne sont pas bloquants.

asyncsocket.read(inputBuffer, 60, TimeUnit.SECONDS /* 60 secs for timeout */, 
    new CompletionHandler<Integer, Object>() {
        public void completed(Integer result, Object attachment) {...}  
        public void failed(Throwable e, Object attachment) {...}
    }
}

Synchrone / Asynchrone décrit la relation entre deux modules.

le blocage / non-blocage doit décrire la situation d'un module.

un exemple:

Module X: "I".

Module Y: "librairie".

X demande à Y: avez-vous un livre nommé "c++ primer"?

1) blocage: avant que Y réponde X, X attend toujours la réponse. Maintenant X (un module) bloque. X et Y sont deux threads ou deux processus ou un thread ou un processus? nous NE savons PAS.

2) non-blocage: avant que Y ne réponde X, X part juste d'ici et fait d'autres choses. x peut revenir toutes les deux minutes pour vérifier si Y a terminé son travail? Ou X ne reviendra pas tant que Y ne l'aura pas appelé? Nous ne savons pas. nous savons seulement que X peut faire d'autres choses avant Y les finitions de son travail. Ici, X (un module) ne bloque pas. X et Y sont deux threads ou deux processus ou un processus? nous NE savons PAS. Mais nous sommes sûrs que X et Y ne peuvent pas être un fil.

3) synchrone: avant que Y réponde X, X continue d'attendre la réponse. Cela signifie que X ne peut pas continuer tant que Y n'a pas fini son travail. Maintenant nous disons: X et Y (deux modules) sont synchrones. X et Y sont deux threads ou deux processus ou un thread ou un processus? nous N'avons PAS savoir.

4) asynchrone: avant que Y réponde X, X s'en va et X peut faire d'autres travaux. X ne reviendra pas tant que Y ne l'aura pas appelé. maintenant nous disons: X et Y (deux modules) sont asynchrones. X et Y sont deux threads ou deux processus ou un processus? nous NE savons PAS. Mais nous sommes sûrs que X et Y ne peuvent pas être un fil.

s'il Vous Plaît payer attention aux deux phrases en gras ci-dessus. Pourquoi la phrase en gras dans le paragraphe 2) contient-elle deux cas alors que la phrase en gras dans le paragraphe 4) Ne contient qu'un cas? C'est une clé de la différence entre les non-bloquant et asynchrone.

voici un exemple typique de non-blocage et synchrone:

// thread X
while (true)
{
    msg = recv(Y, NON_BLOCKING_FLAG);
    if (msg is not empty)
    {
        break;
    }
    sleep(2000); // 2 sec
}

// thread Y
// prepare the book for X
send(X, book);

vous pouvez voir que cette conception est non-bloquant (vous pouvez dire que la plupart du temps cette boucle fait quelque chose non-sens, mais aux yeux du CPU, X est en cours d'exécution, ce qui signifie que X n'est pas bloquant) alors que X et Y sont synchrones parce que X ne peut pas continuer à faire quoi que ce soit (X ne peut pas sauter hors de la boucle) jusqu'à ce qu'il obtient le livre de Y.

Normalement dans ce cas, le blocage de make X est bien meilleur parce que le non-blocage dépense beaucoup de ressources pour une boucle stupide. Mais cet exemple est bon pour vous aider à comprendre le fait: non-blocage ne signifie pas asynchrone.

les quatre mots nous rendent confus ce qu'il faut retenir, c'est que les quatre mots servent à la conception de l'architecture. Apprendre à concevoir une bonne architecture est la seule façon de les distinguer.

Par exemple, nous pouvons concevoir un tel type d'architecture:

// Module X = Module X1 + Module X2
// Module X1
while (true)
{
    msg = recv(many_other_modules, NON_BLOCKING_FLAG);
    if (msg is not null)
    {
        if (msg == "done")
        {
            break;
        }
        // create a thread to process msg
    }
    sleep(2000); // 2 sec
}
// Module X2
broadcast("I got the book from Y");


// Module Y
// prepare the book for X
send(X, book);

Dans l'exemple ici, nous pouvons dire que

• X1 est non-bloquante
• X1 et X2 sont synchrones
• X et Y sont asynchrones

si vous avez besoin, vous pouvez également décrire ces fils créés dans X1 avec les quatre mots.

les choses les plus importantes sont: quand utilisons-nous synchrone au lieu d'asynchrone? quand utilise-t-on le blocage au lieu du non-blocage?

pourquoi Nginx ne bloque-t-il pas? Pourquoi Apache bloque?

À faire un bon choix, vous devez analyser votre besoin et tester la performance de différentes architectures. Il n'existe pas d'architecture de ce type qui soit adaptée à divers besoins.

Un non bloquant appel renvoie immédiatement avec toutes les données disponibles: le nombre d'octets demandés, de moins en moins, ou pas du tout.

Un asynchrone appel demande un transfert qui va être jouée dans son ensemble(ensemble) mais complète à un certain moment dans l'avenir.

Non-blocking: cette fonction n'attendra pas sur la pile.

asynchrone: le travail peut continuer pour le compte de la fonction appel après que cet appel a quitté la pile

blocage appel: le contrôle ne revient que lorsque l'appel est terminé.

appel Non bloqué le contrôle revient immédiatement. Plus tard OS en quelque sorte avise le processus que l'appel est terminé.

programme synchrone : un programme qui utilise des appels de blocage . Afin de ne pas geler pendant l'appel, il doit avoir 2 ou plus les threads (c'est pourquoi on l'appelle synchrone - les threads tournent en synchrone).

asynchrone Programme: UN programme qui utilise des appels Non bloquants . Il ne peut avoir qu'un fil et rester interactif.

synchrone est défini comme se produisant en même temps.

asynchrone est défini comme ne se produisant pas en même temps.

c'est ce qui cause la première confusion. Synchrone est en fait ce qui est connu comme parallèle. Alors que l'asynchrone est séquentielle, faites ceci, puis faites cela.

maintenant, tout le problème est de modéliser un comportement asynchrone, parce que vous avez une opération qui nécessite la réponse d'un autre avant de pouvoir commencer. Donc c'est un problème de coordination, comment saurez-vous que vous pouvez maintenant lancer l'opération?

la solution la plus simple est le blocage.

Blocage , c'est quand vous choisissez simplement attendre que l'autre chose à faire et vous retourner une réponse avant de passer à l'opération qui en avait besoin.

Donc, si vous avez besoin de mettre du beurre sur toast, et donc vous devez d'abord toast the bred. La façon dont vous les coordonniez, c'est que vous portiez d'abord un toast à la race, puis que vous regardiez sans cesse le grille-pain jusqu'à ce qu'il éclate, et que vous mettiez du beurre dessus.

C'est la solution la plus simple, et fonctionne très bien. Il n'y a pas de raison de ne pas l'utiliser, à moins que vous ayez aussi d'autres choses à faire qui ne nécessitent pas de coordination avec les opérations. Par exemple, de faire quelques plats. Pourquoi attendre regarder fixement le grille-pain constamment pour le toast à pop, quand vous savez que ça va prendre un peu de temps, et vous pourriez laver un plat entier pendant qu'il termine?

c'est là que deux autres solutions appelées respectivement non-bloquantes et asynchrones entrent en jeu.

Non-blocking est quand vous choisissez de faire d'autres choses sans rapport pendant que vous attendez que l'opération soit faite. Vérifier la disponibilité de la réponse lorsque vous voyez l'ajustement.

Donc, au lieu de regarder le grille-pain pour qu'il pop. Vous allez laver un plat entier. Et puis vous regardez le grille-pain pour voir si les toasts ont sauté. S'ils ne l'ont pas fait, vous allez laver un autre plat, en vérifiant le grille-pain entre chaque plat. Quand vous voyez les toasts ont sauté, vous arrêtez de laver la vaisselle, et à la place vous prenez les toasts et passer à mettre du beurre sur eux.

avoir à vérifier constamment sur les toasts peut être ennuyeux cependant, imaginez le grille-pain est dans une autre pièce. Entre deux plats, vous perdez votre temps à aller dans l'autre pièce pour vérifier le toast.

c'est asynchrone.

asynchrone est quand vous choisissez de faire d'autres choses sans rapport pendant que vous attendez que l'opération soit faite. Au lieu de vérifier sur, vous déléguez le travail de vérification à quelque chose d'autre, pourrait être l'opération elle-même ou par un observateur, et vous avez ce chose notifier et éventuellement interupt vous lorsque la réponse est disponible afin que vous puissiez procéder à l'autre opération qui en avait besoin.

c'est une terminologie étrange. Cela n'a pas beaucoup de sens, car toutes ces solutions sont des moyens de créer une coordination asynchrone des tâches dépendantes. C'est pour ça que je préfère appeler ça un concours complet.

donc pour celui-ci, vous décidez de mettre à jour votre grille-pain pour qu'il bip quand les toasts sont faits. Vous arrive d'être constamment en écoutant, même en faisant la vaisselle. En entendant le bip, vous faites la queue dans votre mémoire que dès que vous avez fini de laver votre plat actuel, vous arrêterez et allez mettre le beurre sur le toast. Ou vous pouvez choisir d'Intervertir le lavage du plat actuel, et de traiter le toast tout de suite.

si vous avez de la difficulté à entendre le bip, vous pouvez demander à votre partenaire de surveiller le grille-pain pour vous, et venir vous dire quand le toast est prêt. Votre partenaire peut lui-même choisir l'un de les trois stratégies ci-dessus pour coordonner sa tâche de regarder le grille-pain et vous dire quand ils sont prêts.

pour conclure, il est bon de comprendre que même si le non-blocage et l'asynchrone (ou ce que je préfère appeler le Pair) vous permettent de faire d'autres choses pendant que vous attendez, vous ne l'avez pas aussi. Vous pouvez choisir d'constamment en boucle sur la vérification de l'état d'un appel non bloquant, ne rien faire d'autre. C'est souvent pire que de bloquer (comme regarder le grille-pain, puis loin, puis revenir à elle jusqu'à ce qu'elle soit terminée), donc beaucoup d'API non-bloquantes vous permettent de passer en mode de blocage à partir de celle-ci. Pour evented, vous pouvez juste attendre inactif jusqu'à ce que vous êtes notifié. L'inconvénient dans ce cas est que l'ajout de la notification était complexe et potentiellement coûteux au départ. Vous avez dû acheter un nouveau grille-pain avec bip fonctionnalités, ou convaincre votre partenaire de le regarder pour vous.

et une dernière chose, vous devez réaliser les compromis que les trois fournissent. On n'est pas évidemment mieux que les autres. Pensez à mon exemple. Si votre grille-pain est si rapide, vous n'aurez pas le temps de laver un plat, même pas commencer à le laver, voilà à quelle vitesse votre grille-pain est. Dans ce cas, commencer autre chose n'est qu'une perte de temps et d'efforts. Le blocage ne. De même, si laver un plat prend 10 fois plus de temps que la torréfaction. Vous devez vous demander ce qui est plus important à faire? Le pain peut être froid et dur en ce moment, pas la peine, le blocage aussi. Ou vous devriez choisir des choses plus rapides à faire pendant que vous attendez. Il y a plus évident, mais ma réponse est déjà assez longue, mon point est que vous devez penser à tout cela, et les complexités de la mise en œuvre de chaque pour décider si elle vaut la peine, et si elle va réellement améliorer votre tout ou la performance.

Edit:

même si c'est déjà long, je veux aussi qu'il soit complet, donc je vais ajouter deux points.

1) Il existe aussi couramment un quatrième modèle appelé multiplexé . C'est quand pendant que vous attendez une tâche, vous commencez une autre, et pendant que vous attendez les deux, vous commencez un de plus, et ainsi de suite, jusqu'à ce que vous avez beaucoup de tâches tout commencé et puis, vous attendez inactif, mais sur tous. Donc dès que tout est fait, vous pouvez procéder à la manipulation de sa réponse, et puis revenir en arrière pour attendre les autres. Il est connu comme multiplexé, parce que pendant que vous attendez, vous devez vérifier chaque tâche l'une après l'autre pour voir si elles sont faites, ad vitam, jusqu'à ce que l'une soit. C'est un peu une extension en plus du non-blocage normal.

dans notre exemple, ce serait comme démarrer le grille-pain, puis le lave-vaisselle, puis le micro-ondes, etc. Et puis d'attendre sur l'un d'eux. Où vous verriez le grille-pain pour voir si c'est fait, sinon, vous verriez le lave-vaisselle, sinon, le micro-ondes, et autour de nouveau.

2) Même si je crois que c'est un grand erreur synchrone est souvent utilisé pour signifier qu'une seule chose à la fois. Et asynchrone beaucoup de choses à la fois. Ainsi, vous verrez synchrone bloquant non-bloquant utilisé pour désigner le blocage et les non-bloquant. Et le blocage asynchrone et le non-blocage utilisés pour se référer à multiplexé et pair.

Je ne comprends pas vraiment comment nous sommes arrivés là. Mais quand il s'agit de IO et de calcul, synchrone et asynchrone font souvent référence à ce qui est mieux connu comme non-superposé et superposé. C'est-à-dire qu'asynchrone signifie que IO et le calcul se chevauchent, aka, se produisant simultanément. Bien que synchrones signifie qu'ils ne sont pas, se produisant donc séquentiellement. Pour le non-blocage synchrone, cela signifierait que vous ne démarrez pas D'autres IO ou de calcul, vous êtes juste occupé à attendre et simuler un appel de blocage. J'aimerais que les gens arrêtent d'utiliser mal syncronous et asynchrone comme ça. Donc je ne suis pas de l'encourager.

ils ne diffèrent que par l'orthographe. Il n'y a pas de différence dans ce qu'ils appellent. Pour être technique, vous pourriez dire qu'ils diffèrent dans l'accent. Le non blocage fait référence au flux de contrôle(il ne bloque pas.) Asynchrone se réfère à quand l'événement\data est manipulé (pas synchrone.)

les modèles de blocage nécessitent l'application d'initialisation pour bloquer lorsque l'Entrée/Sortie a commencé. Cela signifie qu'il n'est pas possible de chevaucher le traitement et les e/s en même temps. Le modèle synchrone non-bloquant permet le chevauchement du traitement et de l'E/S, mais il exige que l'application vérifie l'état de l'e/s sur une base récurrente. Il n'y a donc plus d'E/S asynchrones non bloquantes, ce qui permet un chevauchement du traitement et des e/s, y compris la notification de l'achèvement des e/s.

blocage: le contrôle revient à invoquer precess après traitement de primitive (sync ou async) complète

Non-blocking: contrôle retourne au traitement immédiatement après l'invocation