WO2013110819A1 - Procede d'execution parallele d'une pluralite de taches informatiques - Google Patents

Procede d'execution parallele d'une pluralite de taches informatiques Download PDF

Info

Publication number
WO2013110819A1
WO2013110819A1 PCT/EP2013/051598 EP2013051598W WO2013110819A1 WO 2013110819 A1 WO2013110819 A1 WO 2013110819A1 EP 2013051598 W EP2013051598 W EP 2013051598W WO 2013110819 A1 WO2013110819 A1 WO 2013110819A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
instruction
tasks
execution
data processing
Prior art date
Application number
PCT/EP2013/051598
Other languages
English (en)
Inventor
Yves Albrieux
Ridha BENOSMAN
Original Assignee
Tymis
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tymis filed Critical Tymis
Publication of WO2013110819A1 publication Critical patent/WO2013110819A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Definitions

  • the present invention relates to the field of parallel architectures.
  • Simple synchronization solutions exist, for example based on cycles: a plurality of compatible tasks are started synchronously at each cycle. Such a mechanism provides satisfaction, but significantly limits the possibilities of parallelism, since each processing unit is inactive between the time it finishes a task and the beginning of the next cycle.
  • mechanisms propose uses of locks and / or semaphores. Locks allow you to block and release tasks during synchronizations based on semaphore values. These mechanisms provide better performance, but are particularly complex to manage. Some specific scheduling of tasks may also pose a problem.
  • the present invention aims to solve these difficulties by proposing a method which presents in two parts the call of a function or a method intended to operate parallel to that of the initiating process. All of these two parts are called P-instruction to emphasize its "parallel" character.
  • the first part of a P-statement is the request that initializes the parallel task and automatically sets up the synchronization process.
  • the second part exploits this synchronization and gives the result of the function or the method.
  • the initiating process continues to function in parallel with the unfolding of the function or the method.
  • the invention relates to a method of parallel execution of a plurality of computing tasks by a plurality of processing units of connected data, each task being an elementary action executable by one of the data processing units, the method being characterized in that it comprises steps of:
  • the data processing units are connected via an application bus, step (a) being implemented by the application bus;
  • Each task is either of a first type or of a second type, each of the tasks of the first type, called “parallel tasks”, being executed in accordance with steps (a) to (c), and each of the tasks the second type, called “simple tasks”, being executed directly by one of the data processing units;
  • the sequence of said plurality of tasks forms a process, the tasks being ordered according to possible dependency constraints vis-à-vis other tasks, the parallel execution method respecting the order indicated by the table d scheduling;
  • the execution of a task uses an area of a shared memory between the data processing units, said memory area being assigned to the task by the application bus at the launch of the first instruction associated with the task, and released at the start of the second instruction associated with the task;
  • the shared memory zone is a partition of a first shared memory block, a descriptor of the shared memory zone being stored in a second shared memory block, the second block being dedicated to the storage of descriptors of the first memory block shared.
  • the invention relates to a system comprising a plurality of data processing units implementing the method according to the first aspect of the invention, at least one memory connected to a data processing unit, and a input receiving the plurality of tasks to be executed.
  • FIG. 1a represents an architecture of three application buses interconnected via their NBA cores
  • FIG. 1b represents an interconnection of two parallel applications via their respective application bus terminal
  • FIG. 2 represents the request / response mechanism on an automatically synchronized channel
  • Figure 3 represents two possible cases in the request / response mechanism.
  • the method of parallel execution of a plurality of computer tasks according to the invention is particularly advantageous by using an application bus. It will be understood that it is not limited to this embodiment and can for example quite operate at a server comprising a multi-core processor, therefore eligible for parallelism.
  • this bus is primarily intended to allow communication applications that are basically not designed to work together.
  • BA Business Bus
  • NBA Application Bus Core
  • MCA Application Bus Multiplexer
  • TSA Application Bus Terminal
  • Tm Master Terminal
  • Ts Terminal Slave
  • NBA Network-based core
  • TCP Transmission Control Protocol
  • IP IP
  • the BA can only be accessed by an application via a TBA connected to the local MBA, as shown in Figure 1b.
  • Each application can launch threads and ask the BA to also provide them with a dedicated terminal which allows two threads to interact.
  • each terminal is able to operate in parallel requests-responses on different channels.
  • a dedicated "message pump” allows this terminal to warn of the arrival of data on a particular channel from another terminal.
  • Recent and / or BA-adapted applications can communicate with BA live at their TBA.
  • older applications that do not know this BA are advantageously supported (“piloted” applications) by specific interfaces of each of these applications, responsible for offering them the specific adaptation allowing them to integrate a TBA: the CIA (interactive communication by PLC).
  • CIA is a kind of host driver with the resources needed for applications connected to bus terminals.
  • Each TBA has a plurality of communication channels with its application, through which channels are made the requests for execution of a task and the withdrawal of responses. For each type of request / response, we associate a single channel. In this way, several exchanges can take place in parallel since the channels will be completely independent.
  • the BA thus offers the possibility of massively parallel processing of any process whose execution is required in a multi-core multi-machine environment regardless of the operating systems.
  • the exchanges are secured independently for each TBA.
  • the MBA manages IPC resources, has a "garbage collection” and offers an error recovery device whose implementation remains at the discretion of the programmer.
  • a process whose execution is requested is composed of a plurality of computer tasks. These tasks are elementary actions each executable by one of the data processing units (hence the possibility of massively parallel processing). As will be seen later, these tasks can not usually be performed independently because of dependency constraints, and must be scheduled.
  • the principle of the invention is to "separate" into two parts the execution of a task intended to operate parallel to the initiating process. All of these two parts are called P-instruction to emphasize its "parallel" character.
  • the first part of a P-Instruction is the "request” that initializes the parallel task and automatically sets up the parallel exchange task and its synchronization process.
  • the second part called “return” or “response”, exploits this synchronization and gives the result of the execution of the task.
  • the initiating process continues to run in parallel with the progress of the execution. More specifically, the method according to the invention comprises steps of:
  • Such a method allows the calling program to continue operating as long as it does not need to have the result of a request, ie as long as there is no request to perform a second task having a dependency constraint on the first task, that is to say, the execution of which is subordinated to the result of the first task (if the second task is a "P-instruction" type task), understands that the execution request is the launch of a first statement).
  • the "request” does not wait (or at least the least possible), it is the "return” which is delayed until the result of the execution is actually necessary. This is made possible by the two-part separation of the P-Instructions which decorrelates the "request” and the "return” and makes it possible not to be bound by the actual duration of execution of the task.
  • the method according to the invention maximizes the number of "anticipated calls” and minimizes the number of "calls without precaution”.
  • each of the tasks of the first type is the subject of a pair of P-instructions and is executed in accordance with the steps (a) to (c) of the method presented above;
  • each of the tasks of the second type is executed directly by one of the data processing units.
  • YAL interpreter (“Yet A Language”) is particularly well suited to the use of P-instructions. For example, here is an excerpt from an automaton that simultaneously opens two dialog boxes, the word processor Word, the Excel spreadsheet. Microsoft applications are executed as background tasks, except word that is shown once the editing of the document is done to allow any retouching by the user.
  • each task being an elementary action executable by a given processing unit to which said application bus is connected, the tasks being ordered according to possible dependency constraints for other tasks, it is possible to execute the process in a parallel way provided that the scheduling order is respected for the execution of the tasks.
  • the invention thus proposes a method of parallel execution of a computer process formed by the sequence of said plurality of tasks, the tasks being ordered according to possible constraints of dependence on other tasks, the parallel execution method respecting the order indicated by the scheduling table.
  • the parallel execution method implements for all or part of the tasks a pair of P-Instructions in the order indicated by the scheduling table.
  • the execution of a task requires a memory space, in particular RAM. If, for example, each computing unit has its own storage space (called “distributed” memory), then there is no obstacle to the immediate execution of the task by the designated data processing unit. using his dedicated memory.
  • This distributed memory system is, however, unnecessarily expensive - since it is necessary to provide in n copies an oversized size memory to avoid overflow problems - and requires that a heavy communication system be provided between the memories. .
  • the execution of a task uses an area of the shared memory between the data processing units, said memory area being assigned to the task at the start of the first instruction associated with the task, and released when the task is started. second statement associated with the task.
  • the affected memory area may have to be "locked” for as long as she can be released safely.
  • a memory proper (in other words a "block"), of any length
  • An access request device composed of a message queue (where the requesting tasks come to "take their turn” in the queue), • An access authorization and synchronization device: "a semaphore”.
  • the task wishing to use a memory deposits its request in the corresponding queue. It specifies the action (read / write) and the protection semaphore, a kind of red / green light that allows to know if the memory can be read / written.
  • the task is blocked by this semaphore and is unblocked by the BA that releases the semaphore only when the memory is ready to be used and / or it is the turn of the said task to access it. If the P-request statement was started early enough, this possible wait time is completely invisible.
  • the method according to the invention thus makes it possible to better distribute the use of memory over time, hence spectacular performances even with small memories.
  • IPC is currently insufficient to manage more than a dozen machines, it is because current methods of using memory use a triplet per channel.
  • the method according to the invention advantageously allows to substantially increase the number of machines manageable by IPC without exceeding these limits.
  • the idea is that all channels of a TBA share only a few tails of messages, or even one, and especially share the same single large memory comprising a set of areas each relating to a channel.
  • the limit in terms of semaphores (32000) poses no problem as the semaphores are reusable.
  • the ratio between the maximum number of message queues and that of the number of shared memory blocks is greater than two. This makes it possible to associate with each queue (and therefore with each TBA) two memory blocks.
  • the shared memory associated with a TBA is composed of two parts, a part dedicated to the storage of the data of the tasks strictly speaking (data on which the processing units act during the execution of a task), and a part dedicated to the storage of descriptors of the structure of the first part.
  • the first block associated with the TBA is dedicated to the storage of the data of the tasks and it is called “block of data”
  • the second block associated with the TBA is dedicated to the storage of the descriptors, and is called “Descriptive block”.
  • a partition of the first block is associated, the data making it possible to identify this partition (the "descriptor" of this partition) being stored in the second block.
  • the launch of the request P-instruction is thus followed by the assignment by the application bus to the task of a resource triplet (IPC) comprising a semaphore, a shared memory area and a queue, the semaphore indicating a blocking state of the task, the shared memory area being a partition of a first shared memory block, a descriptor of the shared memory area being stored in a second shared memory block, said second block being dedicated to storing descriptors of the first shared memory block.
  • IPC resource triplet
  • the semaphore is modified so as to indicate a state of release of the task.
  • the memory area is then available for use by the data processing unit assigned for the execution of the task, without the risk that this use is disturbed by another task. It should be noted that when the memory is available, it is not necessarily immediately used.
  • the first shared memory block is structured into a set of equal size units called "pages" each referenced by an index, the partition of the shared memory allocated as a shared memory area for the task being a set of pages, said descriptor of the shared memory area being a page table containing indexes of the pages composing said partition.
  • the allocation spaces are considered to be a non-contiguous space, this is called pagination.
  • the principle of pagination is to structure the memory space into a set of equal sized units called pages.
  • Space memory assigned to a partition will then consist of a set of pages that are not necessarily successive.
  • a partition is no longer identified by its starting address and its size, but by all the pages that compose it, these pages can be organized as a table called a page table that describes the reference to the partition.
  • the invention proposes systems that can implement a method according to the first aspect of the invention.
  • the first functionality requested from the application bus is to ensure the routing of all data between all the actors of all the interconnected configurations.
  • the system according to the invention comprises the workstation, the latter comprising first of all data display means and data acquisition means. It can be classically a screen and a keyboard with a mouse. This material is simply used to implement one or more human-machine interfaces allowing a user to interact with the BA, possibly by providing processes to execute.
  • the system according to the invention also comprises a data processing unit, which is the unit connected to the application bus, and a memory.
  • the processing unit must preferably be a multicore processor (in this case it will be understood as a plurality of processing units), that is to say a processor that can take advantage parallel execution.
  • the memory is advantageously a single shared memory.
  • This workstation hosts the NBA if there is one.
  • the system according to the invention may not be content with a single workstation, but understand as explained above at least one partner machine.
  • the application bus serves as multiple stations (users) and multiple partners (PLCs) in MSMP configuration. It operates in various configurations called “degraded" Simple / Multiple Station / Partner SSSP, SSMP, MSSP and MSMP. Finally, the application bus is able, as far as possible, to support the links of the real-time type required for certain devices (peripherals, control of production lines, etc.). It thus provides a bridge between the industrial world and the office world for example to obtain a real-time picture of the production.
  • the bus uses the connections and the existing physical media between the usual types of machines (file server, web server, application server, etc.).
  • two TCP / IP ports can be reserved for it (12 and 14 or 3012 and 3014) for its maximum throughput and optimized communications.
  • the communications are multiplexed and each segment has a priority.
  • the task synchronization messages are the highest priorities as well as any real-time links.
  • the scheduling operations of the application bus can be optionally processed by a computer, ideally vector, which is a processing unit of one of the partner machines, which can be dedicated.
  • a graphics card located on a partner is used as GPGPU (General-Purpose Computation on Graphics Processing Units). Indeed a graphics card is a complete vector calculator.
  • the application bus preferably operates in a secure environment.
  • the multiplexer / demultiplexer is thus provided with a strong encryption function.
  • the system used is random key encryption of variable lengths and automatically refreshed. So any attack is foiled by a change of key in a time more short than the one requested by the key search.
  • the strength of the whole is subject to a quality objective that makes the application bus performs particularly advantageously a tracing of its operations and transactions.
  • This tracing is of course not a priority and does not impact the performance of the whole. It is treated as an acquisition of data stored in cache and then saved in times of lower priority.
  • An ancillary tool can make it possible to use these data on demand and at leisure to search the history of any event or extract any useful statistics, or to allow more precise adjustment of the parameters of the application bus so as to optimize the operation for a given configuration.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Abstract

La présente 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 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). L'invention concerne également un système à cet effet.

