FR2696259A1 - Organisation en tâches et en modules d'une exécution dans un processeur. - Google Patents

Organisation en tâches et en modules d'une exécution dans un processeur. Download PDF

Info

Publication number
FR2696259A1
FR2696259A1 FR9311209A FR9311209A FR2696259A1 FR 2696259 A1 FR2696259 A1 FR 2696259A1 FR 9311209 A FR9311209 A FR 9311209A FR 9311209 A FR9311209 A FR 9311209A FR 2696259 A1 FR2696259 A1 FR 2696259A1
Authority
FR
France
Prior art keywords
module
task
data
tasks
time
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
FR9311209A
Other languages
English (en)
Inventor
Eric C Anderson
Hugh B Svendsen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Computer Inc
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 Apple Computer Inc filed Critical Apple Computer Inc
Publication of FR2696259A1 publication Critical patent/FR2696259A1/fr
Pending legal-status Critical Current

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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues

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)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente invention concerne un procédé de groupage de tâches (611 à 614, 631 à 633) à exécuter par un processeur. Il comprend les étapes consistant à: créer une donnée de tâche incluant un élément identifiant d'une première tâche, un champ servant à référencer une donnée de tâche suivante; créer une référence à une donnée de premier module (621a) dans ladite donnée de tâche, ladite donnée de premier module (621a) représentant une première partie de ladite tâche; et lier ladite donnée de premier module à une deuxième donnée de module servant à une deuxième partie de ladite tâche (exerçant des fonction liées à ladite première partie de ladite tâche. Elle concerne aussi un appareil correspondant et une donnée de première tâche comprenant un élément identifiant; un champ de liaison de celle-ci avec une donnée de tâche suivante et. un champ de liaison de ladite donnée de première tâche à une donnée de premier module.

Description

