FR 2739472 A1 19970404 FR 9511496 A 19950929 Description L'invention concerne un procédé de gestion d'une mémoire d'un équipement de traitement de données, ladite mémoire étant composée de blocs de mémoire, et ledit procédé consistant allouer, pour la sauvegarde d'un ensemble de données, un unique bloc de mémoire, lui associer un compteur dit compteur de liens, et libérer ledit bloc de mémoire lorsque ledit compteur de lien est nul. L'invention concerne également un procédé de séquencement d'une pluralité de traitements effectués par des entités fonctionnelles d'un équipement de traitement de données, qui utilise pour la transmission de messages entre entités un tel procédé de gestion de mémoire. L'invention concerne également un système de transmission entre au moins deux équipements de traitement de données reliés par un support de transmission, l'un au moins desdits équipements étant doté d'une pluralité d'entités fonctionnelles et comportant des moyens de communication entre entités par échange de messages. L'invention concerne enfin un équipement de traitement de données destiné à être utilisé dans un tel système de transmission. L'invention a notamment d'importantes applications dans le domaine des télécommunications, par exemple dans des grands systèmes de commutation. Un procédé du type de celui décrit dans le paragraphe introductif est utilisé dans le système d'exploitation UNIX pour la sauvegarde de fichiers informatiques sur disque. Le mécanisme utilisé est décrit au chapitre 16 pages 243 à 250 de l'ouvrage "Unix" de Peter Norton et Harley Hahn publié aux éditions Sybex en 1991. Lors de la création d'un fichier un noeud d'index appelé inode" et contenant les informations nécessaires à la représentation du fichier lui est attribué. Ce noeud d'index est référencé par un numéro appelé "numéro d'inode". Dans un répertoire chaque fichier est référencé par son numéro d'inode auquel est associé un nom de fichier, la correspondance entre le nom du fichier et le numéro d'inode étant appelée lien. Une fois créé, le fichier peut être accessible depuis différents répertoires sous un même nom ou sous un nom différent. Pour cela, on crée un lien vers ce fichier dans un autre répertoire. Le nombre de liens associés au fichier est stocké dans l'inode du fichier: il est incrémenté ou décrémenté d'une unité à chaque création ou suppression de lien.Le fichier n'est réellement détruit (c'est-à-dire que l'inode et l'espace disque associés ne sont marqués comme disponibles) que lorsque le nombre de liens est nul. Un premier but de l'invention est d'adapter un tel procédé à la gestion de la mémoire allouée pour des messages destinés à être transmis entre entités fonctionnelles d'un équipement de traitement de données. Pour cela un procédé selon l'invention et tel que décrit dans le paragraphe introductif est caractérisé en ce que: - ledit ensemble de données est un message destiné à être transmis entre entités fonctionnelles dudit équipement de traitement de données, - la valeur dudit compteur de liens est initialisée au nombre d'entités destinataires dudit message, - et ledit compteur de liens est décrémenté lorsqu'une desdites entités a fini de traiter ledit message. Un tel procédé présente l'avantage d'éviter de multiples recopies d'un message en mémoire lorsqu'il est destiné à plusieurs utilisateurs. Il permet de plus de gérer centralement la libération des blocs mémoire alloués pour ces messages. Un autre but de l'invention est de proposer un procédé de séquencement des traitements effectués par des entités fonctionnelles d'un équipement de traitement de données qui utilise pour la transmission de messages entre entités un tel procédé de gestion de mémoire. Pour cela, un procédé de séquencement de traitements selon l'invention est caractérisé en ce qu'il consiste à émettre à destination des entités effectuant lesdits traitements une suite de messages dits messages de séquencement, un message de séquencement de rang i n'étant émis que lorsque le bloc de mémoire alloué pour le message de séquencement de rang inférieur i-l a été libéré. Un autre but de l'invention est de proposer un système de transmission entre au moins deux équipements de traitement de données reliés par un support de transmission, l'un desdits équipements au moins mettant en oeuvre un procédé de gestion de mémoire selon l'invention. Pour cela, un système de transmission selon l'invention est caractérisé en ce que ledit équipement comporte des moyens pour: - en réponse à une requête d'allocation mémoire préalable à l'émission d'un message par une entité, allouer un unique bloc de mémoire destiné à contenir ledit message, - associer audit bloc de mémoire un compteur dont la valeur initiale est égale au nombre d'entités destinataires dudit message et qui est décrémenté lorsqu'une des entités destinataires a fini de traiter ledit message, - libérer ledit bloc de mémoire dès que le compteur associé est nul. Un autre but de l'invention est de proposer un système de transmission entre au moins deux équipements de traitement de données reliés par un support de transmission, l'un desdits équipements au moins mettant en oeuvre un procédé de séquencement de traitements selon l'invention. Pour cela, un système de transmission selon l'invention est caractérisé en ce ledit équipement comporte des moyens pour émettre à destination d'au moins une entité une suite de messages dits messages de séquencement, un message de séquencement de rang i n'étant émis que lorsque le bloc de mémoire alloué pour le message de séquencement de rang inférieur i-l a été libéré. Lesdites entités fonctionnelles sont susceptibles d'être constituées par trois types d'éléments: - des blocs fonctionnels, c'est-à-dire des blocs regroupant un ensemble de commandes permettant de réaliser une fonction déterminée; - des tâches qui manipulent des objets (le terme objet étant pris ici dans le sens qui lui est couramment attribué en conception orientée objets) modélisant les ressources de l'équipement de traitement de données; c'est ce cas qui est plus particulièrement décrit dans la suite de la description; - ou des objets qui modélisent les ressources de l'équipement de traitement de données. D'autres détails, particularités et avantages de la présente invention apparaîtront à la lumière de la description qui va suivre en regard des dessins annexés qui sont donnés à titre d'exemples non limitatifs et dans lesquels: - la figure 1 est une représentation schématique d'un mécanisme de gestion de mémoire selon l'invention, - la figure 2 représente de façon schématique la structure des messages transmis entre objets, - la figure 3 est un représentation schématique d'un mécanisme de communication entre objets, - la figure 4 est un organigramme de fonctionnement d'un procédé selon l'invention, - la figure 5 représente un équipement de traitement de données selon l'invention, - la figure 6 représente un système de transmission selon l'invention, - la figure 7 représente schématiquement un équipement de télécommunications selon l'invention. L'invention s'applique à un équipement de traitement de données dont les ressources sont modélisées d'un point de vue logiciel sous forme d'objets. Ces objets sont créés à partir d'un modèle générique appelé classe qui regroupe des données, appelées attributs, des traitements applicables sur ces données (consultations, modifications...), des notifications devant être émises vers d'autres objets à la suite d'événements déterminés... A chaque création d'un objet, un numéro d'instance dans la classe lui est attribué. L'objet est alors identifié par le numéro de la classe dont il est issu, et par son numéro d'instance dans la classe. Pour chaque classe enfin, un certain nombre de caractéristiques sont définies et enregistrées dans une table, dite table des classes et notée TC, notamment les caractéristiques suivantes: - une référence des fonctions à appeler lors d'une création ou d'une destruction d'un objet de la classe, et lors de la réception d'un message par un objet de la classe, - le nombre maximum d'instances autorisées pour la classe, - la taille des données des objets de la classe. Dans la suite de la description, ledit équipement de traitement de données est doté d'un système d'exploitation tempsréel. Cet aspect temps-réel implique l'existence de plusieurs tâches se déroulant en temps partagé. Les objets sont répartis entre ces différentes tâches, une classe ne pouvant être portée que par une unique tâche, mais une tâche pouvant porter plusieurs classes. Ledit équipement est de plus doté d'un module de gestion de la mémoire M-MEM et d'un module de messagerie M-MESS invocables par toutes ces tâches. Un mécanisme d'échange de messages entre objets va maintenant être décrit à l'aide des figures 1 à 3. D'après la figure 1, lorsqu'un objet expéditeur OE souhaite envoyer un message à un ou plusieurs objets destinataires, il doit préalablement émettre une requête d'allocation de mémoire R(S) vers le module de gestion de mémoire M-MEM en indiquant la taille S de la mémoire nécessaire pour contenir ledit message. Le module de gestion de la mémoire M-MEM détermine, à partir de la taille S du bloc de mémoire demandé, une partition P de la mémoire dans laquelle le bloc devra être choisi. Puis il transmet le numéro NP de cette partition P au système d'exploitation OS qui sélectionne un bloc B de taille S+s dans la partition P de la mémoire dynamique RAMD de l'équipement. Le bloc alloué a une taille S+s supérieure à la taille S demandée par l'objet OE dans sa requête de façon à pouvoir contenir, en plus de la zone utile E2 destinée à contenir le message proprement dit, une zone d'entête El qui contient des informations relatives à la nature du bloc mémoire, et notamment un compteur CPT, dit compteur de liens, dont l'utilisation sera décrite par la suite. La taille de cette zone El est égale à s. La valeur du compteur de liens CPT est initialisée à un lors de l'allocation du bloc mémoire B. Par la suite, elle est modifiée par le module de gestion de la mémoire M-MEM sur requête du module de messagerie M-MESS, si le message inscrit dans le bloc B est un message multi-destinataires. Dans ce cas, le compteur de liens CPT du bloc B prend la valeur du nombre de tâches destinataires du message. Comme on le verra par la suite, il est décrémenté d'une unité à chaque fois qu'une tâche destinataire du message rend la main au module de messagerie après avoir reçu ledit message. Le bloc B associé audit message n'est libéré par le module de gestion de la mémoire M-MEM que lorsque son compteur de liens est nul. Dans ce mode de réalisation, on a choisi de manipuler le compteur de liens par rapport au nombre de tâches destinataires du message et non par rapport au nombre d'objets réellement destinataires du message pour des questions de simplicité de mise en oeuvre. Chaque tâche qui reçoit le message l'envoie pour traitement à tous les objets destinataires du message et le compteur de liens associé n'est décrémenté que lorsque ces objets ont fini leur traitement et que la tâche rend la main au module de messagerie M MESS. Il est toutefois envisageable dans un autre mode de réalisation de manipuler le compteur de liens associé à un message par rapport au nombre d'objets effectivement destinataires de ce message. Une fois le bloc B sélectionné, le système d'exploitation OS retourne au module de gestion de la mémoire M-MEM un pointeur PTB sur le bloc B alloué. Et le module de gestion de la mémoire M-MEM retourne vers l'objet expéditeur OE un pointeur PTU sur la zone utile du bloc B. L'objet expéditeur OE remplit alors la zone utile avec le message à envoyer. La structure des messages échangés entre objets est représentée sur la figure 2. Un tel message comporte une partie entête H et une partie données DT. La partie entête H comporte: - la longueur L du message, - les références de l'objet OD destinataire du message (classe, numéro d'instance), - les références de l'objet expéditeur du message, - un code indiquant la commande CDE que l'on veut exécuter (création, destruction d'objets, modification d'un attribut, notifications...). La partie données DT du message dépend de la commande que l'on veut exécuter. L'exemple de la figure 2 s'applique à une commande de création d'objets ou de modification d'attributs. Dans ce cas, la partie données DT du message comporte le nombre d'attributs NB sur lesquels porte la commande, suivi d'une liste des références REF de ces attributs et de leurs nouvelles valeurs VAL. Un même message peut-être envoyé à plusieurs destinataires. Pour cela, une option "tous destinataires" est indiquée dans les champs classe et/ou instance identifiant l'objet destinataire dans l'entête du message. De plus chaque classe a la possibilité de "s'abonner" à tous les messages tous destinataires en fonction des commandes qu'ils véhiculent. La liste des commandes auxquelles une classe est abonnée constitue l'une des caractéristiques définies dans la table des classes TC: à chaque commande est associée la fonction à appeler lors de la réception d'un message qui véhicule cette commande. Ainsi, comme cela est indiqué sur la figure 3, le message étant inscrit dans la zone utile du bloc alloué B, la tâche T1 qui porte l'objet expéditeur OE transmet au module de messagerie M-MESS une requête R(MESS) d'envoi du message. Le module de messagerie M-MESS analyse les champs classe et instance du destinataire du message. Lorsque le destinataire est un objet déterminé (c'est-àdire lorsque les champs classe et instance du destinataire sont déterminés) et lorsque les destinataires du message sont toutes les instances d'une classe déterminée (c'est-à-dire lorsque l'option "tous destinataire" a été utilisée pour le champ instance seulement), le module de messagerie M-MESS recherche dans une table de correspondance "tâche-classe" de l'équipement (notée TTC) la tâche qui porte ce ou ces objets (cette tâche est nommée T2 sur la figure 3), et écrit le message MESS, par l'intermédiaire du système d'exploitation OS, dans une file d'attente de réception FAR attachée à ladite tâche. Lorsqu'en revanche plusieurs classes sont destinataires du message (c'est-à-dire lorsque l'option "tous destinataires" a été utilisée pour les champs classe et instance), le module de messagerie M-MESS va rechercher dans la table des classes TC celles qui sont abonnées à la commande véhiculée dans le message. Puis il recherche dans la table de correspondance TTC les tâches qui portent ces classes. Il émet alors vers le module de gestion de la mémoire M-MEM une requête de mise à jour du compteur de liens associé au message. Ce compteur de liens est incrémenté du nombre de tâches destinataires du message, moins 1. Le message est ensuite écrit, par l'intermédiaire du système d'exploitation, dans la file d'attente de réception FAR de chacune de ces tâches. Les messages reçus dans les files d'attente de réception des différentes tâches sont traités par le module de messagerie M-MESS (ce qui est symbolisé par la flèche F1 sur la figure 3). Le module de messagerie M-MESS recherche dans la définition de la classe la fonction à appeler selon la commande reçue (cet appel de fonction est symbolisé par la flèche F2). Dès que les traitements correspondant sont terminés, la main est rendue au module de messagerie M-MESS (ce qui est symbolisé par la flèche F3 sur la figure 3) qui émet vers le module M-MEM une requête pour que le compteur de liens soit décrémenté d'une unité. Le mécanisme d'échanges entre objets qui vient d'être décrit est utilisé par le procédé de séquencement de traitements selon l'invention. Ce procédé est par exemple utilisé pour séquencer des traitements qui ne peuvent être effectués que si un certain nombre de données ont été préalablement acquises. Il permet par exemple de garantir que de telles données seront acquises à un instant tn que les traitements sur ces données seront effectués à un instant ton+1, d'autres traitements utilisant les résultats obtenus pouvant alors être effectués à un instant tn+2 et ainsi de suite. Pour cela, le procédé de séquencement selon l'invention consiste à utiliser des messages spécifiques, dits messages de séquencement. Ces messages sont des messages "tous destinataires" qui sont émis par un objet dédié à la gestion des séquencements, vers tous les objets qui y sont abonnés. Un message de séquencement d'ordre i n'est envoyé que lorsque le message de séquencement qui le précède a été traité par tous ses destinataires. Ainsi, si un ensemble d'objets notés OA1 à OAn doit effectuer une séquence donnée de traitements, ils doivent être abonnés à une série Ai de messages de séquencement. Le procédé de séquencement qui est représenté sur la figure 4 peut être initialisé sur réception d'un événement déterminé (ce qui est le cas sur la figure 4, à la case 10) ou de façon cyclique. Le premier message de séquencement Al de la série Ai (à la case 11 l'indice i est initialisé à 1) est émis vers tous les objets OAl à OAn. Pour cela, un bloc mémoire lui est alloué et son compteur de liens est initialisé à 1 (case 12). Puis, à la case 13, la valeur de ce compteur de liens est incrémenté d'une unité, de telle sorte que la valeur initiale du compteur de liens devienne égale à 2. Lors de l'émission du message de séquencement vers les objets destinataires OAl à OAn (case 14), le compteur de liens est incrémenté du nombre de tâches destinataires du message, moins 1. Chaque tâche destinataire rend la main au module de messagerie M MESS lorsque les objets destinataires qu'elle porte ont achevé leur traitement, et le compteur de liens est alors décrémenté d'une unité. Lorsque toutes les tâches ont rendu la main au module de messagerie M-MESS, le compteur de liens a donc la valeur 1 et non la valeur 0 comme pour des messages classiques. Le bloc mémoire correspondant au message de séquencement n'est donc pas libéré systématiquement, et il est possible de réaliser un test sur la valeur de son compteur de liens (case 15). Lorsque le test réalisé à la case 15 indique que le compteur de liens est égal à 1, on sait que tous les objets OA1 à OAn ont fini leur traitements. Le compteur de liens est alors décrémenté d'une unité (case 16) afin de libérer le bloc mémoire alloué au message de séquencement. L'indice i est alors incrémenté à la case 17, et si le test effectué à la case 18 indique qu'il est inférieur ou égal au nombre NA de messages de séquencement de la série Ai, le procédé reprend à la case 12 pour le message de séquencement suivant. Sinon le procédé se termine à la case 19. Ce procédé est particulièrement intéressant car il permet de synchroniser différents traitements entre objets sans impliquer d'échanges de messages entre ces objets: chaque objet effectue indépendamment les traitements qu'il a à effectuer, et la séquence suivante de traitements n'est déclenchée (par l'émission d'un message de séquencement), que lorsque la séquence précédente est achevée. On évite ainsi tout effet "boule de neige" qui résulterait de l'envoi de messages en cascade d'un objet vers d'autres objets et qui risquerait d'entraîner des surcharges ponctuelles, importantes et non contrôlées du point de vue du temps de traitement. Un équipement 100 de traitement de données selon l'invention est décrit à titre d'exemple sur la figure 5. Il est réalisé à base d'un ensemble à microprocesseur 104 qui est par exemple un 68040 de Motorola. Il comporte une première interface 101 destinée à recevoir des données sur un premier port 102 et à les délivrer sur un second port 103 qui est connecté par l'intermédiaire d'un bus 109 au dit ensemble à microprocesseur 104. Il comporte également une seconde interface 108 qui reçoit, sur un premier port 110, par l'intermédiaire du bus 109 auquel il est connecté, les données qui ont été traitées par l'ensemble à microprocesseur 104. L'interface 108 délivre ces données sur un second port 111. L'ensemble à microprocesseur 104 se compose: - d'un microprocesseur proprement dit 105, - d'un bloc de mémoire dynamique 106 qui contient notamment la table des classes TC, la table de correspondance tâche-classe TTC, la mémoire allouée aux différents objets (TO) ainsi qu'aux messages à transmettre (TM), - et d'un bloc de mémoire morte 107 qui contient notamment le code correspondant au système d'exploitation de l'équipement (OS), aux modules M-MEM et M-MESS d'allocation de mémoire et de messagerie, ainsi que les différents programmes nécessaires au fonctionnement de l'équipement et la mise en oeuvre de la présente invention. La figure 6 représente de façon schématique un système de transmission entre au moins deux équipements de traitement de données tels que représentés sur la figure 5, respectivement notés 100a et 100b. Les ports 102a et 102b de ces équipements sont reliés par l'intermédiaire d'un support de transmission 112. Leurs ports lîla et îîîb sont respectivement connectés à des utilisateurs U1 et U2. L'invention est par exemple avantageusement mise en oeuvre dans un équipement de télécommunications dont les ressources de télécommunications sont représentées d'un point de vue logiciel sous forme d'objets, notamment dans l'équipement ADM155 décrit dans l'article "The ADM 155 and the setting up of synchronous access network" publié par N. Dupre La Tour, Y. Guedes et B. Salle dans la revue commutations & transmissions nul, 1992. Cet équipement permet de multiplexer des signaux à 2Mb/s pour former un signal optique à 155Mb/s. La figure 7 donne, à titre d'exemple, une représentation schématique d'un tel équipement. D'après la figure 7, un tel équipement comporte notamment: - deux modules 200 et 300 présentant une interface STM-1 et dont le rôle essentiel est d'assembler et de désassembler les informations qu ils reçoivent ou qu'ils émettent sur un support de transmission à 155Mb/s, - une pluralité de modules 400 présentant une interface à 2Mb/s et dont le rôle est d'assembler en une trame SDH des données reçues à 2Mb/s, - de façon optionnelle, un module de transfert 500 dont le rôle est de transférer des conduits virtuels entre interfaces STM-1 de telle sorte que n'importe quel conduit virtuel d'un signal STM-1 entrant puisse être redirigé vers n'importe quel conduit virtuel d'un signal STM-1 sortant, - au moins un module de supervision 600 dont le rôle est notamment de gérer la configuration de l'équipement, les alarmes et la qualité des communications.Ce module est doté d'au moins une interface vers l'extérieur (dans cet exemple on a représenté une interface de type V24 notée PC vers un poste local qui assure la gestion de l'équipement), et d'une interface de type V24 vers un bus interne 700 assurant la communication entre les différents modules qui viennent d'être mentionnés. On va maintenant décrire un exemple de mise en oeuvre de l'invention dans un tel équipement pour la gestion des alarmes reçues par l'équipement. Les ressources physiques et virtuelles d'un tel équipement sont modélisées par un ou plusieurs objets entre lesquels peuvent exister des liens de dépendance père/fils. Tout objet père est ainsi doté, pour chacun de ses objets fils, d'un attribut spécifique, dit attribut de lien, qui pointe vers cet objet fils de telle sorte qu'il est possible de reconstituer un parcours de liens entre objets. Par ailleurs, ces objets qui modélisent les ressources de l'équipement sont susceptibles d'être dotés d'attributs dits attributs d'alarme et/ou d'attributs dits attributs de synthèse d'alarmes. Un attribut d'alarme prend une valeur parmi six niveaux d'alarme possibles: un niveau critique, un niveau majeur, un niveau mineur, un niveau information, une alarme inconnue, une absence d'alarme. Un attribut de synthèse d'alarmes est un tableau de six éléments associés chacun à l'un des niveaux d'alarme précités. Chaque élément indique si parmi les objets dépendant de l'objet concerné il existe au moins un attribut d'alarme dudit niveau. Ces objets dépendant sont déterminés en reconstituant un parcours de liens à l'aide des attributs de liens des différents objets. Pour gérer les alarmes reçues par l'équipement une séquence de traitements est déclenchée cycliquement, par un objet dédié qui est implanté au niveau du module 600, pour détecter ces alarmes afin de pouvoir ensuite les traiter. Les objets de l'équipement qui sont concernés par la gestion des alarmes sont donc abonnés à ladite séquence de traitement. Sur réception du premier message de séquencement de la séquence, ils mettent à jour leurs attributs d'alarme. Cette mise à jour consiste pour chacun d'eux à constater l'arrivée à échéance d'une temporisation, lorsqu'une alarme est détectée, avant de modifier l'attribut d'alarme correspondant, afin d'éviter que des parasites ne soient interprétés comme un signal d'alarme. Ainsi, l'alarme ne sera prise en compte que si elle est toujours présente lorsque la temporisation est écoulée. Une fois les attributs d'alarme mis à jour, ces objets réalisent une synthèse locale des états d'alarme, c'est-à-dire qu'ils mettent à jour leur attributs de synthèse d'alarmes. Les objets concernés par ces mises à jour sont tous les objets qui symbolisent une transmission au niveau de l'équipement ainsi que les objets dits objets modules qui représentent les différents modules physiques de l'équipement. Lorsque tous ces objets ont mis leurs attributs à jour, un second message de séquencement est émis. Sur réception de ce message, lesdits objets modules effectuent une synthèse des états d'alarmes de tous les objets qu'ils englobent. Cette synthèse consiste à mettre à jour les attributs de synthèse d'alarmes de chaque objet module, en recherchant, pour chacun des six niveaux d'alarme définis, parmi tous les objets dépendant, s'il existe au moins une alarme dudit niveau. Par exemple, les objets modules qui représentent les modules 200 et 300 sont chacun dotés d'un attribut de synthèse d'alarmes relatif à l'ensemble des objets qu'ils englobent et qui symbolisent une connexion STM-1. De même, les objets qui représentent les modules 400 sont dotés d'un attribut de synthèse d'alarme par connexion 2Mb/s. Lorsque ces traitements sont terminés, un troisième message de séquencement est émis. Sur réception de ce troisième message, l'objet qui représente l'équipement effectue une synthèse des états d'alarme parmi tous les objets modules de l'équipement. Dans cet exemple, chaque synthèse des états d'alarme utilise les résultats obtenus à l'étape précédente du procédé de séquencement: la synthèse des états d'alarme au niveau des objets modules utilise les résultats des mises-à-jour effectuées sur réception du premier message de séquencement et la synthèse au niveau de l'équipement utilise les résultats des synthèses effectuées par les objets modules. Le procédé de séquencement selon l'invention permet donc de garantir que l'ensemble des données qui servent à effectuer les synthèses des états d'alarme à chaque étape soient disponibles lorsque une synthèse est déclenchée à l'étape suivante. Il va de soi que l'invention n'est pas limitée aux modes de réalisation et aux applications qui viennent d'être décrites à titre d'exemple. Le procédé de gestion de mémoire et le procédé de séquencement qui en découle sont applicables à tout type d'équipements de traitement de données, et à des entités fonctionnelles constituées soit par des blocs fonctionnels soit par des tâches portant des objets soit à des objets. REVENDICATIONS 1. Procédé de gestion d'une mémoire d'un équipement de traitement de données, ladite mémoire étant composée de blocs de mémoire, et ledit procédé consistant à: - allouer, pour la sauvegarde d'un ensemble de données, un unique bloc de mémoire, - lui associer un compteur dit compteur de liens, - libérer ledit bloc de mémoire lorsque ledit compteur de lien est nul, caractérisé en ce que: - ledit ensemble de données est un message destiné à être transmis entre entités fonctionnelles dudit équipement de traitement de données, - la valeur dudit compteur de liens est initialisée au nombre d'entités destinataires dudit message, - et ledit compteur de liens est décrémenté lorsqu'une desdites entités a fini de traiter ledit message. 2. Procédé de séquencement d'une pluralité de traitements effectués par des entités fonctionnelles d'un équipement de traitement de données, qui utilise pour la transmission de messages entre entités un procédé de gestion de mémoire selon la revendication 1, caractérisé en ce qu'il consiste à émettre à destination des entités effectuant lesdits traitements une suite de messages dits messages de séquencement, un message de séquencement de rang i n'étant émis que lorsque le bloc de mémoire alloué pour le message de séquencement de rang inférieur i-l a été libéré. 3. Système de transmission entre au moins deux équipements de traitement de données reliés par un support de transmission, l'un au moins desdits équipements étant doté d'une pluralité d'entités fonctionnelles et comportant des moyens de communication entre entités par échange de messages, caractérisé en ce que ledit équipement comporte des moyens pour: - en réponse à une requête d'allocation mémoire préalable à l'émission d'un message par une entité, allouer un unique bloc de mémoire destiné à contenir ledit message, - associer audit bloc de mémoire un compteur dont la valeur initiale est égale au nombre d'entités destinataires dudit message et qui est décrémenté lorsqu'une des entités destinataires a fini de traiter ledit message, - libérer ledit bloc de mémoire dès que le compteur associé est nul. 4. Système de transmission selon la revendication 3, caractérisé en ce que ledit équipement comporte des moyens pour émettre à destination d'au moins une entité une suite de messages dits messages de séquencement, un message de séquencement de rang i n étant émis que lorsque le bloc de mémoire alloué pour le message de séquencement de rang inférieur i-1 a été libéré. 5. Système de transmission de données selon l'une des revendications 3 ou 4, caractérisé en ce que lesdites entités fonctionnelles sont des blocs fonctionnels. 6. Système de transmission de données selon l'une des revendications 3 ou 4, caractérisé en ce que lesdites entités sont des tâches qui portent des objets modélisant les ressources dudit équipement de traitement de données. 7. Système de transmission selon l'une des revendication 3 ou 4, caractérisé en ce que lesdites entités sont des objets modélisant les ressources dudit équipement de traitement de données. 8. Equipement de traitement de données destiné à être utilisé dans un système de transmission selon l'une des revendications 3 à 4.