Apprendre la programmation asynchrone [fermé]

La programmation asynchrone non bloquante pilotée par les événements semble être à la mode. J'ai une compréhension conceptuelle de base de ce que tout cela signifie. Cependant, ce que je ne sais pas, c'est quand et où mon code peut bénéficier d'être asynchrone, ou comment rendre les E / S bloquantes non bloquantes. Je suis sûr que je peux simplement utiliser une bibliothèque pour ce faire, mais je suis plus intéressé par des concepts plus approfondis et les différentes façons de l'implémenter moi-même.

Existe-t-il des livres complets / définitifs ou d'autres ressources sur ce sujet (comme GoF pour Design Patterns, ou K&R pour C, tldp pour des choses comme bash)?

(Remarque: je ne suis pas sûr que ce soit une question fonctionnellement identique à ma question sur l' apprentissage de la programmation événementielle )

La programmation asynchrone est bien plus une philosophie qu'une simple astuce de programmation. Alors que votre dernière question a attiré des réponses principalement sur les aspects de programmation et ma réponse était un solitaire déconnecté pour être principalement théorique, j'essaie de vous donner une nouvelle perspective en s'appuyant sur la même ligne mais des explications plutôt que de simples références.

Celui-ci concerne certains principes fondamentaux de pourquoi et comment de la programmation asynchrone.

Supposons que vous vous rendiez dans une boulangerie (et en supposant que le gâteau sera préparé après la commande) - vous avez deux choix, soit vous choisissez d' attendre que le gâteau soit prêt ou vous donnez la commande et retournez à la maison et ramassez plus tard quand il sera prêt. Le premier (attente) est une méthode synchrone et plus tard est une méthode asynchrone . Inutile de dire que cet exemple fournit une bonne référence pourquoi devriez-vous utiliser des méthodes asynchrones plutôt que synchrones.

La programmation basée sur les événements n'est qu'une des façons dont les systèmes asynchrones peuvent être construits et ce n'est pas seulement un modèle de conception utile, mais plutôt un modèle architectural. J'énumère des cas où cette théorie est utilisée d'une manière pratiquement utile - en espérant qu'elle apporterait une certaine clarté

1. L'un des premiers exemples de systèmes asynchrones est le système d'E / S Unix. Alors que nous savons read(), write()et même des select()appels bloque le flux de programme, mais à l' intérieur du système d' exploitation, ils sont asynchrones, à savoir le noyau sait généralement que le dispositif de bloc (aka disque dur) prendra un certain temps pour le tampon de remplissage, jusqu'à un temps CPU est libre à partir de ce thread respectif et donc le thread est parqué comme (pas prêt). Voir 1. Moris Bach "La conception du système d'exploitation Unix"

2. Un autre exemple le plus courant est la majorité des cadres d'interface utilisateur. Ici, tous les clics des utilisateurs sont d'abord envoyés via un contrôleur qui à son tour rappelle l' application respective. Ce qui est important, c'est que ces rappels ne doivent pas laisser les rappels attendre, sinon le système se fige. Les rappels du contrôleur d'interface utilisateur aux serveurs principaux sont généralement asynchrones s'ils impliquent un traitement intensif.

3. Active Object est un autre bon exemple de programmation asynchrone (en tant que modèle de conception pur). Un objet actif est un objet qui a son propre thread privé de telle sorte que l'on peut conserver de nombreuses requêtes dans une file d'attente et les exécuter une par une. Reportez-vous à ce document: Objet actif . Ce modèle est largement utilisé depuis les logiciels d'entreprise jusqu'aux frameworks mobiles. Les plates-formes populaires Java / EJB et .NET permettent l' appel de méthode asynchrone locale ou distante qui permet essentiellement aux objets normaux de devenir des objets actifs. Les objets actifs étaient présents depuis longtemps dans Symbian: les objets actifs dans Symbian OS par Aapo Haapanen (voir aussi: les objets actifs dans Symbian ). Ceci est maintenant également présent dansAndroid ).

4. En dehors de l'objet actif, le même auteur Douglas C. Schmidt , a produit un certain nombre d'autres travaux qui sont d'autres parallèles à l'objet actif et sont également les modèles asynchrones. Voir cet Event Handling Patterns et un compte rendu complet est disponible sur son livre Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects - V2

5. Lorsqu'un objet donné doit retourner l'API, tout en travaillant en arrière-plan pour accomplir réellement le travail, la méthodologie habituelle est d'avoir un système multi-thread pour y parvenir. Les systèmes filetés sont présents partout de C (posix), C ++ ( boost ) à Java, C # et ainsi de suite. L'objet actif n'est essentiellement qu'une abstraction qui peut cacher cela. Découvrez pourquoi les implémentations d'objets actifs sont préférables aux threads nus. Encore une bonne lecture .

6. Mais ce concept va au-delà des threads ou des objets à l'intérieur d'une application pour devenir asynchrone. L'une des meilleures utilisations est dans les systèmes distribués où deux applications n'ont pas nécessairement besoin de s'attendre l'une l'autre pour les coordinations. Bon vieux (ou pas si bon, quelle que soit la façon dont vous le voyez) RPC était synchrone. [bien sûr, il existe également d'autres RPC asynchrones ]. Mais les alternatives modernes comme le middleware orienté message sont vraiment asynchrones pour de bonnes raisons.

7. Dernier point, mais le plus intéressant, la programmation des Agents qui peut bénéficier du modèle de communication asynchrone .

Bien que la programmation asynchrone ait l'air sexy, elle crée sa propre complexité, notamment:

• cadre pour le passage de la valeur de retour
• frais généraux supplémentaires de communication
• besoin supplémentaire de synchroniser les constructions
• possibilité de blocages, de courses, etc. si les choses ne sont pas bien faites.

... etc.

Il ne doit toujours être utilisé que pour de véritables raisons.

Alors, quand doit-on utiliser le modèle asynchrone? Quand devez-vous mettre un thread d'arrière-plan et permettre à l'appelant de devenir asynchrone?

1. Lorsque le système souhaite appliquer une conversation de ressources sérieuse stricte: par exemple, vous souhaitez conserver un nombre fixe absolu de threads. Le modèle asynchrone force le système à implémenter la file d'attente.

2. Quand le besoin de l'appelant de faire "d'autres choses utiles à faire" est en effet authentique. Tant de fois, l'autre thread, même s'il est débloqué, ne fera rien d'utile et restera en attente de résultats. Cela peut en effet être plus consommateur de CPU que le modèle synchrone de base.

3. Lorsque vous avez besoin de niveaux de fiabilité plus élevés dans les systèmes distribués. (voir Middleware orienté message ).