FR 2986344 A1 20130802 FR 1250810 A 20120127 DOMAINE TECHNIQUE GENERAL La présente invention se rapporte au domaine des architectures parallèles. Plus précisément, elle concerne un procédé d'exécution parallèle d'une pluralité de tâches élémentaires informatique. ETAT DE L'ART Les architectures parallèles sont devenues le paradigme dominant des systèmes informatiques depuis quelques années, le traitement simultané d'une pluralité de tâches démultipliant des performances. Cependant, l'un des problèmes que le parallélisme pose est l'apparition de situations dites de « concurrence ». Toutes les tâches ne peuvent en effet pas être exécutées simultanément, car le plus souvent certaines tâches ont besoin du résultat d'autres tâches pour pouvoir être exécutées. Il est ainsi nécessaire de disposer de mécanismes dits « de synchronisation », qui visent à bloquer l'exécution des différentes tâches à 20 des points précis de leur exécution de manière à ce que toutes les tâches passent les étapes bloquantes au moment prévu par le programmeur. Des solutions simples de synchronisation existent, par exemple basées sur des cycles : une pluralité de tâches compatibles sont lancées de façon synchronisée à chaque cycle. Un tel mécanisme apporte satisfaction, 25 mais limite nettement les possibilités du parallélisme, puisque chaque unité de traitement est inactive entre le moment où elle finit une tâche et le début du cycle suivant. Alternativement, des mécanismes proposent des utilisations de verrous et/ou de sémaphores. Les verrous permettent de bloquer puis 30 libérer des tâches lors des synchronisations en fonction des valeurs des sémaphores. Ces mécanismes permettent de meilleures performances, mais sont particulièrement complexes à gérer. Certains ordonnancements particuliers de tâches peuvent en outre poser un problème. Par ailleurs tous les mécanismes connus nécessitent que le programmeur maîtrise et prévoie quand les synchronisations doivent avoir lieu. Une dernière solution consiste en l'utilisation du système dit « transactionnel » qui évite le souci de la synchronisation mais au prix de performances bien moindres. Il y a donc un besoin en un nouveau procédé d'exécution parallèle qui permette de s'affranchir de la contrainte de synchronisation tout en permettant une utilisation optimale des processeurs (ou des coeurs). PRESENTATION DE L'INVENTION La présente invention vise à résoudre ces difficultés en proposant un procédé qui présente en deux parties l'appel d'une fonction ou d'une méthode destinée à fonctionner parallèlement à celui du processus initiateur. L'ensemble de ces deux parties est appelé P-instruction pour souligner son caractère « parallèle ». La première partie d'une P-Instruction est la demande qui initialise la tâche parallèle et met en place automatiquement le procédé de synchronisation. La seconde partie exploite cette synchronisation et donne le résultat de la fonction ou de la méthode. Entre les appels de ces deux éléments, le processus initiateur continue de fonctionner parallèlement au déroulement de la fonction ou de la méthode. Ainsi, l'invention concerne un procédé d'exécution parallèle d'une pluralité de tâches informatiques par une pluralité d'unités de traitement de données connectées, chaque tâche étant une action élémentaire exécutable par une des unités de traitement de données, le procédé étant caractérisé en ce qu'il comprend des étapes de : (a) Association à au moins une tâche (T) d'une première instruction et d'une deuxième instruction, la première instruction étant une instruction non-bloquante de demande de l'exécution de la tâche (T) et la deuxième instruction étant une instruction bloquante de retour du résultat de l'exécution de la tâche (T) ; (b) Lancement au plus tôt de la première instruction de la tâche (T) et exécution de la tâche (T) par une des unités de traitement de données ; (c) Lancement de la deuxième instruction.de la tâche (T) de 10 façon synchrone avec la demande d'exécution d'une deuxième tâche (T2) ayant une contrainte de dépendance vis-à-vis de la première tâche (T). Selon d'autres caractéristiques avantageuses et non limitatives de l'invention : 15 - les unités de traitement de données sont connectées via un bus applicatif, l'étape (a) étant mise en oeuvre par le bus applicatif ; - chaque tâche est soit d'un premier type, soit d'un deuxième type, chacune des tâches du premier type, dites « tâches parallèles », étant exécutée de façon conforme aux étapes (a) à (c), et chacune des tâches du 20 deuxième type, dites « tâches simples », étant exécutée directement par une des unités de traitement de données ; - l'enchaînement de ladite pluralité de tâches forme un processus, les tâches étant ordonnées en fonction d'éventuelles contraintes de dépendance vis-à-vis d'autres tâches, le procédé d'exécution parallèle 25 respectant l'ordre indiqué par la table d'ordonnancement ; - l'exécution d'une tâche utilise une zone d'une mémoire partagée entre les unités de traitement de données, ladite zone de mémoire étant affectée à la tâche par le bus applicatif au lancement de la première instruction associée à la tâche, et libérée au lancement de la deuxième instruction 30 associée à la tâche ; - sont en outre affectés à la tâche un sémaphore indiquant un état de blocage de la tâche et une file d'attente, le sémaphore étant modifié de sorte à indiquer un état de libération de la tâche lorsque le bus applicatif constate que ladite zone de mémoire partagée affectée est libre et/ou que la tâche est passée en tête de la file d'attente ; - la zone de mémoire partagée est une partition d'un premier bloc de mémoire partagée, un descripteur de la zone de mémoire partagé étant stocké dans un deuxième bloc de mémoire partagé, ledit deuxième bloc étant dédié au stockage de descripteurs du premier bloc de mémoire partagée. Selon un deuxième aspect, l'invention concerne un système comprenant une pluralité d'unités de traitement de données mettant en oeuvre le procédé selon le premier aspect de l'invention, au moins une mémoire connectée à une unité de traitement de données, et une entrée recevant la pluralité de tâches à exécuter. PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - la figure la représente une architecture de trois bus applicatifs interconnectés via leurs noyaux NBA ; - la figure 1 b représente une interconnexion de deux applications parallèles via leur terminal respectif de bus applicatif ; - la figure 2 représente le mécanisme de demande/réponse sur un canal automatiquement synchronisé - la figure 3 représente deux cas possibles dans le mécanisme de demande/réponse.30 DESCRIPTION DETAILLEE D'UN MODE DE REALISATION Architecture de bus applicatif En référence aux figures, le procédé d'exécution parallèle d'une pluralité de tâches informatiques selon l'invention se fait de façon particulièrement avantageuse en utilisant un bus applicatif. On comprendra qu'il n'est pas limité à ce mode de réalisation et peut par exemple tout à fait fonctionner au niveau d'un serveur comportant un processeur à plusieurs coeurs, par conséquent éligible au parallélisme. A l'instar des ESB (bus de services d'entreprise), ce bus a avant tout pour fonction de permettre la communication des applications qui à la base ne sont pas pensées pour fonctionner ensemble. L'architecture du Bus Applicatif (BA) est physiquement répartie sur une constellation de machines. Elle comporte avantageusement les éléments logiciels suivants : - le Noyau du Bus Applicatif (NBA) idéalement hébergé par une machine dédiée (il n'est pas obligatoire pour les petites et moyennes configurations), chargé de dispatcher et d'ordonnancer les commandes et échanges de données en fonction des priorités, - un Multiplexeur de Bus Applicatif (MBA) par système d'exploitation (en d'autres termes par machine hôte), gérant les ressources partagées (en particulier la ou les unités de traitement, l'espace mémoire, etc.), - un Terminal de Bus Applicatif (TBA) par application, ce terminal pouvant être un Terminal Maître (Tm) si l'application est directrice ou un Terminal Esclave (Ts) si l'application est contrôlée. Comme représenté sur la figure 1 a, un bus applicatif peut être interconnecté à un ou plusieurs autres bus via leur noyau (NBA) respectif. Une constellation de machines gérée par un BA sans noyaux ne peut pas être reliée à une autre constellation. Les connexions sont par exemple mise en oeuvre sous protocole standard (TCP/IP, ...) avantageusement via des ports facilement admis par les pare-feu, serveurs de domaines et passerelles classiques, sous procédure hautement sécurisée. Au niveau d'une machine, le BA n'est accessible par une application que via un TBA connecté au MBA local, comme représenté par la figure 1 b. Chaque application peut lancer des threads et demander au BA de leur fournir également un terminal dédié ce qui permet à deux threads d'interagir. D'un point de vue pratique chaque terminal est capable d'exploiter en parallèle des demandes-réponses sur des canaux différents. Une « pompe 10 à messages » dédiée permet à ce terminal de prévenir de l'arrivée de données sur tel ou tel canal en provenance de tel ou tel autre terminal. Des applications récentes et/ou adaptées au BA (applications « natives ») peuvent communiquer avec le BA en direct au niveau de leur TBA. Alternativement, les anciennes applications qui ne connaissent pas ce 15 BA sont avantageusement prises en charge (applications « pilotées ») par des interfaces spécifiques de chacune de ces applications, chargées de leur offrir l'adaptation spécifique leur permettant d'intégrer un TBA : les CIA (communication interactive par automate). Un CIA est une sorte de pilote d'accueil disposant des ressources nécessaires aux applications 20 connectées aux terminaux de bus. Chaque TBA dispose d'une pluralité de canaux de communication avec son application, canaux via lesquels sont faites les demandes d'exécution d'une tâche et le retrait des réponses. A chaque type de demande/réponse, on associe un canal unique. De cette manière, plusieurs 25 échanges peuvent se dérouler en parallèles puisque les canaux seront complètement indépendants. Le BA offre ainsi la possibilité d'un traitement massivement parallèle de tout processus dont l'exécution est demandée dans un environnement multi-machines multi-coeurs indépendamment des systèmes d'exploitation. 30 Au niveau local de chaque machine, la communication et l'échange de données entre les différents processus est basée sur le standard IPC. Les échanges sont sécurisés indépendamment pour chaque Tba. Le MBA gère les ressources IPC, possède un « ramasse-miettes » et offre un dispositif de reprise sur erreur dont la mise en oeuvre reste à la discrétion du programmeur. Fonctionnement d'une P-instruction Un processus dont l'exécution est demandée est composé d'une pluralité de tâches informatiques. Ces tâches sont des actions élémentaires 10 exécutables chacune par une des unités de traitement de données (d'où la possibilité de traitement massivement parallèle). Comme on verra plus tard, ces tâches ne peuvent le plus souvent pas être exécutées indépendamment à cause des contraintes de dépendance, et doivent être ordonnancées. Comme l'on voit sur la figure 2, le principe de l'invention est 15 « séparer » en deux parties l'exécution d'une tâche destinée à fonctionner parallèlement vis-à-vis du processus initiateur. L'ensemble de ces deux parties est appelé P-instruction pour souligner son caractère « parallèle ». La première partie d'une P-Instruction est la « demande » qui initialise la tâche parallèle et met en place automatiquement la tâche 20 chargée des échanges parallèles et son procédé de synchronisation. La seconde partie, appelée « retour » ou « réponse », exploite cette synchronisation et donne le résultat de l'exécution de la tâche. Entre les appels de ces deux éléments, le processus initiateur continue de fonctionner parallèlement au déroulement de l'exécution. 25 Plus précisément, le procédé selon l'invention comprend des étapes de : (a) Association à au moins une tâche T d'une première instruction et d'une deuxième instruction, la première instruction étant une 30 instruction non-bloquante de demande de l'exécution de la tâche T et la deuxième instruction étant une instruction bloquante de retour du résultat de l'exécution de la tâche T ; (b) Lancement au plus tôt de la première instruction de la tâche T et exécution de la tâche T par une des unités de traitement de données ; (c) Lancement de la deuxième instruction.de la tâche T de façon synchrone avec la demande d'exécution d'une deuxième tâche T2 ayant une contrainte de dépendance vis-à-vis de la première tâche T. Un tel procédé permet au programme appelant de continuer à fonctionner tant qu'il n'a pas besoin d'avoir le résultat d'une demande, i.e. tant qu'il n'y a aucune demande d'exécution d'une deuxième tâche ayant une contrainte de dépendance vis-à-vis de la première tâche, c'est-à-dire dont l'exécution est subordonnée au résultat de la première tâche (si la deuxième tâche est une tâche de type « P-instruction », on comprend que la demande d'exécution est le lancement d'une première instruction). Il devient possible de faire de la programmation « anticipée » et d'optimiser l'emploi des processeurs. Le lancement de la première partie de la P-Instruction est en effet mis en oeuvre « au plus tôt », c'est-à-dire avant même que le résultat de la tâche ne soit effectivement nécessaire. On peut par exemple commander l'ouverture d'un dialogue en prévision de son utilisation. Au moment de sa réelle utilisation l'usager aura une impression d'instantanéité d'ouverture. Le lancement « au plus tôt » va à l'encontre des stratégies connues de traitement parallèle où on attend toujours d'avoir besoin d'un résultat pour le commander. En effet, traditionnellement le « retour » suite à l'exécution d'une tâche fait immédiatement suite à la fin de l'exécution de la tâche. En d'autres termes, l'intervalle de temps entre la « demande » et le « retour » est toujours égal à la durée d'exécution de la tâche dans les procédés connus puisque ces deux parties ne sont pas séparées. La synchronisation se fait en retardant le lancement d'une « demande ». Au contraire dans le procédé selon l'invention, la « demande » n'attend pas (ou du moins le moins possible), c'est le « retour » qui est retardé jusqu'au moment où le résultat de l'exécution est effectivement nécessaire. Cela est rendu possible par la séparation en deux parties des P-Instructions qui décorrèle la « demande » et le « retour » et permet de ne pas être lié par la durée réelle d'exécution de la tâche. Deux cas, représentés par la figure 3, apparaissent : soit l'anticipation est inférieure à la durée d'exécution de la tâche T (figure de gauche), en d'autres termes une autre tâche T2 requiert le résultat de l'exécution de la tâche T avant la fin de son exécution (c'est ce que l'on appelle un « appel sans précaution »), et dans ce cas là l'instruction de retour est lancée dès la fin de l'exécution de la tâche ; soit l'anticipation est suffisante (figure de droite), en d'autres termes aucune autre tâche Ti ne requiert le résultat de l'exécution de la tâche T avant la fin de son exécution (c'est ce que l'on appelle un « appel anticipé »), et dans ce cas là le lancement de l'instruction de retour est retardé. La demande d'exécution de l'autre tâche T2 déclenche instantanément le lancement de l'instruction de retour de la première tâche T, d'où une synchronisation naturellement automatique. En lançant toujours « au plus tôt » les instructions de demandes, le procédé selon l'invention maximise le nombre « d'appels anticipés » et minimise le nombre « d'appels sans précaution ». Avantageusement, il n'y a plus que des appels anticipés. L'utilisation des P-Instructions résout ainsi la synchronisation systématique et provoque une accélération spectaculaire pour l'utilisateur. En outre, le lancement « au plus tôt » permet d'exploiter les unités de traitement de données de façon mieux répartie dans le temps. En anticipant les appels, on augmente l'utilisation des ressources système à des périodes « creuses », et par conséquent, on diminue l'engorgement dans les pics d'utilisation. Toutes les tâches informatiques peuvent faire l'objet d'un couple de P-Instructions. Avantageusement, il y a deux types de tâches : - chacune des tâches du premier type, dites « tâches parallèles », fait l'objet d'un couple de P-Instructions et est exécutée de façon conforme aux étapes (a) à (c) du procédé présentées ci-avant ; - chacune des tâches du deuxième type, dites « tâches simples », est exécutée directement par une des unités de traitement de données. Les tâches simples sont des tâches courantes d'exécution très rapide pour lesquelles la mise en oeuvre du parallélisme massif n'a que peu d'intérêt. Fonctionnement d'une P-Instruction au sein du Bus Applicatif Comme expliqué précédemment, les unités de traitement de données sont avantageusement connectées via un BA, l'étape (a) du procédé est alors mise en oeuvre par le BA. On répète que cette disposition est applicable pour tous les processus dits « serveurs » et ne se limite pas qu'au Bus Applicatif. A titre d'exemple dans le cas d'un BA, le lancement d'un thread parallèle ainsi que la synchronisation automatique sont obtenus de la manière suivante : Toute instruction de demande est immédiatement acquittée et retourne un drapeau à trois états : 0 si la demande est acceptée, 1 si elle est interdite (pas de droit, pas de destinataire, ...), 2 si il y en a déjà une en attente en attente d'acquittement. Ce drapeau est élaboré par l'API (l'ensemble des méthodes que possède un TBA). Exemple : int icr=pTm->BaLogin(cNom, cPasswd) ; Le retour est immédiat avec icr=0 si le logeage (« login ») est en cours, 1 si le MBA est absent, et 2 si la demande est déjà en cours. [Lors de la mise au point le retour -1 signifie un mésusage.] Lorsque le retour de la P-instruction est requis par le programme appelant, il est obtenu par la « synchro » formée du nom de la demande complété du suffixe Ret. Exemple : int icr=pTm->BaLoginRet( ) ; Si le login est bien réalisé, icr=0 ; si il est refusé, icr=code retour erreur. L'interpréteur YAL (« Yet A Language ») est particulièrement bien adapté à l'utilisation des P-instructions. Par exemple, voici un extrait d'automate qui ouvre simultanément deux boîtes de dialogue, le traitement de texte Word, le tableur Excel. Les applications de Microsoft sont exécutées en tâches de fond, sauf word qui est montré une fois le montage du document fait afin d'autoriser toute retouche par l'usager. §word -MWord "fichier.docx" ^ lancement Word sur un document en mode caché §excel -MExcel "fichier.xlsx" ^ lancement Excel sur un document en mode caché §actA -MdlgA appel d'un dialogue A en mode caché §actB -Md1gB appel d'un dialogue B en mode caché §actA -C consignes consignes pour activité A §actB -C consignes consignes pour activité B repA -§actA -C visu ouverture du dialogue ; acquisition nom client repB -§actB -C visu ouverture du dialogue ; acquisition de l'adresse §excel -C consigne recherche repA -C consigne extraction données (somme due) repE -§excel ^ extraction « Somme due » de Excel §word -RD "NOM CLIENT" ^ positionnement curseur repA ^ insertion du nom -RD " M ON T AN T " ^ positionnement curseur repB ^ insertion somme due -C visu ouverture du traitement de texte mode visible Repw -§word a attente sortie du traitement de texte. & R a fermeture automatique des activités en sortie. Exécution d'un processus Des méthodes performantes pour découper un processus en une pluralité de tâches et les ordonnancer en vue de leur exécution parallélisée par les différentes unités de traitement de données (processeurs, coeurs, 20 25 30 35 etc.) sont connues. On se réfèrera par exemple aux demandes de brevet FR 2963125 et FR 2963126. Si on a un processus écrit sous la forme d'un enchaînement de tâches, chaque tâche étant une action élémentaire exécutable par une unité de traitement donnée à laquelle ledit bus applicatif est connecté, les tâches étant ordonnées en fonction d'éventuelles contraintes de dépendance vis-à-vis d'autres tâches, il est possible d'exécuter le processus de façon parallélisée à condition de respecter l'ordre d'ordonnancement pour l'exécution des tâches. L'invention propose ainsi un procédé d'exécution parallèle d'un processus informatique formé par l'enchaînement de ladite pluralité de tâches, les tâches étant ordonnées en fonction d'éventuelles contraintes de dépendance vis-à-vis d'autres tâches, le procédé d'exécution parallèle respectant l'ordre indiqué par la table d'ordonnancement. En d'autres termes, le procédé d'exécution parallèle met en oeuvre pour tout ou partie des tâches un couple de P-Instructions respectant l'ordre indiqué par la table d'ordonnancement. Mémoires partagées L'exécution d'une tâche, mise en oeuvre suite au lancement de la première instruction associée à la tâche (la P-instruction de demande), nécessite un espace mémoire, en particulier mémoire vive. Si par exemple chaque unité de calcul dispose d'un espace de stockage propre (on parle de mémoire « distribuée »), alors il n'y a aucun obstacle à l'exécution immédiate de la tâche par l'unité de traitement de données désignée en utilisant sa mémoire dédiée. Ce système de mémoire distribuée est toutefois inutilement cher -car il faut prévoir en n exemplaires une mémoire de taille surdimensionnée pour éviter des problèmes de dépassement de capacité (« overflow »)-, et nécessite que soit prévu un lourd système de communication entre les mémoires. C'est pourquoi avantageusement on trouve la mémoire dite « partagée », c'est-à-dire co-utilisée par les différentes unités de calcul, ce qui évite les inconvénients susmentionnés. Ainsi, l'exécution d'une tâche utilise une zone de la mémoire partagée entre les unités de traitement de données, ladite zone de mémoire étant affectée à la tâche au lancement de la première instruction associée à la tâche, et libérée au lancement de la deuxième instruction associée à la tâche. L'accès à une même mémoire par deux processus ou plus nécessite cependant quelques précautions. D'un point de vue matériel, il est nécessaire d'interdire la lecture d'une zone de mémoire si une autre tâche est en train de la réécrire sous peine de lire un curieux mélange, et réciproquement. Le processus de lecture est en effet plus rapide que celui d'écriture. En outre, deux écritures simultanées ne peuvent être autorisées, sinon on risque une situation de « concurrence », dont le résultat est imprévisible. Seules deux lectures simultanées ne posent pas de problème. En d'autres termes, dans une telle situation, l'exécution à proprement parler de la tâche ne suit pas nécessairement instantanément le lancement de la P-instruction de demande : la zone de mémoire affectée peut devoir être « verrouillée » le temps qu'elle puisse être libérée en toute sécurité. La solution IPC pour le partage sécurisé d'une information nécessite un triplet de « descripteurs » de la tâche : - Une mémoire proprement dite (en d'autres termes un « bloc »), de longueur quelconque, - Un dispositif de demande d'accès composé d'une queue de message (où les tâches demanderesses viennent « prendre leur tour » en file d'attente), - Un dispositif d'autorisation d'accès et de synchronisation : « un sémaphore ». Le fonctionnement d'un triplet décrit ci-avant est le suivant : la tâche désireuse d'utiliser une mémoire dépose sa demande dans la file d'attente correspondante. Elle spécifie l'action (lecture/écriture) et le sémaphore de protection, sorte de feu rouge/vert qui permet de savoir si la mémoire peut être lue/écrite. La tâche est bloquée par ce sémaphore et n'est débloquée par le BA qui libère le sémaphore que lorsque la mémoire est prête à être utilisée et/ou que c'est le tour de la dite tâche d'y accéder. Si la P-instruction de demande a été lancée suffisamment tôt, cet éventuel délai d'attente est complètement invisible. Le procédé selon l'invention permet ainsi de mieux répartir dans le temps l'utilisation de la mémoire, d'où des performances spectaculaires même avec des mémoires peu volumineuses. Si IPC est actuellement insuffisant pour gérer plus d'une dizaine de machines, c'est que les procédés actuels d'utilisation de la mémoire utilisent un triplet par canal. A supposer une constellation de 10 machines Linux ayant en moyenne 4 TBA offrant chacun eux-mêmes 40 canaux, on obtient un besoin de 1600 blocs de mémoire et autant de sémaphores et files d'attentes. Or ce sont ces dernières qui posent problème, puisque la limite maximum de files de messages est de 1649. On remarque également que plus du tiers du nombre maximum (4096) de blocs mémoires sont déjà utilisés, alors que dans la majorité des cas seule une infime fraction de leur espace alloué est réellement exploitée. Bien entendu les limites indiquées sont ajustables pour tous les systèmes : on peut modifier ces valeurs et recompiler le noyau du SE. Mais cette manipulation et les dangers qu'elle présente laisse démunis les utilisateurs qui sont très rarement spécialistes des systèmes d'exploitation et bien plus préoccupés par leur processus métier. Le procédé selon l'invention permet avantageusement de multiplier sensiblement le nombre de machines gérable par IPC sans dépasser pourtant ces limites. L'idée est que tous les canaux d'un TBA se partagent seulement quelques queues de messages, voire une seule, et surtout se partagent la même unique grande mémoire comprenant un ensemble de zones relatives chacune à un canal. La limite en termes de sémaphores (32000) ne pose quant à elle pas de problèmes puisque les sémaphores sont réutilisables. Ainsi, des constellations de plusieurs centaines de machines deviennent possibles. L'autre grande différence par rapport aux solutions classiques est que le programmeur n'a plus à se soucier ni de sockets, ni de 5 synchronisation ni de gestion des échanges. Le MBA prend tout ceci en charge. Le fait d'avoir une unique file d'attente par TBA ne pose pas de gros problèmes : il suffit que le BA ait instruction de traiter immédiatement toute demande de la part d'une tâche (ce qui est le principe d'une P-instruction de 10 demande), de sorte à vider la file (qui est de type FIFO) le plus rapidement possible. En revanche, la gestion « multi-canaux » de la mémoire est plus complexe. La demanderesse a remarqué que le rapport entre le nombre 15 maximum de files d'attente de messages et celui du nombre de blocs de mémoire partagées est supérieur à deux. Cela permet d'associer à chaque file (et donc à chaque TBA) deux blocs mémoires. Pour pouvoir mettre en oeuvre ce procédé, la mémoire partagée associée à un TBA est composée de deux parties, une partie dédiée au 20 stockage des données des tâches à proprement parler (données sur lesquelles les unités de traitement agissent lors de l'exécution d'une tâche), et une partie dédiée au stockage de descripteurs de la structure de la première partie. En d'autres termes, le premier bloc associé au TBA est dédié au 25 stockage des données des tâches et il est appelé « bloc de données », et le second bloc associé au TBA est dédié au stockage des descripteurs, et est quant à lui appelé « bloc descriptif ». Ainsi, au lieu d'associer un bloc mémoire IPC complet à un canal du TBA, on associe une partition du premier bloc, les données permettant 30 d'identifier cette partition (le « descripteur » de cette partition) étant stockées dans le second bloc. Le lancement de la P-Instruction de demande est ainsi suivie par l'affectation par le bus applicatif à la tâche d'un triplet de ressources (IPC) comprenant un sémaphore, une zone de mémoire partagée et une file d'attente, le sémaphore indiquant un état de blocage de la tâche, la zone de mémoire partagée étant une partition d'un premier bloc de mémoire partagée, un descripteur de la zone de mémoire partagé étant stocké dans un deuxième bloc de mémoire partagé, ledit deuxième bloc étant dédié au stockage de descripteurs du premier bloc de mémoire partagée. Lorsque le bus applicatif constate que ladite zone de mémoire partagée affectée est libre (i.e. qu'une tâche précédente n'en a déjà plus besoin) et/ou que la tâche est passée en tête de la file d'attente, le sémaphore est modifié de sorte à indiquer un état de libération de la tâche. La zone mémoire est alors disponible pour utilisation par l'unité de traitement de données affectée pour l'exécution de la tâche, sans risque que cette utilisation soit perturbée par une autre tâche. Il est à noter que lorsque la mémoire est disponible, elle n'est pas forcément immédiatement utilisée. De façon particulièrement avantageuse, le premier bloc de mémoire partagée est structuré en un ensemble d'unités de taille égale appelées « pages » référencées chacune par un indice, la partition de la mémoire partagée affectée en tant que zone de mémoire partagée pour la tâche étant un ensemble de pages, ledit descripteur de la zone de mémoire partagée étant une table de pages contenant les indices des pages composant ladite partition. En d'autres termes, les espaces d'allocation sont considérés comme étant un espace non-contigü, c'est ce que l'on appelle la pagination. Le principe de la pagination consiste à structurer l'espace mémoire en un ensemble d'unités de taille égales appelées pages. L'espace mémoire attribué à une partition se composera alors d'un ensemble de pages qui ne sont pas forcément successives. Une partition n'est plus identifiée par son adresse de départ et sa taille mais par l'ensemble des pages qui la compose, ces pages peuvent être organisées sous forme de table appelée table des pages qui décrit la référence à la partition. Systèmes L'invention propose selon un deuxième aspect des systèmes pouvant mettre en oeuvre un procédé selon le premier aspect de l'invention. La première fonctionnalité demandée au bus applicatif est d'assurer l'acheminement de toutes les données entre tous les acteurs de toutes les configurations interconnectées. Tous les acteurs peuvent être rassemblés dans une seule station, l'unité de traitement du bus applicatif étant celle de la station. Dans ce cas là, le système selon l'invention comprend la station de travail, celle-ci comprenant tout d'abord des moyens d'affichage de données et des moyens de saisie de données. Il peut s'agir classiquement d'un écran et d'un clavier avec une souris. Ce matériel sert tout simplement à mettre en oeuvre une ou plusieurs interfaces homme-machine permettant à un utilisateur d'interagir avec le BA, éventuellement en fournissant des processus à exécuter. Le système selon l'invention comprend également une unité de traitement de données, qui est l'unité reliée au bus applicatif, et une mémoire. Pour que le système ait un intérêt, l'unité de traitement doit être de préférence un processeur multicoeur (dans ce cas on la comprendra comme une pluralité d'unité de traitement), c'est-à-dire un processeur qui pourra tirer parti de l'exécution parallèle. La mémoire est avantageusement une unique mémoire partagée. Cette station de travail héberge le NBA s'il y en a un. Alternativement le système selon l'invention peut ne pas se contenter d'une seule station de travail, mais comprendre comme expliqué précédemment au moins une machine partenaire. Il peut en outre y avoir plusieurs stations de travail contrôlées par des utilisateurs, les différentes stations ayant chacune une unité de traitement et utilisant les mêmes machines partenaires autour d'un bus applicatif unique. Le bus applicatif sert de Multiples Stations (usagers) et de Multiples Partenaires (automates) en configuration dite MSMP. Il fonctionne en diverses configurations dites « dégradées » Simple/Multiple Station/Partenaire SSSP, SSMP, MSSP et MSMP. Enfin, le bus applicatif est capable dans toute la mesure du possible de prendre en charge les liaisons du type temps réel nécessaires à certains dispositifs (périphériques, commande de chaînes de production, ...). Il offre ainsi une passerelle entre le monde industriel et le monde du bureau par exemple pour obtenir un tableau temps réel de la production. Le bus utilise la connectique et les supports physiques existants entre les machines de types habituellement utilisés (serveur de fichiers, serveur Web, Serveur d'applications, etc.). En particulier, deux ports TCP/IP peuvent lui être réservés (12 et 14 ou 3012 et 3014) pour ses communications à débit maximum et optimisé. Les communications sont multiplexées et chaque segment possède une priorité. Les messages de synchronisation des tâches sont les plus prioritaires ainsi que les éventuelles liaisons temps réel. Les opérations d'ordonnancement du bus applicatif peuvent être le cas échéant traitées par un calculateur, idéalement vectoriel, qui est une unité de traitement de l'une des machines partenaires, qui peut être dédié. Sur de moyennes configurations, une carte graphique située sur un partenaire est utilisée comme GPGPU (General-Purpose computation on Graphics Processing Units). En effet une carte graphique est un calculateur vectoriel complet. Etant a priori réparti, le bus applicatif fonctionne préférentiellement dans un cadre sécurisé. Le multiplexeur/démultiplexeur est donc muni d'une solide fonction de cryptage. Le système utilisé est un cryptage par clefs aléatoires de longueurs variables et rafraîchies automatiquement. Ainsi toute attaque est déjouée par un changement de clef en un temps plus court que celui demandé par la recherche de clef. Il y a une clef par port et par sens de transmission. La transmission de la nouvelle clef aléatoirement calculée est elle-même sécurisée par la clef précédente. Ainsi, même si la clef initiale (utilisée une unique fois lors du login) est connue, il ne peut être question de pénétrer la suite des échanges. La solidité de l'ensemble est soumise à un objectif de qualité qui fait que le bus applicatif réalise de façon particulièrement avantageuse un traçage de ses opérations et des transactions. Ce traçage n'est bien entendu pas prioritaire et n'impacte pas les performances de l'ensemble. Il est traité comme une acquisition de données stockées en cache puis sauvegardées dans les temps de plus faible priorité. Un outil annexe peut permettre d'exploiter ces données à la demande et à loisir pour y rechercher l'historique de tout évènement ou en extraire toute statistique utile, ou encore permettre le réglage plus précis des paramètres du bus applicatif de façon à en optimiser le fonctionnement pour une configuration donnée.15 REVENDICATIONS1. Procédé d'exécution parallèle d'une pluralité de tâches informatiques par une pluralité d'unités de traitement de données connectées, chaque tâche étant une action élémentaire exécutable par une des unités de traitement de données, le procédé étant caractérisé en ce qu'il comprend des étapes de : (a) Association à au moins une tâche (T) d'une première instruction et d'une deuxième instruction, la première instruction étant une instruction non-bloquante de demande de l'exécution de la tâche (T) et la deuxième instruction étant une instruction bloquante de retour du résultat de l'exécution de la tâche (T) ; (b) Lancement au plus tôt de la première instruction de la tâche (T) et exécution de la tâche (T) par une des unités de traitement de données ; (c) Lancement de la deuxième instruction.de la tâche (T) de façon synchrone avec la demande d'exécution d'une deuxième tâche (T2) ayant une contrainte de dépendance vis-à-vis de la première tâche (T). 2. Procédé selon la revendication 1, dans lequel chaque tâche est soit d'un premier type, soit d'un deuxième type, chacune des tâches du premier type, dites « tâches parallèles », étant exécutée de façon conforme aux étapes (a) à (c), et chacune des tâches du deuxième type, dites « tâches simples », étant exécutée directement par une des unités de traitement de données. 3. Procédé selon l'une des revendications 1 à 2, dans lequel les unités de traitement de données sont connectées via un bus applicatif, l'étape (a) étant mise en oeuvre par le bus applicatif. 4. Procédé selon les revendications 2 et 3 en combinaison dans lequel l'enchaînement de ladite pluralité de tâches forme un processus, les tâches étant ordonnées en fonction d'éventuelles contraintes de dépendance vis-à-vis d'autres tâches, le procédé d'exécution parallèle respectant l'ordre indiqué par la table d'ordonnancement. 5. Procédé selon l'une des revendications 3 ou 4, dans lequel l'exécution d'une tâche utilise une zone d'une mémoire partagée entre les unités de traitement de données, ladite zone de mémoire étant affectée à la tâche par le bus applicatif au lancement de la première instruction associée à la tâche, et libérée au lancement de la deuxième instruction associée à la tâche. 6. Procédé selon la revendication 5, dans lequel sont en outre affectés à la tâche un sémaphore indiquant un état de blocage de la tâche et une file d'attente, le sémaphore étant modifié de sorte à indiquer un état de libération de la tâche lorsque le bus applicatif constate que ladite zone de mémoire partagée affectée est libre et/ou que la tâche est passée en tête de la file d'attente. 7. Procédé selon la revendication 6, dans lequel la zone de mémoire partagée est une partition d'un premier bloc de mémoire partagée, un descripteur de la zone de mémoire partagé étant stocké dans un deuxième bloc de mémoire partagé, ledit deuxième bloc étant dédié au stockage de descripteurs du premier bloc de mémoire partagée. 8. Système comprenant une pluralité d'unités de traitement de données mettant en oeuvre le procédé selon l'une des revendications précédentes, au moins une mémoire connectée à une unité 30 de traitement de données, et une entrée recevant la pluralité de tâches à exécuter.