La présente invention concerne des processeurs de systèmes d'ordinateurs. Spécifiquement, la présente invention concerne la gestion de tâches dans un processeur.
Des applications modernes, comme des applications a médias multiples ou multimédias dans lesquelles des communications textuelles, audio, parlées, vidéo et de données sont toutes traitées en temps réel, présentent des exigences spéciales. Des micro-ordinateurs classiques commercialisés n'offrent pas jusqu'ici la puissance de traitement nécessaire pour effectuer toutes ces tâches dans un environnement en temps réel. Des architectures de modem qui sont prévues pour traiter la charge associée à la mise en oeuvre de ces types de tâches en temps réel ont parfois dicté l'utilisation d'un processeur de signaux numériques ou DSP.Cependant, lors de l'utilisation d'un processeur de signaux numériques, il faut encore gérer de façon efficace des tâches consommant une grande quantité de largeur de bande de traitement pour que tout le traitement soit exécuté à l'intérieur d'intervalles spécifiques de temps.
Une approche de la gestion des tâches de traitement qui doivent être achevées dans un intervalle spécifié de temps consiste à diviser le temps en une série discrète d'unités appelées "séquences". Les séquences sont des intervalles de temps dans lesquels un signal d'interruption ou un autre signal de synchronisation est engendré à un processeur à des intervalles réguliers et chacune des tâches en cours d'exécution par le processeur est prise en charge successivement. Dans un tel système de traitement à base de séquences, chacune des tâches est typiquement liée ou associée à une autre à l'aide d'une certaine structure de données, et la structure de données est traversée pendant la prise en charge de l'interruption au début de la séquence de façon que chaque tâche soit prise en charge à l'intérieur de la séquence.Une longueur de séquence est typiquement choisie, entre autres considérations, sur la base d'une mémoire de cache disponible dans le système, et de la fréquence minimale possible à laquelle des tâches spécifiques doivent être prises en charge. Par exemple une application utilisant une interface numérique pour instruments musicaux, appelée application MIDI, exige une durée minimale de séquence de 2 à 4 millisecondes. Des applications utilisant le modem de donnée V.32 exigent une limite maximale de séquence de 13 millisecondes. Dans tous les cas, une dimension de séquence est typiquement commandée par l'application, le matériel disponible et d'autres facteurs.
Une technique de l'art antérieur de l'organisation des tâches consiste à les placer dans une liste linéaire, simple. Dans cette approche, chaque tâche est exécutée à son tour. Une défaillance de cette approche est que des tâches qui sont liées l'une à l'autre ne sont pas groupées logiquement. De plus, cette approche de l'art antérieur souffre du défaut qu'il n'existe aucune distinction entre des tâches qui exigent une prise en charge à des intervalles réguliers et celles qui n'exigent qu'une prise en charge occasionnelle. Par conséquent, le temps global d'exécution du processeur peut être handicapé, et certaines applications peuvent être gênées ou ne pas pouvoir fonctionner du tout, lorsque les deux types de tâches sont exécutés sans prendre en compte les exigences de synchronisation des tâches.De plus, puisque toutes les tâches sont liées en succession, une allocation de ressources peut ne pas être effectuée de façon optimale selon une activité de fonction qui comprend une ou plusieurs tâches. Par exemple, certaines des tâches qui sont liées en succession peuvent être reliées entre elles, et une allocation inutile ou inefficace de ressources à chacune des tâches peut en résulter. Ceci se produit parce que des accès en mémoire et d'autres types d'accès à des ressources peuvent être effectués de façon répétitive en fonction de l'emplacement où des tâches reliées apparaissent dans la liste d'exécution.
Une autre défaillance encore de l'organisation des tâches de l'art antérieur est que des conditions d'erreurs qui sont engendrées sur une tâche peuvent provoquer ou ne pas provoquer nécessairement l'abandon d'autres tâches dépendantes. Par conséquent, le programmeur d'application doit inclure, dans chacune de ses tâches, des sous-programmes de traitement d'erreur qui déterminent si une tâche précédente dont elle dépend a été achevée normalement. Ceci empêche l'exécution d'une tâche parce qu'elle ne fonctionne pas d'une façon appropriée en l'absence d'un achèvement normal de la tâche précédente. Ceci exige un travail additionnel du programmeur ainsi qu'un temps inactif additionnel du système de traitement.En général, la gestion des tâches par client ou par processus est difficile en utilisant le procédé de l'art antérieur ou les tâches sont prises en charge et exécutées de façon successive
La liste d'exécution successive des tâches selon l'art antérieur n'offre de plus aucun moyen de réaliser certains groupes de tâches selon des successions différentes. Certaines tâches peuvent fonctionner de façon inutile, même lorsqu'unie tâche antérieur de commande a déterminé que seul un nombre limité de tâches liées doivent être exécutées.
Evidemment, chaque tâche exige un code de commande d'exécution afin de déterminer si la tâche doit être effectuée ou non. Ici aussi, un temps inactif inutile est consommé en appelant chaque tâche pour son exécution, même si ceci n'est pas nécessaire, en raison de la charge et de la sauvegarde de contexte de processeur ainsi que de la restitution de ressources nécessaires à partir d'une mémoire ou d'une mémoire non volatile. Ceci exige que le programmeur possède une connaissance en profondeur du système d'exécution sous-jacent et de son organisation de fonctions, et exige aussi une complexité additionnelle pour chacune des tâches qui sont liées.
Une autre insuffisance encore de l'approche de l'art antérieur, consistant à lier des tâches de façon successive en une liste de tâches, est que l'organisation n'offre aucun moyen de gérer la charge de traitement pour un groupe de tâches qui doivent fonctionner dans un intervalle spécifique de temps réel, là ou il faut des combinaisons différentes des tâches selon le statut de la fonction. Un tel moyen est important pour garantir que chacune des fonctions comprenant une ou plusieurs tâches est prise en charge pendant une séquence. Il en résulte une difficulté de gestion des ressources en temps réel et ceci peut provoquer la défaillance d'un traitement en temps réel en raison d'une détermination incorrecte de la charge d'exécution nécessaire.
L'un des buts de la présente invention est de réaliser un moyen efficace d'organisation des tâches qui groupe des tâches par fonction.
Un autre des buts de la présente invention est de fournir un moyen d'organiser des tâches d'une manière telle que des conditions d'erreur et d'autres informations d'état peuvent être facilement maintenues parmi des groupes de tâches.
Un autre des buts de la présente invention est de réaliser un moyen de commande de flux à l'intérieur d'une tâche d'une manière telle que des ressources ne sont pas consommées inutilement lorsqu'il n'est pas nécessaire que certaines sous-tâches ou modules soient effectués.
Un autre des buts de la présente invention est de réaliser un moyen facilitant une utilisation efficace de la puissance de traitement pour tous les types de tâches.
Un autre des buts de la présente invention est de réaliser un moyen de synchronisation de l'exécution de diverses tâches à l'intérieur d'intervalles spécifiques de temps.
Ces buts, ainsi que d'autres, sont atteints grâce à l'invention qui présente trois aspects.
Selon un premier aspect, l'invention fournit un procédé de groupage de tâches à exécuter par un processeur caractérisé en ce que
il comprend les étapes consistant à:
a. créer une donnée de tâche, ladite donnée de tâche incluant un élément identifiant d'une première tâche, un champ servant à référencer une donnée de tâche suivante;
b. créer une référence à une donnée de premier module dans ladite donnée de tâche, ladite donnée de premier module représentant une première partie de ladite tâche; et
c. lier ladite donnée de premier module à une deuxième donnée de module servant à une deuxième partie de ladite tâche exerçant des fonction liées à ladite première partie de ladite tâche.
Le procédé peut comprendre en outre le fait de relier ladite donnée de deuxième module avec une donnée de troisième module pour une troisième partie de ladite tâche exerçant des fonctions liées à ladite première et à ladite deuxième parties de ladite tâche.
De préférence, le procédé comprend en outre le fait de relier successivement ladite donnée de deuxième module avec une série de données de quatrièmes modules pour les parties restantes de ladite tâche exerçant des fonction liées à ladite première et à la dite deuxième parties de ladite tâche.
La donnée de premier module peut contenir une référence à un code exécutable de ladite première partie de ladite tâche.
La donnée de premier module peut contenir une référence aux sections de ressources exigées par ledit premier module exécutable.
Dans ce cas, les sections de ressources exigées par ledit premier module peuvent inclure des tampons exigés par le premier module; elles peuvent inclure aussi des variables exigées par le premier module, et/ou des tables exigées par le premier module, et/ou des récipients primaires et secondaires exigés par le premier module, et/ou des interconnexions à tampons entre le premier module et ledit deuxième module.
La donnée de deuxième module peut contenir une référence au code exécutable de ladite deuxième partie de ladite tâche.
La donnée de deuxième module peut contenir une référence aux sections de ressources exigées par ledit deuxième module exécutable. Les sections de ressources exigées par ledit deuxième module peuvent alors inclure des interconnexions à tampons entre le premier module et ledit deuxième module.
Dans le cas de la modalité préférée mentionnée ci-dessus, chaque donnée de ladite série de données de quatrième module peut contenir une référence au code exécutable desdites parties restantes de ladite tâche, et/ou une référence aux sections de ressources exigées par lesdites parties restantes dudit code exécutable de ladite tâche, ces sections éventuelles de ressources exigées par chacune des données de ladite série de données du quatrième module pouvant en particulier inclure des interconnexions à tampons entre un module précédent et un module suivant.
Ladite donnée de tâche peut inclure des interconnexions à tampons entre ladite donnée de tâche précédente et ladite donnée de tâche suivante.
Ladite donnée de premier module inclut des interconnexions à tampons avec ladite donnée de deuxième module et ladite donnée de deuxième module inclut des interconnexions à tampons avec ladite donnée de premier module.
Le procédé peut comprendre en outre une exécution d'une tâche associée à la donnée de tâche précédente, puis une exécution de la tâche actuelle, comprenant les étapes consistant à:
a. référencer la donnée de premier module en utilisant la donnée de tâche;
b. charger le contexte du premier module en utilisant des sections de ressources spécifiées dans ladite donnée de premier module;
c. exécuter ladite donnée de premier module; et
d. sauvegarder le contexte de ladite donnée de premier module.
Dans ce dernier cas, le procédé peut comprendre en outre une exécution des étapes b à d, la donnée de deuxième module devenant la donnée de premier module et la donnée de premier module devenant la donnée de tâche.
Le processeur peut être un processeur de signaux numériques ou DSP.
Selon un deuxième aspect, la présente invention réalise un appareil de groupage et d'exécution de tâches par un processeur, caractérisé en ce qu'il comprend:
a. un moyen de création d'un moins une donnée de tâche, la donnée de tâche incluant un élément identifiant d'une premier tâche et une référence à une donnée de tâche suivante;
b. un moyen de création d'une référence à une donnée de premier module dans ladite donnée de tâche, ladite donnée de premier module représentant un premier module exécutable de ladite tâche; et
c. un moyen de liaison de ladite donnée de premier module à une donnée de deuxième module représentant un deuxième module exécutable exerçant des fonctions liées audit premier module exécutable.
L'appareil peut comprendre en outre un moyen de liaison de ladite donnée de deuxième module à une série de données de quatrième module pour les parties restantes de ladite tâche exerçant des fonctions liées à ladite et à ladite deuxième parties de ladite tâche.
La donnée de premier module peut contenir une référence au code exécutable de ladite première partie de ladite tâche.
La donnée de premier module peut contenir une référence aux sections de ressources exigées par ledit premier module exécutable: ces ressources exigées par ledit premier module peuvent en particulier inclure des tampons exigés par le premier module, et/ou des variables exigées par le premier module, et/ou des tables exigées par le premier module, et/ou des récipients primaires et secondaires exigés par le premier module, et/ou des interconnexions à tampons entre le premier module et ledit deuxième module.
La donnée de deuxième module peut contenir une référence au code exécutable de ladite deuxième partie de ladite tâche.
La donnée de deuxième module peut contenir une référence aux sections de ressources exigées par ledit deuxième module exécutable; ces sections de ressources exigées par ledit deuxième module peuvent alors inclure des interconnexions à tampons entre ledit premier module et ledit deuxième module.
Selon un troisième aspect, l'invention fournit une donnée de première tâche représentée comme série d'impulsions électriques dans un système de traitement de donnée pour représenter une première tâche dans une liste de tâches à exécuter par ledit système de traitement de données, caractérisé en ce que
ladite donnée de première tâche comprend:
a. un élément identifiant par ladite première tâche;
b. un champ de liaison de ladite donnée de première tâche avec une donnée de tâche suivante, représentant une tâche suivante dans ladite liste de tâches;
c. un champ de liaison de ladite donnée de première tâche à une donnée de premier module, ladite donnée de module représentant un premier module qui comprend une première fonction de ladite première tâche, ladite donnée de premier module comprenant::
i. une référence à un premier code exécutable pour ledit premier module;
il. un champ de liaison de ladite donnée de premier module à une donnée de module suivante; et
iii. un champ de spécification des interconnexions à tampons entre le premier module et le module suivant.
En groupant entre eux les modules liés qui forment une tâche, des conditions d'erreur et des exigences de ressources de chacune des tâches ou de chacun des modules peuvent être traités de façon plus efficace. Par exemple, selon un mode de réalisation, des modules peuvent référencer des zones communes de mémoire qu'ils exigent, par exemple des sections, de sorte qu'un chargement/une sauvegarde inutile de donnée dans des zones communes de mémorisation peuvent être évités.
Ces buts, particularités et avantages de la présente invention, ainsi que d'autres, seront mieux compris à l'aide de la description qui suit, donnée à titre d'exemple et non à titre limitatif, d'un mode de réalisation de la présente invention et des figures annexées dans lesquelles des références similaires désignent des éléments similaires et dans lesquelles::
La Figure 1 est schéma fonctionnel du système d'ordinateur qui peut être utilisé par le mode de réalisation préféré de la présente invention;
la Figure 2 illustre la structure d'un système d'exploitation qui est utilisé pour gérer des tâches et des clients en utilisant co-processeur, par exemple un processeur de signaux numériques ou DSP;
la Figure 3 illustre l'organisation de données associées à chaque module dans une tâche;
la Figure 4 illustre le mode de réalisation actuellement préféré d'une section dans un module selon la présente invention;
la Figure 5 illustre un exemple de diverses références de ressources associées à un module selon la présente invention;
la Figure 6 illustre l'organisation de tâches en une liste de tâches qui peuvent être exécutées dans un processeur de signaux numériques;;
la Figure 7a représente une organisation de temps en intervalles discrets appelés des séquences;
la Figure 7b représente la latence de traitement de donnée dans un système à base de séquences;
la Figure 8 représente la division d'une séquence en tranches de temps réel et de temps partagé;
la Figure 9 est une représentation plus détaillée de la division d'une séquence en tranches de temps réel et de temps partagé, ainsi que des opérations associées de charge et de mémorisation exigées par ces tâches.
la Figure 10 est une vue détaillée d'une tranche de temps réel d'une séquence ainsi que du chargement et de la sauvegarde de contextes associées pendant l'exécution de chaque traitement en temps réel.
La Figure 11 est un schéma logique représentant le processus utilisé pour la prise en charge de tâches en temps réel et en temps partagé.
La Figure 12 représente l'organisation d'une tâche prise comme exemple, qui comprend une série de modules liés et associés l'un à l'autre.
La Figure 13 représente un procédé utilisé par le mode de réalisation préféré pour commander le flux d'exécution de modules d'une tâche donnée.
Les Figures 14a à 14d représentent divers exemples d'utilisation du procédé d'exécution de flux de tâche décrit à la Figure 13 ci-dessus.
La Figure 15 représente un schéma logique du procédé utilisé pour établir des activations de tâche successives et précises, liées aux séquences.
La Figure 16 représente un schéma logique du procédé d'activation de la succession spécifiée à la
Figure 15.
La Figure 17 représente un schéma logique de la partie concernée du sous-programme d'exécution du noyau résidentiel du processeur de signaux numériques qui effectue réellement l'activation de tâche telle qu'elle est établie à la Figure 15 et à la Figure 16.
La Figure 18 représente un schéma logique d'une variante du processus d'activation / désactivation de tâche.
On va maintenant décrire de façon détaillée la présente invention.
La présente demande est liée aux demandes de brevet également en cours d'examen suivantes, déposées simultanément avec la présente:
une demande de brevet intitulée INTERTASK BUFFER
AND CONNECTIONS, ctest-a-dire tampon et connexions entre tâches, dont les inventeurs sont A.Philip Sohn et Eric Anderson et qui a reçu le numéro de série
Une demande d'application intitulée A METHOD AND
MEANS FOR PROVIDING MULTIPLE CLIENTS SIMULTANEOUS
ACCESS TO A SOUND DATA STREAM, c'est-à-dire un procédé et un moyen de réaliser un accès simultanés de clients multiples à un train de données sonores, dont les inventeurs sont Eric Anderson et Hugh Svendsen et qui a reçu le numéro de série
Une demande d'application intitulée APPARATUS AND
METHOD FOR HANDLING FRAME OVERRUNS IN A DIGITAL SIGNAL
PROCESSING SYSTEM, c'est-à-dire appareil et procédé de traitement de dépassements de séquences dans un système de traitement de signaux numériques, dont les inventeurs sont Eric Anderson et Hugh Svendsen et qui a reçu le numéro de série
Une demande d'application intitulée APPARATUS AND
METHOD FOR ALLOCATING PROCESSING TIME IN A FRAME-BASED
COMPUTER SYSTEM, c'est-à-dire appareil et procédé d'allocation de temps de traitement dans un système d'ordinateur à base de séquences, dont les inventeurs sont Eric et Anderson et A. Philip Sohn et qui a reçu le numéro de série
Une demande de brevet intitulée EXECUTION CONTROL
FOR PROCESSOR TASKS, c'est-à-dire commande d'exécution pour des tâches de processeurs, dont les inventeurs sont Eric Anderson et Hugh B. Svendsen et qui a reçu le numéro de série
La présente description concerne un procédé et un appareil de gestion des tâches dans un processeur.
Dans la description qui suit, dans un but d'explication, des structures de données, des indicateurs, des ressources, des temps, des signaux et des formats spécifiques sont exposés afin de permettre une compréhension complète de la présente invention.
L'homme de l'art comprend cependant que la présente invention peut être mise en oeuvre sans ces détails spécifiques. Dans d'autres cas, des structures et des dispositifs bien connus sont représentés sous forme de schémas fonctionnels afin de ne pas obscurcir inutilement la présente invention.
On exposera d'abord une vue générale d'un système d'ordinateur utilisé dans un mode de réalisation préféré.
Le mode de réalisation préféré de la présente invention peut être mis en oeuvre sur des systèmes d'ordinateurs présentant diverses variantes de configurations. La Figure 1 illustre certains des composants de base d'un tel système d'ordinateur, mais elle n'a pas pour but d'être limitative ni d'exclure d'autres composants ou combinaisons de composants.Le système d'ordinateur illustré à la Figure 1, comprend un bus ou un autre moyen de communication 101 pour la communication d'information, un moyen de traitement 102, appelé généralement un processeur serveur, couplé au bus 101 pour traiter l'information, une mémoire vive, ou REM ou un autre dispositif de mémorisation 103, appelé généralement une mémoire principale, couplé au bus 101 pour mémoriser une information et des instructions pour le processeur 102, une mémoire morte ou ROM, ou un autre dispositif de mémoire statique 104, couplé au bus 101 pour mémoriser une information et des instructions statiques pour le processeur 102.
D'autres dispositifs couplés au bus 101 incluent un dispositif de mémorisation 105 de données, par exemple un disque magnétique et une unité de disque pour mémoriser une information et des instructions, un dispositif alphanumérique d'entrée 106, incluant des touches alphanumériques et autres, pour communiquer une information et ordonner des choix au processeur 102, un dispositif de commande à curseur 107, par exemple une souris, une balle roulante, des touches de commande de curseur, etc. pour commander un curseur et communiquer une information et ordonner des choix au processeur 102, un dispositif d'affichage 108 pour afficher une entrée et une sortie de donnée, un processeur de signaux numériques ou un autre processeur à haute vitesse 109 pour traiter des demandes de ressources de processeur de signaux numériques, un port audio 110 pour l'entrée et la sortie de signaux audio et un port de télécommunications pour l'entrée et la sortie de signaux de télécommunication. Dans une telle configuration de système d'ordinateur, le processeur 109 de signaux numériques est considéré comme un coprocesseur du processeur serveur 102.
Du point de vue architectural, un processeur de signaux numériques est un microprocesseur universel basé sur un ordinateur à jeu réduit d'instructions, ou
RISC, intégré et rapide, qui inclut une unité de traitement arithmétique en pipe-line. Une différence fondamentale vis-à-vis de vrais processeurs universels est qu'un processeur de signaux numériques est prévu pour effectuer très rapidement une opération de multiplication et d'accumulation, ou MAC. L'opération de multiplication et d'accumulation est fortement utilisée dans des programmes de traitement de signaux numériques.Il faut noter que des applications de serveurs de processeurs d'application de signaux numériques peuvent être écrites d'une manière telle qu'elles n'exigent aucun co-processeur 109 de processeur de signaux numériques pour être exécutées, mais qu'elles exploiteraient de tels co-processeurs s'ils sont disponibles. Un mode de réalisation de la présente invention est implanté de manière à être utilisé sur certains des membres de la famille des ordinateurs de marque Macintosh(R), commercialisés par
Apple Computer, Inc. de Cupertino, Californie.
Macintosh(R) est une marque déposée de Apple Computer,
Inc. Un co-processeur 109 qui peut être utilisé est un processeur numérique quelconque pourvu de caractéristiques opérationnelles et de fonctions semblables à celles que l'on trouve dans un processeur de signaux numériques Digital Signal Processor DSP 3210 commercialisé par American Telephone and
Telegraph (AT & ) Microelectronics de Allentown,
Pennsylvanie.
On exposera maintenant l'organisation du système d'exploitation.
L'organisation du système d'exploitation de ce mode de réalisation est séparée en deux moitiés distinctes pour les deux processeurs fonctionnant dans le système d'ordinateur. En se référant à la Figure 2, les applications/clients de serveur 210 sont traités par un gestionnaire de DSP 211, qui fonctionne dans le processeur serveur pour diriger et engendrer des tâches qui doivent être mises en oeuvre dans le DSP.
En revanche, des modules ou tâches 220 de DSP, qui sont engendrées par le gestionnaire de DSP 211 dans le processeur serveur, sont mis en oeuvre à partir d'un noyau résidentiel 211 de DSP qui fonctionne à l'intérieur du processeur 109. En bref, il existe deux niveaux distincts de programmes d'ordinateur qui sont utilisés pour le fonctionnement selon le mode de réalisation préféré:
(1) des programmes de logiciel de client, c'est à-dire, d'applications ou de coffre à outils de niveau supérieur, qui sont exécutés sur le processeur serveur; et
(2) des programmes de processeurs de signaux numériques, appelés "modules" qui fonctionnent dans le
DSP 109 (Figure 1).
Par conséquent, des programmes peuvent être écrits séparément pour le DSP 109 et pour le serveur 102. Par exemple, des sous-programmes de bibliothèque peuvent être engendrés de manière à fonctionner dans le DSP 109, et ces sous-programmes peuvent être rendus disponibles à des programmeurs du client serveur à titre de référence pendant l'exécution. Une communication entre processus, entre le gestionnaire 211 de DSP du processeur serveur 102 et le DSP, est réalisée par le noyau résidentiel de DSP fonctionnant dans le DSP 109 (Figure 1) et effectuée au moyen d'une mémoire partagée 230. L'espace 230 de mémoire partagée peut être couplé au bus 101 ou peut faire partie de la mémoire vive 103 du système.
La mémoire partagée 230 contient des sémaphores, des données, des messages et d'autres informations qui sont nécessaires pour la communication entre les processus des deux processeurs 102 et 109. Le gestionnaire 221 de DSP est en outre couplé à un dispositif de commande 212 de serveur qui réalise diverses fonctionnalités selon l'implantation du matériel pour le gestionnaire 211 de DSP et d'autres fonctions qui concernent le dispositif de commande 222 de noyau résidentiel de DSP. Par conséquent, des sousprogrammes de coffre à outils peuvent être rendus disponibles au programme 210 d'application/de client pour diriger diverses actions dans les outils résidant dans le dispositif de commande 222 de noyau résidentiel de DSP.Une communication entre les processeurs est réalisée par l'intermédiaire de la zone 230 de mémoire partagée, ainsi que par des lignes d'interruption 231 qui sont activées lorsque des actions doivent être prises, soit par le dispositif de commande 212 de DSP, soit par le dispositif de commande 222 de noyau résidentiel de DSP. On notera que la structure représentée à la Figure 2 n'est pas nécessaire pour mettre en oeuvre la présente invention et qu'elle n'est exposée que dans des buts d'illustration. L'homme de l'art comprendra que d'autres structures de système d'exploitation peuvent être utilisées pour réaliser une communication entre les processus.
Le gestionnaire 211 de DSP est disponible aux sous-programmes 210 d'application/de client de serveur par l'intermédiaire d'une interface connue comme interface de programmation d'application, ou API. Dans le mode de réalisation actuellement préféré, le gestionnaire 211 de DSP effectue trois services principaux qui sont accessibles par l'intermédiaire de l'interface de programmation d'application. Ces trois services sont appelés les gestionnaires 211B de dispositif et de client, les services d'entrée/sortie 211C et les gestionnaires 211D de structure de donnée.
Ces divers services lancent des appels aux gestionnaires 211E d'allocation aux niveaux inférieurs du gestionnaire 211 de DSP. La structure du noyau résidentiel 221 est semblable à celle du gestionnaire 211 de DSP en ce qu'il inclut une interface de programme de module ou MPI 220A qui est accessible aux modules 220 de DSP engendrés par des programmeurs de
DSP. L'interface de programme de module 220A dispose d'un accès aux services disponibles aux modules de
DSP, par exemple des services d'entrée/de sortie 221B, des services de largeur de bande de traitement garantie, ou GPB, et de commande 221C, et des services de cache 221D. Une couche d'exécution 221E qui est responsable de la gestion des fonctions de séquences de tâche et de manipulation des blocs est sous-jacente à ces fonctions.Ces sous-programmes de noyau résidentiel possèdent un accès au dispositif de commande 222 de noyau résidentiel de DSP et possèdent donc un accès aux zones 230 de mémoire partagée et aux lignes d'interruption 231. De plus, les couches d'exécution 221E accèdent également à la zone 230 de mémoire partagée pour la communication de messages vers le gestionnaire 211 de DSP résidant dans le processeur serveur et à partir de ce gestionnaire.
On va maintenant décrire les structures de données utilisées dans le mode de réalisation préféré.
Les structures de données utilisées par le mode de réalisation actuellement préféré de la présente invention sont appelés des "modules" ou "tâches". Un module est une structure de donnée définie par le système et le programmeur de DSP qui est prévu pour exercer une fonction prédéterminée. Un module de DSP inclut toujours un code de programme, mais il peut également inclure des données, des tampons d'entrée/de sortie et des blocs de paramètres. Le nombre de modules et leurs ressources exigées sont définies par le programmeur de DSP.
Une tâche est une structure de données concernant une référence à une liste d'un ou plusieurs modules.
Ainsi, une tâche de DSP comprend un ou plusieurs modules de DSP. Les modules d'une tâche sont groupés dans l'ordre approprié et sont pourvus des connexions appropriées d'entrée/de sortie et de tampons.
Fréquemment, une tâche de DSP ne contient qu'un seul module de DSP. Une tâche est activée ou désactivée sous forme d'unité unique. Des tâches peuvent être groupées entre elles afin d'exercer une fonction spécifique. Le groupe de tâches, selon un ordre de succession, est appelé une liste de tâches.
Essentiellement, une liste de tâches est une structure de donnée qui référence une série de modules exécutables, c'est-à-dire de programmes. De plus, un ensemble de tâches peut être activé ou désactivé de manière successive ou simultanée. Une tâche est installée et enlevée de la liste des tâches sous forme d'unité.
Des modules de DSP sont fournis à un programmeur d'application comme ressources et sont chargés dans une tâche de DSP en utilisant un gestionnaire 211 de
DSP. Une tâche est construite en utilisant une série d'appels au gestionnaire 211 de DSP. Ces appels créent la structure de tâche, chargent et connectent des modules selon l'agencement souhaité, allouent la mémoire nécessaire et installent la tâche achevée dans une liste de tâches de DSP. Chacun des modules comprend un en-tête de module de DSP contenant une information d'indicateur et d'autres informations liées à la structure de donnée et une série de sections de DSP qui indiquent chacune diverses ressources, y compris un code exécutable nécessaire pour que le module DSP exerce sa fonction.
Le mode de réalisation actuellement préféré de module 300 est représenté à la Figure 3. La structure interne de module 300 inclut tant un code que des données. Chaque module comprend un en-tête et une ou plusieurs sections. L'en-tête 301 contient une information concernant le module entier, par exemple son nom, une information de largeur de bande de traitement garantie et des drapeaux de commande. L'entête 301 inclut également un compte du nombre de sections du module. Ceci permet au module 300 d'être d'une longueur variable et permet de faire varier le nombre des sections. Finalement, lten-tête 300 contient le numéro de la section qui contient le code de début du module.
Le module 300 comporte des sections 302 à 305.
Des sections permettent à des modules d'être créés pour une grande variété de fonctionnalités. Dans le mode de réalisation actuellement préféré, chaque section possède un nom, un indicateur, des drapeaux et des champs de type de donnée. De plus, chaque section contient des indicateurs concernant jusqu deux récipients séparés. Les récipients tiennent les données ou le code correspondant à la section. Les sections peuvent indiquer un code, des tables de données, des variables, des tampons, des paramètres, un espace de travail ou toute autre ressource nécessaire pour exercer la fonction souhaitée.
Une section ne contient pas le code ou la donnée réel utilisé par le DSP. Au contraire, une section est une structure de donnée qui contient des indicateurs concernant le bloc de code ou de donnée. Le système d'exploitation du DSP utilise la structure de section et les drapeaux pour entrer en cache le bloc de code ou de donnée réel dans une mémoire de cache à haute vitesse pendant l'exécution du module. En se référant à la Figure 4, la section 400 comprend un indicateur 401 de nom, des drapeaux 402, un type 403, un indicateur 404 de récipient primaire, un indicateur 405 de récipient secondaire et des connexions 406.
L'indicateur 401 de nom indique une chaîne de caractères qui identifie de façon unique la section d'un module. Les drapeaux 402 et le type 403 sont utilisés par le mode de réalisation préféré pour commander les opérations de cache et gérer les tampons. Les connexions 106 consistent en une donnée qui est utilisée pour la gestion des tampons à l'intérieur du gestionnaire de DSP et sont décrites ci-dessous.
L'indicateur 404 de récipient primaire indique le récipient primaire 420 tandis que l'indicateur de récipient secondaire indique le récipient secondaire 421. Dans le mode de réalisation actuellement préféré, le récipient primaire 420 et le récipient secondaire 421 sont des tampons. Le DSP utilise ces indicateurs chaque fois qu'il souhaite localiser la donnée de section. Il faut normalement que chaque section possède un indicateur 404 de récipient primaire qui puisse indiquer des emplacements, soit en fonction, soit hors fonction, de la micro-plaquette 109 de processeur de DSP. L'indicateur 405 de récipient secondaire est facultatif.Si une section comprend un indicateur 405 de récipient secondaire, l'indicateur 404 de récipient primaire désigne l'emplacement ou le code d'utilisateur de DSP accède à la section et l'indicateur 405 de récipient secondaire indique l'emplacement ou le système d'exploitation de DSP garde les données entre des exécutions des modules. Le récipient primaire 420 est alloué dans la mémoire locale s'il contient des données fixes ou des paramètres en vue d'une communication entre l'application de serveur et le module. Dans le cas contraire, le récipient primaire 420 est positionné dans un cache à haute vitesse, c'est-a-dire une mémoire vive statique sur micro-plaquette ou SRAM dans le mode de réalisation préféré, afin d'augmenter la performance d'exécution.Le récipient secondaire 421 est généralement alloué dans la mémoire locale, mais il peut dans certains cas spéciaux être alloué dans le cache. Une mémoire allouée de chaque récipient peut être soit dans la mémoire locale, soit dans la mémoire de cache.
Pour exécuter des modules, chaque module est entré en cache en vue d'un accès d'une exécution par le DSP. Le mode de réalisation préféré de la présente invention supporte deux modèles d'exécution appelés
AutoCache et DemandCache, c'est-à-dire, littéralement, cache automatique et cache à la demande. Dans
AutoCache, le programmeur spécifie les blocs de codes et de données qui doivent être chargés et sauvegardés.
Le noyau résidentiel de DSP effectue automatiquement toutes les fonctions de charge et de sauvegarde. Dans
Demandcache, le programmeur déplace explicitement des blocs de codes et de données dans les micro-plaquettes et hors de celles-ci chaque fois que ceci est nécessaire, en lançant les appels appropriés au noyau résidentiel de DSP dans le code de DSP du module.
Lors de l'entrée en cache d'un module AutoCache, un code et des données sont chargé dans le cache avant leur utilisation, selon les drapeaux de sections, et les données sont ensuite sauvegardées en retour depuis le cache lorsque l'exécution est achevée. En ce qui concerne le récipient primaire 420 et le récipient secondaire 421, pendant les opérations de cache, la donnée est déplacée du récipient secondaire 421 vers le récipient primaire 420. Dans le mode de réalisation actuellement préféré, ceci implique habituellement de déplacer le contenu depuis la mémoire locale vers la mémoire de cache, avant l'exécution du module. C'est ce que l'on appelle communément un chargement en cache. Après l'exécution du module, le DSP déplace lui aussi des données depuis le récipient primaire 420 vers le récipient secondaire 421.Dans le mode de réalisation actuellement préféré, ceci implique de déplacer le contenu depuis la mémoire de cache vers la mémoire locale. C'est ce que l'on appelle communément une sauvegarde de cache. Lorsque l'entrée en cache n'est pas nécessaire, seul un récipient est nécessaire, le récipient principal 420. L'utilisation d'un récipient réalise une communication entre des modules et l'application de serveur. Ceci est habituellement exécuté à l'aide d'une zone de mémoire partagée qui, soit réside dans la mémoire serveur, comme 103, soit est relié à un bus comme 101, représenté à la Figure 1.L'utilisation de sections, comme décrit ici, offre des capacités uniques dans lesquelles des modules multiples, soit disponibles commercialement, soit écrits par un programmeur DSP, peuvent être modularisés de manière à être assemblés entre eux selon une multiplicité de combinaisons. Les programmeurs d'application peuvent ainsi créer leur propre programme sans devoir traiter la fonctionnalité sous-jacente des modules spécifiques au DSP. De plus, il est possible d'implanter diverses plates-formes de matériel au moyen du modèle à sections en permettant une compatibilité avec une variété de plates-formes de matériel et de futurs matériels plus avancés.
Un module donné à titre d'exemple, pourvu de ses récipients primaire et secondaire, est représenté à la
Figure 5. Le module 500 est appelé "Equalizer" c'est à-dire littéralement égaliseur, et il contient cinq sections comme indiqué dans lten-tête 501. Le module 500 comprend des indicateurs 502, 503 et 504 de section de programme, de variables, et de tables indiquant le récipient primaire 510 contenant une information 511 de programme, une information de variables 512, et une information de tables 513. De plus, le module 500 comprend un tampon d'entrée et de sortie indiqué par 505 et 506 qui indiquent le tampon 514 d'entrée et le tampon 515 de sortie sonore.Une sortie de cache réalisée par le système dans le mode de réalisation préféré déplace l'information entre les récipients secondaire et primaire avant l'exécution du module et déplace la donnée entre les récipients primaire et secondaire après l'exécution du module. Le récipient secondaire 520 inclut un code 521, des variables 522 et des tables 523. Le module et les récipients secondaires sont situés dans la mémoire vive locale, et les récipients primaires sont situés dans le cache. Dans l'exemple représenté, les sections de code, de variables et de tables sont chargées dans le cache avant l'exécution de la section de code fournie par le module 500. Lorsque l'exécution est achevée, seules les variables sont sauvegardées en retour vers la mémoire locale.
Pour exécuter le module 500, une mémoire doit être allouée. La gestion d'allocation de mémoire est accomplie en deux phases. Lorsque le client charge le module 500 dans la mémoire à partir d'un fichier de ressources, le gestionnaire de DSP alloue tous les blocs nécessaires dans la mémoire locale pour tenir leur structure. Pour le module 500, le gestionnaire de
DSP alloue un espace de mémoire pour le module luimême et les trois récipients secondaires 521, 522 et 523. Les récipients 521, 522, 523 sont ensuite chargés de données à partir des fichiers de ressource pour achever la première phase.
Le client doit également spécifier des connexions d'entrée/de sortie du module 500. Les spécifications des connexions d'entrée/de sortie, ou connexions E/S, sont décrites ci-dessous. Les connexions sont effectuée d'une manière telle que toute allocation de mémoire élimine autant de déplacement de tampons que possible. Si un tampon peut être établi et laissé à un emplacement sans être déplacé entre l'exécution de modules ou de tâches, le temps inactif de maintien de tampon est également réduit. En plus de la spécification des connexions E/S, il faut charger d'autres modules et les relier entre eux afin de former une tâche à modules multiples. Lorsque ceci est achevé, le gestionnaire de DSP appelle l'un des gestionnaires d'allocation afin d'effectuer l'allocation de cache. L'allocation par le gestionnaire d'allocation est la deuxième phase d'allocation. Dès lors que la mémoire de cache a été allouée à la tâche, elle est prête à être installée.
Pour Demandcache, une allocation additionnelle est effectuée par le noyau résidentiel de DSP lors du fonctionnement.
On va maintenant décrire la structure d'ensemble de tâches.
La structure d'ensemble de tâches à exécuter selon le mode de réalisation est représentée à la structure 600 à la Figure 6. Le système comprend un ensemble de globaux de DSP 601 qui maintient une commande et une information concernant chacun des dispositifs de DSP, par exemple 602 et 603, couplés dans le système. Chaque dispositif de DSP, par exemple 602 et 603 peut être un dispositif comme celui qui est représenté comme DSP 109 à la Figure 1. Dans cet environnement à traitements multiples, il est possible d'utiliser une série de dispositifs de DSP pour certaines tâches et/ou pour certaines capacités du système. Chacun des dispositifs de DSP peut être couplé à un bus 101 et résider sur la carte principale de logique du système, ou être couplé au bus sous forme de dispositif d'expansion dans le système d'ordinateur.La structure détaillée d'un seul des dispositifs 602 est représentée dans un but de simplicité, mais le dispositif 603 de DSP et les dispositifs ultérieurs couplés sur le bus 101 peuvent être de la même structure.
Un dispositif de DSP, par exemple 602, traite une série de clients de DSP, par exemple 604 et 605, le client étant, soit un coffre à outils de système, soit une application qui souhaite utiliser un DSP 109. Un client de DSP est activé en "inscrivant" le client en utilisant un appel de système lancé par l'intermédiaire du gestionnaire 211 de DSP. Les gestionnaires 211B de client et de dispositif sont utilisés pour gérer des clients utilisant le dispositif 602 de DSP. De cette manière, chaque dispositif de DSP maintient une information concernant le client en ce qui concerne les tâches que le client demande.
Chaque dispositif de DSP, par exemple 602, maintient deux listes indépendantes de tâches, 610 et 630 qui sont utilisées pour garder trace des tâches actuellement en cours dans le système d'exécution de
DSP. Une liste 110 de tâches est appelée la liste des tâches "en temps réel" et consiste en un ensemble de sous-programmes qui doivent être exécutés à intervalles réguliers. Chaque tâche, par exemple 611 et 614 de la liste 610 de tâches en temps réel n'est exécutée qu'une fois pendant des intervalles réguliers de sorte que le client demandant les services de chaque tâche de DSP de la liste 610 de tâches est pris en charge à l'intérieur d'un intervalle spécifique de temps.Une technique appelée la largeur de bande de traitement de garantie, ou GPB, est utilisée pour assurer que les tâches de la liste 110 des tâches en temps réel ne dépassent pas la longueur maximale de temps dans lesquelles des tâches en temps réel peuvent être exécutées. La largeur de bande de traitement garantie est décrite dans la demande également en cours d'examen, intitulée Apparatus and méthode for
Allocating Processing Time in a Frame-based Computer System, c'est-à-dire "Appareil et procédé d'allocation de temps de traitement dans un système d'ordinateur à base de séquences qui a reçu le numéro de série et qui est attaché ici comme annexe
A.Le gestionnaire 211 de DSP assure, au moyen des gestionnaires 211B de client et de dispositifs, qu'un nombre excessif de tâches en temps réel n'est pas inséré dans une liste 610 de tâches en temps réel.
La liste 610 des tâches en temps réel lie toutes les tâches 611 et 614 en temps réel qui doivent être exécutées à l'intérieur du DSP dans un intervalle spécifié de temps appelé la séquence de temps réel.
Chacune des "tâches représentées en 611 à 614 est en fait une donnée d'une structure de données qui référence la donnée suivante de tâche dans la liste des tâches. Pendant chaque séquence de temps réel, le noyau résidentiel 211 de DSP explore la liste 610 de tâches en temps réel et exécute une seule fois les tâches 611 à 614 dans cet ordre de succession, comme indiqué par les flèches représentées à la Figure 6.
Lorsque la fin de la liste des tâches en temps réel est atteinte, par exemple, à la tâche 614 de DSP, l'exécution des tâches en temps réel cesse. Chacune des tâches 611 à 614 de DSP est en fait une donnée d'une structure de données, qui référence certains "modules" de DSP, par exemple 621, 624, 625, et 627.
Des modules sont des fonctions ou des sous-tâches reliées à l'intérieur de chaque tâche. Chaque donnée de module de DSP, par exemple 621 contient un premier champ 621a qui fait référence sur le code exécutable pour le module. Un deuxième champ, appelé les champs 621b de section(s) de DSP est utilisé pour référencer toutes les ressources exigées par le module exécutable qui est référencé par le premier champ 621a.
En plus de la liste 610 des tâches en temps réel, le dispositif de DSP maintient une deuxième liste de tâches appelée la liste 630 des tâches en temps partagé. La liste 630 des tâches en temps partagé maintient une liste semblable d'éléments d'une structure de donnée, par exemple 631 et 633, qui référencent chacun ce que l'on appelle des tâches "en temps partagé, c'est-à-dire des tâches qui n'ont pas à être exécutées à des intervalles de temps réguliers.
Chacun des éléments 631 à 633 de la liste des tâches en temps partagé référence des "modules", par exemple 635, 636, et 639, qui contiennent tous des références à un code exécutable et des ressources nécessaires pour chacun des modules de DSP en temps partagé. C'est une structure similaire à celle qui est exposée pour la liste des tâches en temps réel décrite ci-dessus.
La liste des tâches en temps partagé est exécutée "en rond" chaque fois que la liste des tâches en temps réel n'est pas en cours d'exécution.
Le fait de maintenir séparément une liste 610 de tâches en temps réel et une liste 630 de tâches en temps partagé permet de grouper les fonctions par priorité dans le système d'exploitation du mode de réalisation préféré. Par conséquent, une distinction est établie entre les tâches qui sont critiques en fonction du temps et celles qui ne le sont pas. Ceci est une amélioration par rapport au procédé de l'art antérieur comprenant une liste unique de tâches qui n'effectue aucune distinction de ce type et qui peut surcharger le DSP 110 en lui faisant supporter plus d'exécution de tâches que ce qui est réellement nécessaire.
On va maintenant exposer le temps alloué aux tâches en temps réel et en temps partagé.
Le groupage unique de tâches en temps réel listées dans la liste 610 de tâches en temps réel et de tâches en temps partagé listées dans la liste 630 de tâches en temps partagé, offre certaines capacités puissantes qui permettent à la puissance de traitement du DSP d'être allouée de façon efficace et permettent l'exécution de tâches en temps réel aussi rapidement que possible. Le mode de réalisation utilise une approche à base de "séquences" pour traiter des tâches résidant dans les deux structures de tâches.
L'approche d'exécution des tâches à base de séquences est décrite en référence à la Figure 7A. Comme représenté à la Figure 7A, le temps est divisé en intervalles uniformes discrets, appelés séquences. Une séquence N 700 est précédée et suivie par des séquences comme 701 et 703 qui sont de la même longueur que la séquence 700. Pendant chaque séquence, le code de programme, les variables et les données d'entrée nécessaires pour chacune des tâches en temps réel de la liste 610 des tâches sont chargés dans un cache à haute vitesse. Le programme est exécuté à partir du cache, et la donnée de sortie qui en résulte est envoyée depuis le cache en retour vers la mémoire externe. En variante, la donnée d'entrée peut déjà être dans le cache, depuis l'opération précédente, et la donnée de sortie peut être retenue dans le cache si nécessaire pour les opérations suivantes.Ce procédé d'utilisation d'un cache à haute vitesse est appelé l'utilisation de cache visible.
Le traitement à base de séquences utilisé par le mode de réalisation préféré exige une certaine latence dans le flux de données. Un port d'entrée de DSP doit collecter une valeur d'échantillon égale à une séquence totale avant que le DSP ne puisse le traiter.
De même, le DSP doit engendrer une quantité d'échantillons égale à une séquence complète avant que le port de sortie ne puisse commencer à les transmettre. Ceci exige la latence de deux séquences entre la donnée d'entrée et la donnée de sortie. Ceci est représenté en référence à la Figure 7d. Par exemple, la donnée qui serait traitée à la séquence 750 doit être collectée pendant la séquence précédente 751 tandis que les tâches de la séquence précédente sont en cours de traitement. Une donnée d'entrée N 760 collectée pendant la séquence 751 est donc disponible à la séquence 750 pour être traitée. De même, une donnée engendrée pendant l'intervalle de séquence 750 n'est pas disponible pour être sortie avant la séquence 752, dans laquelle la donnée de séquence suivante est en cours de traitement.Ainsi, une donnée de sortie N 761 est disponible pour être sortie à l'instant où le DSP 110 est en train de traiter une information dans l'intervalle de séquence 752.
Les durées des séquences varient selon les besoins du programme, ou des programmes, d'application et la quantité de ressources disponibles. Il existe essentiellement quatre facteurs qui influencent le choix des intervalles de temps des séquences. Ce sont:
1. La dimension du tampon: elle est proportionnelle à l'intervalle de temps de la séquence. Plus la séquence est longue, plus il faut de mémoire de cache pour chaque tampon.
2. La réduction de temps inactif: elle est inversement proportionnelle à l'intervalle de temps de séquence. Plus la séquence est courte, plus le pourcentage de temps de traitement de DSP utilisé en temps inactif est grand. Par exemple, si la séquence représente 240 échantillons, le temps inactif est 1/240, ou 0,42%, par rapport au traitement d'un échantillon à la fois.
3. La granularité, ou caractère granulaire, d'accès. Pendant une séquence, le traitement ne peut pas être facilement interrompu. Des variations de configuration de processus doivent se produire aux limites de séquences. Plus la séquence est longue, plus l'accès est granulaire.
4. La latence d'entrée/de sortie de diverses algorithmes importants. Plus la séquence est longue, plus la latence entre les trains de donnée d'entrée/de sortie est élevée. Comme représenté à la Figure 7b, la latence est de 2 séquences entre le train d'entrée et le train de sortie.
Les éléments 1 et 2 tirent dans des directions opposées. L'élément 3 dépend de l'application. Une synthèse sonore à l'aide d'une interface numérique d'instruments musicaux, ou MIDI, est l'une des applications éventuelles les plus exigeantes, en appliquant une limite inférieure d'environ 2 à 4 millisecondes par séquence pour la séquence. L'élément 4 place la limite supérieure du temps de séquence. Les besoins de latence du modem de données V.32 sont très exigeants, et sa limite supérieure est de 13 millisecondes par séquence.
Le mode de réalisation préféré utilise un temps de séquence de dix millisecondes. Cependant, pour mettre en oeuvre la présente invention, l'homme de l'art comprend qu'une séquence d'une longueur quelconque est également applicable ici, selon les circonstances des fonctionnements.
De façon générale, chaque séquence est divisée de la manière décrite en référence à la Figure 8. Une séquence 800 qui est exécutée pour un intervalle donné de temps comprend trois sections: une partie 801 d'exécution en temps réel, une partie 802 d'exécution en temps partagé et une partie de sommeil 803. La partie 801 en temps réel est le temps réellement utilisé pour traiter les fonctions en temps réel qui sont actuellement actives dans la liste 610 de tâches en temps réel décrite ci-dessus. La section 801 de temps réel peut varier en longueur selon le nombre de tâches de la liste 610 de tâches en temps réel.
Cependant, la partie 801 de temps réel est limitée, à l'intérieur de la séquence 800, à un intervalle maximal de temps défini par la limite de largeur de bande de traitement garantie en temps réel allouée représenté comme temps 805 à la Figure 8. Ceci limite le nombre de tâches et la longueur d'exécution de chacune des tâches contenue dans la liste 610 de tâches.
La deuxième partie de la séquence 802 est utilisée pour l'exécution de tâches en temps partagé de la liste 630 de tâches. Le traitement de tâches en temps partagé est effectué à l'intérieur du segment de la séquence qui est une partie du temps partagé total disponible, ou ATT, 804. S'il n'existe aucune tâche active en temps partagé, ce segment est sauté. Toutes les tâches en temps partagé sont prises en charge "en rond" pendant le segment 802, jusqu'à ce que, soit la séquence se termine, soit toutes les tâches en temps partagé deviennent inactives. Si toutes les tâches en temps partagé contenues dans la liste 630 sont achevées, c'est-à-dire deviennent inactives, à l'intérieur d'une séquence comme 800, le DSP 110 se met en sommeil pour le reste de la séquence à la partie de temps 803 de la séquence 800.En d'autres termes, tout le traitement est suspendu et aucune tâche n'est exécutée jusqu'au début de la séquence suivante, des tâches en temps réel étant à nouveau ici réalisées à un instant comme 801 représenté à la
Figure 8. Des tâches en temps partagé peuvent ne pas être achevées en un temps inférieur au temps partagé total disponible (ATT) dans une séquence donnée, auquel cas elles occupent la période totale 804 et aucune période de sommeil 803 n'existe dans la séquence. Le traitement de temps partagé se poursuit après le segment en temps réel de la séquence suivante. Pendant la période 800, s'il n'existe aucune tâche active en temps partagé à exécuter, le processeur passe effectivement en mode de sommeil, tout le traitement étant alors arrêté, et le processeur s'arrête de lui même, dans le mode de réalisation préféré, en utilisant une instruction d'arrêt d'alimentation. Dans le mode de réalisation préféré, un DSP comme le AT & 32010 émet "l'instruction d'arrêt d'alimentation". Le DSP est ensuite ramené en fonctionnement lorsque l'interruption de séquence suivante signale le début de la séquence suivante. Ceci permet des économies automatiques de puissance, en particulier dans des applications à utiliser sur des ordinateurs portables.
Selon un autre mode de réalisation, le gestionnaire 211 de DSP du processeur serveur arrête même l'alimentation de tous les circuits concernant le DSP contenu dans 100, y compris les horloges, les ports sériels et d'autres équipements liés afin d'économiser encore davantage la puissance, si leur fonctionnement n'est pas nécessaire.
La quantité de temps de tâche en temps partagé disponible ou ATT 804 dépend du nombre de tâches en temps réel qui sont exécutées dans l'intervalle de temps 801. Si l'intervalle de temps 801 est très court, ATT 804 peut comprendre toute la séquence 800.
La détermination des processus qui seront exécutés pendant la partie en temps réel 801 d'une séquence et des tâches qui seront exécutées dans la partie de temps partagé 802 d'une séquence, et qui sont donc dans l'une des listes de tâches 610 ou 630 dépend d'un certain nombre de facteurs. Les tâches en temps réel sont les tâches qui doivent être exécutées à chaque séquence. Ceci signifie que la tâche doit être divisée en parties distinctes qui doivent être exécutées en une séquence. Les tâches en temps réel sont celles qui doivent être exécutées à des intervalles réguliers, mais non nécessairement aussi rapidement que possible. Une tâche quelconque de train de donnée reliée à un port en temps réel est une telle tâche, par exemple une tâche de traitement de son, une tâche de traitement de parole ou une tâche de télécommunications.L'un quelconque de ces types de tâches, s'il est relié à un port en temps réel, comme un haut-parleur, un microphone ou une ligne téléphonique, exige une prise en charge en temps réel.
Ce type de traitement est appelé traitement isosynchrone. On notera que les mêmes tâches pourraient ne pas être en temps réel si elles étaient utilisées pour un traitement hors ligne, par exemple la réalisation du traitement sonore d'un fichier de disque.
Des tâches mises en oeuvre dans la liste 630 des tâches en temps partagé donnent à une application le temps maximal de traitement disponible. Des tâches en temps réel peuvent être exécutées à une fréquence garantie, mais leur temps total de traitement est limité à la quantité allouée. Même s'il existe un temps de traitement inutilisé, des tâches en temps réel doivent rester à l'intérieur de leur temps de traitement alloué. Le traitement en temps partagé est appelé traitement asynchrone. Des exemples de tâches en temps partagé incluent une compression sans pertes de fichiers de disque, des graphiques, une animation, une décompression et une compression d'images fixes, une décompression vidéo, un traitement audio hors ligne et d'autres applications semblables qui exigeaient des quantités importantes de temps de traitement.
Une vue plus détaillée d'une séquence comme 800 est représentée à la Figure 9. Comme représenté à la
Figure 9, à l'instant d'une interruption de séquence en temps réel à un instant comme 900, un processus appelé sauvegarde 901 de contexte de temps partagé doit être effectué avant le traitement de tâches en temps réel si un temps partagé était actif lorsque l'interruption se produit. Si l'interruption se produit au milieu du traitement d'une liste 630 de tâches en temps partagé, le contexte de tâches en temps partagé doit être sauvegardé parce que le traitement a été arrêté pendant une opération en cours. Ceci est exécuté à l'instant 901 comme représenté à la Figure 9. Dès lors que le contexte de temps partagé est sauvegardé selon la commande de l'interruption à l'instant 900, un traitement isosynchrone d'interruption de temps réel peut être effectué à l'instant 902.Une vue plus détaillée d'un traitement de tâche en temps réel est décrite à la
Figure 10 ci-dessous, Puis, à l'achèvement du traitement de tâches en temps réel à l'instant 902, le contexte éventuel de tâches en temps partagé qui a été sauvegardé à l'instant 901 est restauré à l'instant 903. Pendant le laps de temps 904, le traitement de tâches en temps partagé de la liste 630 des tâches en temps partagé se poursuit jusqu'à ce que la liste de tâches en temps partagé soit vide, c'est-à-dire que toutes les tâches en temps partagé ont été achevées, ou que toutes les tâches en temps partagé sont inactives ou que la séquence se termine. Si le traitement en temps partagé se termine avant que la séquence ne se termine, comme décrit ci-dessus, le DSP peut envoyer une instruction d'arrêt d'alimentation peut passer en mode de sommeil à l'instant 803 pour le reste de la séquence 800.Il faut noter que, puisque la partie 904 de temps partagé s'est achevée dans cet exemple avant la fin de la séquence, aucune sauvegarde de contexte de temps partagé n'est nécessaire, comme c'était le cas à la période 901, parce qu'aucune tâche ne reste dans la liste 630 des tâches en temps partagé. Par conséquent, au début de la période de traitement isosynchrone 801 en temps réel suivante, le contexte de traitement de temps partagé n'est pas à sauvegarder.
Une vue plus détaillée de la tranche 902 de séquence en temps réel ou le traitement des tâches en temps réel s'effectue est représentée à la Figure 10.
La liste 610 des tâches en temps réel est traitée au fur et à mesure en exécutant chacune des tâches en temps réel de la liste, par exemple 1002, 1005, 1008 et 1011, représentées à la Figure 10. Evidemment, chaque contexte de tâches en temps réel peut être sauvegardé à l'achèvement de son exécution et être restauré avant exécution. Par exemple, à la tâche en temps réel N 1, 1002 exige que son contexte soit restauré à la période 1001 et soit sauvegardé à la période 1003. De même, la tâche en temps réel n 2 1005 exige d'être restaurée à la période 1004 et d'être sauvegardée à la période 1006. Ce processus de sauvegarde/restauration est appelé le traitement de cache visible et peut être réduit en temps si une tâche utilise la sortie d'une tâche précédente, ou la donnée reste dans le cache.Dans ce cas, il n'est pa nécessaire de sauvegarder et de restaurer la donnée, ce qui permet à une tâche en temps réel d'accéder efficacement à une information venant de la tâche précédente, ce qui augmente le nombre de tâches qui peuvent être exécutées dans une tranche 902 de séquences en temps réel. Finalement, la dernière tâche en temps réel qui est exécutée à la période 1011 est sauvegardée à la période 1012 et la tranche de temps partagé 802 est ensuite exécutée de la manière décrite ci-dessus. La Figure 10 est représentée sous forme simplifiée, en supposant que chaque tâche en temps réel est une opération unique. Cependant, comme décrit plus loin, une tâche comprend en fait plusieurs modules et chaque module à l'intérieur de la tâche en temps réel est exécuté à l'intérieur de la tâche, par exemple dans une période 1002 ou 1005.
En résumé, le processus utilisé dans le mode de réalisation préféré pour effectuer un traitement de tâches en temps réel et en temps partagé est représenté en référence à la Figure 11. Le processus 1100 commence à l'étape 1101 et il est déterminé s'il existe d'autres tâches en temps réel à exécuter à l'étape 1102. Ceci peut être réalisé en déterminant que l'indicateur de la tâche suivante est nul pour la liste 610 de tâche. S'il n'existe pas d'autres tâches en temps réel à prendre en charge, l'étape 1102 passe à l'étape 1103 dans laquelle le contexte de tâche suivante en temps réel est chargé. La tâche suivante en temps réel est ensuite exécutée à l'étape 1104 et son contexte est sauvegardé à l'étape 1105. Puis, les étapes 1102 à 1105 peuvent être exécutées de nouveau s'il existe d'autres tâches en temps réel dans la liste 610 des tâches en temps réel.Dès lors que toutes les tâches en temps réel ont été prises en charge comme déterminé à l'étape 1102, 1102 se branche vers l'étape 1106 qui détermine s'il reste, dans la séquence, du temps pour prendre en charge des tâches de temps partagé. En d'autres termes, il faut qu'il reste une période minimale dans la séquence pour que des tâches en temps partagé soient prises en charge.
En particulier, il faut un temps suffisant pour restaurer le contexte, effectuer un certain traitement et sauvegarder ensuite le contexte au début de la séquence suivante: puisque les trois fonctions: charger contexte, traiter, sauvegarder contexte, sont nécessaires pour chaque séquence, il faudrait suffisamment de temps restant pour ces trois opérations dans la séquence, quand toutes les tâches en temps réel sont effectuées, avant d'activer le temps partagé. Il serait inutile de restaurer le contexte si le contexte ne peut pas être utilisé pour achever un traitement. Dans le mode de réalisation préféré, le temps nécessaire pour restaurer et sauvegarder le temps partagé est déterminé pendant le processus d'amorçage, et il est rendu disponible au noyau résidentiel de DSP de sorte que la décision peut être effectuée à l'étape 1106.Si le temps est insuffisant pour restaurer et exécuter un temps partagé, un branchement est effectué vers l'étape 1110 et le DSP attend la séquence suivante pour effectuer un traitement en temps réel.
En revanche, s'il est déterminé à l'étape 1106 que le temps restant dans la séquence est suffisant pour prendre en charge des tâches de temps partagé de la liste 630 des tâches, le contexte des tâches en temps partagé est sauvegardé avant l'interruption précédente et chargé à l'étape 1107. S'il n'existait pas de contexte précédent, aucun contexte n'est chargé. En revanche, le traitement passe à l'étape 1108 dans tous les cas. Ceci se produit dans le cas où une tâche de temps partagé a été activée à l'instant qui suit une période sans exécution de tâche de temps partagé. Puis, chacune des tâches de temps partagé peut être exécutée à son tour, à l'étape 1108, en chargeant leurs contextes respectifs en exécutant la tâche à l'étape 1108.Ceci se poursuit jusqu'à ce qu'un l'un des deux événements se produisent:
1) L'interruption de séquence suivante se produit; ou
2) Il n'existe aucune tâche active de temps partagé dans la liste 630 des tâches.
Si une interruption se produit en premier lieu, le contexte de tâches en temps partagé est sauvegardé à l'étape 1109, et le processus 1100 revient à l'étape 1101 pour une exécution de tâches en temps réel. En revanche, s'il n'existe plus aucune tâche en temps partagé à exécuter, le processus 1100 passe à l'étape inactive ou de sommeil à l'étape 1110 dans laquelle une instruction d'arrêt d'alimentation est émise dans un mode de réalisation de la présente invention ou bien une bouche de retard est exécutée dans le mode de réalisation de la présente invention, et le DSP 110 attend que le reste de la séquence soit écoulé.
Finalement, l'interruption de séquence suivante se produit et le processus revient à l'étape 1101. De cette manière, les tâches en temps réel et en temps partagé peuvent être gérées selon leurs exigences, et une largeur de bande de processeur peut être utilisée efficacement.
Avant qu'une tâche ne soit installée dans la liste des tâches en temps partagé, il faut d'abord déterminer si cette tâche peut être prise en charge de façon appropriée sur une base de temps partagé, en raison du fait que le temps total partagé disponible varie de façon dynamique. Le noyau résidentiel de DSP connaît la quantité de temps de traitement disponible pour chaque séquence puisqu'il calcule la largeur de bande de traitement pour toutes les tâches en temps réel. Le temps réel total disponible restant, c'est-àdire inutilisé, à utiliser pour les tâches en temps partagé peut être calculé de la manière suivante: pour chaque séquence, le temps moyen restant lorsque toutes les tâches en temps réel ont été achevées est recalculé. On utilise une forme de calcul par moyenne mobile, par exemple:
temps partagé moyen = valeur moyenne précédente 0,9 + valeur de séquence actuelle. 0,1.
Ceci donne au temps restant de chaque nouvelle séquence une pondération de 10% et une pondération de 90% pour la moyenne précédente. Des variantes de techniques de calcul de moyenne peuvent être utilisées. De plus, il est possible que le gestionnaire de DSP effectue ce calcul en échantillonnant la valeur toutes les N séquences.
Alors que ceci peut ne pas être précis, ceci simplifie le noyau résidentiel.
En plus du traitement de moyenne de temps partagé disponible, la fréquence de l'exécution de la liste des tâches en temps partagé est nécessaire. S'il existe de nombreuses tâches dans la liste des tâches en temps partagé, la fréquence d'exécution de chaque tâche est faible. Une mesure de ceci peut être calculée en calculant une moyenne mobile du nombre de séquences nécessaires pour traiter complètement une fois la liste. Ceci doit être fait chaque fois en passant par toute la liste des tâches en temps partagé. Le calcul pourrait être effectué de la façon suivante:
séquences utilisées = numéro de la séquence de fin - numéro de la séquence de début
moyenne des séquences utilisées = moyenne précédente des séquences utilisées . 0,9 + séquences actuelles utilisées . 0,1.
On note qu'il est possible que la valeur des "séquences utilisées" soit de 0 dans des cas où peu de tâches en temps partagé sont actives ou installées, où la majeure partie du temps de traitement est disponible pour le temps partagé. Il en résulte une valeur moyenne des séquences utilisées inférieure à 0,1. D'autres procédés de calcul de moyenne peuvent être utilisés. La valeur moyenne des séquences utilisées pourrait en variante être calculé par le gestionnaire de DSP en échantillonnant les numéros de séquences en temps réel et en temps partagé sur une base régulière. Ceci est moins précis, mais réduit la complexité du noyau résidentiel.
En utilisant la moyenne des séquences utilisées et la moyenne du traitement en temps partagé disponible par séquence, la fréquence selon laquelle une nouvelle tâche en temps partagé est exécutée peut être calculée de la façon suivante:
charge actuelle en temps partagé = moyenne du temps partagé . moyenne des séquences utilisées
charge proposée en temps partagé = charge actuelle en temps partagé + estimation GPB de tâche.
séquence utilisées calculées = charge de temps partagé proposée/moyenne du temps partagé.
L'estimation de GPB de la tâche est décrite dans la demande également en cours d'examen intitulée "Apparatus and Method for Allocating Processing Time in a Frame-based Computer System", déjà citée, qui a reçu le numéro de série et qui est attachée ici comme annexe A.
Si la valeur "proposée" calculée pour les séquences utilisées est trop élevées pour la fonction souhaitée, c'est-à-dire que la fréquence est insuffisante, la tâche ne doit pas être installée dans la liste en temps partagé. Il faut noter qu'un client en temps partagé doit surveiller la fréquence de traitement de ses tâches en temps partagé parce qu'une modification de la charge en temps réel ou de la liste des tâches en temps partagé affectent la quantité de traitement que reçoit sa tâche en temps partagé. Ce processus peut être aidé en notifiant un client en temps partagé chaque fois qu'une nouvelle tâche en temps réel est ajoutée à la liste des tâches. Une autre technique de surveillance de la fréquence de traitement en temps partagé consiste, pour le client, à demander au gestionnaire de DSP le numéro de séquence de temps partagé.Le numéro est incrémenté une fois pour chaque passage à travers la liste des tâches en temps partagé. Une autre aide à la gestion du temps partagé consiste à fournir la valeur de traitement non allouée par séquence en plus de la valeur moyenne de temps partagé décrite ci-dessus.
Puisque la GPB peut être allouée et non utilisée, le traitement non alloué est typiquement inférieur au traitement moyen typique réellement disponible. Ce nombre est utilisé pour donner une fréquence de séquence calculée dans "le pire des cas" de la manière suivante:
Charge actuelle en temps partagé = moyenne du temps partagé. moyenne des séquences de temps partagé utilisées.
Charge proposée en temps partagé = charge actuelle en temps partagé + estimation de GPB de la tâche.
Fréquence de séquence calculée dans le pire des cas = charge en temps partagé proposée / GPB non allouée.
Ce calcul donne la fréquence des séquences d'exécution en temps partagé, en supposant que toutes les tâches en temps réel utilisent leur traitement alloué.
On va maintenant décrire la division des tâches en modules.
En revenant à la Figure 6, il faut noter que chacune des tâches résidant, soit dans la liste 610 des tâches en temps réel, soit dans la liste 630 des tâches en temps partagé, est en fait une série de structures de données contenant des références à des "modules" de l'architecture du mode de réalisation préféré. Une "tâche" de DSP, par exemple 611, est en fait une donnée d'une structure de données appelée la liste 610 de tâches qui référence une série de programmes exécutables appelée "modules". Par exemple, un tâche comme 611 peut se référer à des modules 621, 622, 623. Chacune des tâches 611 à 614 et 631 à 633 consiste en fait en éléments d'une structure de données qui se réfère à ces modules. Chacun des modules comme 621 à 623 est en lui même une série de structures de données.Les modules sont tous des fonctions, reliées à l'intérieur de la tâche, qui possèdent des fonctions prédéterminées. De cette manière, puisqu'ils possèdent cette structure de tâche à double niveau, les modules reliés peuvent être associés entre eux sous un en-tête de tâche.
Une tâche comme 611 dans le mode de réalisation préféré consiste en modules de DSP comme 621, 622 et 623, et en tâches de DSP comme 611. Chacun des modules de DSP et chacune des tâches de DSP sont des structures de données et sont distinguées de la manière suivante:
Module de DSP: un module de DSP est le composant de base de la fonctionnalité des DSP. Il inclut toujours un code DSP, mais il peut également inclure aussi des données, des tampons d'entrée/de sortie et des blocs de paramètres. Le nombre des modules et les ressources qu'ils exigent peuvent être définis par le programmeur de DSP.
tâche de DSP. Une tâche de DSP consiste en un ou plusieurs modules de DSP. Ce groupage assemble entre eux, dans l'ordre approprié et avec les communications appropriées d'entrée/de sortie et de tampon, toutes les fonctions de base de modules nécessaires pour achever un travail particulier. Une tâche de DSP ne contient fréquemment qu'un seul module de DSP.
Des modules de DSP comme 621, 622, 623 sont fournis à un programmeur d'application sous forme de ressources et sont chargés dans une tâche de DSP comme 611 en utilisant un gestionnaire 211 de DSP. Une tâche est fabriquée en utilisant une série d'appels au gestionnaire 211 de DSP. Ces appels créent la structure de tâche, chargent et connectent des modules selon l'agencement souhaité, allouent la mémoire nécessaire et installent la tâche achevée dans une liste de tâches de DSP comme 610 ou 630. Des modules peuvent être, soit programmés par le programmeur d'application, soit obtenues en tant que sousprogrammes de bibliothèque commercialisés, appelés par le programmes d'application, qui fournissent une certaine fonctionnalité spécifique et qui atteignent un résultat souhaité par le programmeur d'application.
Chacun des modules 621 comprend un module de DSP 621a, qui contient une information d'indicateur et d'autres informations liées à la structure de donnée, ainsi qu'une série de sections 621b de DSP qui indiquent chacune diverses ressources et un code exécutable exigé par le module de DSP. Ceci est décrit de façon plus détaillée en référence aux Figures 10 à 12. Une vue plus détaillée d'une tâche et de son organisation de module est représentée en référence à la Figure 9.
A la Figure 12, 1200 représente la donnée de tâche 1201 et ses données associées de modules 1202 à 1206 qui comprennent une tâche unique intitulée "PhoneMan", c'est-à-dire littéralement: téléphoniste.
PhoneMan 1200 est une tâche de répondeur téléphonique implantée à l'intérieur du DSP 110 du mode de réalisation préféré. Dans ce mode de réalisation, la donnée 1201 de tâche est représentée comme possédant une certaine information de base à propos de la tâche, par exemple, le nom "PhoneMan", et est référencée à partir de la tâche précédente de la liste des tâches, et contient une référence à la tâche suivante de la liste des tâches. Il faut noter que la tâche PhoneMan 1200 peut être soit une tâche en temps réel soit une tâche en temps partagé, selon l'application. De plus, la donnée 1201 de tâche contient une référence à un module d'état 1202 de PhoneMan qui exerce diverses fonctions de commande à l'intérieur de la tâche. Par exemple, selon un mode de réalisation, le module de commande ou d'état 1202 peut commander le flux d'exécution à l'intérieur des modules restant 1203 à 1205. Il faut noter que 1202 à 1205 sont simplement des éléments de structure de données qui peuvent être, soit reliés en utilisant des indicateurs, soit référencés d'une autre manière bien connue de l'homme de l'art. On se référera au sous-programme exécutable réel nécessaire pour ce module dans des champs contenus avec chacun des éléments 1202 à 1205 de structure de données. Comme mentionné précédemment, les modules 1202 à 1205 peuvent être des modules commercialisés prêts à l'emploi, disponibles pour le programmeur d'application, ou bien le programmeur d'application peut lui même coder des modules 1202 à 1205.
Dans l'exemple représenté à la Figure 12, il existe en plus du module d'état 1202 qui commande l'exécution d'ensemble de la tâche 1200, un module
Subband Encoder, c'est-à-dire littéralement encodeur de sous-bande 1203. L'encodeur de sous-bande 1203 est utilisé pour enregistrer des messages venant de l'appelant entrant. Le module 1203 d'encodeur de sousbande référence un module 1204 de décodeur de sousbande qui est utilisé pour lire des salutations ou d'autres messages à l'appelant. Le module de décodeur de sous-bande 1204 référence le décodeur 1205 DTMF, c'est-à-dire à fréquence multiple à double tonalité.
Le décodeur 1205 DTMF est utilisé pour décoder les signaux de commande de tonalité de touches entrantes émis par l'appelant entrant. Les résultats de ce module sont rendus disponibles au module 1202 de statut et de commande lors de la séquence suivante par l'intermédiaire de la mémoire partagée et peuvent donc être utilisés pour modifier le fonctionnement du programme du répondeur téléphonique. On notera que les modules d'encodeur de sous-bande, de décodeur de sousbande et de décodeur de DTMF, dans cet exemple, sont probablement disponibles commercialement, tandis que le module d'état et de commande doit typiquement être écrit pour supporter une application particulière.
La structuration spéciale d'une tâche en "modules", exposée ci-dessus, offre certaines fonctions puissantes. Ceci constitue une amélioration sensible par rapport à la manipulation linéaire d'une liste de tâches qui ne fournit aucune connexion logique entre des tâches de la liste des tâches.
Ainsi, l'avantage principal du groupage des fonctions en tâches et en modules, exposé et décrit ci-dessus en référence aux Figures 6 à 12, est de grouper des fonctions par modules sous un en-tête général appelé une "tâche" afin de synchroniser très efficacement ses fonctions. Un autre avantage encore de l'utilisation de la structure de tâches à deux niveaux est le traitement des conditions d'erreur. Par exemple, si un module comme le module d'état 1202 ou l'encodeur de sous-bande 1203 est soumis à une condition d'erreur, les modules ultérieurs qui peuvent être exécutés comme 1204 ou 1205 peuvent être abandonnés ou marqués d'un drapeau indiquant de ne pas charger ni exécuter, et un message peut être renvoyé au gestionnaire de DSP du processeur serveur de manière à indiquer que la tâche a été abandonnée.De cette manière, toute la donnée de tâche 1200 peut être marquée d'un drapeau d'une manière telle que la tâche se trouve en condition d'erreur et la tâche peut dès lors être relancée, abandonnée ou enlevée de la liste des tâches. De nombreuses conditions de traitement d'erreurs sont envisagées à l'intérieur de l'esprit et du cadre de la présente invention.
Un autre avantage encore du groupage de tâches en modules sous un en-tête de tâches est de gérer la largeur de bande du processeur d'une manière efficace. De cette manière, la durée d'exécution dans le pire des cas, appelée la "largeur de bande de traitement garantie" ou GPB, des modules d'une tâche comme 1200 peut être maintenue dans une donnée comme l'élément 1201 de structure de donnée de tâches. En utilisant cette synchronisation du pire des cas, l'exécution des parties en temps réel et en temps partagé de la séquence peut être gérée efficacement à l'intérieur de la largeur de bande fournie par le processeur.
En général, l'avantage d'ensemble de l'existence d'une structure semblable à celle qui est représentée aux Figures 6 à 12 est de permettre au client une gestion efficace des tâches par modules. Ainsi, des conditions d'erreur, un temps insuffisant dans une séquence, un flux d'exécution comme décrit ci-dessous, une allocation de ressources comme une mémoire, et toutes autres conditions d'exploitation qui rendent commode une référence aux tâches par modules sont rendues sensiblement plus faciles pour le programmeur d'application. Puisqu'il est possible de se référer à des tâches d'une liste de tâches, et à ces tâches par les modules auxquelles elles se référencent, la gestion de processus dans le DSP est beaucoup plus efficace.En outre, le développement de programmes d'application est simplifié en permettant le développement de modules spécifiques de DSP qui doivent être utilisés pour former des programmes d'application.
En résumé, l'architecture modulaire du mode de réalisation préféré apporte de nombreux avantages par rapport à l'art antérieur. L'homme de l'art comprend que l'application et l'utilité de la structure présente des tâches réparties entre les listes de tâches que l'on peut appeler: à double convolution, comme représenté en 610 et en 630 à la Figure 6, et la structure en modules à deux niveaux représentée aux
Figures 6 et 12, est utilisable bien au delà de ce qui est décrit ici.
On va maintenant décrire la commande de flux d'exécution.
Un autre avantage qui résulte de la structuration des tâches en modules, décrite en référence à la
Figure 12 ci-dessous, est que la commande du flux d'exécution à l'intérieur des tâches peut être accomplie en plaçant, dans chaque module, des références à des modules ultérieurs. On y parvient dans le mode de réalisation préféré en lançant des appels à des sous-programmes dans le gestionnaire de
DSP. De cette manière, au lieu d'utiliser des structures de programmation à l'intérieur des programmes d'application afin de commander le flux d'exécution entre des modules d'une tâche, il est offert une possibilité de mettre à jour les modules et même d'empêcher leur chargement en mémoire, et donc de conserver des ressources et la largeur de bande du processeur. Ceci est effectué en utilisant une technique appelée le traitement par saut.
Le traitement par saut est décrit en référence à la Figure 13. A la Figure 13 est représentée la tâche 201 décrite ci-dessus, un champ comme le champ 1302 du module 1202 qui est intitulé "SkipCount", c'est-à-dire compte de sauts , étant cependant associé à chaque module. Un compte de sauts comme le champ 1302 indique quel est le module suivant à exécuter. Dans l'exemple représenté à la Figure 16, le module d'état 1202 contient un champ de compte de sauts 1302. Le compte de sauts 1302 peut contenir une valeur entière indiquant le module suivant qui doit être exécuté.
Ceci permet à l'exécution des modules de passer de façon appropriée et d'être commandée à l'intérieur de l'application au programme de DSP. La valeur contenue dans le champ de compte de sauts 1302 peut contenir, comme indiqué ci-dessous, une valeur qui spécifie le module suivant qui est exécuté.
Compte Action de sauts -1 Fin de tâche 0 Exécuter module suivant 1 sauter prochain module
(et exécuter module suivant) 2 sauter les deux prochains modules
N Sauter les N modules suivants (passer au
N+1-ième module après le module actuel)
En se référant à l'exemple représenté à la Figure 13, 1302 contient un x, c'est-à-dire une valeur indéfinie, indiquant que cette valeur de compte de sauts est définie par le module 1202 d'état et de commande. Des comptes de sauts comme 1302 à l'intérieur d'un module ne peuvent être modifiés que par le module, ou par le serveur. Dans ce cas, le compte de sauts 1302 est modifié par le module qui le possède, 1202. Si le téléphone est accroché et ne sonne pas, cette valeur est placée à -1 par un appel au noyau résidentiel de DSP, et aucun des autres modules de PhoneMan n'est exécuté.Ceci libère le temps maximal pour des tâches en temps partagé.
Dès lors que le téléphone sonne le nombre approprié de fois, comptées par le module 1202, il est décroché, également par le module 1202. Quelques séquences plus tard, il est approprié qu'un message de salutation soit lu. Le module d'état et de commande 1202 fait passer son champ de compte de sauts 1302 de - 1 à 1, et le module 1204 de décodeur de sous-bande et le module 1205 de décodeur de DTMF sont donc activés en sautant le module suivant 1203.Le décodeur de sous-bande 1204 lit les messages, qui durent habituellement de nombreuses séquences, et le module 1205 de décodeur DTMF explore la donnée entrante pour voir si l'appelant émet des ordres à une application par l'intermédiaire des touches de son poste à clavier. S'il en est ainsi, ces valeurs sont placées dans un emplacement de mémoire partagée en vue d'un traitement, soit par l'application, soit par le module 1202 d'état et de commande. De cette manière, un appelant peut interrompre les salutations et accéder à d'autres fonctions du répondeur. Ces autres fonctions pourraient être traitées par l'application de serveur, ou par des modules additionnels de la tâche.
Dès lors que les salutations ont été achevées et qu'une tonalité aiguë, est émise, en tant que partie de la salutation, ou engendrée par un autre module encore, le module d'état et de commande 1202 fait passer son compte de sauts 1302 a 0, en amenant le module d'encodeur de sous-bande 1203 à devenir actif, c'est-à-dire en sautant au module suivant 1203.
Puisque le compte de sauts 1303 du module 1203 d'encodeur de sous-bande est à 1, l'exécution passe au décodeur de DTMF 1205 et saute le module suivant, le décodeur de sous-bande 1204. Ce choix permet à tout message entrant d'être enregistré et maintient cependant la fonction de décodeur DTMF en vue d'une poursuite de commande d'accès à distance par l'appelant. Dès lors que le module 1202 d'état et de commande détermine que l'appel est achevé, il fait sauter son compte de sauts 1302 en retour à -1, et le traitement reste dans le module unique de commande 1202 jusqu'à ce qu'un nouvel appel soit reçu.
Comme l'homme de l'art le comprend, il existe de nombreuses configurations possibles pour une tâche à modules multiples, selon la fonction souhaitée et les modules de fonctions disponibles. Dans l'exemple de la tâche 1200 PhoneMan, tous les modules peuvent être des fonctions classiques, à l'exception du module 1202 d'état et de commande qui doit être écrit spécifiquement pour l'application de répondeur téléphonique. En revanche, les modules 1203 à 1205 de codeurs de sous-bande et de décodeur DTMF ne sont pas nécessairement spécifiques à l'application téléphonique mais peuvent être utilisés dans d'autres configurations et d'autres applications et peuvent être réalisés commercialement sous forme de composants prêts à l'emploi.Normalement, le compte de sauts de ces modules est lancé à 0 lorsqu'il est chargé et il doit être placé à des valeurs souhaitées pour l'application spécifique par le programme d'application avant de placer la tâche active. On note ici encore que, dans le mode de réalisation préféré, des modules ne peuvent modifier que leur propre compte de sauts, mais que le processeur serveur peut également modifier le compte de sauts de chacun de ces modules à un instant quelconque. Ceci permet à un module de commande comme 1202 d'effectuer de telles actions par l'intermédiaire du serveur.
Un jeu d'exemples utilisant le champ de compte de sauts est représenté aux Figures 14a et 14b. Par exemple, comme représenté à la Figure 14a, tous les modules 1401 à 1405 sont exécutés successivement parce que chacun des comptes de sauts contenus dans les modules est égal à 0, sauf pour 1405, qui contient le compte de sauts de -1, qui indique que c'est le dernier module de la liste d'exécution. On notera que la valeur du compte de sauts du dernier module est sans importance puisque l'exécution de la tâche s'y termine dans tous les cas. La Figure 14b représente un exemple dans lequel des modules 141à, 1411 et 1413 sont exécutés successivement. Le compte de sauts 1410 contient un 0, ce qui indique qu'il doit sauter au module suivant 1411. Le compte de sauts 1411 contient un 1 qui indique qu'il doit sauter le module suivant 1412 et passer donc à l'exécution du module 1413.Le compte de sauts du module 1412 est ignoré. Le module 1413 contient un champ de compte de sauts de -1 indiquant qu'il est le dernier module à exécuter.
Un autre exemple encore d'un flux d'exécution est représenté à la Figure 14c. Le trajet d'exécution à la
Figure 14c exécute successivement 1420, 1421 et ensuite 1422. Le champ de compte de sauts de 1420, comme aussi le module 1421, contient un 0. Ainsi, chacun de ces modules est exécuté successivement, en passant la commande au module 1422. Le champ de compte de sauts de 1422 est égale -1, ce qui indique que c'est le dernier module du trajet d'exécution (Figure 14c). Finalement, l'exécution des modules représentée à la Figure 14d passe du module 1430 au module 1433.
Le module 1430 comprend un compte de sauts égal à 2, ce qui indique que l'exécution doit sauter les modules 1431 et 1432. Les modules 1431 et 1432 sont sautés et ne sont pas exécutés, et l'exécution passe au module 1433. Leurs comptes de sauts sont ignorés. 1433 contient un compte de sauts égal à 0, ce qui indique que l'exécution doit passer au module 1434, et le compte de sauts du module 1434 contient un - 1, ce qui indique que c'est le dernier module du flux d'exécution.
Ainsi, l'homme de l'art peut comprendre qu'une flux de commande de modules agencés de la manière décrite en référence aux Figures 13 et 14a à 14d, empêche un chargement inutile de modules exécutables.
En utilisant un champ de compte de sauts comme décrit ci-dessus, on évite donc une consommation inutile de ressources, qui serait due à un chargement et une sauvegarde de programmes, exécutés alors qu'ils ne sont pas nécessaires. L'homme de l'art comprend que l'utilisation d'un compte de sauts et donc la commande externe de flux d'exécution en dehors de modules exécutables possède une utilité qui dépasse celle qui est décrite ici. L'homme de l'art comprend aussi que la valeur particulière et l'association du compte de sauts en tant que champ à l'intérieur de la donnée du module n'est pas nécessaire pour mettre en oeuvre la présente invention.Par exemple, dans une variante de mode de réalisation, un compte de sauts peut représenter le module suivant à exécuter, une valeur entière positive N indiquant à quel N-ième module suivant il faut sauter, une valeur négative pouvant être utilisée pour revenir à un module antérieur exécuté de la tâche, un -l signifiant par exemple un retour au module précédant et un 0 signifiant la fin de la tâche. On peut comprendre que de nombreuses variantes situées à l'intérieur du cadre de l'invention décrit ci-dessus peuvent être réalisées par l'homme de l'art.
On va maintenant décrire la synchronisation de l'exécution de tâche.
Une autre particularité présentée par la structuration spéciale des tâches en une liste de tâches selon le mode de réalisation préféré, par exemple une liste 610 de tâches en temps réel et une liste 630 de tâches en temps partagé, est l'utilisation d'une série de drapeaux pour commander l'exécution de tâches à l'intérieur d'un intervalle de temps spécifié. Une activation et une désactivation simultanées de tâches est réalisée pour des tâches en temps réel dans le mode de réalisation préféré parce qu'il peut falloir que certaines de ces tâches soient exécutées en ne laissant qu'un intervalle de temps particulier maximal entre l'une et l'autre. Ceci est exigé dans deux cas:
1) Une tâche ou une série de tâches doit être commencée de façon successive à une séparation particulière de séquences sur le même processeur.
2) Une tâche ou série de tâches doit être commencée successivement à une séparation particulière de séquence sur des processeurs différents.
Le premier cas peut se produire si la première tâche, la productrice de données, n'engendre pas des données synchrones en séquences, c'est-à-dire la valeur de données d'une séquence à chaque séquence, et est connectée à une tâche, la consommatrice de données, qui exige des données à chaque séquence. Un exemple de ce cas est un décodeur qui agit sur des séquences plus longues que la fréquence actuelle de séquence et qui doit donc interrompre le décodage de ces données et le répartir sur plusieurs séquences, et qui ne possède une sortie de donnée que lorsque ceci est achevé. Un exemple est le décodeur audio MPEG II, qui utilise des séquences plus grandes que la fréquence normalisée de séquences prévue dans le système du mode de réalisation préféré.Le résultat est que la sortie de données de telles tâches s'effectue "par paquets" au lieu d'être synchrone avec les séquences et qu'elle doit donc être envoyée dans une tampon premier entré-premier sorti, ou FIFO et que la consommatrice de données doit être lancée un certain nombre fixe de séquences plus tard. Le serveur ne peut pas être suffisamment sensible pour pouvoir assurer, sans mécanisme de temps réel, que la séquence de départ est correcte ou en temps.
Le deuxième cas est plus facile à voir.
Lorsqu'une série de tâches synchrones en séquence s'envoient des données les unes aux autres sur un processeur unique, une synchronisation de données est automatique. Toutes les tâches devraient être lancées au même instant, et le flux et la synchronisation de données sont déterminés par l'ordonnancement des tâches et des modules. En revanche, si les mêmes tâches sont placées sur plusieurs processeurs différents synchrones en séquences, il n'existe aucune garantie de leur relation temporelle à l'intérieur d'une séquence donnée. En fait, les données doivent être transférées par l'intermédiaire d'un tampon, par exemple un FIFO, et la tâche productrice doit être lancée une séquence avant la tâche consommatrice afin d'assurer qu'il existe pour la consommatrice une alimentation en données à chaque séquence.Dans le mode de réalisation préféré, une version simplifiée du
FIFO est utilisée dans ce but. Ce FIFO simplifié est appelé un HIHO et il ne retient que deux séquences de données. L'homme de l'art comprendra facilement que ce cas, c'est-à-dire un tampon de séquence et un déport de début d'une séquence, est le cas de latence minimal d'un tel système.
Ainsi, ce qu'il faut est un mécanisme qui permette à un programmeur d'application de serveur d'établir l'activation d'un ensemble de tâches, qui peuvent être sur un DSP ou sur plusieurs DSP différents, dans lequel elles peuvent être activées selon une succession appropriée et une position relative de séquences. Alors qu'il est possible de réaliser ceci avec deux mécanismes séparés, l'un pour un processeur unique, et des mécanismes séparés pour des processeurs multiples, il est plus efficace de le faire à l'aide de mécanisme unique.
Le procédé du mode de réalisation préféré permettant d'accomplir cette synchronisation de début est également utilisé pour des tâches de désactivation. La fonction est identique. La fonction consiste en deux appels au gestionnaire de DSP et en un sous-programme dans le sous-programme d'exécution du noyau résidentiel de DSP.
Le client commence par indiquer au système les tâches qu'il souhaite activer, ou désactiver, ou toute combinaison d'activations et de désactivations, en effectuant une série d'appels "Set Task to Activate", c'est-à-dire: placer la tâche à activer. Cet appel, représenté à la Figure 15, établit une structure de données qui contient l'information nécessaire pour effectuer rapidement les opérations appropriées de la liste des tâches lorsqu'il est temps de le faire. Le client donne le nom de la tâche ou un numéro de référence de tâche et la séquence d'activation correspondante. Par exemple, la valeur relative de séquence d'activation de 0 (zéro) signifie que cette tâche commencera la première. Une valeur de 1 signifie que cette tâche commencera une séquence après toute tâche dont la valeur est 0.Une valeur de 2 signifie une activation retardée de deux séquences, etc. Ceci peut être utile pour la relation productrice / consommatrice décrite ci-dessus.
Le gestionnaire de DSP établit une structure de donnée possédant l'information nécessaire. Selon un mode de réalisation, la structure de donnée est un réseau. La donnée nécessaire est un moyen d'accès rapide à la structure de tâche, un indicateur de tâche, par exemple, et la valeur de déport d'activation de séquence décrite ci-dessus. Pour les systèmes à DSP multiples, une référence de DSP est également nécessaire pour permettre une vérification d'erreur. Le processus commence à l'étape 1501, le point d'entrée. L'étape 1502 vérifie la présence d'erreurs éventuelles. Selon un mode de réalisation, des erreurs incluent des conditions dans lesquelles la tâche est encore en train de répondre à un ordre précédent d'activation / désactivation. Pour un système à processeurs multiples, une tâche peut se produire si l'un des DSP spécifiés n'est pas synchrone en séquence avec des DSP précédemment spécifiés dans la liste actuelle d'activation. Une autre erreur est constituée par une tentative de synchroniser des tâches qui sont sur les deux listes 610 et 630 de tâches en temps réel et tâches en temps partagé, ou de tenter de synchroniser des tâches sur deux listes différentes de tâches en temps partagé. Aucune de ces opérations n'est sensée en raison de la nature de la liste des tâches en temps partagé. S'il se produit une erreur, un code d'erreur est renvoyé au client à l'étape 1503.
En supposant une absence d'erreurs, le processus passe à l'étape 1504, où il est déterminé si une liste d'activation a déjà été commencée pour ce client. On notera qu'il existe différentes manières d'implanter cette fonction, mais le procédé décrit ci-dessus est le mode de réalisation préféré. S'il n'existe aucune liste de ce genre, pour ce client, une nouvelle liste est commencée, à l'étape 1505. La tâche est ajoutée à la liste d'activation à l'étape 1506. la liste inclut toutes les données nécessaires pour accomplir l'activation. Finalement, le processus est achevé à l'étape 1507.
Le client appelle le sous-programme décrit autant de fois qu'il est nécessaire, en établissant la liste d'activation. Lorsque toutes les tâches nécessaires sont ajoutées dans la liste d'activation, le client effectue un appel d'activation de tâches, représenté à la Figure 16.
Le point d'entrée du sous-programme d'activation est représenté en 1601. L'étape 1602 vérifie si tous les DSP référencés dans la liste actuelle d'activation fonctionnent et sont synchronisés. Cette vérification répétée assure que la configuration n'a pas été modifiée pendant le temps où le client était en trait d'établir la liste des activations. Si l'une ou l'autre de ces deux conditions existe, un code d'erreur est renvoyé à l'étape 1603.
En supposant qu'aucune erreur n'est détectée, l'étape 1604 désactive des interruptions sur le serveur et calcule le numéro de séquence de référence.
Dans le mode de réalisation préféré, ce numéro est le numéro de séquence actuelle plus 2. Le fait que les interruptions sont invalidées et que ce calcul simple est effectué assure que la première séquence possible d'activation est suffisamment éloignée dans le futur pour que toutes les modifications à la liste des tâches soient achevées avant cette séquence. La valeur 2 est utilisée ici, plutôt que 1, parce qu'il est possible que le numéro actuel de séquence en mémoire partagée change immédiatement après la lecture de la valeur par le serveur. Si la première séquence d'activation possible est la valeur lue plus 1, et si le nombre change immédiatement après la lecture, la première séquence d'activation est déjà en cours, et une activation nécessaire peut être manquée.En ajoutant 2 au numéro des séquences pour retarder le début / arrêt simultané, il peut être assuré qu'au moins une séquence complète se passe après la lecture du nombre et avant que le traitement de mise à jour de la tâche ne doive être achevé.
On notera que ce mécanisme est prévu pour réaliser le temps d'invalidation d'interruption le plus court possible pour le serveur. La liste est structurée d'une manière telle qu'une exploration descendant des listes de tâches et une vérification des tâches souhaitées à synchroniser n'est pas nécessaire pendant le temps d'invalidation d'interruption.
A l'étape 1605, il est vérifié s'il existe d'autres tâches à traiter dans la liste d'activations.
Si tel est le cas, on passe à l'étape 1606. Ici, la valeur de déport fournie par le client est ajoutée au numéro de séquence de référence. Ceci donne le numéro de séquence d'activation de cette tâche. A l'étape 1607 ce numéro est mémorisé dans la structure de donnée de tâche en vue d'une utilisation par le noyau résidentiel de DSP. A l'étape 1608, le drapeau d'état demandé est basculé. Ce drapeau indique si la tâche devrait être active ou inactive. C'est un drapeau de demande puisque sa valeur n'indique pas l'état réel de la tâche. Il existe un autre drapeau, le drapeau d'état, que seul le noyau résidentiel peut modifier et qui indique l'état réel de la tâche. La convention de basculement est utilisée dans le mode de réalisation préféré parce que ceci permet au même mécanisme d'être utilisé soit pour l'activation soit pour la désactivation d'une tâche.Cependant, il est possible, selon une variante de mode de réalisation, d'utiliser des drapeaux séparés et ceci peut être traité par l'appel unique, en exigeant que le client passe un paramètre indiquant l'état que souhaite le processus, ou ceci peut être traité par des appels séparés, par exemple "Set Task to Activate " et "Set task to Inactivate", c'est-à-dire littéralement placer tâche à activer et placer tâche à inactiver.
Dès lors que cet élément de liste d'activation a été implanté, le processus revient à l'étape 1605 pour vérifier la présence d'éléments additionnels éventuels dans la liste d'activations. S'il n'en existe plus, le processus passe à l'étape 1609 alors qu'il revient dans le cas contraire à l'étape 1606. Les étapes 1606 et 1608 sont répétées pour chaque tâche de la liste d'activations.
A l'étape 1609, les interruptions destinées au serveur sont validées de nouveau. A l'étape 1610, le processus se défait de la liste d'activations. Des variantes de mode de réalisation peuvent exiger que le client effectue ceci. Finalement, le processus est terminé à l'étape 1611.
A cet instant, le client a achevé toutes les étapes nécessaires pour activer ou désactiver un ensemble d'une ou plusieurs tâches. On notera que chaque étape du processus n'exige pas d'attente par le serveur: chaque appel est immédiatement traité.
C'était là une autre des exigences du mécanisme: dans un systèmes à tâches multiples, il est souhaitable d'éviter que des boucles inactives attendent qu'un autre processus soit achevé. Ceci élimine un traitement du serveur en pure perte.
Ce processus est conçu pour se terminer au plus tard bien avant la fin de la séquence précédant la première séquence d'activation. Ceci évite toute condition de course entre le processeur serveur et le processeur de DSP et assure un traitement successif approprié des tâches dans le temps.
Le programme d'exécution du noyau résidentiel de
DSP est responsable de la mise en succession des tâches sur DSP. La partie concernée du programme d'exécution servant à traiter la fonction d'activation / désactivation est représentée à la Figure 17.
Le point d'entrée de prise en charge de l'événement d'activation du noyau résidentiel est représenté à l'étape 1701. Le noyau résidentiel compare l'état réel de la tâche à l'état demandé à l'étape 1702. S'ils sont identiques, le processus passe à l'étape 1706. S'ils sont différents, il passe à l'étape 1703. L'étape 1703 vérifie si le numéro de séquence d'activation est égal ou inférieur au numéro de la séquence actuelle. S'il l'est, le traitement continue à l'étape 1704. Dans le cas contraire, le traitement continue à l'étape 1706. L'étape 1704 modifie l'état actif pour qu'il soit le même que l'état demandé. L'étape 1705 envoie au serveur un message indiquant que l'activation ou la désactivation a été réalisée pour cette tâche.Cette étape est importante lorsqu'une gestion de l'alimentation est souhaitable, par exemple dans une application d'ordinateur portable. Un message permet au gestionnaire d'alimentation, qui fait partie du gestionnaire 211 de DSP, de déterminer quand l'alimentation peut être réduite ou éliminée dans le sous-système de DSP. Ceci est possible parce que toutes les activations et désactivations de tâches sont traitées par ce mécanisme. Dès lors que l'activation ou la désactivation de tâche est achevée, le processus continue à l'étape 1706.
On notera que, si le numéro de séquence d'activation est inférieur au numéro de séquence actuel, une erreur d'activation s'est produite, c'està-dire que la tâche aurait dû être activée dans une séquence antérieure. Ceci ne devrait jamais se produire dans un système configuré de façon appropriée. Cependant, dans certains modes de réalisation, cette erreur pourrait être vérifiée et rapportée par l'intermédiaire d'un message au gestionnaire de DSP et au client de la tâche.
A l'étape 1706 le noyau résidentiel détermine si la tâche actuelle est active ou inactive. On notera que l'état peut avoir changé à l'instant. Si la tâche est inactive, le processus continue par l'étape 1708 en recherchant la tâche suivante. Dans le cas contraire, l'étape 1707 exécute la tâche actuelle.
Dans l'un et l'autre des cas, le traitement continue par l'étape 1709. Le processus d'activation représenté à la Figure 17 est répété pour chaque tâche de temps partagé.
Une variante de mode de réalisation d'activation / désactivation simultanées de tâches est représentée à la Figure 18. Un processus d'activation / désactivation simultanées de tâches 1800 commence au point d'entrée 1801 et il est déterminé à l'étape 1802 si le sémaphore de tâches simultanées a été activé par l'un des client pris en charge par le DSP. Si le sémaphore d'activations simultanées de tâches n'a pas été activé par un client, le processus 1800 passe à l'étape 1807 et revient à l'étape 1809. En revanche, si le sémaphore d'activation / désactivation simultanées de tâches a été activé selon la détermination de l'étape 1802, il est déterminé à l'étape 1803 si ce client possède le sémaphore. Tous les clients qui ne possèdent pas le sémaphore peuvent lire le sémaphore, cependant, ils ne peuvent pas modifier le sémaphore.Par conséquent, dès lors qu'un client possède le sémaphore, et si un autre client ultérieur cherche un accès à ce dernier, l'étape 1703 conduit à la fin du processus 1800 pour cette tâche.
En bref, la tâche est contournée jusqu ce qu'il soit déterminé, soit que le sémaphore n'est pas activé, selon la détermination de l'étape 1802, soit que le client possède le sémaphore.
En revanche, si le client vérifiant le sémaphore d'activation de tâche possède effectivement le sémaphore, selon la détermination de l'étape 1803, le drapeau de bascule est vérifié à l'étape 1804. Le drapeau de bascule donne au gestionnaire de DSP l'instruction de "basculer" l'état du drapeau actif.
Ceci est exécuté à l'étape 1805. Le drapeau actif est utilisé pour activer la tâche. Ainsi, dès lors qu'un sémaphore a été activé, le drapeau active commande l'exécution de la tâche. En revanche, l'exécution de la tâche n'est effectuée que lorsque le drapeau de tâche active a été placé. Dans le cas contraire, le drapeau de tâche active est effacé et l'exécution de la tâche est arrêté. Par conséquent, le drapeau de bascule constitue un moyen d'activation ou de désactivation simultanées de tâches selon l'état du drapeau actif. Lors d'un passage ultérieur à travers le processus 1800, si la bascule n'est pas placée selon la détermination 1804, le drapeau de tâche active est vérifié et, s'il est placé, selon la détermination de l'étape 1806, la tâche est exécutée à l'étape 1807 et le processus 1800 revient à l'étape 1809.De manière similaire, dès lors qu'une tâche a été activée dans une séquence unique, par exemple dans un passage d'exécution antérieur du processus 1800, le drapeau actif de tâche peut être basculé à nouveau, comme déterminé à l'étape 1804 et exécuté à l'étape 1805. Puis, un passage ultérieur par 1800 détermine si le drapeau actif de tâche est placé à l'étape 1806. Si le drapeau actif de tâche est donc effacé, le processus 1800 passe à l'étape 1808 et l'exécution de tâche est arrêtée. Puis le processus 1800 peut se terminer à l'étape 1809.A cet instant, le client peut libérer le sémaphore et une exécution normale de toutes les tâches de la liste 610 de tâches en temps réel peut à nouveau être exécutée normalement jusqu'à ce qu'une autre tâche obtienne une commande du sémaphore d'activation / désactivation de tâches,
Ainsi, un moyen d'activer des tâches simultanément ou successivement dans une ou plusieurs listes de tâches est réalisé par les processus 1500, 1660, 1700 et 1800 exposés ci-dessus. Alors que ceci a été décrit en référence à des drapeaux et à des structures de données spécifiques, l'homme de l'art comprendra que ceci peut être implanté à l'aide de divers modes de réalisation sans s'écarter de l'esprit et du cadre de la présente invention.
Ainsi, en résumé, il a été fourni un procédé perfectionné de gestion de tâches dans un processeur.
Alors que la présente invention a été décrite particulièrement en référence aux Figures 1 à 18, l'homme de l'art comprendra que la présente invention est utilisable bien au delà de ce qui est décrit dans les Figures. Il est envisagé que de nombreuses altérations et modifications peuvent y être apportées par l'homme de l'art sans s'écarter de l'esprit et du cadre de la présente invention décrite ci-dessus.

