Quelle est la différence entre asynchrone et non-blocage des appels? Aussi entre le blocage et des appels synchrones (avec des exemples s'il vous plaît)?
Réponses
Trop de publicités?Dans de nombreux cas, ils sont des noms différents pour la même chose, mais dans certains contextes, ils sont très différents. Donc ça dépend. La terminologie n'est pas appliquée de façon totalement cohérente à travers l'ensemble de l'industrie du logiciel.
Par exemple dans le classique API sockets, un socket non bloquant est simplement la renvoie immédiatement avec un spécial "bloquerait" message d'erreur, d'où un blocage de la douille auraient bloqué. Vous devez utiliser une autre fonction telle que select
ou poll
, pour savoir quand est le bon moment pour recommencer.
Mais sockets asynchrones (pris en charge par Windows sockets), ou asynchrone IO motif est utilisé dans .NET, sont plus commodes. Vous appelez une méthode pour démarrer une opération, et dans le cadre des appels à vous en arrière quand il est fait. Même ici, il y a des différences fondamentales. Asynchrone Win32 sockets "maréchal" de leurs résultats sur un spécifique thread GUI en passant de la Fenêtre de messages, alors qu' .NET asynchrone IO est libre de thread (vous ne savez pas quel fil de votre callback sera appelé).
Donc ils n'ont pas toujours la même chose. À distiller le socket exemple, pourrait-on dire:
- Blocage et synchrone signifient la même chose: vous appelez l'API, il raccroche le fil jusqu'à ce qu'il a en quelque sorte une réponse et il retourne à vous.
- Non-blocage signifie que si une réponse ne peut pas être retourné rapidement, l'API retourne immédiatement avec un message d'erreur et ne fait rien d'autre. Donc il doit y avoir certains sont liés de façon à se demander si l'API est prêt à être appelé (c'est-à simuler une attente de manière efficace, pour éviter le manuel d'interrogation dans une boucle).
- Asynchrone signifie que l'API renvoie toujours immédiatement, ayant commencé un "fond" de l'effort de répondre à votre demande, donc il doit y avoir certains sont liés de manière à obtenir le résultat.
Mettre cette question dans le contexte de NIO et NIO.2 dans java 7, async IO est une étape plus avancée que la non-bloquant.
Avec java NIO appels non bloquants, on pourrait définir l'ensemble des canaux (SocketChannel, ServerSocketChannel, FileChannel, etc) en tant que tel en appelant AbstractSelectableChannel.configureBlocking(false)
.
Après ces IO appels de retour, cependant, vous aurez probablement encore besoin de contrôle les contrôles tels que 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 dans java 7, ces contrôles peuvent être réalisés dans le plus polyvalent des moyens.
L'une des 2 méthodes est d'utiliser CompletionHandler
. Notez que les deux read
des appels sont non-bloquant.
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) {...}
}
}
Comme vous pouvez probablement voir à partir de la multitude de différents (et souvent mutuellement exclusifs) réponses, cela dépend de qui vous demandez. Dans certains domaines, les termes sont synonymes. Ou ils peuvent faire référence à deux concepts similaires:
- Une interprétation est que l'appel sera de faire quelque chose dans le fond essentiellement sans surveillance afin de permettre au programme de ne pas être tenu en place par un processus de longue haleine qu'il n'a pas besoin de contrôle. La lecture audio peut être un exemple - un programme pourrait appeler une fonction à jouer (dire) un mp3, et à partir de ce point, elle pourrait continuer à autre chose tout en laissant à l'OS pour gérer le processus de rendu de l'audio sur le matériel audio.
- L'autre interprétation est que l'appel sera de faire quelque chose que le programme aura besoin de surveiller, mais permettra à la plupart des processus en arrière-plan seulement avertir le programme de points critiques dans le processus. Par exemple, le fichier asynchrone IO pourrait être un exemple - le programme fournit un tampon pour le système d'exploitation d'écrire dans un fichier, et l'OS informe le programme lorsque l'opération est terminée ou qu'une erreur se produit.
Dans les deux cas, l'intention est de permettre au programme de ne pas être bloqué dans l'attente d'un lent processus, la façon dont le programme est prévu pour répondre est la seule vraie différence. Quel terme désigne ce qui change également de programmeur programmeur, la langue, ou de la plate-forme à plate-forme. Ou les conditions peuvent se référer à des concepts complètement différents (tels que l'utilisation de synchrone/asynchrone par rapport au fil de la programmation).
Désolé, mais je ne crois pas qu'il existe une seule bonne réponse qui est globalement vrai.