EP2145255A1 - Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants. - Google Patents

Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.

Info

Publication number
EP2145255A1
EP2145255A1 EP08736208A EP08736208A EP2145255A1 EP 2145255 A1 EP2145255 A1 EP 2145255A1 EP 08736208 A EP08736208 A EP 08736208A EP 08736208 A EP08736208 A EP 08736208A EP 2145255 A1 EP2145255 A1 EP 2145255A1
Authority
EP
European Patent Office
Prior art keywords
application
processor
time
processor time
applications
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.)
Withdrawn
Application number
EP08736208A
Other languages
German (de)
English (en)
Inventor
Thierry Didi
Jacques Montes
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.)
Sierra Wireless SA
Original Assignee
Sierra Wireless SA
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 Sierra Wireless SA filed Critical Sierra Wireless SA
Publication of EP2145255A1 publication Critical patent/EP2145255A1/fr
Withdrawn 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
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic

Definitions

  • the field of the invention is that of computers comprising a single processor (also called single processor computers) and an operating system for managing the execution, by this processor, of several applications (also called programs).
  • each application includes one or more processes, and allows the execution of one or more tasks. Indeed, each process includes a sequence of elementary instructions (called “son”, “lightened processes”, or “threads” in English) necessary for the execution of a task. In the case where an application allows the execution of several tasks, each task can be associated with a priority level within the application.
  • the invention relates to a management technique, by an operating system, a time of use of a single processor by at least two applications.
  • processor time is called "processor time”.
  • the invention applies in particular, but not exclusively, in the case where the operating system is a real-time operating system (RTOS), that is, say in the case where at least one of the applications has to be executed in real time.
  • RTOS real-time operating system
  • the operating system is then called multi-task. Indeed, one of the roles of the operating system (and more specifically of the operating system kernel scheduler) is to allow multiple processes to run and to use the processor optimally from the point of view of the user. In order to give the illusion that several processes are processed simultaneously, the scheduler relies on notions of context switching and scheduling.
  • each task is assigned a priority and can be in one of five states: dormant (it is not sequenced), executable (it is ready to execute instructions but does not currently have the use of the processor), active (its instructions are running by the processor), blocked (its execution is suspended pending a signal or the availability of a resource) and interrupted (it executes a user-programmed interrupt routine).
  • the scheduler always assigns the processor to the non-dormant and unblocked task that has the highest priority.
  • the scheduler is not preemptive.
  • the disadvantage is that the response time of a task is affected by the behavior of the lower priority tasks; either the operating system switches the task T1 in the executable state and assigns the processor to T2.
  • the scheduler is preemptive.
  • the scheduling algorithm is of the Round-robin type: it allocates time slots to each process in equal proportion without prioritizing processes.
  • the priority scheduling technique has other drawbacks because it performs task-level, not application-level, management: a task from a first application can always be stopped (it then switches to executable state) because a higher priority task of a second application goes into the executable state. So, this first application does not have a minimum processor time. It seems difficult to harmonize the task priorities of all applications, especially since it is common for applications to run on the same processor from different vendors; if the highest priority task (all applications combined) causes a crash, all applications (not just the one to which the crashed job belongs) are blocked and can not use the processor.
  • the solution proposed today to solve this problem is to provide a "watchdog" mechanism ("watchdog") to ensure that an application has not not blocked at a particular stage of treatment. This mechanism is a protection intended to restart the system if a defined action is not executed within a given time.
  • Time-slice scheduling also has a disadvantage because it performs task-level and not application-level management. It is possible to guarantee a minimum processor time per task, but it is impossible to guarantee a minimum processor time for a given application. Indeed, the actual processor time that each application has depends on the total number of applications executed by the processor (in addition, not all applications have the same number of tasks). However some applications need more processor time than others and above all need a minimum processor time (for example an emergency call application, in case of accident).
  • time slice scheduling does not optimally utilize processor time. Indeed, if a task does not use all the time slot dedicated to it, the unused part of this time slot can not be assigned to another task, and is therefore lost. 3. OBJECTIVES OF THE INVENTION
  • the invention in at least one embodiment, is intended in particular to overcome these various disadvantages of the state of the art. More specifically, one of the objectives of the present invention, in at least one embodiment, is to provide a management technique, by an operating system, a time of use of a single processor by the least two applications, this technique to ensure a minimum processor time to each application, even if one of the applications is blocked. The invention also aims, in at least one embodiment, to provide such a technique to optimize the use of processor time.
  • a complementary objective of the invention in at least one embodiment, is to provide such a technique that is simple to implement and inexpensive.
  • a complementary objective of the invention in at least one embodiment, is to provide such a technique that is transparent to the applications when they execute.
  • SUMMARY OF THE INVENTION in a particular embodiment of the invention, there is provided a method of management, by an operating system, of a time of use of a single processor by at least two applications. said operating time being called processor time, said method comprising the following steps: associating with each application a slice of said processor time, said processor time slot being able to be zero; association with each application of one of the following two classes:
  • processor time slice that is associated with said application is reserved for said application even if said application does not use it entirely, said application not being able to use more than the processor time slot associated therewith ;
  • a second class such that said application takes precedence to use the processor during the processor time slice associated with it, if a part of the processor time slot associated with said application is not used by said application, then said part not used may be used by another application of said second class, said application being able to use more than the processor time slot associated therewith using an unused portion of a processor time slot associated with another application of said second class or part of a time slot associated with no application; and - management of said processor time according to the processor time slots and classes associated with the applications.
  • the general principle of this embodiment therefore consists in performing processor time management at the level of the applications themselves (each application may include one or more processes, each process executing a task), and not at the task level. Whatever the class associated with it, each application has a minimum guaranteed processor time since a processor time slice (possibly zero) is associated with it.
  • processor time is optimized since, between applications of the second class, the portions of processor time slots not used by some applications are reused by other applications.
  • said processor time is divided into cycles, each cycle comprising a number N of time slots, and the processor time slot associated with each application comprises a number K 1 of time slots in each cycle, with 1 ⁇ K 1 ⁇ N, and i an index relating to the application.
  • each time interval defines the granularity of context switching between applications.
  • a short duration may increase system operation with, potentially, a high number of context switches between applications.
  • a long duration does not allow fine distribution of processor time between applications.
  • said method comprises the step of: if during a current cycle, a second class of application does not use the entire period of its K 1 time slots of the fact that it did not need the processor during X of said
  • a second catch-up mechanism is proposed, allowing a given application, over several cycles, to use the processor for a cumulative total duration equal to or close to the duration actually associated with this application.
  • said method comprises the following step, for at least one of said applications: association with said application of a start time for the processor time slot associated with said application, or a start time for each interval time included in the processor time slot associated with said application.
  • said method comprises the following step, for at least one application of the second class: association with said application of a priority level, making it possible to decide which application of the second class can use the processor in the case where several applications of the second class are eligible to use the processor.
  • a Round-robin algorithm is used to decide which application of the second class can use the processor in the case where several applications of the second class are eligible to use the processor.
  • the available processor time is distributed fairly evenly between applications in the second class because second-class applications do not use all the processor time slots associated with them.
  • said method comprises a verification step that the sum of the processor time slots of all the applications is less than or equal to 100% of an application processor time, defined as the difference between said processor time and a portion of said processor time used. by said operating system.
  • the system is suitably configured to operate in the worst case, that is, if each of the applications used the entire processor time slot associated with it (because it really needs it, case of a greedy application in processor time, or because there is a bug, case of an application entered in loop).
  • said operating system is a real-time operating system.
  • the present invention is particularly adapted to respond to real-time constraints.
  • the time slice associated with each application that has to run in real time should be properly chosen.
  • At least one interrupt is associated with none of said applications and is not taken into account in the management of said processor time.
  • At least one interruption is associated with none of said applications and is taken into account in the management of said processor time as follows: a quantity of time is reserved for all interrupts of the second type, so that the sum of the processor time slots of all applications is less than or equal to 100% of said processor time minus said amount of time reserved.
  • interruptions of the second type are taken into account in the management of the processor time, but independently of the applications.
  • At least one interruption is associated with at least one of said applications and is taken into account in the management of said processor time as follows: a quantity of processor time required for said interruption of the third type is taken into account in the processor time slot of the application or applications associated with said interrupt of the third type; and the processor time preempted by said interruption of the third type on at least one other application is retroceded to said at least one other application.
  • interruptions of the third type are taken into account in the management of the processor time, but in relation to the applications with which they are associated.
  • said processor is included in a radio communication circuit, and said applications comprise an application for managing a radio communication stack and at least one client application.
  • Radiocommunication circuit is an electronic radiocommunication module intended to be integrated into a radiocommunication device.
  • Radiocommunication devices also known as radio communication terminals or wireless terminals
  • the electronic radiocommunication module is for example a module of the "WISMO” (registered trademark) family of the company WAVECOM (applicant of the present patent application).
  • WISMO registered trademark
  • WAVECOM applicant of the present patent application.
  • the WAVECOM company has indeed for several years proposed an approach overcoming a number of these disadvantages, consisting in grouping together in a single module (called electronic radio communication module), all or at least most of the functions of a digital radiocommunication device .
  • Such a module is in the form of a single housing, preferably shielded, that the device manufacturers can implement directly, without having to take into account a multitude of components.
  • This module is formed of a grouping of several components on a substrate, so as to be implanted in the form of a single element.
  • the radiocommunication circuit is not a radiocommunication module in the aforementioned sense but a printed circuit included in a radiocommunication device and on which are directly implanted a set of electronic components whose purpose is to provide the various radiocommunication functions necessary, from the reception of an RF signal until the generation of an audible signal (in the case of a radio telephone), and vice versa.
  • the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, this computer program product comprising instructions program code for the implementation of the aforementioned method, when said program is executed on a computer.
  • the invention relates to a storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the above method.
  • the invention in another embodiment, relates to a device comprising an operating system for managing a time of use of a single processor by at least two applications, said time of use being called processor time.
  • This device comprises: means for associating with each application a slice of said processor time, said processor time slot being able to be zero; means of association with each application of one of the two following classes:
  • a first class such that the processor time slice that is associated with said application is reserved for said application even if said application does not use it entirely, said application not being able to use more than the processor time slot associated therewith ;
  • a second class such that said application takes precedence to use the processor during the processor time slice associated with it, if a part of the processor time slot associated with said application is not used by said application, then said part not used may be used by another application of said second class, said application being able to use more than the processor time slot associated therewith using an unused portion of a processor time slot associated with another application of said second class or part of a time slot associated with no application; and means for managing said processor time as a function of the processor time slots and the classes associated with the applications.
  • the device comprises means for implementing the processor time management method as described previously (in any one of its various embodiments). 5. LIST OF FIGURES
  • FIG. 1 shows a flowchart of a particular embodiment of the method according to the invention
  • FIG. 2 illustrates a first example of sharing of the processor time between three applications associated with the CTR class, according to a particular embodiment of the invention
  • FIG. 3 illustrates a second example of sharing of the processor time between three applications, one associated with the CTR class and the other two with the VTR class, according to a particular embodiment of the invention
  • Figure 4 illustrates an example of task tables and interrupt handlers associated with three applications, as well as the sharing of processor time between these three applications
  • FIG. 5 illustrates a third example of processor time sharing between three applications associated with the VTR class, according to a particular embodiment of the invention.
  • each application is associated with a slice of CPU time (or "CPU Time Slice”).
  • a periodic timer is used to divide the processor time into cycles, each cycle comprising a number N of time intervals (also noted
  • the processor time slot associated with each application comprises a number K 1 of time slots in each cycle, with 1 ⁇ K 1 ⁇ N, and i an index relating to the application.
  • Each time slot is therefore composed of the recurrence of a certain number of time slots within a cyclic structure comprising a determined number of time intervals. For example, if a time interval has a duration of 20 ms and a cycle includes 5 time slots, an application can be associated with a time slot comprising 2 * 20 ms every 100 ms.
  • each application is associated with one of the following two application classes: class CTR (for "Constant Time Rate” in English, or “constant time share” in French), such as the processor time slice that is associated with a CTR application is reserved for this application even if it does not use it entirely (that is to say even if it has no software activity during this time slot).
  • a CTR application can not use more than the processor time slice associated with it, even if the processor is idle; - class VTR (for "Variable Time Rate” in English, or “variable time share” in French), such as a CTR application has priority to use the processor during the processor time slice associated with it.
  • a VTR application may use more than the processor time slot associated with it, by using an unused portion of a processor time slot associated with another VTR application or a portion of a time slot associated with any application.
  • a start time of execution can be associated with at least one application.
  • This start time is for example defined by the number (rank within the aforementioned cycle) of the first of the time slots assigned to this application.
  • the time slot comprising 2 * 20 ms every 100 ms starts for example, with each cycle, with the first of the five intervals of the cycle.
  • a step 4 one associates with each of the applications VTR (or only with some of them) a level of priority. This priority is used to decide which VTR application can use the processor in case more than one VTR application is eligible to use the processor (when the processor is idle).
  • the application No. 1 is associated with the class C 1 (CTR or VTR), a processor time slot comprising K 1 time slots per cycle and starting at the X time interval of each cycle, and at a priority P 1 (if it is a VTR application).
  • CTR class C 1
  • P 1 priority
  • the operating system verifies that the sum of the processor time slots of all the applications is less than or equal to 100% of an application processor time, defined as the difference between the total processor time and a portion of this total processor time that is used by the operating system. In the above example, this amounts to checking that the cumulative total number of time slots associated with the different applications is not greater than the number of time slots in a cycle.
  • the operating system manages the processor time according to all the information associated with the applications (that is to say, according to the content of the aforementioned ART table).
  • FIG. 2 illustrates a first example of processor time sharing, the ART table of which is as follows:
  • each time interval (AST) has a duration (D AST ) of 20 ms, and that one cycle comprises 5 time slots, i.e., has a duration (D cycle ) of 100 ms.
  • the second and third time slots are reserved for the A2 application, which does not use them entirely. But the part (referenced 20) not used by the application A2 can not be used by another application, because the application A2 is an application of the CTR class.
  • the fourth time slot is reserved for the A3 application, which uses it entirely.
  • the fifth time slot (referenced 21) can not be used by any of the applications Al, A2 and A3 (because they are all of the CTR class), the processor can switch to low power mode. This fifth interval of time is available in case of modification of the set of applications sharing the processor time.
  • FIG. 3 illustrates a second example of processor time sharing, the ART table of which is as follows:
  • each time interval (AST) has a duration (D AST ) of 20 ms, and a cycle comprises 5 time slots, i.e., has a duration (D cycle ) of 100 ms.
  • the second and third time slots are reserved for the A2 application, which does not use them entirely. From the time referenced T1, the A2 application no longer needs the processor and because it is a VTR class application, it can pass the hand to another VTR class application: the A3 application in this case. At the moment referenced T2 located before the end of the third time interval, an external event occurs for the application A2, which takes over the hand since the second and third time slots are reserved for it. At the time referenced T3 before the end of the third time slot, the application A2 does not need the processor again and therefore passes the hand to the application A3.
  • the fourth and fifth time slots are not reserved for any of the applications but can be used by applications of the VTR class, ie the A2 and A3 applications (the application 2 having priority over the application 3 in the case where both of them wish to use the processor at the same time In the example illustrated in Figure 3, a portion (referenced 30) of the fourth and fifth time slots is not used.
  • FIG. 4 shows an example of task tables and interrupt handlers associated with three applications, as well as the sharing of processor time between these three applications.
  • Each application (Al, A2 and A3 respectively) is associated with: a task table (4O 1 , 4O 2 and 4O 3 respectively), comprising:
  • ISR Interrupt Service Routine
  • Each application includes a set of real-time tasks, each of these tasks being assigned a priority level (between 0 and 100 for example).
  • the real-time operating system configures the duration of a time interval (20 ms for example).
  • CTR CTR or VTR
  • number of time slots assigned to this application priority level of this application (for VTR applications only) (not to be confused with the priority levels of the tasks included in this application) and, possibly, the start time of this application in the cycle (that is, the rank, within the cycle, of the first time slot assigned to this application).
  • the operating system creates a task table for each application, with its corresponding tasks (see Figure 4); starts the first time interval; launches the first application of the ART table, loading the corresponding task table; order tasks according to their condition and priority.
  • the real-time operating system verifies that the duration assigned to the current active application is reached. In case of positive check, then it launches the next application (by loading the corresponding task table).
  • a "watchdog” type mechanism is for example implemented to detect that an application does not return to rest after a given number of cycles. Indeed, such a situation can be normal (for example, if it is an application using the processor intensively) or not (the application has entered an infinite loop).
  • notification to the application (reminder) that it spent more than a predefined amount of time before returning to the REST task, resetting the application, reset the entire system.
  • the processor may be used by another class application
  • At least one of the following compensation mechanisms is for example implemented: during at least one subsequent cycle, dynamic modification of the number of time slots associated with the first application (in steps of + 10% or -10%, for example); dynamic modification of the duration of at least one next cycle (in steps of + 10% or -10% for example).
  • each time interval (AST) has a duration (D AST ) of 20 ms, and a cycle comprises 5 time slots, i.e., has a duration (D cycle ) of 100 ms. It is also assumed that assigning a time slot of 20 ms every 100 ms to an application is equivalent to granting a CPU utilization capacity of 20 MIPS.
  • the application Al is an emergency call application, for example the "eCall" application.
  • the radiocommunication device that runs the "eCall” application and is installed in a vehicle sends an emergency call to an appropriate emergency call center, and sends at the same time a certain number of data relating to the vehicle (in particular its precise location).
  • the emergency call can be triggered manually by the occupants of the vehicle or automatically, in the event of a serious accident, thanks to sensors installed in the vehicle.
  • the main constraints of the "eCall” application are: use of 5 MIPS in normal mode, and 15 MIPS during an emergency call; protection against bugs in other applications embedded in the same radiocommunication device (it must be able to run in all cases); and reaction to an accident in less than 1 second. These constraints are met by assigning a time slot of 20 ms every 100 ms, which is equivalent to 20 MIPS.
  • the application A2 is a GPS navigation application ("Nav”), which for example sends over a wireless Bluetooth link messages conforming to the NMEA-0183 protocol ("National Marine Electronics Association"). Its main constraints are: execution at least once a second (for 100 ms); and use of at least 1 MIPS.
  • Nav GPS navigation application
  • NMEA-0183 protocol National Marine Electronics Association
  • the A3 application is a free-hand kit (KML) application, which for example can implement: - automated speech recognition (ASR), for "Automatic Speech
  • ASR automated speech recognition
  • the voice recognition (ASR) and voice synthesis (TTS) functions can use all the processor time not used by the other applications.
  • ASR voice recognition
  • TTS voice synthesis
  • ISR Interrupt Service Routine
  • Strategy # 1 an interruption of a first type is not associated with any of the applications (either because it serves several applications or because it uses a very small amount of time, or for any other choice of design) and it is not taken into account in the management of processor time. It is considered "system noise”.
  • Strategy n ° 2 an interruption of a second type is not associated with any of the applications (either because it serves several applications, because it uses a very small amount of time, or for any other choice of design) but it must be taken into account in the management of processor time. A quantity of time is reserved for all interrupts of this second type, so that the sum of the processor time slots of all the applications is less than or equal to
  • an interruption of a third type is associated with one or more applications and is taken into account in the management of the processor time in the following way: a quantity of processor time necessary for the interruption of the third type is taken in account in the processor time slot of the application or applications associated with this interruption of the third type; and the processor time preempted by this interruption of the third type on at least one other application is retroceded to this at least one other application (except if this at least one other application is the one with which the interruption of the third type is associated).
  • the processor is shared between an application for managing a radio communication stack ("GSM stack" for example) and at least one client application.
  • GSM stack an application for managing a radio communication stack
  • client application an application for managing a radio communication stack
  • This electronic radiocommunication module is for example a module of the family "WISMO" (registered trademark) of the company WAVECOM
  • the radio communication stack is considered as an application, to which various information can be associated, such as: class (CTR or VTR), number of time slots, priority level (for VTR applications only) and, possibly, start time of this application in the cycle.
  • class CTR or VTR
  • number of time slots CTR or VTR
  • priority level for VTR applications only
  • the radio communication stack typically has a heavy processor time consuming interrupt (ISR).
  • ISR processor time consuming interrupt
  • This interruption is managed according to one of the three aforementioned strategies.
  • strategy No. 3 is adopted: the interrupt is associated with the stack itself, and the processor time consumed by this interrupt is restored to the applications to which this time has been preempted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

II est proposé un procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur. Ce procédé comprend les étapes suivantes : association (1) à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle; association (2) à chaque application d'une classe parmi deux possible; gestion (6) dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications. Les deux classes possibles sont : une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée; une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application.

Description

Procédé et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des ordinateurs comprenant un unique processeur (aussi appelés ordinateurs mono processeur) et un système d'exploitation permettant de gérer l'exécution, par ce processeur, de plusieurs applications (aussi appelées programmes).
Par ordinateur, on entend toute machine permettant de traiter des informations selon des séquences d'instructions ou programmes, y compris notamment des machines de petite taille, telles que des PDA (pour « Personal Digital Assistant », ou « assistant numérique personnel » en français), des dispositifs ou circuits de radiocommunication, ou des appareils électroniques autonomes (sondes spatiales, robot, ordinateur de bord de véhicule,...). Chaque application comprend un ou plusieurs processus, et permet l'exécution d'une ou plusieurs tâches. En effet, chaque processus comprend une suite d'instructions élémentaires (appelés « fils », « processus allégés », ou encore « threads » en anglais) nécessaires à l'exécution d'une tâche. Dans le cas où une application permet l'exécution de plusieurs tâches, chaque tâche peut être associée à un niveau de priorité au sein de l'application.
Plus précisément, l'invention concerne une technique de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications.
Dans la suite de la description, on appelle « temps processeur » le temps d'utilisation du processeur.
L'invention s'applique notamment, mais non exclusivement, dans le cas où le système d'exploitation est un système d'exploitation temps réel (ou RTOS, pour « Real Time Operating System » en anglais), c'est-à-dire dans le cas où au moins une des applications doit être exécutée en temps réel. 2. ART ANTÉRIEUR II est courant que plusieurs processus (et donc plusieurs tâches) soient exécutés en parallèle sur un ordinateur monoprocesseur. Le système d'exploitation est alors qualifié de multi-tâche. En effet, un des rôles du système d'exploitation (et plus précisément de l'ordonnanceur du noyau du système d'exploitation) est de permettre à plusieurs processus de s'exécuter et d'utiliser le processeur de manière optimale du point de vue de l'utilisateur. De façon classique, pour arriver à donner l'illusion que plusieurs processus sont traités simultanément, l'ordonnanceur s'appuie sur des notions de commutation de contexte et d'ordonnancement.
On peut distinguer deux familles de systèmes d'exploitation temps-réel : ceux qui mettent en œuvre un ordonnancement des tâches par priorités (ou « Priority
Scheduling » en anglais), et ceux mettant en œuvre un ordonnancement des tâches par tranches de temps (ou « Time Sharing Scheduling » ou encore « Time Slicing Scheduling » en anglais).
Dans le cas d'un système d'exploitation temps-réel mettant en œuvre un ordonnancement des tâches par priorités, chaque tâche se voit attribuer une priorité et peut se trouver dans l'un des cinq états suivants : dormante (elle n'est pas ordonnancée), exécutable (elle est prête a exécuter des instructions mais ne possède pas en ce moment l'usage du processeur), active (ses instructions sont en cours d'exécution par le processeur), bloquée (son exécution est suspendue en attente d'un signal ou de la disponibilité d'une ressource) et interrompue (elle exécute une routine d'interruption programmée par l'utilisateur). L'ordonnanceur attribue toujours le processeur à la tâche non dormante et non bloquée qui possède la plus haute priorité. S'il est possible que plusieurs tâches de même priorité deviennent actives, plusieurs stratégies sont envisageables : soit on alterne l'exécution de séquences bornées d'instructions de toutes ces tâches (technique dite de « Time Slicing » en anglais, du fait que chaque tâche dispose de tranches de temps successives), soit on attribue arbitrairement le processeur à une de ces tâches, soit on évite cette situation en interdisant d'attribuer la même priorité à deux tâches distinctes. Quand une tâche T2 plus prioritaire qu'une tâche Tl active passe de l'état bloqué à l'état exécutable, deux mécanismes sont possibles : - soit la tâche T2 reste suspendue (état exécutable) jusqu'à la complétion de
Tl. L'ordonnanceur n'est alors pas préemptif. L'inconvénient est que le temps de réponse d'une tâche est affecté par le comportement des tâches moins prioritaires ; soit le système d'exploitation bascule la tâche Tl dans l'état exécutable et attribue le processeur à T2. L'ordonnanceur est préemptif. Dans le cas d'un système d'exploitation temps-réel mettant en œuvre un ordonnancement des tâches par tranches de temps, l'algorithme d'ordonnancement est de type Round-robin : il attribue des tranches de temps à chaque processus en proportion égale, sans accorder de priorité aux processus.
Malheureusement, aucune des deux techniques connues précitées d'ordonnancement des tâches (par priorités ou par tranches de temps) ne fournit une solution optimale au problème de la gestion d'un temps d'utilisation d'un unique processeur par plusieurs applications.
Un inconvénient commun à ces deux techniques connues est qu'elles ne permettent pas de définir précisément les moments où une application donnée pourra disposer du processeur.
La technique d'ordonnancement des tâches par priorités présente d'autres inconvénients découlant du fait qu'elle effectue une gestion au niveau tâche, et pas au niveau application : une tâche d'une première application peut toujours être arrêtée (elle bascule alors dans l'état exécutable) du fait qu'une tâche plus prioritaire d'une deuxième application passe dans l'état exécutable. Donc, cette première application n'a pas un temps processeur minimal assuré. Il paraît difficile d'harmoniser les priorités des tâches de toutes les applications, d'autant plus qu'il est fréquent que les applications devant s'exécuter sur le même processeur proviennent de fournisseurs différents ; si la tâche la plus prioritaire (toutes applications confondues) provoque un plantage informatique (« crash » en anglais), toutes les applications (et pas seulement celle à laquelle appartient la tâche ayant provoqué le plantage) sont bloquées et ne peuvent utiliser le processeur. La solution proposée aujourd'hui pour résoudre ce problème consiste à prévoir un mécanisme de « chien de garde » (« watchdog » en anglais) destiné à s'assurer qu'une application ne s'est pas bloquée à une étape particulière du traitement. Ce mécanisme est une protection destinée à redémarrer le système si une action définie n'est pas exécutée dans un délai donné.
La technique d'ordonnancement des tâches par tranches de temps présente elle aussi un inconvénient découlant du fait qu'elle effectue une gestion au niveau tâche, et pas au niveau application. Il possible de garantir un temps processeur minimal par tâche, mais il est impossible de garantir un temps processeur minimal pour une application donnée. En effet, le temps processeur dont dispose réellement chaque application dépend du nombre total d'applications exécutées par le processeur (en outre, toutes les applications n'ont pas le même nombre de tâches). Or certaines applications ont besoin de plus de temps processeur que d'autres et surtout ont besoin d'un temps processeur minimal (cas par exemple d'une application d'appel en urgence, en cas d'accident).
Un autre inconvénient de la technique d'ordonnancement des tâches par tranches de temps est qu'elle n'utilise pas de façon optimale le temps processeur. En effet, si une tâche n'utilise pas toute la tranche de temps qui lui est dédiée, la partie non utilisée de cette tranche de temps ne peut pas être affectée à une autre tâche, et est donc perdue. 3. OBJECTIFS DE L'INVENTION
L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, cette technique permettant de garantir un temps processeur minimal à chacune des applications, même si une des applications est bloquées. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant d'optimiser l'utilisation du temps processeur.
Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en œuvre et peu coûteuse. Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit transparente pour les applications quand elles s'exécutent. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, ledit procédé comprenant les étapes suivantes : association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; association à chaque application d'une des deux classes suivantes :
* une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ;
* une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.
Le principe général de ce mode de réalisation consiste donc à effectuer une gestion du temps processeur au niveau des applications elles-mêmes (chaque application pouvant comprendre un ou plusieurs processus, chaque processus exécutant une tâche), et non pas au niveau des tâches. Quelle que soit la classe qui lui est associée, chaque application dispose d'un temps processeur minimal garanti puisqu'une tranche de temps processeur (éventuellement nulle) lui est associée.
Par ailleurs, l'utilisation du temps processeur est optimisée puisque, entre applications de la seconde classe, les parties de tranches de temps processeur non utilisées par certaines applications sont réutilisées par d'autres applications.
Il est également à noter que cette technique est transparente pour les applications qui s'exécutent. C'est le système d'exploitation qui gère l'utilisation du processeur. Les applications n'ont aucune requête à émettre pour utiliser le processeur. De façon avantageuse, ledit temps processeur est découpé en cycles, chaque cycle comprenant un nombre N d'intervalles de temps, et la tranche de temps processeur associée à chaque application comprend un nombre K1 d'intervalles de temps dans chaque cycle, avec 1 ≤ K1 < N, et i un indice relatif à l'application.
La durée de chaque intervalle de temps définit la granularité de la commutation de contexte entre applications. Une durée faible risque d'alourdir le fonctionnement du système avec, potentiellement, un nombre élevé de commutations de contexte entre applications. Une durée élevée ne permet pas de répartir de façon fine le temps processeur entre les applications.
Avantageusement, ledit procédé comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K1 intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits
K1 intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K1 - X, alors modification dynamique du nombre d'intervalles de temps K1 pendant au moins un cycle suivant.
Ainsi, un premier mécanisme de rattrapage est proposé, permettant à une application donnée, sur plusieurs cycles, d'utiliser le processeur pendant un nombre d'intervalles de temps égal ou proche du nombre d'intervalles de temps réellement associés à cette application. Selon une caractéristique avantageuse, ledit procédé comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K1 intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K1 intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K1 - X, alors modification dynamique de la durée d'au moins un cycle suivant.
Ainsi, un second mécanisme de rattrapage est proposé, permettant à une application donnée, sur plusieurs cycles, d'utiliser le processeur pendant une durée totale cumulée égale ou proche de la durée réellement associée à cette application.
De façon avantageuse, ledit procédé comprend l'étape suivante, pour au moins une desdites applications : association à ladite application d'un instant de début pour la tranche de temps processeur associée à ladite application, ou d'un instant de début pour chaque intervalle de temps compris dans la tranche de temps processeur associée à ladite application.
Ainsi, il est possible de garantir qu'une application va prendre la main à des moments précis. Ceci est très important notamment dans le cas où certaines applications doivent être synchronisées avec d'autres.
Avantageusement, ledit procédé comprend l'étape suivante, pour au moins une application de la seconde classe : association à ladite application d'un niveau de priorité, permettant de décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur.
Ainsi, on décide à l'avance quelles applications de la seconde classe vont prioritairement utiliser le temps processeur disponible du fait que des applications de la seconde classe n'utilisent pas toutes les tranches de temps processeur qui leur sont associées.
Selon une variante, on utilise un algorithme de type Round-robin pour décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur. En d'autres termes, on répartit équitablement entre applications de la seconde classe le temps processeur disponible du fait que des applications de la seconde classe n'utilisent pas toutes les tranches de temps processeur qui leur sont associées. Avantageusement, ledit procédé comprend une étape de vérification que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre ledit temps processeur et une partie dudit temps processeur utilisée par ledit système d'exploitation.
De cette façon, on vérifie que le système est convenablement configuré pour fonctionner dans le pire cas, c'est-à-dire si chacune des applications utilisait la totalité de la tranche de temps processeur qui lui a été associée (du fait qu'elle en a réellement besoin, cas d'une application gourmande en temps processeur, ou du fait qu'il y un bogue, cas d'une application entrée en boucle).
Dans un mode de réalisation particulier de l'invention, ledit système d'exploitation est un système d'exploitation temps réel.
La présente invention est particulièrement adaptée pour répondre aux contraintes temps réel. Il convient de choisir convenablement la tranche de temps associée à chaque application devant s'exécuter en temps réel.
De façon avantageuse, au moins une interruption, dite interruption d'un premier type, n'est associée à aucune desdites applications et n'est pas prise en compte dans la gestion dudit temps processeur.
Chaque interruption du premier type est donc considérée comme du « bruit système ».
Avantageusement, au moins une interruption, dite interruption d'un deuxième type, n'est associée à aucune desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps est réservée pour l'ensemble des interruptions du deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% dudit temps processeur moins ladite quantité de temps réservée.
Ainsi, on tient compte des interruptions du deuxième type dans la gestion du temps processeur, mais indépendamment des applications.
Selon une caractéristique avantageuse, au moins une interruption, dite interruption d'un troisième type, est associée à au moins une desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps processeur nécessaire à ladite interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à ladite interruption du troisième type ; et le temps processeur préempté par ladite interruption du troisième type sur au moins une autre application est rétrocédé à ladite au moins une autre application.
Ainsi, on tient compte des interruptions du troisième type dans la gestion du temps processeur, mais en relation avec les applications auxquelles elles sont associées.
Dans un mode de réalisation particulier de l'invention, ledit processeur est compris dans un circuit de radiocommunication, et lesdits applications comprennent une application de gestion d'une pile de radiocommunication et au moins une application cliente.
L'invention s'applique notamment, mais non exclusivement, dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Par dispositifs de radiocommunication (aussi appelés terminaux de radiocommunication ou terminaux sans-fil), on entend tous dispositifs ou moyens capables d'échanger des signaux à l'aide d'un système de radiocommunication, implantés par exemple dans des machines ou des véhicules (marchés M2M, pour « Machine to Machine », et automobile). Le module électronique de radiocommunication est par exemple un module de la famille « WISMO » (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet). La société WAVECOM a en effet depuis plusieurs années proposé une approche palliant un certain nombre de ces inconvénients, consistant à regrouper dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de radiocommunication numérique. Un tel module se présente sous la forme d'un boîtier unique, préférentiellement blindé, que les fabricants de dispositifs peuvent implanter directement, sans devoir prendre en compte une multitude de composants. Ce module est formé d'un regroupement de plusieurs composants sur un substrat, de façon à être implanté sous la forme d'un unique élément.
Il comprend les composants (notamment un processeur, des mémoires, et des logiciels) essentiels nécessaires au fonctionnement d'un dispositif de radiocommunication utilisant des fréquences radioélectriques. Il n'y a donc plus d'étapes complexes de conception du design, et de validation de celui-ci. Il suffit de réserver la place nécessaire au module. Un tel module permet donc d'intégrer facilement, rapidement et de façon optimisée l'ensemble des composants dans des terminaux sans-fil (téléphones portables, modems, ou tout autre dispositif exploitant un standard sans fil). Dans une variante d'application de l'invention, le circuit de radiocommunication n'est pas un module de radiocommunication au sens précité mais un circuit imprimé compris dans un dispositif de radiocommunication et sur lequel sont directement implantés un ensemble de composants électroniques ayant pour but d'assurer les différentes fonctions de radiocommunication nécessaires, depuis la réception d'un signal RF jusqu'à la génération d'un signal audible (dans le cas d'un radio-téléphone), et inversement.
Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ce produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé précité, lorsque ledit programme est exécuté sur un ordinateur.
Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en œuvre le procédé précité.
Dans un autre mode de réalisation, l'invention concerne un dispositif comprenant un système d'exploitation permettant de gérer un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur. Ce dispositif comprend : - des moyens d'association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; des moyens d'association à chaque application d'une des deux classes suivantes :
* une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; * une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - des moyens de gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.
Plus généralement, le dispositif comprend des moyens de mise en œuvre du procédé de gestion de temps processeur tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). 5. LISTE DES FIGURES
D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : la figure 1 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; la figure 2 illustre un premier exemple de partage du temps processeur entre trois applications associées à la classe CTR, selon un mode de réalisation particulier de l'invention ; la figure 3 illustre un second exemple de partage du temps processeur entre trois applications, l'une associée à la classe CTR et les deux autres à la classe VTR, selon un mode de réalisation particulier de l'invention ; la figure 4 illustre un exemple de tables de tâches et de gestionnaires d'interruption associés à trois applications, ainsi que le partage du temps processeur entre ces trois applications ; et la figure 5 illustre un troisième exemple de partage du temps processeur entre trois applications associées à la classe VTR, selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE On présente maintenant, en relation avec la figure 1. un mode de réalisation particulier du procédé selon l'invention de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur (appelé temps processeur par la suite) par au moins deux applications.
Dans une étape 1, on associe à chaque application une tranche du temps processeur (ou « CPU Time Slice » en anglais). Pour cela, on utilise par exemple une minuterie (« timer » en anglais) périodique permettant de découper le temps processeur en cycles, chaque cycle comprenant un nombre N d'intervalles de temps (aussi noté
AST par la suite, pour « Application Scheduling Tick » en anglais). La tranche de temps processeur associée à chaque application comprend un nombre K1 d'intervalles de temps dans chaque cycle, avec 1 ≤ K1 < N, et i un indice relatif à l'application. Chaque tranche de temps est donc composée de la récurrence d'un certain nombre d'intervalles de temps au sein d'une structure cyclique comprenant un nombre déterminé d'intervalles de temps. Par exemple, si un intervalle de temps a une durée de 20 ms et si un cycle comprend 5 intervalles de temps, une application peut être associée à une tranche de temps comprenant 2*20 ms toutes les 100 ms.
Dans une étape 2, on associe à chaque application une des deux classes d'application suivantes : classe CTR (pour « Constant Time Rate » en anglais, ou « part de temps constante » en français), telle que la tranche de temps processeur qui est associée à une application CTR est réservée à cette application même si elle ne l'utilise pas entièrement (c'est-à-dire même si elle n'a pas d'activité logicielle pendant cette tranche de temps). Une application CTR ne peut pas utiliser plus que la tranche de temps processeur qui lui est associée, même si le processeur est au repos ; - classe VTR (pour « Variable Time Rate » en anglais, ou « part de temps variable » en français), telle qu'une application CTR est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée. Si une partie de la tranche de temps processeur associée à une application VTR n'est pas utilisée par celle-ci, alors elle peut être utilisée par une autre application VTR. Une application VTR peut utiliser plus que la tranche temps processeur qui lui est associée, en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application VTR ou une partie d'une tranche de temps associée à aucune application.
Dans une étape 3, un instant de début d'exécution peut être associé à au moins une application. Cet instant de début est par exemple défini par le numéro (rang au sein du cycle précité) du premier des intervalles de temps affectés à cette application. Si l'on reprend l'exemple ci-dessus (intervalle de temps de 20 ms et cycle de 5 intervalles de temps), la tranche de temps comprenant 2*20 ms toutes les 100 ms débute par exemple, à chaque cycle, avec le premier des cinq intervalles du cycle.
Dans une étape 4, on associe à chacune des applications VTR (ou seulement à certaines d'entre elles) un niveau de priorité. Cette priorité est utilisée pour décider quelle application VTR peut utiliser le processeur dans le cas où plusieurs applications VTR sont éligibles pour utiliser le processeur (quand ce dernier est au repos).
A l'issue de ces étapes 1 à 4, l'ensemble des informations associées aux applications peuvent être stockées dans une mémoire par le système d'exploitation, par exemple sous la forme de la table ci-dessous (on y a noté M le nombre d'applications). Cette table est appelée par la suite table ART (pour « Applications Rate Table » en anglais).
Ainsi, par exemple, l'application n°l est associée à la classe C1 (CTR ou VTR), à une tranche de temps processeur comprenant K1 intervalles de temps par cycle et commençant au Xème intervalle de temps de chaque cycle, et à une priorité P1 (s'il s'agit d'une application VTR). Dans une étape 5, le système d'exploitation vérifie que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre le temps processeur total et une partie de ce temps processeur total qui est utilisée par le système d'exploitation. Dans l'exemple précité, cela revient à vérifier que le nombre total cumulé d'intervalles de temps associés aux différentes applications n'est pas supérieur au nombre d'intervalles de temps dans un cycle.
Dans une étape 6, le système d'exploitation gère le temps processeur en fonction de l'ensemble des informations associées aux applications (c'est-à-dire en fonction du contenu de la table ART précitée).
La figure 2 illustre un premier exemple de partage du temps processeur, dont la table ART est la suivante :
On suppose que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée (Dcycle) de 100 ms.
On voir sur la figure 2 que le premier intervalle de temps est réservé à l'application Al, qui l'utilise entièrement.
Les deuxième et troisième intervalles de temps sont réservés à l'application A2, qui ne les utilise pas entièrement. Mais la partie (référencée 20) non utilisée par l'application A2 ne peut pas être utilisée par une autre application, du fait que l'application A2 est une application de la classe CTR.
Le quatrième intervalle de temps est réservé à l'application A3, qui l'utilise entièrement.
Le cinquième intervalle de temps (référencé 21) ne pouvant être utilisé par aucune des applications Al, A2 et A3 (car elles sont toutes de la classe CTR), le processeur peut commuter en mode basse consommation. Ce cinquième intervalle de temps est disponible en cas de modification du jeu d'applications se partageant le temps processeur.
La figure 3 illustre un deuxième exemple de partage du temps processeur, dont la table ART est la suivante :
On suppose à nouveau que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée (Dcycle) de 100 ms.
On voir sur la figure 3 que le premier intervalle de temps est réservé à l'application Al, qui l'utilise entièrement.
Les deuxième et troisième intervalles de temps sont réservés à l'application A2, qui ne les utilise pas entièrement. A partir de l'instant référencé Tl, l'application A2 n'a plus besoin du processeur et du fait qu'il s'agit d'une application de classe VTR, elle peut passer la main à une autre application de classe VTR : l'application A3 en l'espèce. A l'instant référencé T2 situé avant la fin du troisième intervalle de temps, un événement externe intervient pour l'application A2, qui reprend la main puisque les deuxième et troisième intervalles de temps lui sont réservés. A l'instant référencé T3 situé avant la fin du troisième intervalle de temps, l'application A2 n'a à nouveau plus besoin du processeur et passe donc la main à l'application A3.
Les quatrième et cinquième intervalles de temps ne sont réservés à aucune des applications mais peuvent être utilisés par les applications de la classe VTR, c'est-à-dire les applications A2 et A3 (l'application 2 étant prioritaire sur l'application 3, dans le cas où elles souhaitent toutes les deux utiliser le processeur au même moment. Dans l'exemple illustré sur la figure 3, une partie (référencée 30) des quatrième et cinquième intervalles de temps n'est pas utilisée. On présente avec la figure 4 un exemple de tables de tâches et de gestionnaires d'interruption associés à trois applications, ainsi que le partage du temps processeur entre ces trois applications.
Chaque application (Al, A2 et A3 respectivement) est associée à : - une table de tâches (4O1, 4O2 et 4O3 respectivement), comprenant :
* une tâche REPOS (Tâche Al-repos, Tâche A2-repos et Tâche A3-repos respectivement) permettant de détecter l'inactivité de l'application concernée et des commutations entre applications possibles ;
* des tâches classiques (par exemple Tâches Al-I, Al-2 et Al-3 pour l'application Al) ; et un gestionnaire d'interruption (4I1, 4I2 et 4I3 respectivement) (« Interrupt
Handler » ou « ISR (Interrupt Service Routine) » en anglais).
On décrit maintenant un mode de mise en oeuvre particulier de l'invention.
Chaque application comprend un jeu de tâches temps réel, chacune de ces tâches étant affectée d'un niveau de priorité (entre 0 et 100 par exemple). Le système d'exploitation temps réel configure la durée d'un intervalle de temps (20 ms par exemple). La table
ART stocke les informations associées à chaque application : classe de cette application
(CTR ou VTR), nombre d'intervalles de temps affectés à cette application, niveau de priorité de cette application (pour les applications VTR seulement) (à ne pas confondre avec les niveaux de priorité des tâches comprises dans cette même application) et, éventuellement, instant de début de cette application dans le cycle (c'est-à-dire le rang, au sein du cycle, du premier intervalle de temps affecté à cette application).
Au démarrage, le système d'exploitation : crée une table de tâches pour chaque application, avec ses tâches correspondantes (cf figure 4) ; commence le premier intervalle de temps ; lance la première application de la table ART, en chargeant la table de tâches correspondante ; ordonnance les tâches en fonction de leur état et de leur priorité. A chaque expiration d'un intervalle de temps, le système d'exploitation temps réel vérifie que la durée affectée à l'application active courante est atteinte. En cas de vérification positive, alors il lance l'application suivante (en chargeant la table de tâches correspondante) .
Quand l'application active courante entre dans sa tâche REPOS : si l'application est de la classe CTR, alors aucune commutation d'application ne se produit (la tranche de temps est non préemptive) ; si l'application est de la classe VTR, alors le système d'exploitation :
* mémorise la proportion de sa tranche de temps processeur que cette application a déjà utilisée ;
* vérifie si une autre application VTR est en attente du processeur. Si plusieurs applications VTR sont éligibles, celle de plus haute priorité est choisie) ;
* si une telle application est trouvée, elle est lancée (en chargeant la table de tâches correspondante).
Un mécanisme de type « chien de garde » (« watchdog » en anglais) est par exemple mis en œuvre pour détecter qu'une application ne revient pas au repos après un nombre déterminé de cycles. En effet, une telle situation peut être normale (par exemple, s'il s'agit d'une application utilisant intensivement le processeur) ou non (l'application est entrée dans une boucle infinie). Quand une telle situation est détectée, au moins une des actions suivantes est mise en œuvre : notification à l'application (rappel) qu'elle a dépensé plus qu'une quantité de temps prédéfinie avant de repasser à la tâche REPOS, réinitialisation de l'application, réinitialisation de l'ensemble du système.
Si une première application de la classe VTR n'a pas besoin du processeur pendant un de ses intervalles de temps (c'est-à-dire un des intervalles de temps qui lui ont été associés), le processeur peut être utilisé par une autre application de la classe
VTR. Si la première application a finalement besoin du processeur avant la fin de son intervalle de temps, il reprend la main et peut utiliser le processeur. Néanmoins, à la fin du cycle courant, la première application peut ne pas avoir eu le temps processeur qui lui était réservé pendant ce cycle. Au moins un des mécanismes de compensation suivant est par exemple mis en œuvre : pendant au moins un cycle suivant, modification dynamique du nombre d'intervalles de temps associés à la première application (par pas de +10% ou - 10% par exemple) ; modification dynamique de la durée d'au moins un cycle suivant (par pas de +10% ou -10% par exemple).
On présente maintenant, en relation avec la figure 5. un troisième exemple de partage du temps processeur, dont la table ART est la suivante :
On suppose à nouveau que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée (Dcycle) de 100 ms. On suppose également qu'attribuer un intervalle de temps de 20 ms toutes les 100 ms à une application est équivalent à accorder une capacité d'utilisation du processeur de 20 MIPS.
L'application Al est une application d'appel d'urgence, par exemple l'application « eCall ». En cas d'accident, le dispositif de radiocommunication qui exécute l'application « eCall » et qui est installé dans un véhicule envoie un appel d'urgence à un centre de réception des appels d'urgence le plus approprié, et envoie en même temps un certains nombre de données relatives au véhicule (notamment sa localisation précise). L'appel d'urgence peut être déclenché manuellement par les occupants du véhicule ou automatiquement, en cas d'accident grave, grâce à des capteurs installés dans le véhicule. Les contraintes principales de l'application « eCall » sont : utilisation de 5 MIPS en mode normal, et 15 MIPS pendant un appel d'urgence ; protection contre les bogues dans d'autres applications embarquées dans le même dispositif de radiocommunication (elle doit pouvoir s'exécuter dans tous les cas) ; et réaction à un accident en moins de 1 seconde. Ces contraintes sont respectées par l'attribution d'un intervalle de temps de 20 ms toutes les 100 ms, ce qui est équivalent à 20 MIPS.
L'application A2 est une application de navigation GPS (« Nav »), qui par exemple envoie sur une liaison sans fil Bluetooth des messages conformes au protocole NMEA-0183 (« National Marine Electronics Association »). Ses contraintes principales sont : exécution au moins une fois par seconde (pendant 100 ms) ; et utilisation d'au moins 1 MIPS.
Ces contraintes sont respectées par l'attribution d'un intervalle de temps de 20 ms toutes les 100 ms, ce qui est équivalent à 20 MIPS. En outre, le fait que l'intervalle de temps attribué soit le premier du cycle garantit que des messages NMEA peuvent être envoyés précisément à chaque seconde (c'est-à-dire tous les dix cycles).
L'application A3 est une application de kit main libre (KML), qui par exemple peut mettre en œuvre : - une reconnaissance vocale automatisée (ASR, pour « Automatic Speech
Récognition » en anglais) et une synthèse vocale (TTS, pour « Text To Speech » en anglais) ; et un établissement d'appel GSM, qui utilise 2 MIPS.
La contrainte principale de l'application A3 est que la reconnaissance vocale automatisée (ASR) doit traduire une phrase en moins de deux secondes pour une bonne interaction humaine, et pour cela doit disposer d'au moins 60 MIPS quand elle est exécutée.
Cette contrainte est respectée par l'attribution de trois intervalles de temps (soit
60 ms au total) toutes les 100 ms (ce qui est équivalent à 60 MIPS), et du niveau de priorité maximal. Ainsi, les fonctions de reconnaissance vocale (ASR) et synthèse vocale (TTS) peuvent utiliser tout le temps processeur non utilisé par les autres applications. En mode nominal, l'application eCall utilise 15 MIPS en cas d'urgence et l'application Nav utilise 1 MIPS. Il reste donc 84 MIPS pour les fonctions ASR et TTS.
Dans le pire des cas, les applications eCall et Nav sont entrées dans une boucle infinie, et bloque chacune 20 MIPS. Il reste quand même 60 MIPS pour les fonctions ASR et
TTS. Par ailleurs, diverses stratégies peuvent être envisagées pour la gestion des interruptions. Ces différentes stratégies peuvent être appliquées simultanément à différentes interruptions. On rappelle qu'une interruption est l'appel d'une routine spéciale appelée ISR (pour « Interrupt Service Routine »). Stratégie n°l : une interruption d'un premier type n'est associée à aucune des applications (soit parce qu'elle sert plusieurs applications, soit parce qu'elle utilise une très petite quantité de temps, ou encore pour toute autre choix de conception) et elle n'est pas prise en compte dans la gestion du temps processeur. Elle est considérée comme du « bruit système ». Stratégie n°2 : une interruption d'un deuxième type n'est associée à aucune des applications (soit parce qu'elle sert plusieurs applications, soit parce qu'elle utilise une très petite quantité de temps, ou encore pour toute autre choix de conception) mais elle doit être prise en compte dans la gestion du temps processeur. Une quantité de temps est réservée pour l'ensemble des interruptions de ce deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à
100% du temps processeur moins la quantité de temps réservée. On suppose que cette quantité de temps réservée est redistribuée de façon égale entre toutes les applications. Par conséquent, statistiquement, toutes les applications se voient attribuées leurs tranches de temps respectives. Stratégie n°3 : une interruption d'un troisième type est associée à une ou plusieurs applications et est prise en compte dans la gestion du temps processeur de la façon suivante : une quantité de temps processeur nécessaire à l'interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à cette interruption du troisième type ; et le temps processeur préempté par cette interruption du troisième type sur au moins une autre application est rétrocédé à cette au moins une autre application (sauf si cette au moins une autre application est celle à laquelle est associée l'interruption du troisième type). Dans un mode de réalisation particulier, le processeur est partagé entre une application de gestion d'une pile de radiocommunication (« pile GSM » par exemple) et au moins une application cliente. Ceci s'applique notamment dans le cas où le processeur est compris dans un circuit de radiocommunication, comme par exemple un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Ce module électronique de radiocommunication est par exemple un module de la famille « WISMO » (marque déposée) de la société WAVECOM
(déposante de la présente demande de brevet).
Dans ce cas, la pile de radiocommunication est considérée comme une application, à laquelle peuvent être associées diverses informations, comme par exemple : classe (CTR ou VTR), nombre d'intervalles de temps, niveau de priorité (pour les applications VTR seulement) et, éventuellement, instant de début de cette application dans le cycle.
La pile de radiocommunication possède typiquement une interruption (ISR) forte consommatrice de temps processeur. Cette interruption est gérée selon l'une des trois stratégies précitées. Dans un mode de réalisation particulier de l'invention, la stratégie n°3 est adoptée : l'interruption est associée avec la pile elle-même, et le temps processeur consommée par cette interruption est restituée aux applications auxquelles ce temps a été préempté.

Claims

REVENDICATIONS
1. Procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, caractérisé en ce qu'il comprend les étapes suivantes : - association (1) à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; association (2) à chaque application d'une des deux classes suivantes :
* une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ;
* une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et gestion (6) dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.
2. Procédé selon la revendication 1, caractérisé en ce que ledit temps processeur est découpé en cycles, chaque cycle comprenant un nombre N d'intervalles de temps, et en ce que la tranche de temps processeur associée à chaque application comprend un nombre K1 d'intervalles de temps dans chaque cycle, avec 1 ≤ K1 < N, et i un indice relatif à l'application.
3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K1 intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K1 intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K1 - X, alors modification dynamique du nombre d'intervalles de temps K1 pendant au moins un cycle suivant.
4. Procédé selon la revendication 2 ou 3, caractérisé en ce qu'il comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K1 intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K1 intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K1 - X, alors modification dynamique de la durée d'au moins un cycle suivant.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend l'étape suivante, pour au moins une desdites applications : association (3) à ladite application d'un instant de début pour la tranche de temps processeur associée à ladite application, ou d'un instant de début pour chaque intervalle de temps compris dans la tranche de temps processeur associée à ladite application.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend l'étape suivante, pour au moins une application de la seconde classe : association à ladite application d'un niveau de priorité, permettant de décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur.
7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce qu'il comprend une étape de vérification (5) que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre ledit temps processeur et une partie dudit temps processeur utilisée par ledit système d'exploitation.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit système d'exploitation est un système d'exploitation temps réel.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que au moins une interruption, dite interruption d'un premier type, n'est associée à aucune desdites applications et n'est pas prise en compte dans la gestion dudit temps processeur.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que au moins une interruption, dite interruption d'un deuxième type, n'est associée à aucune desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps est réservée pour l'ensemble des interruptions du deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% dudit temps processeur moins ladite quantité de temps réservée.
11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que au moins une interruption, dite interruption d'un troisième type, est associée à au moins une desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps processeur nécessaire à ladite interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à ladite interruption du troisième type ; et - le temps processeur préempté par ladite interruption du troisième type sur au moins une autre application est rétrocédé à ladite au moins une autre application.
12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ledit processeur est compris dans un circuit de radiocommunication, et en ce que lesdits applications comprennent une application de gestion d'une pile de radiocommunication et au moins une application cliente.
13. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.
14. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en œuvre le procédé selon.au moins une des revendications 1 à 12.
15. Dispositif comprenant un système d'exploitation permettant de gérer un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, caractérisé en ce qu'il comprend : des moyens d'association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; des moyens d'association à chaque application d'une des deux classes suivantes :
* une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ;
* une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et des moyens de gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.
EP08736208A 2007-04-13 2008-04-14 Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants. Withdrawn EP2145255A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0702708A FR2915006B1 (fr) 2007-04-13 2007-04-13 Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.
PCT/EP2008/054510 WO2008125664A1 (fr) 2007-04-13 2008-04-14 Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.

Publications (1)

Publication Number Publication Date
EP2145255A1 true EP2145255A1 (fr) 2010-01-20

Family

ID=38567010

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08736208A Withdrawn EP2145255A1 (fr) 2007-04-13 2008-04-14 Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.

Country Status (5)

Country Link
US (1) US20100122263A1 (fr)
EP (1) EP2145255A1 (fr)
CN (1) CN101836189B (fr)
FR (1) FR2915006B1 (fr)
WO (1) WO2008125664A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2956226B1 (fr) * 2010-02-10 2012-12-14 Airbus Operations Sas Procede, programme d'ordinateur et dispositif de supervision d'un ordonnanceur pour la gestion du partage de temps de traitement dans un systeme informatique multitache
FR2956913B1 (fr) * 2010-03-01 2012-04-20 Sagem Defense Securite Procede de sequencement deterministe multitache
WO2011158405A1 (fr) * 2010-06-18 2011-12-22 パナソニック株式会社 Unité de génération d'informations de priorité et appareil de traitement d'informations
US9280391B2 (en) * 2010-08-23 2016-03-08 AVG Netherlands B.V. Systems and methods for improving performance of computer systems
CN103348294A (zh) * 2011-01-31 2013-10-09 丰田自动车株式会社 安全控制装置以及安全控制方法
WO2014044301A1 (fr) * 2012-09-19 2014-03-27 Nokia Siemens Networks Oy Procédé et dispositif d'allocation de ressources
CN104216781B (zh) * 2013-05-29 2019-10-08 上海联影医疗科技有限公司 显存分配方法及系统
KR20140142996A (ko) * 2013-06-05 2014-12-15 삼성전자주식회사 복수의 시큐어 엘리먼트에 구비된 애플릿의 데이터 처리 방법 및 장치
CN109144682A (zh) 2017-06-27 2019-01-04 阿里巴巴集团控股有限公司 任务的优先级处理方法和处理装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08328880A (ja) * 1995-05-31 1996-12-13 Mitsubishi Electric Corp 複数のアプリケーションプログラムを同時に実行できるオペレーティングシステムにおける計算機運転管理システム
JPH0954699A (ja) * 1995-08-11 1997-02-25 Fujitsu Ltd 計算機のプロセススケジューラ
DE19535546B4 (de) * 1995-09-25 2004-04-08 Siemens Ag Verfahren zum Betreiben eines durch ein Realzeit-Betriebssystem gesteuerten Realzeit-Computersystems
US6654780B1 (en) * 1997-03-28 2003-11-25 International Business Machines Corporation System of managing processor resources in a non-dedicated computer system
US6757897B1 (en) * 2000-02-29 2004-06-29 Cisco Technology, Inc. Apparatus and methods for scheduling and performing tasks
US7302685B2 (en) * 2000-06-02 2007-11-27 Honeywell International Inc. Methods and apparatus for sharing slack in a time-partitioned system
FR2821940B1 (fr) * 2001-03-12 2006-09-29 Centre Nat Etd Spatiales Procede et systeme de gestion du temps dans un systeme temps reel
CN100514301C (zh) * 2005-03-30 2009-07-15 李晓波 一种程序缓时执行的方法及其装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008125664A1 *

Also Published As

Publication number Publication date
US20100122263A1 (en) 2010-05-13
CN101836189A (zh) 2010-09-15
CN101836189B (zh) 2013-03-20
FR2915006A1 (fr) 2008-10-17
WO2008125664A1 (fr) 2008-10-23
FR2915006B1 (fr) 2009-08-21

Similar Documents

Publication Publication Date Title
WO2008125664A1 (fr) Procede et dispositif de gestion de l&#39;utilisation d&#39;un processeur par plusieurs applications, produit programme d&#39;ordinateur et moyen de stockage correspondants.
EP2893444B1 (fr) Gestion de ressources à base de quota
US6367074B1 (en) Operation of a system
KR101255382B1 (ko) 운영체제에 친숙한 부트로더
EP2676206B1 (fr) Service de transfert en arrière-plan pour des applications sur des dispositifs mobiles
US7386859B2 (en) Method and system for effective management of client and server processes
US11010190B2 (en) Methods, mediums, and systems for provisioning application services
US20060010446A1 (en) Method and system for concurrent execution of multiple kernels
CN111158879A (zh) 一种系统资源的调度方法，装置、机器可读介质和系统
EP3120498A1 (fr) Diffusion d&#39;informations de gestion à l&#39;aide de codes fontaine
FR2818769A1 (fr) Procede et systeme d&#39;exploitation temps reel multitaches
FR2998689A1 (fr) Ensemble electronique comprenant un module de desactivation
US9128754B2 (en) Resource starvation management in a computer system
FR2905819A1 (fr) Procede de gestion de l&#39;architecture logicielle d&#39;un circuit de radiocommunication,application,produit programme d&#39;ordinateur et circuit correspondants.
JP6189545B2 (ja) 電力消費の低減のためのネットワークアプリケーション並行スケジューリング
FR2926146A1 (fr) Dispositif informatique a memoire reservee pour des applications prioritaires.
CN116932058A (zh) 一种龙芯硬件平台系统启动方法
FR2995482A1 (fr) Gestion de l&#39;utilisation d&#39;une passerelle par une pluralite de terminaux
EP3502949B1 (fr) Procédé et système de contrôle d&#39;ordonnancement de tâches logicielles
US8694999B2 (en) Cooperative scheduling of multiple partitions in a single time window
CN109144745B (zh) 进程间通信的监控方法、电子装置以及可读存储介质
US12124871B2 (en) Controlling invocations of a software component based on estimation of residual capability thereof
WO2009010535A1 (fr) Procede de gestion de l&#39;execution d&#39;une architecture logicielle d&#39;un circuit de radiocommunication a frequence processeur constante, produit programme d&#39;ordinateur et circuit correspondants
US20230080849A1 (en) Controlling invocations of a software component based on estimation of residual capability thereof
CN109062705B (zh) 进程间通信的监控方法、电子装置以及可读存储介质

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20091006

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20101130

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20141104