Résumé

  • Dans une opération split-phase, la commande lançait ou refusait la demande puis rendait la main immédiatement ; un événement signalait plus tard la fin définie par le composant fournisseur.
  • Cette séparation économisait piles et énergie, mais obligeait l’application à conserver l’état, la garde du tampon, les délais et les transitions de reprise.
  • sendDone pouvait autoriser la réutilisation locale d’un message sans prouver sa réception, son acceptation ou son traitement par une application distante.

La garde d’un tampon

L’exemple le plus parlant de TinyOS n’est pas une grande architecture. C’est un tampon de paquet que deux parties ne doivent pas modifier en même temps.

L’application appelle send. Si le composant radio accepte la demande, il a besoin du contenu pendant un intervalle qui survit au retour de la fonction. Copier le paquet consommerait une mémoire et une énergie précieuses. Le pointeur circule donc sans que la donnée change immédiatement de propriétaire. Le composant radio en reçoit la garde provisoire.

L’événement sendDone ferme cette garde locale. Avant lui, réécrire le tampon risque de corrompre un paquet encore en cours d’émission. Sans lui, le tampon peut rester immobilisé indéfiniment. Si l’événement est associé à la mauvaise demande, une ressource rare est libérée au mauvais moment.

Cette petite discipline contient déjà une théorie de la preuve. Le retour de send ne dit pas que la radio a fini. L’événement ne dit pas nécessairement que le destinataire final a reçu le paquet. Chaque trace répond à une question et laisse la suivante ouverte.

Pourquoi la machine ne pouvait pas attendre en bloquant

Les motes qui ont façonné TinyOS vivaient sous des contraintes très éloignées d’un ordinateur généraliste. Quelques kilo-octets de RAM devaient servir à l’application, aux files, aux états et à la pile. La radio dominait souvent la dépense active ; lorsque rien ne se passait, le processeur devait dormir.

Donner une pile privée à chaque activité en attente aurait gaspillé la ressource la plus rare. Garder le processeur éveillé jusqu’à la fin d’une conversion ou d’une transmission aurait gaspillé l’énergie. TinyOS a donc organisé le calcul autour de tâches différées et d’événements. Quand la file de tâches était vide, le mote pouvait retourner au sommeil jusqu’à une interruption.

Une opération longue devenait split-phase. La commande ne bloquait pas ; elle rendait la main. Plus tard, un événement permettait à l’automate de reprendre la séquence. Plusieurs activités pouvaient progresser avec une seule pile.

Le gain matériel avait un prix intellectuel. Ce qui aurait été écrit comme une suite linéaire devait devenir un automate : état courant, opération pendante, tampon concerné, prochain événement attendu, traitement d’un refus et politique d’expiration. TinyOS ne supprimait pas l’attente. Il la rendait explicite.

Deux sens dans une même interface

nesC a inscrit cette asymétrie dans le langage. Les interfaces étaient bidirectionnelles. La commande descendait vers le composant qui fournissait le service ; l’événement remontait vers celui qui l’utilisait. send et sendDone appartenaient au même contrat, et le câblage reliait simultanément les deux directions.

Cette forme aidait le compilateur à voir le programme entier. Il pouvait vérifier la composition statique, éliminer des indirections et repérer de nombreuses courses de données. Sur une machine où les protections dynamiques coûtaient cher, déplacer une partie de la sûreté au moment de la compilation était décisif.

Mais le câblage ne transformait pas le compilateur en autorité universelle. Il prouvait qu’un composant compilé était relié à un autre selon un type d’interface. Il n’authentifiait pas un capteur physique. Il ne prouvait pas l’identité d’un voisin radio. Il ne certifiait ni la vérité d’une mesure ni l’effet produit à distance.

Même le mot « événement » devait garder son périmètre. Certains événements achevaient une demande antérieure ; d’autres venaient de l’environnement, par exemple une réception ou l’expiration d’un minuteur. Un événement n’était pas toujours un reçu, pas plus qu’une commande n’était un résultat.

L’acceptation est un état, pas une victoire

Les textes de TinyOS envisagent deux réactions à la contention. Le fournisseur peut refuser immédiatement une demande concurrente, ou la mettre en file. Ces deux décisions n’ont pas la même conséquence.

Un refus laisse l’opération chez l’appelant : aucune transmission ne doit être inventée, et le tampon demeure disponible. Une admission crée au contraire une obligation pendante. Le fournisseur doit soit mener l’opération jusqu’au point de fin défini, soit rendre visible un échec ou une annulation selon le contrat.

C’est ici que beaucoup d’interfaces modernes se trompent. Elles appellent « succès » le fait d’avoir reçu une requête, puis laissent le lecteur supposer validation, exécution et effet final. TinyOS forçait la question suivante : succès de quoi ?

Le champ success d’un sendDone peut avoir une signification très utile au niveau local. Il peut permettre de réutiliser le message et d’avancer l’automate. Selon l’implémentation, il peut aussi intégrer une information de transmission ou d’acquittement de liaison. Son nom seul ne prouve pourtant pas que l’application distante a reçu, compris, stocké ou exécuté le message.

Une preuve étroite n’est pas une preuve faible. Elle devient dangereuse seulement lorsqu’on lui prête le rôle d’un acteur qui n’a pas parlé.

Quand le chemin du reçu sature

