Le synchrone et l'asynchrone sont une notion importante en ingénieries aussi bien pour construire des moteurs que du code informatique, que des usines.
Pourtant ... alors qu'en informatique on arrive pas à s'entendre sur ce terme au sein même de la profession, la notion employée est-elle la même que celle des autres, et n'est-elle pas
cinompréhensible sans introduire du contexte ?
Souvenez vous de cet adage disant qu'avant toute chose le code, c'est de la politique ... au sens de déléguer des tâches...
D'abord commençons par les choses sur lesquels on sera tous (sauf parfois moi) qu'elles sont synchrones :
- les moteurs synchrones,
- la natation synchronisées,
- les horloges
- le retour des saisons, de la pleine lune et des marées,
- le retour des touristes avec les beaux jours
La logique de synchronicité est à la fois en même temps (syn-avec + chronos + temps) et lié dans son action par un lien rigide.
Un « un deux » en foot est un mouvement synchrone entre 2 joueurs.
Des montres réglées magiquement par des serveurs radioguidées à travers le monde sont synchronisées, ce qui permet à notre société d'avoir une logistique.
les feux de circulation (sémaphores) sont synchronisés afin que quand c'est vert pour les uns ce soit le rouge des autres.
La saisons scolaire, les examens nationaux sont synchronisés, les bilans comptables annuels sont synchronisés...
En fait, la synchronisation n'est pas la périodicité, mais elles sont souvent liées.
Genre, pour un agriculteur sont activité physique est synchronisée à celle des choses avec les quelles il interagit genre les saisons. Et comme les saisons sont régulières en fréquences alors la synchronicité de son activité avec les saisons entraîne que son activité professionelle est planifiable en cycle. Ce n'est pas sycnchrone => périodicité :les récoltes sont saisonnières parce que l'activité de l'agriculteur étant synchronisée avec la disponibilité des ressources (dont chaleur) qu'il a une activité fortement «saisonalisée».
Donc par couplage, (c'est ce qu'on appelle vivre en société et coopérer) de l'activité saisonnière de métier assez structurant pour notre survie (bouffe) que notre société est synchronisée sur le maillon le plus faible et ou important.
Maintenant qu'est ce qui est « asynchrone » ?
Littérallement : ce qui n'a pas de temporalité.
Un accident est asynchrone.
Une moissonneuse batteuse qui tombe en panne pendant une récolte EST asynchrone. MAIS, par effet de synchronisation de tout les agriculteurs la probabilité des accidents asynchrones de moissonneuse batteuse a la propriété d'avoir plus de chance d'arriver en même temps que les récoltes. Donc, il y a un paradoxe d'observations et que l'asynchrone est souvent observé de manière synchrone et que les emmerdes (choses asynchrones) dans un contexte synchronisé ont tendance à voler en escadrilles.
On dit en physique statistique que le temps est l'accident des accidents.
C'est parce qu'au niveau microscopique des collisions d'atome d'une manière irréversible arrivent que nous dérivons la propriété observable de température (avec un thermomètre) qui en fait permet d'établir une flêche du temps.
Et je pense qu'on ne va pas couper à la question pourquoi il y a t'il quelque chose plutôt que rien ?
Je viens quasiment de dire que tout est asynchrone puisque notre mesure de ce qui est synchrone (le temps) dérive de la référence à des accidents statistiques qui arrivent aléatoirement.
La temps et donc la synchronisation sont des abstractions humaines, pour distinguer quand un évènement est programmable ou non.
Quand un évènement est anticipable on le dira synchronisable et de nature à créer des choses synchrones : genre faire du pain.
En fait, le problème avec parler comme un livre, c'est qu'en vérité les tâches ne sont synchrones que si et seulement si on les force à être synchrones en faisant des préparations.
Il faut que j'ai la farine, l'eau et de la levure vivante pour faire du pain.
Si je n'ai pas les ingrédients ALORS une tâche asynchrone vient d'apparaître acheter la farine ou préparer un levain ou acheter de la farine.
Mais dans un livre on oublie que l'ordre de certaines tâches pour faire le pain ne sont pas important.
Il n'est pas important que vous réveilliez votre levure avant de préparer le plain de travail pour mélanger farine et eau. Disons qu'il existe juste une fenêtre de synchronisation forte entre mettre la levure vivante dans le pétrain avant de le mettre à lever.
C'est clairement l'oeil de l'observateur qui classe dans ce cas la tâche comme totalement synchrone, et permet au codeur de créer une machine à pain qui va permettre à des gens de créer une machine qui prenant chaque ingrédient va après appui sur un bouton sortir un pain en un temps déterminé.
Le plus simples des mécanismes synchrones est un intérupteur.
Dessus on bâti mon robot préféré : un auto-cuiseur pour le riz. T'appuies sur un bouton et t'as le riz 30 minutes plus tard.
Que les auto-cuiseurs aient une logique asynchrone matérialisée par une lame de métal qui se déforme quand le riz est suffisamment chaud pour passer de cuisson rapide à lente est un détail du point de vue de l'utilisateur. Au final c'est une tâche pilotable à ma demande qui a un fonction déterminée et déterministe de production en un temps donnée.
Si je modélisais la lame de métal en javascript je ferais un
on_hot(function() { temperature.switch(low) }.Vous commencez à me voir arriver avec l'enfer des callbacks, mais le callback est une parmi les nombreuses manière de gérer ce qui est asynchrone. La lame de métal vierge de tout design pattern dans l'autocuiseur fait son office en se déformant par les lois de la physique et non celle de la logique abstraite d'un PhD en math.
Est-ce que vous remarquez que j'ai commencé par taquiné les observables physiques globaux comme le mouvement des planètes qui inspira les interpréations les plus fantaisistes de moults religions pour en arriver à des robots ménagers ?
Quelque part le premier robot synchrone est justement l'objet de la vénération à 250 000 boules pièce par les classes dirigeantes et on appelle ça une montre.
Que la logique de temps synchrone absolu soit une contre vérité physique claquée au sol ne peut lutter contre des millénaires de prêtres ayant fait croire qu'en observant les étoiles ils ont tout compris du temps.
Les leaps seconds en informatique sont là pour nous rappeler que les durées des jours, des mois, des années varient car contrairement à ce que les prêtres imaginaient la mécanique des cieux n'est pas une horloge synchronisée, car tout n'est pas lié rigidement. Aussi pseudo périodique soit-il, le système solaire est chaotique dans son mouvement. La périodicité d'un jour que l'on observe est métastable et ... depuis aussi loin qu'on a des chronomètres mécaniques.
Je sens le premier de la classe en train de se dire, il me bullshite on a eu cette conversation vendredi et il avait l'air de plutôt voir une différentiation solide entre synchrone et asynchrone. Yep, c'est le maître qui décide ce qui est synchrone ou asynchrone, mais la nature de toute chose reste fondamentalement asynchrone.
La synchronisation correspond à un état de liaison de tâches artificiel fait pour organiser le travail de manière à satisfaire un maître.
Si on a fait des usines c'est pour rendre la tâche de faire sien un bien synchrone. Je vais chez le concessionnaire, j'arrive j'appuie sur un bouton, un commercial arrive, je lui dis la voiture que je veux, je lui donne un chèque ou quelque autres jetons, il me donne une facture/contrat en échange et je repare immédiatement avec une voiture qui a demandé la synchronisation de moults évènements en amont.
La fabrication d'une voiture dans l'usine d'henri le bâtard a été fait pour que le salarié soit synchronisé sur la tâche des autres dans un enfer abrutissant du bruit des moteurs synchrones qui tournent, des livraisons synchronisées de ressources de campagnes de pubs .... La synchronisation est l'accident des accidents nécessaire à ce que la transformation des ressources naturelles soit délivrées dans l'expérience la plus plaisante possibles aux maîtres.
L'expérience de vie du mineur de manganèse nécessaire à faire des alliages n'est pas synchrone, elle est fait d'accident (dont d'avoir choisi de naître pauvre dans un pays pauvre) qui fait qu'il ne profitera jamais du résultat de sa tâche.
En tant que codeur, j'ai aucune empathie avec le silicium, et abuser de technique d'exploitations pour finir le boulot et rentrer le plus tôt possible ne me pose aucun problème moral ou éthique, et j'embrasse l'exploitation du silicium comme un Beruf, une vocation.
En ceci, j'embrasse la synchronisation car les ordinateurs avec lesquels j'ai grandi et que j'aime sont fondamentalement synchrones (M68K, MIPS, 6502, x386, 486). En fait pas vraiment.
L'accident, la plaie dans le cul du développeur, c'est évidemment ce qui n'est pas prévu, et c'est ce que les utilisateurs aiment. Genre tu déplaces une souris, tu cliques et booom ça explose.
L'asynchrone c'est l'accident que t'as prévu. Et fasse à l'imprévisible t'as masse stratégie mais voyons les plus courantes en revue, en commençant ce qui parle le plus en français : ALLER AU RESTO.
Vu que j'ai fait du service à l'anglaise, à la russe et à la française (mais que je me souviens jamais lequel est lequel) je vais vous montrer différemment scénario que l'on qualifiera d'asynchrone ou synchrone pour les workers (travailleurs) et le les consommateurs (utilisateurs).
Le routier :
- j'arrive au resto, j'ai une expérience asychrone (car non scriptée) de prise de commande, je pose mes fesses et expérimente un repas synchrone car à chaque fin de plat automagiquement le suivant apparaît. La magie de ce synchronisme apparent est : des serveurs qui planifient la cuisine (scheduleur) et "pollent" les clients
- du point de vue du travailleur dans une synchronicité de la fenêtre du service je vis 2 heures de travails subis basé sur des alarmes qui sonnent les ordres, les tâches partitionnées dont certaines interruptibles (les pates ont besoin de 7 minutes pour cuire sans que je les regarde) Le «mleko bar» polonais (qui ressemble aux vieux restau du quartier latin):
- T'arrives dans une file, t'attends, tu donnes ton ordre (souvent de la cuisine déjà préparée en aval), tu t'assois, t'attends et quand on te sonnes parce que ton plateau repas est prêt tu vas le chercher avec entrée, plat dessert dessus
- du point de vue du travailleur, tu prépares en masses tes plats avant le coup de fouet et tu vis une expérience synchrone
J'insiste sur le fait qu'en expérience utilisateur le synchrone désigne la partie dans une interaction où tu es celui qui est en position de diriger la tâche de l'autre.
Mais, il y a aussi le synchrone - synchrone. Prenez la cantine scolaire de l'école de ma fille : parce que l'évènement est récurrent (synchronisable et non synchrone donc), les pitchous peuvent arriver à la cantine sans qu'il y ait d'expérience asynchrone ni pour les élèves, ni pour les travailleurs.
Le prix à payer est l'absence de « choix » et les polémiques qui reviennent comme des maronniers à chaque rentrée sur les choix de viandes, légumes ... imposés de manière jacobine à tous et à toutes.
Le l10n (localization) est un sujet trop touffu en informatique pour que j'en cause aujourd'hui, mais il m'en chauffe pour être honnête.
Revenons au travailleur celery (un travailleur supposé asynchrone) en cuisine et au client (le web service).
Imaginons que je suis un dev socratique qui sait qu'il ne sait rien, mais qui sait le prix à la connaissance.
De mon point de vue qui sait qu'il ne sait rien et est limité, je vais vouloir une interface synchrone pour un monde fondamentalement asynchrone. Je vais dire : je veux arriver au comptoir dire je veux telle ressource ou résultat, et j'ai.
Manque de bol, comme j'utilise le web qui est tout cassé, la tâche que je veux n'est pas instantannée (genre un repas sur mesure avec une cuisson spécifique). Et bien l'asynchrone vise à rendre l'expérience de celui qui veut pas attendre pour une tâche qui est forcément longue est pleine d'aléas paraisse standardisée par un ordre qui paraît simple : fais moi un jambon beurre cornichon halal/kosher/végétarien.
Bon ok, ça ne le fait pas, faisons plus simple une commande mc do avec l'interface qui te permet de modifier ta commande.
L'UX du consommateur de mc do est asynchrone. Tu passes ta commandes, tu as un ticket avec un task id et tu vas avoir un callback du serveur sur quand ta command est prête. Une fois ton ticket émis en borne, la cuisine (la queue) affiche ta commande, les workers (équipiers mc do) se voient gentiment incité à acquitter réception (ACK) de la commande et commencer à travailler. Mc Do est doué pour router l'information sur deux pub-sub (broadcast) un en cuisine (préparation du chaud) et un en comptoir (boisson, déssert, et autre truc demandable à des robots synchrones). Ensuite des rituels forcés à coup de truelles manageuriales font que les tâches se propagent et arrivent jusqu'au comptoir pour l'assemblage (join comme en distribué) où la tâche est finalisée puis livrée.
Pourquoi cette merveille d'organisation du travail est-elle qualifiée péjorativement par la société et ceux qui l'ont vécu alors que sur le papier de l'informatique c'est hyper souhaitable du point de vue de l'utilisateur ?
J'ai envie de te demander : imagines quand tu fais un truc sérieux qui requiert de la concentration (genre coudre) t'as un zigue qui te tapes l'épaule pour te demander de coudre son cul ?
Peut être pas son cul, mais de faire un truc qui a aucun rapport. Tu vas devoir poser ton aiguille, la ranger dans sa boîte, ranger ton ouvrage qui est chiant comme tout à reprendre, pour interrompre ta tâche pour ensuite la reprendre ...
Ayant fait de l'assembleur, cette analogie n'est pas pétée du cul claquée au sol : quand une interruption matérielle venant d'un périphérique (genre une souris ou un clavier arrive) les OS font le boulot de mettre dans la pile les registres CPU et flags pour executer le code interrompant urgent, afin de pouvoir restaurer ensuite à la tâche ces registres. La perte de temps liées à un « changement de contexte » est lourde : un registre CPU que je comptais utiliser était à un cycle d'horloge. Même en cache L1, c'est 400 cycles x 2 d'aller retour perdu, soit ... à minima 800 instructions. Un processeur qui fait 1 milliards d'instructions par secondes ne peut faire qu'un million d'interruptions par secondes AU MIEUX.
Le coût de l'asynchrone (donc de l'accident) c'est le coût de nettoyer et restaurer à l'identique son plan de travail avant et après une interruption qui est sacralisée comme le mode normal de fonctionnement.
L'asynchrone n'est pas mal, il est même un de mes modes de programmation préféré comme élégant pour la gestion de ce qui est imprévisible, MAIS, l'asynchrone a un coût élevé qu'il est souhaitable de questionner et surtout observer.
Pour résumer que ce soit en informatique, en mécanique ou dans la vraie vie le synchrone c'est un rouleau compresseur organisationnel qui fait peu de variation mais qui est le mode pour envoyer du bois : genre une cantine avec un menu très limité. L'asynchrone c'est le monde du à la carte (en français dans le texte) et de rendre synchrone une expérience fondamentalement asynchrone pour l'utilisateur (au prix de maltraiter le travailleur (worker)).
En tant que codeur, j'ai vraiment toujours aucun problème éthique à maltraiter les CPU/GPU/ASICs/périphériques. Par contre, je peux au vu des organisations réelles que cela induit (un message est parfois un bon de commande/facture à executer sur le champs) avoir une aversion à l'asynchrone comme parcours client car je devines les ombres des travailleurs condamnés à vivre dans l'attente d'un ticket pour pouvoir subsister sans pouvoir maîtriser leur temps et ça me pose des questions.
Pour info, je travaille en ce moment sur un système asynchrone au taffe et aucun humain (ou animal) n'a été blessé ou impacté dans le processus. (Je ne pense pas que des instances docker soit considérées comme sapientes).
No comments:
Post a Comment