Claims (34)

REVENDICATIONS
1. Procédé de groupage de tâches (611 à 614, 631 à 633) à exécuter par un processeur caractérisé en ce que
il comprend les étapes consistant à:
a créer une donnée de tâche (611 à 614, 631 à 633), ladite donnée de tâche (611 à 614, 631 à 633) incluant un élément identifiant d'une première tâche (611 à 614, 631 à 633), un champ servant à référencer une donnée de tâche (611 à 614, 631 à 633) suivante;
b. créer une référence à une donnée de premier module (300; 621a) dans ladite donnée de tâche (611 à 614, 631 à 633), ladite donnée de premier module (300; 621a) représentant une première partie de ladite tâche (611 à 614, 631 à 633); et
c. lier ladite donnée de premier module (300; 621a) à une deuxième donnée de module (300; 621a) servant à une deuxième partie de ladite tâche (611 à 614, 631 à 633) exerçant des fonction liées à ladite première partie de ladite tâche (611 à 614, 631 à 633).
2. Procédé selon la revendication 1, caractérisé en ce que
il comprend en outre le fait de relier ladite donnée de deuxième module (300; 621a) avec une donnée de troisième module (300; 621a) pour une troisième partie de ladite tâche (611 à 614, 631 à 633) exerçant des fonctions liées à ladite première et à ladite deuxième parties de ladite tâche (611 à 614, 631 à 633).
3. Procédé selon la revendication 1, caractérisé en ce que
il comprend en outre le fait de relier successivement ladite donnée de deuxième module (300; 621a) avec une série de données de quatrièmes modules (300; 621a) pour les parties restantes de ladite tâche (611 à 614, 631 à 633) exerçant des fonction liées à ladite première et à la dite deuxième parties de ladite tâche (611 à 614, 631 à 633).
4. Procédé selon la revendication 1 caractérisé en ce que
la donnée de premier module (300; 621a) contient une référence à un code exécutable de ladite première partie de ladite tâche (611 à 614, 631 à 633).
5. Procédé selon la revendication 1 caractérisé en ce que
la donnée de premier module (300; 621a) contient une référence aux sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) exécutable.
6. Procédé selon la revendication 5 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des tampons exigés par le premier module (300; 301 à 305).
7. Procédé selon la revendication 5 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des variables exigées par le premier module (300; 301 à 305).
8. Procédé selon la revendication 5 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des tables exigées par le premier module (300; 301 à 305).
9. Procédé selon la revendication 5 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des récipients primaires et secondaires exigés par le premier module (300; 301 à 305).
10. Procédé selon la revendication 5 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des interconnexions à tampons entre le premier module (300; 621a) et ledit deuxième module (300; 301 à 305).
11. Procédé selon la revendication 1 caractérisé en ce que
la donnée de deuxième module (300; 621a) contient une référence au code exécutable de ladite deuxième partie de ladite tâche (611 à 614, 631 à 633).
12. Procédé selon la revendication 1 caractérisé en ce que
la donnée de deuxième module (300; 621a) contient une référence aux sections (400; 621b) de ressources exigées par ledit deuxième module (300; 621a) exécutable.
13. Procédé selon la revendication 12 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit deuxième module (300; 621a) incluent des interconnexions à tampons entre le premier module (300; 621a) et ledit deuxième module (300; 301 à 305).
14. Procédé selon la revendication 3 caractérisé en ce que
chaque donnée de ladite série de données de quatrième module (300; 621a) contient une référence au code exécutable desdites parties restantes de ladite tâche (611 à 614, 631 à 633).
15. Procédé selon la revendication 3 caractérisé en ce que
chaque donnée de ladite série de données du quatrième module (300; 621a) contient une référence aux sections (400; 621b) de ressources exigées par lesdites parties restantes dudit code exécutable de ladite tâche (611 à 614, 631 à 633).
16. Procédé selon la revendication 15 caractérisé en ce que
les sections (400; 621b) de ressources exigées par chacune des données de ladite série de données du quatrième module (300; 621a) incluent des interconnexions à tampons entre un module (300; 621a) précédent et un module (300; 621a) suivant.
17. Procédé selon la revendication 1, caractérisé en ce que
ladite donnée de tâche (611 à 614, 631 à 633) inclut des interconnexions à tampons entre ladite donnée de tâche (611 à 614, 631 à 633) précédente et ladite donnée de tâche (611 à 614, 631 à 633) suivante.
18. Procédé selon la revendication 1 caractérisé en ce que
ladite donnée de premier module (300; 621a) inclut des interconnexions à tampons avec ladite donnée de deuxième module (300; 621a) et ladite donnée de deuxième module (300; 621a) inclut des interconnexions à tampons avec ladite donnée de premier module (300; 301 à 305).
19. Procédé selon la revendication 1 caractérisé en ce que
il comprend en outre une exécution d'une tâche (611 à 614, 631 à 633) associée à la donnée de tâche (611 à 614, 631 à 633) précédente, puis une exécution de la tâche (611 à 614, 631 à 633) actuelle, comprenant les étapes consistant à:
a. référencer la donnée de premi#er module (300; 621a) en utilisant la donnée de tâche (611 à 614, 631 à 633);
b. charger le contexte du premier module (300; 621a) en utilisant des sections (400; 621b) de ressources spécifiées dans ladite donnée de premier module (300; 301 à 305)-;
c. exécuter ladite donnée de premier module (300; 301 à 305); et
d. sauvegarder le contexte de ladite donnée de premier module (300; 301 à 305).
20. Procédé selon la revendication 19 caractérisé en ce que
il comprend en outre une exécution des étapes b à d, la donnée de deuxième module (300; 621a) devenant la donnée de premier module (300; 621a) et la donnée de premier module (300; 621a) devenant la donnée de tâche (611 à 614, 631 à 633).
21. Procédé selon la revendication 1 caractérisé en ce que
le processeur est un processeur de signaux numériques ou DSP.
22. Appareil de groupage et d'exécution de tâches (611 à 614, 631 à 633) par un processeur, caractérisé en ce qu'il comprend:
a un moyen de création d'un moins une donnée de tâche (611 à 614, 631 à 633), la donnée de tâche (611 à 614, 631 à 633) incluant un élément identifiant d'une premier tâche (611 à 614, 631 à 633) et une référence à une donnée de tâche (611 à 614, 631 à 633) suivante;
b. un moyen de création d'une référence à une donnée de premier module (300; 621a) dans ladite donnée de tâche (611 à 614, 631 à 633), ladite donnée de premier module (300; 621a) représentant un premier module (300; 621a) exécutable de ladite tâche (611 à 614, 631 à 633); et
c. un moyen de liaison de ladite donnée de premier module (300; 621a) à une donnée de deuxième module (300; 621a) représentant un deuxième module (300; 621a) exécutable exerçant des fonctions liées audit premier module (300; 621a) exécutable.
23. Appareil selon la revendication 22, caractérisé en ce que
il comprend en outre un moyen de liaison de ladite donnée de deuxième module (300; 621a) à une série de données de quatrième module (300; 621a) pour les parties restantes de ladite tâche (611 à 614, 631 à 633) exerçant des fonctions liées à ladite et à ladite deuxième parties de ladite tâche (611 à 614, 631 à 633).
24. Appareil selon la revendication 22, caractérisé en ce que
la donnée de premier module (300; 621a) contient une référence au code exécutable de ladite première partie de ladite tâche (611 à 614, 631 à 633).
25. Appareil selon la revendication 22 caractérisé en ce que
la donnée de premier module (300; 621a) contient une référence aux sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) exécutable.
26. Appareil selon la revendication 25, caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des tampons exigés par le premier module (300; 301 à 305).
27. Appareil selon la revendication 25, caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des variables exigées par le premier module (300; 301 à 305).
28. Appareil selon la revendication 25 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des tables exigées par le premier module (300; 301 à 305).
29. Appareil selon la revendication 25 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des récipients primaires et secondaires exigés par le premier module (300; 301 à 305).
30. Appareil selon la revendication 25 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit premier module (300; 621a) incluent des interconnexions à tampons entre le premier module (300; 62la) et ledit deuxième module (300; 301 à 305).
31. Appareil selon la revendication 25 caractérisé en ce que
la donnée de deuxième module (300; 621a) contient une référence au code exécutable de ladite deuxième partie de ladite tâche (611 à 614, 631 à 633).
32. Appareil selon la revendication 22 caractérisé en ce que
la donnée de deuxième module (300; 621a) contient une référence aux sections (400; 621b) de ressources exigées par ledit deuxième module (300; 621a) exécutable.
33. Appareil selon la revendication 35 caractérisé en ce que
les sections (400; 621b) de ressources exigées par ledit deuxième module (300; 621a) incluent des interconnexions à tampons entre ledit premier module (300; 621a) et ledit deuxième module (300; 301 à 305).
34. Donnée de première tâche (611 à 614, 631 à 633) représentée comme série d'impulsions électriques dans un système de traitement de donnée pour représenter une première tâche (611 à 614, 631 à 633) dans une liste (610, 630) de tâches (611 à 614, 631 à 633) à exécuter par ledit système de traitement de données, caractérisé en ce que
ladite donnée de première tâche (611 à 614, 631 à 633) comprend:
a. un élément identifiant par ladite première tâche (611 à 614, 631 à 633);
b. un champ de liaison de ladite donnée de première tâche (611 à 614, 631 à 633) avec une donnée de tâche (611 à 614, 631 à 633) suivante, représentant une tâche (611 à 614, 631 à 633) suivante dans ladite liste (610, 630) de tâches (611 à 614, 631 à 633));
c. un champ de liaison de ladite donnée de première tâche (611 à 614, 631 à 633) à une donnée de premier module (300; 301 à 305), ladite donnée de module (300; 621a) représentant un premier module (300; 621a) qui comprend une première fonction de ladite première tâche (611 à 614, 631 à 633), ladite donnée de premier module (300; 621a) comprenant:
i. une référence à un premier code exécutable pour ledit premier module (300; 301 à 305);
il. un champ de liaison de ladite donnée de premier module (300; 621a) à une donnée de module (300; 621a) suivante; et
iii. un champ de spécification des interconnexions à tampons entre le premier module (300; 621a) et le module (300; 621a) suivant.
FR9311209A 1992-09-30 1993-09-21 Organisation en tâches et en modules d'une exécution dans un processeur. Pending FR2696259A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US95498892A 1992-09-30 1992-09-30

