WO2010070222A1 - Gestionnaire physique de barriere de synchronisation entre processus multiples - Google Patents

Gestionnaire physique de barriere de synchronisation entre processus multiples Download PDF

Info

Publication number
WO2010070222A1
WO2010070222A1 PCT/FR2009/052322 FR2009052322W WO2010070222A1 WO 2010070222 A1 WO2010070222 A1 WO 2010070222A1 FR 2009052322 W FR2009052322 W FR 2009052322W WO 2010070222 A1 WO2010070222 A1 WO 2010070222A1
Authority
WO
WIPO (PCT)
Prior art keywords
barrier
processes
blocks
call
synchronization
Prior art date
Application number
PCT/FR2009/052322
Other languages
English (en)
Inventor
Angelo Solinas
Jordan Chicheportiche
Saïd Derradji
Jean-Jacques Pairault
Zoltan Menyhart
Sylvain Jeaugey
Philippe Couvee
Original Assignee
Bull Sas
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 Bull Sas filed Critical Bull Sas
Priority to ES09797109.7T priority Critical patent/ES2689125T3/es
Priority to BRPI0917747A priority patent/BRPI0917747A2/pt
Priority to US13/139,989 priority patent/US9218222B2/en
Priority to EP09797109.7A priority patent/EP2366147B1/fr
Priority to JP2011540156A priority patent/JP5626690B2/ja
Publication of WO2010070222A1 publication Critical patent/WO2010070222A1/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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/522—Barrier synchronisation