Description

PROCEDE D'EXECUTION PARALLELE D'UNE PLURALITE DE
TACHES INFORMATIQUES
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 à 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, 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 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 cœurs).
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 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 :
• les unités de traitement de données sont connectées via un bus applicatif, l'étape (a) étant mise en œuvre 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 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 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 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 œuvre 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 1 a 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.
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 cœurs, 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 œuvre 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 à 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 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 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 é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-cœurs indépendamment des systèmes d'exploitation.
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 œuvre 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 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 « 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 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. 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 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 œuvre « 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 à rencontre 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 œuvre 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 œuvre 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'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 "fïchier.docx" Q lancement Word sur un document en mode caché
§excel -MExcel "fichier.xlsx" Q lancement Excel sur un document en mode caché
§actA -MdlgA Q appel d'un dialogue A en mode caché
§actB -MdlgB Q appel d'un dialogue B en mode caché
§actA ~C consignes Q consignes pour activité A
§actB ~C consignes Q consignes pour activité B
repA ~§actA ~C visu Q ouverture du dialogue ; acquisition nom client repB ~§actB ~C visu Q ouverture du dialogue ; acquisition de l'adresse
§excel ~C consigne recherche repA
~C consigne extraction données (somme due)
repE ~§excel Q extraction « Somme due » de Excel
§word ~RD "NOM CLIENT" Q positionnement curseur
~I repA Q insertion du nom
~RD "MONTANT" Q positionnement curseur
~I repB Q insertion somme due
~C visu Q ouverture du traitement de texte mode visible
Repw ~§word Q attente sortie du traitement de texte.
&_R n 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, cœurs, 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 œuvre 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 œuvre 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 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 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 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 œuvre ce procédé, la mémoire partagée associée à un TBA est composée de deux parties, une partie dédiée au 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 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 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-contigu, 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 œuvre 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 œuvre 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.