Le rapport T2 apporte la partie la plus inconfortable de l’histoire. Pour avertir l’étage supérieur, la pile radio devait généralement poster une tâche qui signalerait sendDone. Or la file de tâches avait une taille finie.

Si cette publication échouait, l’appelant pouvait attendre indéfiniment et conserver le tampon. TinyOS avait parfois recours à une échappatoire : signaler sendDone directement dans le contexte d’interruption. La progression revenait, mais au prix d’une violation du modèle attendu. Un code écrit pour s’exécuter comme tâche pouvait soudain être appelé de manière asynchrone et provoquer une course ou une corruption de mémoire.

Les auteurs de T2 soulignent que la forme du problème dépasse une pile radio particulière. Tout composant split-phase qui dépend d’une tâche pour livrer sa fin peut perdre le reçu lorsque la file est pleine. La panne remonte alors : blocage permanent si rien n’est signalé, risque de concurrence si le signal arrive dans le mauvais contexte.

Il ne faut pas convertir cet exemple en verdict sur chaque version et chaque déploiement TinyOS. Le rapport est une critique de conception issue de l’expérience, non un inventaire d’incidents. Il démontre néanmoins un point essentiel : la voie qui transporte la preuve consomme elle aussi des ressources. Un reçu n’existe pas seulement parce que l’interface le promet.

L’automate comme journal d’exécution

Un bon automate ne contient pas seulement « en cours » et « fini ». Il peut distinguer la demande créée, le refus immédiat, l’admission, l’attente matérielle, l’achèvement local, l’expiration, l’annulation et l’arrivée tardive d’un événement.

Cette finesse protège les reprises. Une expiration signifie que l’observateur n’a pas reçu la preuve dans le délai ; elle ne prouve pas automatiquement que l’opération n’a jamais eu lieu. Relancer sans identité peut dupliquer l’action. Réutiliser l’identité permet la réconciliation, à condition que le fournisseur conserve l’historique nécessaire.

L’automate devient ainsi un petit registre de transitions. Il n’est fiable que si chaque état correspond à un fait observable. Une variable « terminé » mise à vrai au retour de la commande reproduirait précisément la confusion que le modèle split-phase cherchait à éviter.

La comparaison avec la primauté du code en exécution de Heng Lu intervient ici comme lecture contemporaine. La déclaration de commande exprime une intention. Le composant en activité et l’événement ultérieur apportent une preuve plus forte. Pourtant, l’événement ne devient pas souverain : il n’atteste que la transition que son rôle contrôle. Cette comparaison n’attribue pas aux auteurs de TinyOS une doctrine publiée bien plus tard.

Une œuvre collective autour de Culler

La page officielle de Berkeley fait de TinyOS et des Berkeley Motes des éléments centraux du parcours de David Culler. Son rôle de chercheur, d’organisateur et de bâtisseur d’environnement justifie la perspective biographique. Il n’autorise pas à effacer les coauteurs.

L’article NSDI réunit Philip Levis, Sam Madden, David Gay, Joseph Polastre, Robert Szewczyk, Alec Woo, Eric Brewer et Culler. L’article nesC appartient à Gay, Levis, Robert von Behren, Matt Welsh, Brewer et Culler. Le rapport T2 rassemble une équipe encore plus vaste, issue de plusieurs universités et entreprises. La rétrospective de 2012 est l’analyse de Philip Levis.

Cette attribution correspond au sujet. TinyOS était un système de composants interdépendants ; son histoire est elle aussi composée de langage, d’ordonnancement, de radio, de matériel, de déploiements et de communauté. Le réduire à une signature unique ferait disparaître les frontières qui ont rendu le travail instructif.

Le coût qui apparaît après le succès

La rétrospective de 2012 rappelle l’ampleur prise par TinyOS à cette date : une plateforme de recherche dominante, des usages commerciaux et environ 25 000 téléchargements par an. Ces chiffres sont historiques, non une mesure actuelle.

Levis montre surtout comment les forces du projet ont produit leur propre coût. La minimisation des ressources et la prévention des bogues ont permis des systèmes complexes. nesC et les composants fins ont facilité l’expérimentation. À maturité, la spécialisation du langage et la dispersion de la logique entre de nombreux petits composants ont aussi rendu l’ensemble difficile à apprendre et à relire.

Une abstraction peut donc être juste au niveau local et coûteuse à l’échelle d’un écosystème. Le compromis n’annule pas la leçon split-phase. Futures, promesses, files d’achèvement et travaux durables reprennent aujourd’hui la même séparation sous d’autres noms : la soumission n’est pas l’issue.

Le bon reçu s’arrête à sa frontière

TinyOS n’a pas rendu la commande imparfaite en la faisant revenir tôt. Il lui a retiré une prétention fausse. La commande pouvait dire que la demande avait été présentée et, selon son résultat, admise ou refusée. Elle ne prétendait pas que le temps matériel avait disparu.

L’événement de fin avait une force complémentaire. Il pouvait rendre un tampon, fermer une opération locale et autoriser une transition. Il ne parlait pas au nom du voisin radio, de l’application distante ou du monde physique.

Le système honnête conserve cette chaîne au lieu de la réduire à une coche verte. Il relie la demande au bon événement, garde visibles les états non résolus et exige un reçu supplémentaire pour chaque frontière supplémentaire. Les contraintes sévères du mote ont rendu cette discipline impossible à masquer. Les systèmes abondants en ressources en ont tout autant besoin.

Sources