Definitions

  • the present invention relates to the processing of processes executed in parallel.
  • parallel to a computer is meant a computer on which several processors or at least one processor with several cores, or at least one processor with several threads (“threads”), are mounted.
  • a computer program divides its task (or main task) into several sub-tasks, whose calculations can be performed in parallel by different processes. Each process will therefore aim to execute and perform one of these subtasks. Once a process has completed its current subtask, it will be possible to assign a second subtask to perform, after which it will eventually be assigned a subtask and so on.
  • multi-process processing implies a need for synchronization of these processes. In particular, this synchronization is intended to allow an orderly restructuring of the main task when the subtasks have been completed.
  • inter-process synchronization mechanism Such synchronization is generally provided by a mechanism called "inter-process synchronization mechanism”. This mechanism must be fast so as not to nullify the temporal advantage derived from the use of processes executed in parallel.
  • 'barrier mechanism' a mechanism of software nature. This mechanism can be based on various algorithms that follow the same main scheme described below.
  • a computer program for performing a task is executed via n processes, themselves being able to execute a set of sub-tasks.
  • Each subtask is divided into successive blocks intended to perform work steps, such as an intermediate calculation for example.
  • the blocks or intermediate calculations of the different processes are executed in parallel.
  • Each process that has completed one block waits at a barrier (synchronization barrier), until all other parallel blocks of the other processes are completed and have joined the barrier. It is only when all processes have reached the barrier that the following blocks are executed during a subsequent no work. This principle is described below using a time diagram.
  • Figure 1 shows a barrier mechanism and thus the general operation of a synchronization barrier.
  • a PM process manager will firstly break down the task T, into n ST sub-tasks. These n sub-tasks ST will be executed by n process P.
  • the main task T complex is decomposed into several simple sub-tasks ST, each of these sub-tasks being accomplished by a separate process.
  • PM process manager is not necessarily a clean element.
  • the process manager can generally be seen as a capability of a computer program to implement a passive or active clipping method to allow processes to divide the subtasks between them.
  • the capacity can be implicit, determined by one of the processes or correspond to a predefined division by a user.
  • n processes are themselves divided into blocks B, which are to be executed successively in time.
  • the subset of the B blocks that are executing at the same time (and from different P processes) constitutes a W work step. Therefore, each set of B blocks of the same rank / constitutes a distinct work step W .
  • the blocks B, of the rank of work pitch /, denoted W, are executed in parallel.
  • the execution time of blocks B from different processes P 1 is variable.
  • the blocks B are subjected to a synchronization barrier BS (100).
  • This barrier BS (100) is called by each process P when it has finished executing its block B, in progress. It is the synchronization barrier BS (100) which allows a passage to the block B 1+ , of a following rank, and this only when all the blocks B, in progress have "joined" the barrier, that is to say it informed that their execution is complete.
  • the first block B completed that is to say the one with the shortest execution time, informs by request the synchronization barrier BS (100) on the one hand that it has completed its work and on the other hand.
  • the number of blocks in progress remaining during the same work step is equivalent to the number n of processes P.
  • Synchronization barriers are usually equipped with a counter.
  • the counter is initialized when the first block B has reached the barrier. Subsequently, the counter is decremented each time another block B joins the barrier BS (100).
  • the barrier BS (100) can follow the progression (or advancement) of a work step, and more specifically the termination of each block B in progress.
  • the last block B namely the one with the highest execution time has reached the barrier BS (100)
  • the latter informs each process P and allows them to pass to a next work step W.
  • this next work step W consists of blocks B executed in parallel and originating from the various processes P.
  • the mechanism of the barrier BS (100) is similar to the previous one. This is repeated for each step of work, and continues until the completion of the processes P.
  • the task T will then be accomplished by reconstituting the results of the processes P.
  • Such algorithms require a certain number of interactions between the processes, blocks and the barrier. These interactions will be described later in the detailed description and include the initialization of the barrier, the information given to the barrier when a block has completed its work, the verification that all sub-processes have completed their current block. , especially. These interactions, when managed by barriers of a software nature, are relatively slow and consume a lot of bandwidth.
  • FIG. 2 relating to the prior art represents a known BS (100) synchronization barrier implementation.
  • BS 100
  • Known mechanisms are implemented in software.
  • the data defining the synchronization barrier BS (100) is stored in the RAM (202) (meaning in English language RAM: Random Access Memory) of a computer (or other computing device) and the various processes P access (read / write R / W) to this RAM (202) to interact with said BS (100) barrier. This access is done using an address space and an ADR address (detailed below).
  • Access includes, as described above, the initialization of the barrier BS (100) (with the initialization of the counter), the fact of informing the barrier BS (100) every time a block B has finished its work when the same step W, check whether all the processes P have finished their block B of the current work step W, etc.
  • the program intended to perform these functions is also active in RAM, in particular by calling a library of functions.
  • An address space can be segmented into independent segments.
  • segment is generally meant a segment of memory defined by two values: - the address at which this segment starts (base address), and - the size of the segment.
  • a segment therefore constitutes a range of continuous addresses in a main memory (physical or virtual).
  • FIG. 2 shows a computing device comprising several processors PZi to PZ y (200), a memory access manager CACHE COHER MGR (206), a RAM memory (202) containing a program area in which is located the barrier of BS synchronization (100) of software nature.
  • the device according to FIG. 2 therefore comprises a processing unit capable of multi-process processing. The processes will then run on different processors, on different cores ("cores") of processors, and / or on different threads ("threads").
  • the processing unit provides these processors with so-called "address space", in particular to the RAM, where the code and the data defining the BS (100) software synchronization barrier are located, in a area associated with a specific address ADR, which may be the address of the beginning of the area.
  • the device of FIG. 2 further comprises a process manager (208) of the type as defined above for decomposing a task T into n processes P, themselves divided into successive blocks B.
  • the barriers of the prior art make it possible to implement a synchronization between different processes P. But, as already mentioned, the software nature of a barrier makes it slow with respect to certain needs. Indeed, each time a process P interacts with it, a library of functions of the barrier BS (100) is used. In addition, within the library, many interactions with the memory are required to read and write the barrier update data until all processes have reached the rendezvous point ( "Synchronization barrier"). Then, once the process P has informed the BS (100) barrier, the process P must regularly query the BS barrier (100) to see if the other current B blocks have completed their work.
  • the present invention improves the situation.
  • the invention introduces a computer device with a synchronization barrier, comprising a memory, a processing unit, capable of multiprocessing processing on different processors and allowing parallel execution of blocks by processes, said blocks being associated by group in successive work steps, and a hardware circuit with a usable address space to the memory, capable of receiving a call from each process indicating the completion of a current block, each call comprising data, and said hardware circuit being arranged to allow the execution of blocks of a subsequent work step when the set of blocks of the current work step have been executed, which is accessed from the segmented address space derived from said data of each call.
  • the hardware circuit of the device includes a firmware for performing data processing of at least one call.
  • the processing may include, inter alia, suspending responses to each call until an end condition is verified that all processes have reported the completion of the block of the current work step.
  • the hardware circuit can respond to each call with a data output and allow the processes to pass to the subsequent work step.
  • the above-mentioned processing includes extracting the number of processes from a first call and then down-counting. on this number from other calls, until the end condition is checked. Note that each call can indicate this number of processes.
  • the present invention introduces a method of computer processing at the process level, of the type comprising the following steps: a. break a task into subtasks executed as processes composed of successive blocks; b. providing a synchronization barrier provided with a counter in relation to the number of processes, in a physical barrier manager; vs. in each process, setting a first block as a current block and executing it, while accessing said synchronization barrier to decrement said counter when the execution of that current block terminates; d. in each process where the execution of the current block is completed, wait for a response from said synchronization barrier, the response being directly linked to the counter and sent when it indicates that all the current blocks are executed, e. when all current blocks are running, define new blocks in progress from the next block of each process, and repeat steps c. and D. with these new blocks in progress.
  • FIG. 1 is a timing diagram which illustrates the general operation of a barrier mechanism
  • FIG. 2 is the block diagram of an implementation of a software synchronization barrier of the prior art
  • FIG. 3 represents a computing device comprising a memory and a processing unit, capable of multiprocessing processes on different processors with a hardware circuit forming a synchronization barrier manager;
  • FIG. 4 represents a hardware circuit forming a synchronization barrier manager, a dedicated memory and a firmware,
  • FIG. 5 represents a synchronization barrier automatism according to one embodiment of the invention
  • FIG. 6 represents a flowchart of the main operations according to one embodiment of the invention.
  • the computer device of FIG. 3 comprises a RAM memory (202), a processing unit capable of multi-process processing on different processors PZi to PZ y (200), and a memory access manager COHER CACHE MGR ( 206) between said RAM (202) and the PZ processors (200).
  • the device further comprises a hardware circuit forming a HBM synchronization barrier manager (400), comprising a Ded_MEM dedicated memory (404) and a micro-Prog microprogram (402) as shown in FIG. 4.
  • the HBM manager (400) only needs a "D (unidirectional)" data output. In practice, it is an input / output especially for reasons of compatibility (read / write R / W) with the bus connected.
  • the address / data links to the hardware circuit avoid the memory access manager COHER CACHE MGR (206).
  • the HBM synchronization barrier manager COHER CACHE MGR (206).
  • the synchronization barrier manager HBM (400) can for example be in a processor, in a chipset (or chipset) or as shown in FIG. 3 within an additional component such as a circuit equipment.
  • the HBM (400) must be accessible for any transaction originating from the P processes participating in the BS (100) barrier and targeting that manager.
  • the HBM manager (400) can therefore be accessed or called by any request to his memory space.
  • multiple addresses can target the same barrier BS (100) ("address aliasing").
  • each process P issuing a request to the synchronization barrier BS (100) carries: in the higher weight of this request, the address of the barrier, and
  • An example of additional data may be the number of processes P participating in the BS (100) barrier. Each of the processes P can thus target a single barrier BS (100) by communicating information necessary for synchronization. This information can be stored by the micro-Prog micro-program (402) in its Ded_MEM dedicated memory (404) and then processed by the micro-Prog micro-program (402) of the synchronization barrier manager HBM (400).
  • the HBM synchronization barrier manager (400) can handle a plurality of BS synchronization barriers (100) at a time. This possibility is important in some applications.
  • the barrier BS (100) is in its initial state, and none of the n processes P has accessed it.
  • the processes P are in a first work step W and each execute their first blocks B (see FIG. 1). Similar to what is described above, the first process P having completed its block B, informs the barrier BS (100) by means of a request.
  • This request includes on its lower weight the number n of processes P participating in the barrier, which allows the initialization of a counter CNT (406) of the barrier BS (100) once the first request received. It is upon receipt of this first request that the synchronization barrier BS (100) switches to the activated mode (or state).
  • the HBM timing barrier manager (400) will decrement (down count) the CNT counter (406). Queries are only answered with D data when the HBM (400) synchronization barrier manager has received all requests from the n processes P participating in the barrier BS (100). At this point, synchronization is considered effective. The set of processes P is then allowed to pass to the next work step W.
  • the corresponding process interrogates the barrier BS only once to determine the progress of the working step W. This is because the barrier BS is able to store in its space Ded_MEM memory (404) own, the number of requests already received. Each process will remain pending until the response from the BS barrier is received. There is therefore no need for a multiple interrogation (regular or not) of the processes towards the barrier. In addition, each query is less expensive in terms of bandwidth. This is at the origin of the bandwidth gain achieved by the invention.
  • the execution time t of a block B is not necessarily related with the arrival of it to the synchronization barrier BS. Indeed, for reasons of competition, non-scheduling of communication channels, conflicts or arbitration, a second request part later than a first request can reach the barrier BS before said first request. However, this does not change the operation of the barrier according to the invention. For the sake of simplicity, it is considered in the present description that a request issued by a first process having a run time t shorter than a second process, will join the barrier BS before the request issued by the second process.
  • the memory space of the BS synchronization barrier (100) is implemented in the memory space dedicated to the PCI bus of the computer.
  • the synchronization barrier manager may be advantageous for the synchronization barrier manager to manage these barriers in relation to memory segments, for example pages of memory.
  • This plurality of barriers can be connected to the same circuit or to separate circuits.
  • the PCI memory provides enough space to provide a predetermined size of memory page for each barrier while providing barrier protected access.
  • the HBM synchronization barrier manager (400) can therefore host M * 64KB pages, where M is the number of physical BS (100) barriers implemented in the HBM synchronization barrier manager (400). M can especially be 512, which results in a total memory space of 32 MB (mega-bytes). These 32 MB obviously correspond to a virtual type of memory that is not to be considered as "real" MB but are simply seen as such by the application to synchronize.
  • This request includes the address of the barrier BS (100), a command in progress (detailed below), the indication whether it is a synchronization at one or more levels (detailed below). below) and the number of processes involved in the synchronization and therefore the barrier.
  • the values 0 or 1 correspond respectively to one-level synchronization and two-level synchronization.
  • a higher synchronization level is detailed in the exemplary embodiment below.
  • FIG. 5 relates to an exemplary embodiment of an HBM synchronization manager (400), which is capable of managing a higher level synchronization, and more precisely here at two levels.
  • a two-level synchronization may for example be used when several distinct groups of P processes must be synchronized, with each group having a physical (or physical) BS (100) barrier.
  • the manager of synchronization HBM (400) must handle the case where each group must be synchronized on its own, then all the groups must be synchronized with each other.
  • the first request received by the barrier BS (100) to a ready state PRE contains on its lower weights information indicating whether it is a synchronization at one or two levels. If it is a one-level synchronization, it will be managed by a barrier at a level, or more precisely by an active state ACT of the barrier designed for a level (state ACT 1 N). If, on the contrary, it is a two-level synchronization, this same barrier will enter an ACT active state designed for two levels (state ACT 2 N), in which case its behavior will be as described below:
  • the barrier BS (100) When all the requests have been received by the barrier BS (100), it chooses one of the processes P as being master M among all the processes P participating in the barrier BS (100). At first, only the request of the master M will be answered by a special data D indicating that he is the master of the group. From there, the master is free to perform the second level of synchronization.
  • This second level of synchronization may for example be a BS (100) barrier of a software nature.
  • the master M When the master M has completed this second synchronization level, it transmits a last request to the barrier BS (100). In response to this latter request, the barrier responds to all other requests from the other processes P participating in the BS (100) barrier (including the master M), and returns to the ready state PRE.
  • the master M is dynamic and can be redefined at each synchronization.
  • the different states of the barrier automatism shown in FIG. 5 are the following:
  • the physical barrier is ready to receive requests from processes participating in the barrier.
  • three transitions can take place: T1, T2 or T13.
  • the barrier will choose which transitions to perform.
  • the query includes in its lower weights the information that there is need for a single-level synchronization (SYNC_1_N).
  • the barrier is activated and is then in active state with synchronization at ACT 1 N.
  • Transition T2 Similar to T1, this transition corresponds to the reception of the barrier of a request with a SAVE record command in order to initialize the barrier.
  • the request includes in its lower weight, the information that there is need of a synchronization with two levels (SYNC_2_N).
  • the gate is activated and goes into active state with two-level synchronization ACT 2 N.
  • the barrier performs a single-level synchronization. Several transitions exist from this state.
  • the internal counter CNT (406) is decremented at each transition T3 (CNT> threshold value).
  • T3 corresponds substantially to each termination of the current blocks B, during the same step W work.
  • chronic counter time counter
  • Transition T14 This transition corresponds to the reception of the barrier of a request with an OFF command OFF
  • Transition T6 analogous to the T3 transition (see above).
  • the barrier BS (100) returns to ready state PRE.
  • the barrier BS (100) is provided with a time counter, also called counter-chron.
  • the counter is configurable and can describe a time limit. The counter starts a countdown (usually in units ⁇ s) upon receipt of the first request. The time then begins to run. If the predetermined time limit is exceeded before the last request is received at the barrier BS (100), then it passes to the cancellation state ANN.
  • the time limit can vary according to the barriers, and more precisely according to the different states of a barrier, in particular: ACT_1_N, ACT_2_N, SYNC.
  • this time limit is programmable. Its upper limit can be set according to the context, in particular to avoid interference with the time-out of the processor.
  • the barrier returns to ready state PRE (see above). This, for example, invites the set of processes (P) to go back towards the end of execution of a previous work step (W).
  • the flow diagram of FIG. 6 shows the main operations of a synchronization barrier BS according to one embodiment of the invention.
  • the flowchart shows the barrier BS (100) in its ready state PRE (operation 700).
  • the first process P having completed its block B, informs (by a call) the barrier BS (100) by means of a request for the HBM manager (400) (operation 702).
  • the barrier stores the identifier SVEJD Req corresponding to the process P having recently informed the barrier BS (100) (operation 708).
  • the barrier BS (100) checks whether the counter CNT (406) has reached its threshold value (operations 710 and 712).
  • the barrier BS (100) elects a master M among the current processes P (operation 732; CH M) and performs a second synchronization (operation 734; SYNC) before the response by data D (operation 740).
  • a single barrier BS is used for the synchronization of processes. It may be useful to integrate in a computer system several synchronization barriers BS and in particular to allow to synchronize several groups of processes, each group contributing to the execution of a different task. For example in scientific computing on a machine of 16 cores, one can consider that 2 independent calculations are done using each 8 cores, one will then have 2 groups of 8 processes, each process executing on a different heart. In this example we will need 2 barriers.
  • the device may comprise several hardware circuits, which are accessed from the address spaces by segments derived from said data of each call.
  • each of the hardware circuits is connected either to the same circuit or to separate circuits.
  • the computing device described herein may therefore further include a software synchronization barrier, operating in combination with said hardware circuit.

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 se rapporte à un dispositif informatique à barrière de synchronisation. Le dispositif comprend une mémoire et une unité de traitement, capable de traitement multiprocessus sur différents processeurs et permettant une exécution en parallèle de blocs par des processus, lesdits blocs étant associés par groupe en pas de travail successifs. Le dispositif comprend en outre un circuit matériel avec un espace d'adresse exploitable vers la mémoire, capable de recevoir un appel de chaque processus indiquant la fin d'exécution d'un bloc en cours, chaque appel comprenant des données. Le circuit matériel est agencé pour autoriser l'exécution de blocs d'un pas de travail ultérieur lorsque l'ensemble des blocs du pas de travail en cours ont été exécutés. L'accessibilité à l'espace d'adresse est réalisée par segments tirés des données de chaque appel.