Claims

REVENDICATIONS
1. 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 œuvre 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 œuvre le procédé selon l'une des revendications précédentes, 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.
PCT/EP2013/051598 2012-01-27 2013-01-28 Procede d'execution parallele d'une pluralite de taches informatiques WO2013110819A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1250810A FR2986344B1 (fr) 2012-01-27 2012-01-27 Procede d'execution parallele d'une pluralite de taches informatiques
FR1250810 2012-01-27

Publications (1)

Publication Number Publication Date
WO2013110819A1 true WO2013110819A1 (fr) 2013-08-01

Family

ID=47827136

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/051598 WO2013110819A1 (fr) 2012-01-27 2013-01-28 Procede d'execution parallele d'une pluralite de taches informatiques

Country Status (2)

Country Link
FR (1) FR2986344B1 (fr)
WO (1) WO2013110819A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776015A (zh) * 2016-11-29 2017-05-31 郑州云海信息技术有限公司 一种并行程序任务处理方法及其装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070271565A1 (en) * 2006-05-18 2007-11-22 Sun Microsystems, Inc. Anticipatory helper thread based code execution
FR2963125A1 (fr) 2010-07-26 2012-01-27 Tymis Procede d'execution parallele d'un processus informatique par un bus applicatif
FR2963126A1 (fr) 2010-07-26 2012-01-27 Tymis Procede d'execution parallele d'une pluralite de taches ordonnees selon une table d'ordonnancement

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070271565A1 (en) * 2006-05-18 2007-11-22 Sun Microsystems, Inc. Anticipatory helper thread based code execution
FR2963125A1 (fr) 2010-07-26 2012-01-27 Tymis Procede d'execution parallele d'un processus informatique par un bus applicatif
FR2963126A1 (fr) 2010-07-26 2012-01-27 Tymis Procede d'execution parallele d'une pluralite de taches ordonnees selon une table d'ordonnancement

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
B. LISKOV ET AL: "Promises: linguistic support for efficient asynchronous procedure calls in distributed systems", PROCEEDINGS OF THE ACM SIGPLAN 1988 CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION , PLDI '88, 1 January 1988 (1988-01-01), New York, New York, USA, pages 260 - 267, XP055049111, ISBN: 978-0-89-791269-3, DOI: 10.1145/53990.54016 *
CHATTERJEE A ED - INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS: "FUTURES: a mechanism for concurrency among objects", PROCEEDINGS OF THE SUPERCOMPUTING CONFERENCE. RENO, NOV. 13 - 17, 1989, NEW YORK, IEEE, US, 12 November 1989 (1989-11-12), pages 562 - 567, XP031577358, ISBN: 978-0-89791-341-6 *
HUANG Y-M ET AL: "URPC: A TOOLKIT FOR PROTOTYPING REMOTE PROCEDURE CALLS", COMPUTER JOURNAL, OXFORD UNIVERSITY PRESS, SURREY, GB, vol. 39, no. 6, 1 January 1996 (1996-01-01), pages 525 - 540, XP000639358, ISSN: 0010-4620, DOI: 10.1093/COMJNL/39.6.525 *
ROBERT H. HALSTEAD: "MULTILISP: a language for concurrent symbolic computation", ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS, vol. 7, no. 4, 1 October 1985 (1985-10-01), pages 501 - 538, XP055049112, ISSN: 0164-0925, DOI: 10.1145/4472.4478 *
UWE ZDUN, HENTRICH CARSTEN: "Service Integration Patterns for Invoking Services from Business Processes", PROCEEDINGS OF THE 12TH EUROPEAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMS (EUROPLOP '2007), IRSEE, GERMANY, JULY 4-8, 2007, 1 January 2008 (2008-01-01), pages 235 - 278, XP055049110, ISBN: 978-3-87-940819-1, [retrieved on 20130109] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776015A (zh) * 2016-11-29 2017-05-31 郑州云海信息技术有限公司 一种并行程序任务处理方法及其装置

Also Published As

Publication number Publication date
FR2986344A1 (fr) 2013-08-02
FR2986344B1 (fr) 2015-05-22

Similar Documents

Publication Publication Date Title
EP2480969B1 (fr) Système et procédé de gestion de l'execution entrelacée de fils d'instructions
Risco et al. Serverless workflows for containerised applications in the cloud continuum
EP1967949A1 (fr) Procédé pour exécuter un programme relatif à plusieurs services, système et dispositif électroniques correspondants
FR2925187A1 (fr) Systeme comportant une pluralite d'unites de traitement permettant d'executer des taches en parallele,en mixant le mode d'execution de type controle et le mode d'execution de type flot de donnees
EP2643961B1 (fr) Communication entre deux applications web
FR3103586A1 (fr) Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR3025907B1 (fr) Mecanisme et procede pour permettre une communication entre un client et un serveur en accedant a des donnees de messages en memoire partagee.
EP2366147A1 (fr) Gestionnaire physique de barriere de synchronisation entre processus multiples
FR3103585A1 (fr) Procédé de gestion de la configuration d’accès à des périphériques et à leurs ressources associées d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR2742892A1 (fr) Systeme de protection de logiciel pour ordinateur ecrit en langage interprete
FR3103584A1 (fr) Procédé de gestion du débogage d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
WO2013110816A2 (fr) Procédé d'utilisation d'une mémoire partagée
WO2013110819A1 (fr) Procede d'execution parallele d'une pluralite de taches informatiques
FR3055716A1 (fr) Echange de messages pendant l'execution parallele de processus dans un calculateur haute performance
EP2417523B1 (fr) Procede et dispositif permettant l'execution de composants transactionnels heterogenes
EP2545449B1 (fr) Procédé de configuration d'un système informatique, programme d'ordinateur et système informatique correspondants
EP2278466A1 (fr) Dispositif et procédé pour l'exécution distribuée de traitements de données numériques
FR3025632A1 (fr) Procede et dispositif de controle de la fourniture de certificats d'authentification a des nœuds de service d'un calculateur haute performance
EP2575327B1 (fr) Procédé de partage d'une application web entre plusieurs terminaux informatiques reliés à un réseau de communication
FR3057081A1 (fr) Processeur comprenant une pluralite de coeurs de calcul
EP2713625A1 (fr) Procédé et système de fourniture d'un contenu multimédia, machine virtuelle, serveurs, terminal de communication et programme d'ordinateur correspondants
EP1341093B1 (fr) Accès à une ressource collective
FR3014626A1 (fr) Procede de traitement de donnees pour l’etablissement d’une communication webrtc, dispositif et programme d’ordinateur correspondant.
EP2863305B1 (fr) Double déport de traitement vers dispositif de traitement supplémentaire et central
US20230288786A1 (en) Graphic user interface system for improving throughput and privacy in photo booth applications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13707560

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24.11.2014)