Publications (1)

Publication Number Publication Date
FR2696259A1 true FR2696259A1 (fr) 1994-04-01

Family

ID=25496205

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9311209A Pending FR2696259A1 (fr) 1992-09-30 1993-09-21 Organisation en tâches et en modules d'une exécution dans un processeur.

Country Status (2)

Country Link
US (1) US5448735A (fr)
FR (1) FR2696259A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0644484A2 (fr) * 1993-09-21 1995-03-22 Microsoft Corporation Méthode multitâche préemptive sur des tâches groupées
WO2003093995A2 (fr) * 2002-04-30 2003-11-13 Livedevices Limited Ameliorations se rapportant a la repartition de taches dans des systemes d'exploitation temps reel preemptifs a priorites

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6854116B1 (en) * 1992-09-30 2005-02-08 Apple Computer, Inc. Execution control for process task
US6951019B1 (en) * 1992-09-30 2005-09-27 Apple Computer, Inc. Execution control for processor tasks
US5586317A (en) * 1993-07-30 1996-12-17 Apple Computer, Inc. Method and apparatus for implementing I/O in a frame-based computer system
US5687369A (en) * 1993-09-02 1997-11-11 International Business Machines Corporation Selecting buckets for redistributing data between nodes in a parallel database in the incremental mode
US6948172B1 (en) 1993-09-21 2005-09-20 Microsoft Corporation Preemptive multi-tasking with cooperative groups of tasks
US6430592B1 (en) * 1994-06-02 2002-08-06 International Business Machines Corporation System for sharing CPU time amongst multiple users
DE19500957A1 (de) * 1994-07-19 1996-01-25 Bosch Gmbh Robert Verfahren zur Steuerung von technischen Vorgängen oder Prozessen
US5680608A (en) * 1995-02-06 1997-10-21 International Business Machines Corporation Method and system for avoiding blocking in a data processing system having a sort-merge network
WO1996041279A1 (fr) * 1995-06-07 1996-12-19 Advanced Micro Devices, Inc. Systeme informatique comportant un moteur multimedia et une memoire multimedia specialises
US5784592A (en) * 1995-09-11 1998-07-21 Advanced Micro Devices, Inc. Computer system which includes a local expansion bus and a dedicated real-time bus for increased multimedia performance
US5692211A (en) * 1995-09-11 1997-11-25 Advanced Micro Devices, Inc. Computer system and method having a dedicated multimedia engine and including separate command and data paths
US5748921A (en) * 1995-12-11 1998-05-05 Advanced Micro Devices, Inc. Computer system including a plurality of multimedia devices each having a high-speed memory data channel for accessing system memory
US5898892A (en) * 1996-05-17 1999-04-27 Advanced Micro Devices, Inc. Computer system with a data cache for providing real-time multimedia data to a multimedia engine
US6134601A (en) * 1996-06-17 2000-10-17 Networks Associates, Inc. Computer resource management system
CA2224466C (fr) * 1997-01-09 2003-12-23 Mitel Corporation Transfert de connaissances de base a des agents
US6145007A (en) * 1997-11-14 2000-11-07 Cirrus Logic, Inc. Interprocessor communication circuitry and methods
DE19835177A1 (de) * 1998-08-04 2000-02-10 Alcatel Sa Verfahren, Module und Vermittlungsstelle zum Kennzeichnen von Prozessen sowie von deren Daten und Betriebsmitteln
US6282631B1 (en) 1998-12-23 2001-08-28 National Semiconductor Corporation Programmable RISC-DSP architecture
US7047537B1 (en) * 2000-01-04 2006-05-16 Cisco Technology, Inc. Code linking system
US7140022B2 (en) * 2000-06-02 2006-11-21 Honeywell International Inc. Method and apparatus for slack stealing with dynamic threads
US7512951B2 (en) * 2000-07-31 2009-03-31 Infineon Technologies Ag Method and apparatus for time-sliced and multi-threaded data processing in a communication system
EP1410199A2 (fr) * 2000-11-06 2004-04-21 Koninklijke Philips Electronics N.V. Procede et systeme permettant d'affecter un budget a une tache
US7140016B2 (en) * 2000-11-29 2006-11-21 Texas Instruments Incorporated Media accelerator quality of service
JP3578082B2 (ja) * 2000-12-20 2004-10-20 株式会社デンソー 処理実行装置及び記録媒体
DE10065498B4 (de) * 2000-12-28 2005-07-07 Robert Bosch Gmbh Verfahren und Vorrichtung zur Rekonstruktion des Prozessablaufs eines Steuerprogramms
US7093254B2 (en) * 2002-04-01 2006-08-15 International Business Machines Corporation Scheduling tasks quickly in a sequential order
GB2388213A (en) * 2002-04-30 2003-11-05 Innovation Ct Improvements relating to task dispatch in priority pre-emptive real-time operating systems
US6985150B2 (en) * 2003-03-31 2006-01-10 Sun Microsystems, Inc. Accelerator control unit configured to manage multiple hardware contexts
CN1275480C (zh) * 2003-07-31 2006-09-13 上海贝尔阿尔卡特股份有限公司 一种多标准软件无线电(sdr)基带处理方法
US7791741B2 (en) * 2005-04-08 2010-09-07 Palo Alto Research Center Incorporated On-the-fly state synchronization in a distributed system
US7873962B2 (en) * 2005-04-08 2011-01-18 Xerox Corporation Distributed control systems and methods that selectively activate respective coordinators for respective tasks
US8819103B2 (en) * 2005-04-08 2014-08-26 Palo Alto Research Center, Incorporated Communication in a distributed system
US7706007B2 (en) * 2005-04-08 2010-04-27 Palo Alto Research Center Incorporated Synchronization in a distributed system
US7793299B2 (en) * 2005-08-30 2010-09-07 International Business Machines Corporation System and method for scheduling tasks for execution
US7583262B2 (en) * 2006-08-01 2009-09-01 Thomas Yeh Optimization of time-critical software components for real-time interactive applications
JP2008102830A (ja) * 2006-10-20 2008-05-01 Denso Corp マイクロコンピュータ、プログラム及び車両用電子制御装置
US9424102B2 (en) * 2014-05-14 2016-08-23 International Business Machines Corporation Task grouping by context

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4229790A (en) * 1978-10-16 1980-10-21 Denelcor, Inc. Concurrent task and instruction processor and method
US4507752A (en) * 1983-02-22 1985-03-26 International Business Machines Corporation In-place index compression
US4864492A (en) * 1986-09-17 1989-09-05 International Business Machines Corporation System and method for network configuration
US5247658A (en) * 1989-10-31 1993-09-21 Microsoft Corporation Method and system for traversing linked list record based upon write-once predetermined bit value of secondary pointers
JP2829078B2 (ja) * 1990-02-05 1998-11-25 株式会社日立製作所 プロセス分散方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
A. VAN TILBORG AND L. WITTIE: "Distributed task force scheduling in multi-microcomputer networks", AFIPS CONFERENCE PROCEEDINGS 1981 NATIONAL COMPUTER CONFERENCE, vol. 50, 4 May 1981 (1981-05-04), CHICAGO, USA, pages 283 - 289 *
D. BROWN ET AL: "Scheduling of computer processing among group of users", IBM TECHNICAL DISCLOSURE BULLETIN., vol. 19, no. 11, April 1977 (1977-04-01), NEW YORK US, pages 4305 - 4310 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0644484A2 (fr) * 1993-09-21 1995-03-22 Microsoft Corporation Méthode multitâche préemptive sur des tâches groupées
EP0644484A3 (fr) * 1993-09-21 1995-04-26 Microsoft Corp
US6052707A (en) * 1993-09-21 2000-04-18 Microsoft Corporation Preemptive multi-tasking with cooperative groups of tasks
WO2003093995A2 (fr) * 2002-04-30 2003-11-13 Livedevices Limited Ameliorations se rapportant a la repartition de taches dans des systemes d'exploitation temps reel preemptifs a priorites
WO2003093995A3 (fr) * 2002-04-30 2004-12-29 Livedevices Ltd Ameliorations se rapportant a la repartition de taches dans des systemes d'exploitation temps reel preemptifs a priorites