Description

GESTIONNAIRE PHYSIQUE DE BARRIERE DE SYNCHRONISATION ENTRE PROCESSUS MULTIPLES
La présente invention concerne le traitement de processus exécutés en parallèle.
Certains logiciels ou programmes d'ordinateur prennent un temps important pour exécuter ou accomplir une tâche donnée. Pour être plus efficace et diminuer les temps de calcul, ces programmes peuvent tirer avantage de la nature parallèle des ordinateurs sur lesquels ils sont exécutés. Par nature parallèle d'un ordinateur, on entend un ordinateur sur lequel sont montés plusieurs processeurs ou au moins un processeur à plusieurs cœurs, ou au moins un processeur à plusieurs files d'exécution ("threads").
Pour profiter de la nature parallèle, un programme d'ordinateur divise sa tâche (ou tâche-principale) en plusieurs sous-tâches, dont les calculs peuvent être effectués en parallèle par différents processus. Chaque processus aura donc pour objet d'exécuter et d'accomplir une de ces sous-tâches. Une fois qu'un processus aura terminé sa sous-tâche en cours, il sera possible de lui attribuer une seconde sous-tâche à accomplir, après laquelle il lui sera éventuellement attribuer une sous- tâche suivante et ainsi de suite. L'utilisation d'une multitude de processus (traitement multiprocessus) implique un besoin de synchronisation de ces derniers. Cette synchronisation a notamment pour but de permettre une restructuration ordonnée de la tâche principale lorsque les sous-tâches ont été accomplies.
Une telle synchronisation est généralement assurée par un mécanisme dit "mécanisme de synchronisation inter-processus". Ce mécanisme doit être rapide afin de ne pas annuler l'avantage temporel tiré de l'utilisation de processus exécutés en parallèle.
Pour réaliser la synchronisation sus-mentionnée, on connaît un mécanisme de nature logicielle dit 'mécanisme de barrière'. Ce mécanisme peut être basé sur divers algorithmes qui suivent un même schéma principal décrit ci-après.
Dans un premier temps, un programme d'ordinateur destiné à accomplir une tâche est exécuté via n processus, eux mêmes étant aptes à exécuter un ensemble de sous-tâches. Chaque sous-tâche est divisée en blocs successifs destinés à accomplir des pas de travail, tels qu'un calcul intermédiaire par exemple. Ainsi, les blocs ou calculs intermédiaires des différents processus, sont exécutés en parallèle. Chaque processus ayant terminé un bloc, se met en attente au niveau d'une barrière (barrière de synchronisation), jusqu'à ce que tous les autres blocs parallèles des autres processus sont terminés et ont rejoint à leur tour la barrière. C'est seulement quand tous les processus ont atteint la barrière, que les blocs suivants sont exécutés lors d'un suivant pas de travail. Ce principe est décrit ci-après à l'aide d'un diagramme temporel.
La figure 1 montre un mécanisme de barrière et ainsi le fonctionnement général d'une barrière de synchronisation. En partant d'une tâche principale T, un gestionnaire de processus PM va dans un premier temps décomposer la tâche T, en n sous-tâches ST. Ces n sous-tâches ST seront exécutées par n processus P. En d'autres termes, la tâche principale T complexe est décomposée en plusieurs sous- tâches ST simples, chacune de ces sous-tâches étant accomplie par un processus distinct.
Les résultats obtenus des différentes sous-tâches ST exécutées par les processus P seront au final réunis en vue d'accomplir la tâche principale T.
Remarquons que la notion de gestionnaire de processus PM est à comprendre au sens large. Ainsi, le gestionnaire PM n'est pas nécessairement un élément propre. En effet, le gestionnaire de processus peut généralement être vu comme une capacité d'un programme d'ordinateur d'implémenter une méthode de découpage passive ou active pour permettre aux processus de se répartir les sous- tâches entre eux. La capacité peut être implicite, déterminée par un des processus ou encore correspondre à un découpage prédéfini par un utilisateur.
Comme mentionné plus haut, lors de la décomposition d'une tâche en une multitude de processus P1, il existe un besoin de synchronisation dans l'exécution en parallèle de ces différents processus. Pour cela, les n processus sont eux-mêmes divisés en blocs B, qui sont à exécuter successivement dans le temps. Le sous- ensemble des blocs B qui sont en exécution en même temps (et issus de différents processus P) constitue un pas de travail W. Par conséquent, chaque ensemble de blocs B d'un même rang /constitue un pas de travail W distinct. Les blocs B, du pas de travail de rang /, noté W, sont exécutés en parallèle. Le temps t d'exécution de blocs B issus de différents processus P1 est variable. Pour assurer la synchronisation mentionnée ci-dessus, les blocs B sont soumis à une barrière de synchronisation BS (100). Cette barrière BS (100) est appelée par chaque processus P lorsqu'il a fini d'exécuter son bloc B, en cours. C'est la barrière de synchronisation BS (100) qui autorise un passage au bloc B1+, d'un rang suivant, et ceci seulement lorsque tous les blocs B, en cours auront "rejoint" la barrière, c'est- à-dire informé celle-ci que leur exécution est terminée.
Le premier bloc B terminé, c'est-à-dire celui avec un temps t d'exécution le plus court, informe par requête la barrière de synchronisation BS (100) d'une part qu'il a terminé son travail et d'autre part du nombre de blocs en cours restant lors du même pas de travail. Généralement, le nombre de blocs lors d'un pas de travail est équivalent au nombre n de processus P.
Les barrières de synchronisation sont habituellement munies d'un compteur. Le compteur est initialisé lorsque le premier bloc B a rejoint la barrière. Par la suite, le compteur est décrémenté à chaque fois qu'un autre bloc B rejoint la barrière BS (100). Ainsi, la barrière BS (100) peut suivre la progression (ou avancement) d'un pas de travail, et plus précisément la terminaison de chaque bloc B en cours. Lorsque le dernier bloc B, à savoir celui avec un temps t d'exécution le plus élevé aura rejoint la barrière BS (100), cette dernière informe chaque processus P et les autorise à transiter vers un pas de travail suivant W. À nouveau, ce pas de travail W suivant est constitué de blocs B exécutés en parallèle et issus des différents processus P. Lors de ce pas de travail suivant, le mécanisme de la barrière BS (100) est analogue au précédent. Cela se répète pour chaque pas de travail, et se poursuit jusqu'à terminaison des processus P. La tâche T sera alors accomplie par reconstitution des résultats des processus P.
De tels algorithmes nécessitent un certain nombre d'interactions entre les processus, blocs et la barrière. Ces interactions seront décrites plus loin dans la description détaillée et comprennent l'initialisation de la barrière, l'information donnée à la barrière lorsqu'un bloc a terminé son travail, la vérification du fait que tous les sous processus ont terminé leur bloc en cours, notamment. Ces interactions, lorsqu'elles sont gérées par des barrières de nature logicielle, sont relativement lentes et très consommatrices en bande passante.
La figure 2 relative à l'art antérieur représente une implémentation de barrière de synchronisation BS (100) connue. Les mécanismes connus sont implémentés dans des logiciels. Ainsi, les données définissant la barrière de synchronisation BS (100) sont stockées dans la mémoire RAM (202) (signification en langue anglaise de RAM : Random Access Memory) d'un ordinateur (ou autre dispositif informatique) et les différents processus P accèdent (par lecture/écriture R/W) à cette mémoire RAM (202) pour interagir avec ladite barrière BS (100). Cet accès se fait au moyen d'un espace d'adresse et d'une adresse ADR (détaillé plus loin). L'accès comprend, tel que décrit plus haut, l'initialisation de la barrière BS (100) (avec l'initialisation du compteur), le fait d'informer la barrière BS (100) à chaque fois qu'un bloc B a terminé son travail lors d'un même pas de travail W, vérifier si tous les processus P ont terminé leur bloc B du pas de travail W en cours, etc. Le programme destiné à effectuer ces fonctions est lui aussi actif en mémoire vive, notamment par appel d'une bibliothèque de fonctions.
Un espace d'adresse peut être segmenté en segments indépendants. Par segment on entend généralement un segment de mémoire défini par deux valeurs : - l'adresse auquel ce segment commence (adresse de base), et - la taille du segment.
Un segment constitue donc une plage d'adresses continues dans une mémoire principale (physique ou virtuelle).
La figure 2 montre un dispositif informatique comprenant plusieurs processeurs PZi à PZy (200), un gestionnaire d'accès en mémoire CACHE COHER MGR (206), une mémoire RAM (202) contenant une zone de programme dans laquelle se trouve la barrière de synchronisation BS (100) de nature logicielle. Le dispositif selon la figure 2 comprend donc une unité de traitement capable de traitements multi-processus. Les processus vont alors s'exécuter sur différents processeurs, sur différents coeurs ("cores") de processeurs, et/ou encore sur différents fils d'exécution ("threads"). L'unité de traitement procure à ces processeurs ce qu'on appelle un "espace d'adresse", notamment vers la mémoire vive, où se trouvent le code et les données qui définissent la barrière de synchronisation BS (100) logicielle, dans une zone associée à une adresse précise ADR, qui peut être l'adresse du début de la zone. Le dispositif de la figure 2 comprend en outre un gestionnaire de processus (208) du type comme défini plus haut pour décomposer une tâche T en n processus P, eux-mêmes divisés en blocs B successifs.
Les barrières de l'art antérieur (figure 2) permettent la mise en œuvre d'une synchronisation entre différents processus P. Mais, comme déjà évoqué, la nature logicielle d'une barrière la rend lente par rapport à certains besoins. En effet, à chaque fois qu'un processus P interagit avec celle-ci, il est fait appel à une bibliothèque de fonctions de la barrière BS (100). De plus, au sein de la bibliothèque, il faut de nombreuses interactions avec la mémoire pour lire et écrire les données de mise à jour de la barrière, jusqu'à détection de ce que tous les processus ont atteint le point de rendez-vous (« barrière de synchronisation »). Ensuite, une fois que le processus P a informé la barrière BS (100), le processus P doit régulièrement interroger la barrière BS (100) pour voir si les autres blocs B en cours ont terminé leur travail.
Tout ceci, et notamment les nombreuses interactions cités ci-dessus, fait que les barrières de synchronisation BS (100) de nature logicielle sont lentes et consommatrices en bande passante. Cela se traduit par des pertes de cycles d'horloge, ce qui est d'autant plus gênant que l'on utilise le mode multi-processus pour aller plus vite.
En outre, il risque de se produire que différents blocs appartenant à des processus respectifs distincts informent la barrière en même temps ; d'où des conflits d'accès mémoire générateurs de problèmes supplémentaires de latence et de bande passante (gestion des conflits par le CACHE COHER MGR).
La présente invention vient améliorer la situation.
A cet effet, l'invention vient introduire un dispositif informatique à barrière de synchronisation, comprenant une mémoire, une unité de traitement, capable de traitement multiprocessus sur différents processeurs et permettant une exécution en parallèle de blocs par des processus, lesdits blocs étant associés par groupe en pas de travail successifs, et un circuit matériel avec un espace d'adresse exploitable vers la mémoire, capable de recevoir un appel de chaque processus indiquant la fin d'exécution d'un bloc en cours, chaque appel comprenant des données, et ledit circuit matériel étant agencé pour autoriser l'exécution de blocs d'un pas de travail ultérieur lorsque l'ensemble des blocs du pas de travail en cours ont été exécutés, dont on accède à l'espace d'adresse par segments tirés desdites données de chaque appel.
Dans un mode de réalisation le circuit matériel du dispositif comprend un microprogramme pour effectuer un traitement tiré des données d'au moins un appel.
Dans ce cas, le traitement peut notamment comprendre la suspension de réponses à chaque appel, jusqu'à vérification d'une condition de fin indiquant que tous les processus ont signalé la fin d'exécution du bloc du pas de travail en cours. Une fois la condition de fin vérifiée, à savoir lorsque tous les processus ont signalé la fin d'exécution du bloc du pas de travail en cours, le circuit matériel peut répondre à chaque appel par une sortie de données et autoriser les processus à transiter vers le pas de travail ultérieur.
Dans un autre mode de réalisation le traitement cité ci-dessus comprend l'extraction du nombre de processus à partir d'un premier appel, puis le décomptage sur ce nombre à partir d'autres appels, jusqu'à vérification de la condition de fin. On note que chaque appel peut indiquer ce nombre de processus.
Egalement, la présente invention vient introduire un procédé de traitement informatique au niveau processus, du type comprenant les étapes suivantes : a. décomposer une tâche en sous-tâches exécutées en tant que processus composés de blocs successifs; b. prévoir une barrière de synchronisation munie d'un compteur en rapport avec le nombre de processus, dans un gestionnaire physique de barrière ; c. dans chaque processus, définir un premier bloc comme bloc en cours et l'exécuter, tout en accédant à ladite barrière de synchronisation pour décrémenter ledit compteur lorsque l'exécution de ce bloc en cours se termine ; d. dans chaque processus où l'exécution du bloc en cours est terminée, attendre une réponse de ladite barrière de synchronisation, la réponse étant directement liée au compteur et émise lorsque celui-ci indique que tous les blocs courants sont exécutés, e. lorsque tous les blocs courants sont exécutés, définir de nouveaux blocs en cours à partir du bloc suivant de chacun des processus, et répéter les étapes c. et d. avec ces nouveaux blocs en cours. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après et les dessins annexés sur lesquels :
- la figure 1 est un diagramme temporel qui illustre le fonctionnement général d'un mécanisme de barrière,
- la figure 2 est le schéma de principe d'une implémentation d'une barrière de synchronisation logicielle de l'art antérieur,
- la figure 3 représente un dispositif informatique comprenant une mémoire et une unité de traitement, capable de traitements multiprocessus sur différents processeurs avec un circuit matériel formant gestionnaire de barrière de synchronisation, - la figure 4 représente un circuit matériel formant gestionnaire de barrière de synchronisation comprenant une mémoire dédiée et un microprogramme,
- la figure 5 représente un automatisme de barrière de synchronisation selon un mode de réalisation de l'invention, et - la figure 6 représente un organigramme des principales opérations selon un mode de réalisation de l'invention.
Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
La Demanderesse est parvenue à surmonter les problèmes de l'art antérieur cités et propose ainsi une barrière de nature physique ou matérielle. Elle sera maintenant décrite en référence à la figure 3, qui propose une telle barrière de nature physique ou matérielle. Ainsi, le dispositif informatique de la figure 3 comprend une mémoire RAM (202), une unité de traitement capable de traitement multi-processus sur différents processeurs PZi à PZy (200), et un gestionnaire d'accès en mémoire COHER CACHE MGR (206) entre ladite mémoire RAM (202) et les processeurs PZ (200). Dans le mode de réalisation décrit ici, le dispositif comprend en outre un circuit matériel formant gestionnaire de barrière de synchronisation HBM (400), comprenant une mémoire dédiée Ded_MEM (404) et un microprogramme micro-Prog (402) tel que représenté sur la figure 4. A ce stade, le gestionnaire HBM (400) n'a besoin que d'une sortie de données « D (unidir) ». En pratique, il s'agit d'une entrée/sortie notamment pour des raisons de compatibilité (lecture/écriture R/W) avec le bus connecté.
Dans le mode de réalisation décrit les liaisons adresse/données vers le circuit matériel (HBM, 400) évitent le gestionnaire d'accès en mémoire COHER CACHE MGR (206). De manière générale, le gestionnaire de barrière de synchronisation HBM
(400) va directement interagir avec les processus P qui participent à la barrière BS (100). L'interaction peut être suivi d'un stockage de données dans la mémoire dédiée Ded_MEM (404).
Le gestionnaire de barrière de synchronisation HBM (400) peut par exemple se trouver dans un processeur, dans un jeu de puces (« chipset » ou autre) ou comme représenté sur la figure 3 au sein d'une composante supplémentaire tel qu'un circuit matériel. Le gestionnaire HBM (400) doit être accessible pour toute transaction issue des processus P participant à la barrière BS (100) et visant ce gestionnaire. Le gestionnaire HBM (400) peut donc être accédé ou appelé par toute requête visant son espace de mémoire. C'est ainsi que de multiples adresses peuvent viser la même barrière BS (100) ("address aliasing").
En d'autres termes, chaque processus P émettant une requête vers la barrière de synchronisation BS (100) porte : - dans les poids supérieurs de cette requête, l'adresse de la barrière, et
- dans les poids inférieurs, des données supplémentaires. Bien évidemment, il est possible d'organiser librement dans les poids supérieurs ou inférieurs (poids choisis) la localisation les informations susmentionnées (adresse et données). Ainsi, les poids supérieurs de la requête peuvent porter lesdites données supplémentaires et les poids inférieurs l'adresse de la barrière.
Un exemple de données supplémentaires peut être le nombre de processus P participant à la barrière BS (100). Chacun des processus P peut ainsi viser une seule et même barrière BS (100) en lui communiquant des informations nécessaires à la synchronisation. Ces informations peuvent être stockées par le micro-programme micro-Prog (402) dans sa mémoire dédiée Ded_MEM (404) et ensuite traitées par le micro-programme micro-Prog (402) du gestionnaire de barrière de synchronisation HBM (400).
En appliquant ce principe, le gestionnaire de barrière de synchronisation HBM (400) peut gérer plusieurs barrières de synchronisation BS (100) à la fois. Cette possibilité est importante dans certaines applications.
Considérons maintenant un groupe de n processus P qui utilisent pour leur synchronisation une barrière physique. Dans une première étape, la barrière BS (100) est dans son état initial, et aucun des n processus P n'y a accédé. Les processus P se trouvent dans un premier pas de travail W et exécutent chacun leurs premiers blocs B (voir figure 1 ). Similairement à ce qui est décrit plus haut, le premier processus P ayant terminé son bloc B, informe la barrière BS (100) au moyen d'une requête. Cette requête comprend sur ses poids inférieurs le nombre n de processus P participant à la barrière, ce qui permet l'initialisation d'un compteur CNT (406) de la barrière BS (100) une fois la première requête reçue. C'est à la réception de cette première requête que la barrière de synchronisation BS (100) passe au mode (ou état) activé. A partir de là, chaque fois qu'une requête vise la barrière BS (100), le gestionnaire de barrière de synchronisation HBM (400) va décrémenter (décomptage) le compteur CNT (406). Il n'est répondu aux requêtes par des données D que lorsque le gestionnaire de barrière de synchronisation HBM (400) a reçu toutes les requêtes issues des n processus P participant à la barrière BS (100). À ce moment là, la synchronisation est considérée comme effective. L'ensemble des processus P est alors autorisé à transiter vers le pas de travail W suivant.
Notons qu'une fois un bloc terminé, le processus correspondant n'interroge qu'une seule fois la barrière BS pour déterminer l'avancement du pas de travail W. Ceci en raison du fait que la barrière BS est capable de stocker dans son espace de mémoire Ded_MEM (404) propre, le nombre de requêtes déjà reçues. Chaque processus demeurera en attente jusqu'à réception de la réponse issue de la barrière BS. Il n'y a donc pas lieu d'une interrogation multiple (régulière ou non) des processus vers la barrière. De plus, chaque interrogation est moins coûteuse en termes de bande passante. Ceci est à l'origine du gain en bande passante atteint par l'invention.
Incidemment, remarquons ici que le temps d'exécution t d'un bloc B n'est pas nécessairement lié avec l'arrivée de celui-ci à la barrière de synchronisation BS. En effet, pour des raisons de concurrence, de non-ordonnancement des voies de communication, de conflits ou encore d'arbitrage, une seconde requête partie plus tard qu'une première requête peut atteindre la barrière BS avant ladite première requête. Toutefois, ceci ne change rien au fonctionnement de la barrière selon l'invention. Pour des raisons de simplicité, on considère dans la présente description, qu'une requête émise par un premier processus ayant un temps d'exécution t plus court qu'un second processus, rejoindra la barrière BS avant la requête émise par le second processus.
Dans un mode de réalisation de l'invention, l'espace de mémoire de la barrière de synchronisation BS (100) est implémenté dans l'espace de mémoire consacré au bus PCI de l'ordinateur.
Dans cet exemple, ce que l'on a appelé « requête » provient d'une instruction « load » du processeur avec une adresse de l'espace mémoire du bus PCI. Cette requête est un message sur le bus système. Cet espace de mémoire permet une interaction rapide entre les processus P et/ou requête et la barrière de synchronisation BS (100).
Si plusieurs barrières sont requises, il peut être avantageux que le gestionnaire de barrière de synchronisation gère ces barrières en relation avec des segments de mémoire, par exemple des pages de mémoire. Cette pluralité de barrières peut être branchée sur un même circuit ou sur des circuits distincts. Ainsi, la mémoire PCI offre suffisamment d'espace pour prévoir une taille prédéterminée de page de mémoire pour chaque barrière tout en permettant de fournir un accès protégé entre barrières.
Par exemple, pour des pages de 64 KB (Kilo-Bytes), ceci permet l'utilisation des 16 poids inférieurs (bits) d'une requête (appel) pour transmettre des données (notamment ADR); Le gestionnaire de barrière de synchronisation HBM (400) peut donc héberger M*64KB pages, où M est le nombre de barrières BS (100) physiques implémentées dans le gestionnaire de barrière de synchronisation HBM (400). M peut notamment être de 512, ce qui aboutit à un espace de mémoire total de 32 MB (Méga-Bytes). Ces 32 MB correspondent bien évidemment à une mémoire de type virtuelle qui n'est donc pas à considérer comme de « vrais » MB mais sont simplement vus comme tel par l'application à synchroniser. Ci-après est représenté un exemple d'une composition d'une requête qui peut être utilisée pour accéder à la mémoire (R [J..I] = bits de la requête de I à J). Cette requête comprend notamment l'adresse de la barrière BS (100), une commande en cours d'exécution (détaillée plus loin), l'indication s'il s'agit d'une synchronisation à un ou plusieurs niveaux (détaillé ci- dessous) et le nombre de processus participant à la synchronisation et donc à la barrière.
Figure imgf000012_0001
Dans le bit R[8], les valeurs 0 ou 1 correspondent respectivement à une synchronisation à un niveau et une synchronisation à deux niveaux. Un niveau de synchronisation supérieur est détaillé dans l'exemple de réalisation ci-dessous.
La figure 5 est relative à un exemple de réalisation d'un gestionnaire de synchronisation HBM (400), lequel est apte à gérer une synchronisation de niveau supérieur, et plus précisément ici à deux niveaux. Une synchronisation à deux niveaux peut par exemple être utilisée lorsque plusieurs groupes distincts de processus P doivent être synchronisés, avec chacun des groupes possédant une barrière BS (100) physique (ou matérielle). Dans ce cas, le gestionnaire de synchronisation HBM (400) doit gérer le cas où chaque groupe doit être synchronisé à lui seul, puis l'ensemble des groupes doivent être synchronisés entre eux.
La première requête reçue par la barrière BS (100) à un état prêt PRE, contient sur ses poids inférieurs une information indiquant s'il s'agit d'une synchronisation à un ou à deux niveaux. S'il s'agit d'une synchronisation à un niveau, celle-ci va être gérée par une barrière à un niveau, ou plus précisément par un état actif ACT de la barrière conçue pour un niveau (état ACT 1 N). Si au contraire il s'agit d'une synchronisation à deux niveaux, cette même barrière entrera dans un état actif ACT conçu pour deux niveaux (état ACT 2 N), auquel cas son comportement sera tel que décrit ci-après :
Lorsque toutes les requêtes ont été reçues par la barrière BS (100), celle-ci choisit un des processus P comme étant maître M parmi tous les processus P participants à la barrière BS (100). Dans un premier temps, seulement la requête du maître M se verra répondre par une donnée D spéciale indiquant qu'il est le maître du groupe. A partir de là, le maître est libre d'accomplir le second niveau de synchronisation. Ce second niveau de synchronisation peut par exemple être une barrière BS (100) de nature logicielle. Lorsque le maître M a terminé ce second niveau de synchronisation, il transmet une dernière requête à la barrière BS (100). En réponse à cette dernière requête, la barrière répond à toutes les autres requêtes issues des autres processus P participant à la barrière BS (100) (y compris le maître M), et retourne dans l'état prêt PRE. Le maître M est dynamique et peut être redéfini à chaque synchronisation.
Exemple de réalisation. Les différents états de l'automatisme de barrière représentés sur la figure 5 sont les suivants :
- état veille INACT,
- état prêt PRE,
- état actif avec synchronisation à un niveau ACT 1 N, - état actif avec synchronisation à deux niveaux ACT 2 N,
- état synchronisation SYNC, et
- état annulation ANN.
Chaque état est détaillé ci-dessous.
• INACT La barrière physique est en état veille et inactive. La seule transition possible est la transition TO. Cette transition correspond à la réception de la barrière d'une requête avec une commande de mise en état prêt PRE dite PREPA (Commande = PREPA en vue d'activer la barrière. La barrière passe à l'état prêt PRE.
• PRE
La barrière physique est prête à recevoir des requêtes des processus participants à la barrière.
Selon le mode de réalisation décrit, trois transitions peuvent avoir lieu : T1 , T2 ou T13. Selon la requête, la barrière choisira laquelle des transitions à effectuer.
• Transition T1 : Cette transition correspond à la réception de la barrière d'une requête contenant une commande d'enregistrement ENREGISTRER (Commande = ENREGISTRER) en vue d'initialiser la barrière. La requête comprend dans ses poids inférieurs, l'information qu'il y a besoin d'une synchronisation à un seul niveau (SYNC_1_N).
La barrière est activée et se trouve alors en état actif avec synchronisation à un niveau ACT 1 N.
• Transition T2 : Similairement à T1 , cette transition correspond à la réception de la barrière d'une requête avec une commande d'enregistrement ENREGISTRER en vue d'initialiser la barrière. Par contre, la requête comprend dans ses poids inférieur, l'information qu'il y a besoin d'une synchronisation à deux niveaux (SYNC_2_N). La barrière est activée et passe en état actif avec synchronisation à deux niveaux ACT 2 N. • Transition T13 : Cette transition correspond à la réception de la barrière d'une requête avec une commande d'extinction ETEINDRE (Commande = ETEINDRE) en vue d'inactiver la barrière et de passer à l'état veille INACT (voir ci-dessus).
• ACT_1_N
La barrière effectue une synchronisation à un seul niveau. Plusieurs transitions existent à partir de cet état.
• Transition T3 : Cette transition à lieu, chaque fois que la barrière BS (100) reçoit une requête d'un processus P avec une commande d'enregistrement ENREGISTRER (Commande = ENREGISTRER), et ce avant un temps limite prédéterminé (détaillé plus loin). Le compteur interne CNT (406) est décrémenté à chaque transition T3 (CNT > valeur seuil). T3 correspond sensiblement à chaque terminaison des blocs courants B, lors d'un même pas de travail W. Les blocs B "s'accumulent" (T3) au niveau de la barrière BS (100), jusqu'à ce que le compteur CNT (406) indique que tous les blocs B courants ont été exécutés (CNT = valeur seuil). Transition T4 : Cette transition à lieu, lorsque le compteur CNT (406) indique que, tous les blocs B courants ont été exécutés: La barrière reçoit une dernière commande d'enregistrement ENREGISTRER (Commande = ENREGISTRER) et le compteur est décrémenté à sa valeur seuil (CNT = valeur seuil). Il est répondu aux requêtes issues des processus P participant à la barrière BS (100). La réponse indique le succès de la synchronisation. La barrière BS (100) retourne en état prêt PRE. • Transition T5 : le compteur doit atteindre sa valeur seuil avant un temps limite prédéterminé. Le choix du seuil d'un temps limite est variable et se fait selon l'application. Si ce temps limite prédéterminé est dépassé, la transition T5 permet l'annulation de la synchronisation. Avec optionnellement retour d'un message d'erreur ou ordre d'augmentation de temps limite par exemple. Le temps limite peut être préenregistré sur une unité de contrôle munie d'un compteur de temps (« compteur chronique ») apte à effectuer un décomptage en unité de temps (par exemple μs).
• Transition T14 : Cette transition correspond à la réception de la barrière d'une requête avec une commande d'extinction ETEINDRE
(Commande = ETEINDRE) en vue d'inactiver la barrière et de passer à l'état veille INACT.
• ACT_2_N La barrière effectue une synchronisation à deux niveaux. Plusieurs transitions existent à partir de cet état.
• Transition T6 : analogue à la transition T3 (voir ci-dessus).
• Transition T7 : dans un premier temps la transition T7 est analogue à T4. En effet, T7 à lieu, lorsque le compteur CNT (406) indique que, tous les blocs B courants ont été exécutés : La barrière reçoit une dernière commande d'enregistrement ENREGISTRER (Commande = ENREGISTRER) et le compteur est davantage décrémenté et atteint sa valeur seuil (CNT = valeur seuil). Contrairement à la transition T4, ici il n'est pas répondu à l'ensemble des requêtes issues des processus P, mais seulement à l'un d'entre eux. La réponse consiste à élire l'un quelconque des processus P en tant que maître M. La barrière procède alors vers l'état synchronisation SYNC (détaillé plus loin). Lors de T7, le temps limite prédéterminé est réinitialisé.
• Transition T8 : analogue à la transition T5 (voir ci-dessus). • Transition T15 : analogue à la transition T13 (voir ci-dessus).
• SYNC
Trois transitions possibles :
• Transition T9 : le maître M reçoit une requête avec une commande d'enregistrement ENREGISTRER (Commande = ENREGISTRER), avant le temps limite prédéterminé (avec: CNT = valeur seuil). Il est répondu, à l'ensemble des processus P. La réponse indique le succès de la synchronisation. La barrière BS (100) retourne en état prêt PRE.
• Transition T10 : analogue à la transition T5 (voir ci-dessus). • Transition T16 : analogue à la transition T13 (voir ci-dessus).
• ANN
Pour fixer un temps optimal (maximum acceptable) pour l'accomplissement d'une synchronisation, la barrière BS (100) est munie d'un compteur de temps, appelé aussi compteur-chronique. Le compteur est configurable et peut décrire un temps limite. Le compteur démarre un décomptage (généralement en unité μs) à la réception de la première requête. Le temps commence alors à courir. Si le temps limite prédéterminé est dépassé avant réception de la dernière requête à la barrière BS (100), alors celle-ci transite vers l'état annulation ANN. Le temps limite peut varier selon les barrières, et plus précisément selon les différents états d'une barrière, notamment: ACT_1_N, ACT_2_N, SYNC.
En d'autres termes, si la barrière BS (100) entre en état annulation ANN, ceci est dû au fait que la limite de temps à été dépassé dans l'état précédent, avant réception de toutes les requêtes. La barrière répond alors aux requêtes déjà reçues, par un message d'échec de synchronisation. Dans la pratique, ce temps limite est programmable. Sa limite supérieure peut être fixée en fonction du contexte, notamment pour éviter des interférences avec les « time-out » du processeur.
Trois transitions existent en état annulation ANN : • Transition T1 1 : Une requête est reçue avec une commande d'enregistrement ENREGISTRER" (Commande = ENREGISTRER). Auquel cas il est répondu aux requêtes par un message d'erreur tel que décrit ci-dessus.
• Transition T12 : Une requête est reçue avec une commande indiquant le retour à l'état prêt PRE (Commande = PREPA). La barrière retourne à l'état prêt PRE (voir plus haut). Ceci, par exemple, invite l'ensemble les processus (P) à remonter vers la fin d'exécution d'un pas de travail (W) antérieur.
• Transition T17 : analogue à la transition T13 (voir ci-dessus). L'organigramme de la figure 6 reprend les principales opérations d'une barrière de synchronisation BS selon un mode de réalisation de l'invention. L'organigramme montre la barrière BS (100) dans son état prêt PRE (opération 700). Le premier processus P ayant terminé son bloc B, informe (par un appel) la barrière BS (100) au moyen d'une requête visant le gestionnaire HBM (400) (opération 702). La requête comprend l'information sur le ou les niveaux de synchronisation (commande = ENREGISRTER pour ACT_1_N ou ACT_2_N par exemple). Le compteur CNT (406) est initialisé (généralement à n = nombre de processus P) et la barrière BS (100) stocke d'une part un identifiant SVEJD Req correspondant audit premier processus P et d'autre part l'information sur le ou les niveaux de synchronisation SVE N (opération 704). La barrière BS (100) activée attend dès lors les prochains appels des autres processus P (opération 706). Si le temps limite prédéterminé est dépassé ou si la barrière BS (100) reçoit une requête avec une commande d'extinction (commande = ETEINDRE) (opération 714), la barrière passe respectivement en état d'annulation ANN ou veille INACT (opération 716). Par contre, si un autre processus P informe la barrière de la terminaison de son bloc en cours (sans dépassement du temps limite t_Lim, et sans commande = ETEINDRE), le compteur CNT (406) est décrémenté (opération 708, avec m = nombre de processus n'ayant pas encore terminé leur bloc B lors du pas de travail W en cours). Parallèlement à la décrémentation, la barrière stocke l'identifiant SVEJD Req correspondant au processus P ayant dernièrement informé la barrière BS (100) (opération 708). La barrière BS (100) vérifie ensuite si le compteur CNT (406) a atteint sa valeur seuil (opérations 710 et 712). Si non, (opération 710 ; CNT > 0) la barrière retourne en état d'attente (opération 706); Si oui (opération 712 ; CNT= 0), la barrière progresse en vue de réaliser la synchronisation (selon niveau fixé à l'opération 704). Après une synchronisation ayant été fixée à un niveau (opération 720 ; ACT 1 N), la barrière répond à chaque processus P par des donnés D, comprenant par exemple une commande d'avancement vers un prochain pas de travail W, (opération 740). Lorsque le niveau de synchronisation a été fixé à deux niveaux (opération 730 ; ACT 1 N), c'est-à-dire par exemple pour plusieurs groupes de processus P (voir plus haut), la barrière BS (100) élit un maître M parmi les processus P en cours (opération 732 ; CH M) et effectue une seconde synchronisation (opération 734 ; SYNC) avant la réponse par des donnés D (opération 740). La synchronisation se termine (opération 750) avec le retour en état prêt PRE (command = PREPA) ou avec une inactivation de la barrière (command = ETEINDRE).
Bien évidemment, l'invention ne se limite pas aux modes de réalisation décrits ci-avant mais englobe toutes les réalisations que pourra envisager l'homme de l'art dans le cadre des revendications annexées.
Ainsi dans le mode de réalisation décrit, une seule barrière BS est utilisée pour la synchronisation des processus. Il peut être utile d'intégrer dans un système informatique plusieurs barrières de synchronisation BS et notamment pour permettre de synchroniser plusieurs groupes de processus, chaque groupe concourant à l'exécution d'une tâche différente. Par exemple en calcul scientifique sur une machine de 16 cœurs, on peut envisager que 2 calculs indépendants se fassent en utilisant chacun 8 cœurs, on aura alors 2 groupes de 8 processus, chaque processus s'exécutant sur un cœur différent. Dans cet exemple on aura besoin de 2 barrières.
Lorsque plusieurs barrières de synchronisation BS sont utilisées celles-ci peuvent bien évidemment être implémenté dans un même composant ou en encore dans des composants différents. En effet, le dispositif peut comporter plusieurs circuits matériels, dont on accède aux espaces d'adresses par des segments tirés des desdites données de chaque appel. Dans ce cas on peut prévoir que chacun des circuits matériels est branché soit sur un même circuit, soit des circuits distincts.
On note également que l'on peut aisément envisager un mélange entre barrières de type logiciel et des barrières selon l'invention, à savoir avec un circuit matériel. Le dispositif informatique décrit ici peut donc en outre comprendre une barrière de synchronisation logicielle, opérant en combinaison avec ledit le circuit matériel.

Claims

REVENDICATIONS
1. Dispositif informatique à barrière de synchronisation, comprenant :
- une mémoire (RAM, 202), - une unité de traitement, capable de traitement multiprocessus sur différents processeurs (PZ, 200) et permettant une exécution en parallèle de blocs (B) par des processus (P), lesdits blocs (B) étant associés par groupe en pas de travail (W) successifs,
- un circuit matériel (HBM, 400) avec un espace d'adresse exploitable vers la mémoire (RAM, 202), capable de recevoir un appel de chaque processus (P) indiquant la fin d'exécution d'un bloc (B) en cours, chaque appel comprenant des données, et ledit circuit matériel (HBM, 400) étant agencé pour autoriser l'exécution de blocs (B) d'un pas de travail ultérieur lorsque l'ensemble des blocs (B) du pas de travail en cours (W) ont été exécutés, dont on accède à l'espace d'adresse par segments tirés desdites données de chaque appel.
2. Dispositif selon la revendication 1 , dans lequel le circuit matériel comprend un microprogramme (micro-Prog, 402) pour effectuer un traitement tiré des données d'au moins un appel.
3. Dispositif informatique selon la revendication 2, dans lequel le traitement comprend la suspension de réponses à chaque appel, jusqu'à vérification d'une condition de fin indiquant que tous les processus (P) ont signalé la fin d'exécution du bloc (B) du pas de travail en cours (W).
4. Dispositif informatique selon la revendication 2 ou 3, dans lequel le circuit matériel (HBM, 400) est agencé pour répondre à chaque appel par une sortie de données (D) et d'autoriser les processus (P) à transiter vers le pas de travail (W) ultérieur lorsque tous les processus ont signalé la fin d'exécution du bloc (B) du pas de travail en cours (W).
5. Dispositif informatique selon l'une des revendications 2 à 4, dans lequel le traitement comprend l'extraction du nombre de processus à partir d'un premier appel, puis le décomptage sur ce nombre à partir d'autres appels, jusqu'à vérification de ladite condition de fin.
6. Dispositif informatique selon la revendication 5, dans lequel chaque appel indique ledit nombre de processus.
7. Dispositif informatique selon l'une des revendications 2 à 6, dans lequel l'ensemble des appels sont de même type (ENREGISRTER) défini par les données de chaque appel.
8. Dispositif informatique selon l'une des revendications précédentes, dans lequel le dispositif comporte plusieurs circuits matériels, dont on accède aux espaces d'adresses par segments tirés desdits desdites données de chaque appel.
9. Dispositif informatique selon la revendication 8, dans lequel chacun desdits circuits matériels est branché sur un même circuit.
10. Dispositif informatique selon la revendication 8, dans lequel chacune chacun desdits circuits matériels est branché sur un circuit distinct.
1 1 . Dispositif informatique selon l'une des revendications précédentes, dans lequel le dispositif comprend en outre une barrière de synchronisation logicielle, opérant en combinaison avec ledit le circuit matériel.
12. Dispositif informatique selon l'une des revendications précédentes, dans lequel le dispositif comprend en outre un gestionnaire d'accès en mémoire (CACHE
COHER MGR, 206), et dans lequel lesdits appels vers le circuit matériel (HBM, 400) sont directs, évitant le gestionnaire d'accès en mémoire.
13. Dispositif informatique selon l'une des revendications 2 à 12, dans lequel le dispositif comprend en outre une mémoire dédiée (Ded_MEM, 404) en liaison avec ledit microprogramme (micro-Prog, 402).
14. Procédé de traitement informatique au niveau processus, du type comprenant les étapes suivantes : a. décomposer une tâche (T) en sous-tâches exécutées en tant que processus (P) composés de blocs (B) successifs ; b. prévoir une barrière de synchronisation (BS, 100) munie d'un compteur
(CNT, 406) en rapport avec le nombre de processus (P), dans un gestionnaire physique de barrière (HBM, 400) ; c. dans chaque processus (P), définir un premier bloc (B) comme bloc en cours et l'exécuter, tout en accédant à ladite barrière de synchronisation (BS, 100) pour décrémenter ledit compteur (CNT, 406) lorsque l'exécution de ce bloc (B) en cours se termine ; d. dans chaque processus (P) où l'exécution du bloc (B) en cours est terminée, attendre une réponse de ladite barrière de synchronisation (BS, 100), la réponse étant directement liée au compteur (CNT, 406) et émise lorsque celui-ci indique que tous les blocs (B) courants sont exécutés, lorsque tous les blocs (B) courants sont exécutés, définir de nouveaux blocs (B) en cours à partir du bloc suivant de chacun des processus (P), et répéter les étapes c. et d. avec ces nouveaux blocs (B) en cours.
PCT/FR2009/052322 2008-12-16 2009-11-27 Gestionnaire physique de barriere de synchronisation entre processus multiples WO2010070222A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
ES09797109.7T ES2689125T3 (es) 2008-12-16 2009-11-27 Gestor físico de barrera de sincronización entre procesos múltiples
BRPI0917747A BRPI0917747A2 (pt) 2008-12-16 2009-11-27 dispositivo de informática com barreira de sincronização e processo de tratamento da informática
US13/139,989 US9218222B2 (en) 2008-12-16 2009-11-27 Physical manager of synchronization barrier between multiple processes
EP09797109.7A EP2366147B1 (fr) 2008-12-16 2009-11-27 Gestionnaire physique de barriere de synchronisation entre processus multiples
JP2011540156A JP5626690B2 (ja) 2008-12-16 2009-11-27 マルチプロセス間のバリアの物理マネージャ

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0807089 2008-12-16
FR0807089A FR2939922B1 (fr) 2008-12-16 2008-12-16 Gestionnaire physique de barriere de synchronisation entre processus multiples

Publications (1)

Publication Number Publication Date
WO2010070222A1 true WO2010070222A1 (fr) 2010-06-24

Family

ID=40785419

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/052322 WO2010070222A1 (fr) 2008-12-16 2009-11-27 Gestionnaire physique de barriere de synchronisation entre processus multiples

Country Status (7)

Country Link
US (1) US9218222B2 (fr)
EP (1) EP2366147B1 (fr)
JP (1) JP5626690B2 (fr)
BR (1) BRPI0917747A2 (fr)
ES (1) ES2689125T3 (fr)
FR (1) FR2939922B1 (fr)
WO (1) WO2010070222A1 (fr)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5568048B2 (ja) * 2011-04-04 2014-08-06 株式会社日立製作所 並列計算機システム、およびプログラム
US9195516B2 (en) 2011-12-01 2015-11-24 International Business Machines Corporation Determining collective barrier operation skew in a parallel computer
US9092272B2 (en) * 2011-12-08 2015-07-28 International Business Machines Corporation Preparing parallel tasks to use a synchronization register
US8924763B2 (en) * 2011-12-15 2014-12-30 International Business Machines Corporation Synchronizing compute node time bases in a parallel computer
JP5994601B2 (ja) * 2012-11-27 2016-09-21 富士通株式会社 並列計算機、並列計算機の制御プログラム及び並列計算機の制御方法
US20150033234A1 (en) * 2013-07-23 2015-01-29 Qualcomm Incorporated Providing queue barriers when unsupported by an i/o protocol or target device
US9501300B2 (en) * 2013-09-16 2016-11-22 General Electric Company Control system simulation system and method
WO2015163780A1 (fr) * 2014-04-23 2015-10-29 Sciensys Sas Parallélisation de programme au niveau de la procédure dans des systèmes à multiples processeurs avec mémoire à partage logique
US10318355B2 (en) * 2017-01-24 2019-06-11 Oracle International Corporation Distributed graph processing system featuring interactive remote control mechanism including task cancellation
US11353868B2 (en) * 2017-04-24 2022-06-07 Intel Corporation Barriers and synchronization for machine learning at autonomous machines
US10678925B2 (en) * 2017-06-26 2020-06-09 Microsoft Technology Licensing, Llc Data quarantine and recovery
JP7159696B2 (ja) * 2018-08-28 2022-10-25 富士通株式会社 情報処理装置，並列計算機システムおよび制御方法
US10824481B2 (en) * 2018-11-13 2020-11-03 International Business Machines Corporation Partial synchronization between compute tasks based on threshold specification in a computing system
US11409579B2 (en) * 2020-02-24 2022-08-09 Intel Corporation Multiple independent synchonization named barrier within a thread group
US11531565B2 (en) * 2020-05-08 2022-12-20 Intel Corporation Techniques to generate execution schedules from neural network computation graphs
US11461130B2 (en) 2020-05-26 2022-10-04 Oracle International Corporation Methodology for fast and seamless task cancelation and error handling in distributed processing of large graph data
US11720360B2 (en) 2020-09-11 2023-08-08 Apple Inc. DSB operation with excluded region

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070113233A1 (en) * 2005-11-10 2007-05-17 Collard Jean-Francois C P Program thread synchronization

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3482897B2 (ja) * 1999-01-20 2004-01-06 日本電気株式会社 クラスタ型並列計算機システムおよびプロセッサ間バリア同期方法
US6766437B1 (en) * 2000-02-28 2004-07-20 International Business Machines Corporation Composite uniprocessor
US7100021B1 (en) * 2001-10-16 2006-08-29 Cisco Technology, Inc. Barrier synchronization mechanism for processors of a systolic array
JP4448784B2 (ja) * 2005-03-15 2010-04-14 株式会社日立製作所 並列計算機の同期方法及びプログラム
US8645959B2 (en) * 2005-03-30 2014-02-04 Intel Corporaiton Method and apparatus for communication between two or more processing elements
US7865911B2 (en) * 2005-11-08 2011-01-04 Microsoft Corporation Hybrid programming
US7861060B1 (en) * 2005-12-15 2010-12-28 Nvidia Corporation Parallel data processing systems and methods using cooperative thread arrays and thread identifier values to determine processing behavior
TWI318750B (en) * 2006-09-22 2009-12-21 Nuvoton Technology Corp Software development methods, systems, and storage media storing software developed thereby
US20080109604A1 (en) * 2006-11-08 2008-05-08 Sicortex, Inc Systems and methods for remote direct memory access to processor caches for RDMA reads and writes
JP2008234074A (ja) * 2007-03-16 2008-10-02 Fujitsu Ltd キャッシュ装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070113233A1 (en) * 2005-11-10 2007-05-17 Collard Jean-Francois C P Program thread synchronization

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Retrieved from the Internet <URL:http://portal.acm.org/citation.cfm?id=1105743> [retrieved on 20090625] *
SAMPSON J ET AL: "Fast Synchronization for Chip Multiprocessors", INTERNET CITATION, vol. 33, no. 4, November 2005 (2005-11-01), ACM SIGARCH Computer Architecture News, pages 64 - 69, XP002417542, Retrieved from the Internet <URL:http://www.cse.ucsd.edu/~rakumar/dasCMP05/paper07.pdf> [retrieved on 20070123] *
W. E. COHEN, H. G. DIETZ, J. B. SPONAUGLE: "Dynamic Barrier Architecture For Multi-Mode Fine-Grain Parallelism Using Conventional Processors", INTERNET ARTICLE, March 1994 (1994-03-01), pages 1 - 23, XP002533890, Retrieved from the Internet <URL:http://aggregate.org/TechPub/TREE94_10/tree94_10.ps> [retrieved on 20090625] *

Also Published As

Publication number Publication date
JP2012512452A (ja) 2012-05-31
JP5626690B2 (ja) 2014-11-19
BRPI0917747A2 (pt) 2016-02-16
FR2939922A1 (fr) 2010-06-18
EP2366147B1 (fr) 2018-05-09
EP2366147A1 (fr) 2011-09-21
US9218222B2 (en) 2015-12-22
FR2939922B1 (fr) 2011-03-04
ES2689125T3 (es) 2018-11-08
US20110252264A1 (en) 2011-10-13

Similar Documents

Publication Publication Date Title
EP2366147B1 (fr) Gestionnaire physique de barriere de synchronisation entre processus multiples
EP1805611B1 (fr) Procede d&#39;ordonnancement de traitement de tâches et dispositif pour mettre en oeuvre le procede
FR2632096A1 (fr) Systeme de microcalculateur a bus multiple avec arbitrage d&#39;acces aux bus
FR2931970A1 (fr) Procede de generation de requetes de manipulation d&#39;une base de donnees d&#39;initialisation et d&#39;administration d&#39;une grappe de serveurs , support de donnees et grappe de serveurs correspondants
FR3007542A1 (fr) File d&#39;echange de donnees ayant une profondeur illimitee
EP1158405A1 (fr) Système et méthode de gestion d&#39;une architecture multi-ressources
FR3047821A1 (fr) Procede et dispositif de gestion d&#39;un appareil de commande
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
EP1594065A1 (fr) Système sur une puce avec unité d&#39;arbitrage, et clé de stockage l&#39;incorporant
EP1081597B1 (fr) Dispositif à plusieurs processeurs ayant une interface pour une mémoire collective
EP2802992A1 (fr) Systeme et procede de gestion de correspondance entre une memoire cache et une memoire principale
EP1341087B1 (fr) Procédé et système de gestion d&#39;un journal personnel d&#39;évènements
WO2013175138A1 (fr) Procede, dispositif et programme d&#39;ordinateur de controle dynamique de distances d&#39;acces memoire dans un systeme de type numa
FR2995424A1 (fr) Procede et dispositif de decompte du temps deporte pour unite de traitement dans un systeme de traitement de l&#39;information
EP1603049A1 (fr) Interfacage de modules fonctionnels dans un systeme sur une puce
WO2013110816A2 (fr) Procédé d&#39;utilisation d&#39;une mémoire partagée
EP0822495B1 (fr) Distribution de tickets dans un système informatique multinodal
FR2656707A1 (fr) Procede d&#39;exploitation d&#39;un bus d&#39;ordinateur.
WO2011110790A1 (fr) Procédé de configuration d&#39;un système informatique, programme d&#39;ordinateur et système informatique correspondants
EP2221730B1 (fr) Procédé d&#39;accès direct et concurrent de plusieurs unités de traitment virtuelles à une unité périphérique
WO2019129958A1 (fr) Procede de stockage de donnees et procede d&#39;execution d&#39;application avec reduction du temps d&#39;acces aux donnees stockees
EP1341093B1 (fr) Accès à une ressource collective
EP3729273A1 (fr) Systeme et procede d&#39;elaboration et d&#39;execution de tests fonctionnels pour grappe de serveurs
WO2013038112A1 (fr) Procede, dispositif et programme d&#39;ordinateur pour allouer dynamiquement des ressources d&#39;un cluster a l&#39;execution de processus d&#39;une application
EP1293909B1 (fr) Controle d&#39;accès dynamique d&#39;une fonction à une ressource collective.

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: 09797109

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009797109

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011540156

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 13139989

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: PI0917747

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20110615