Also Published As

Publication number Publication date
US5448735A (en) 1995-09-05

Similar Documents

Publication Publication Date Title
FR2696259A1 (fr) Organisation en tâches et en modules d'une exécution dans un processeur.
EP3417380B1 (fr) Enregistrement de conférences web
FR2950714A1 (fr) Systeme et procede de gestion de l'execution entrelacee de fils d'instructions
CN104572294B (zh) 预测性自动缩放引擎
FR2937439A1 (fr) Procede d'execution deterministe et de synchronisation d'un systeme de traitement de l'information comportant plusieurs coeurs de traitement executant des taches systemes.
US9535768B2 (en) Managing multi-threaded operations in a multimedia authoring environment
WO2019024638A1 (fr) Procédé et système de mise en pause de diffusion en direct, appareil de mise en pause de diffusion en direct, et serveur de diffusion en direct
FR2756070A1 (fr) Systeme de gestion et de traitement de transactions distribuees d'objets et procede mis en oeuvre par ledit systeme
TW201709059A (zh) 持續及有彈性之工作處理
EP1949234A1 (fr) Procede et systeme de calcul intensif multitache et multiflot en temps reel
EP0637798B1 (fr) Procédé d'analyse d'interblocage dans un système d'exploitation
US10908963B2 (en) Deterministic real time business application processing in a service-oriented architecture
EP0517558A1 (fr) Dispositif permettant d'accroître les performances d'un noyau d'exécutif temps réel associé à une structure multiprocesseur pouvant comprendre un nombre élevé de processeurs
EP3665571B1 (fr) Procédé d'exécution de plans de séquencement assurant une communication à faible latence entre tâches temps-réel
FR2881309A1 (fr) Procede d'optimisation de la transmission de donnees de journalisation en environnement multi-ordinateurs et systeme mettant en oeuvre ce procede
EP2545449B1 (fr) Procédé de configuration d'un système informatique, programme d'ordinateur et système informatique correspondants
EP2875428B1 (fr) Procede de gestion des fils d'execution dans une unite informatique et unite informatique agencee pour la mise en oeuvre de ce procede
WO2013110816A2 (fr) Procédé d'utilisation d'une mémoire partagée
JP2018538632A (ja) ノードの再起動後にデータを処理する方法及びデバイス
FR2980611A1 (fr) Circuit pour planifier le deroulement d'un traitement de donnees
US20230143133A1 (en) Intelligently enhancing media content items
FR2894694A1 (fr) Procede et dispositif de mise au point d'un programme execute par un processeur multitache
FR2895532A1 (fr) Systeme informatique dote de moyens de gestion de ressources ameliores
EP1410178A2 (fr) Procede et systeme de gestion du temps dans un systeme temps reel
FR3041448A1 (fr) Systeme et procede de lancement et d'arret automatique des services a duree de vie limitee dans un systeme d'exploitation