A multi-core processor computer system configured to activate statically defined tasks, and a method for managing such a multi-core processor.

Abstract

The description concerns a method and a multi-core processor computer system configured to activate statically defined tasks comprising at least one initiating task to start one or more asynchronous processes, and at least one set of two identical implementing tasks that perform the same asynchronous process(es) and are each allocated to a different core of the multi-core processor. The initiating task activates the implementing tasks of a given set when a given asynchronous process needs to be started, and the implementing task of the given set that is ready first performs the given asynchronous process, while the other implementing task(s) of the given set ignore the given asynchronous process. This optimizes core utilization, enables dynamic selection at runtime of the core responsible for executing a given asynchronous process, and thus minimizes the waiting time. Figure for the abstract: Figure 6

Description

Title of the invention: Multi-core processor computer system configured to activate statically defined tasks, and method for managing such a multi-core processor. technical field

[0001] This description relates to a multi-core processor computer system configured to activate statically defined tasks. Such processors are used, for example, in embedded real-time systems, for example in the automotive field. Technical background

[0002] Real-time systems must respond to events or perform tasks within predictable and strictly defined timeframes. Exceeding these timeframes can lead to critical failures. These constraints are particularly important in embedded systems such as those used in automobiles.

[0003] In the automotive field, the operating systems used follow the OSEK standard (from the German "Offene Système und deren Schnittstellen fur die Elektronik in Kraftfahrzeugen").

[0004] The OSEK standard specifies an operating system architecture, including a software task management structure. In particular, it mandates a static definition of tasks, meaning that tasks must be defined in advance, at system configuration time, and cannot be created dynamically during runtime. In practice, all tasks and their properties must be specified in a static configuration file before system deployment. A task's properties include, among other things, a fixed priority, an initial state of the task from among several possible states, and the hardware and software resources required to execute the task.

[0005] Given the complexity of embedded systems, most of these systems use multi-core processor microcontrollers, i.e. having several processing units that can be used simultaneously.

[0006] Different strategies can be implemented to distribute the processing of tasks across the different cores of a multi-core processor.

[0007] There is a need to optimize these strategies in order to improve the overall performance of the computer system, by making the best use of all available cores, and to reduce the waiting times of tasks before their execution. Summary

[0008] A first aspect of the present description relates to a multi-core processor computer system configured to activate statically defined tasks. In the computer system described here, said tasks comprise: at least one initiating task, configured to initiate one or more processes, including one or more asynchronous processes, and at least one set of implementing tasks, comprising at least two implementing tasks configured to perform the same asynchronous processes, and each allocated to a different core of the multi-core processor.The initiating task is configured to activate the performing tasks of a given set of performing tasks when a given asynchronous process needs to be initiated, and the performing tasks are configured such that the first performing task of the given set of performing tasks that is ready performs the given asynchronous process, while the other performing task or tasks of the given set of performing tasks ignore the given asynchronous process.

[0009] In one embodiment, each of the initiating and performing tasks is allocated to a different core of the multi-core processor.

[0010] In one embodiment, the initiating task is configured to generate a request to initiate the given asynchronous processing, and the implementing tasks are configured to check, before performing the given asynchronous processing, that there is a request to initiate the given asynchronous processing waiting to be executed.

[0011] In one embodiment, the initiator and implementer tasks are configured to manage information representing a number of initiation requests pending execution for each asynchronous process, said information being updated on the one hand, by the initiator task when it initiates a given asynchronous process to increment the number of initiation requests pending execution for the given asynchronous process, and on the other hand, by the implementer tasks when they perform the given asynchronous process to decrement the number of initiation requests pending execution for the given asynchronous process.

[0012] In one embodiment, the computer system comprises a single set of execution tasks, configured to perform all the asynchronous processing associated with at least one initiating task. In an alternative embodiment, the computer system comprises several sets of execution tasks, configured to collectively perform all the asynchronous processing associated with at least one initiating task. For example, each execution task in the same set is associated with the same level of automotive safety integrity, different from at least one other level of automotive safety integrity associated with the execution tasks in at least one other set of execution tasks. For example, the computer system comprises a first and a second set of execution tasks, the execution tasks in the first set of execution tasks being configured to perform at least one asynchronous process associated with a first level of automotive safety integrity, and the execution tasks of the second set of execution tasks being configured to perform at least one asynchronous process associated with a second level of automotive safety integrity different from the first level.

[0013] A second aspect of this description relates to a method for managing a multicore processor configured to execute statically defined tasks. In the method described here, said tasks comprise at least one initiator task configured to initiate one or more processes, including one or more asynchronous processes, and at least one set of execution tasks comprising at least two execution tasks configured to perform the same asynchronous processes, each allocated to a different core of the multicore processor.The process comprises the following steps: when a given asynchronous processing is to be performed, each of the realizing tasks in a given set of realizing tasks is activated by the initiating task; and the given asynchronous processing is performed by the realizing task in the given set of realizing tasks that is ready to perform it first, the other realizing tasks ignoring the given asynchronous processing.

[0014] In one embodiment, each of the initiating and implementing tasks is allocated to a different core of the multi-core processor.

[0015] In one embodiment, the method for managing a multicore processor includes a generation, by the initiating task, of a request to initiate the given asynchronous processing, and a verification, by the implementing tasks, before carrying out a given asynchronous processing, that there is a request to initiate the given asynchronous processing waiting to be executed.

[0016] In one embodiment, the method for managing a multicore processor includes, when the initiating task initiates a given asynchronous process, an update by the initiating task of information representing a number of initiation requests pending execution for each asynchronous process, to increment the number of initiation requests pending execution for the given asynchronous process; and when a given implementing task performs the given asynchronous process, an update of said information by the given implementing task, to decrement the number of initiation requests pending execution for the given asynchronous process.

[0017] In one embodiment of the method for managing a multicore processor, a single set of execution tasks is configured to perform all the asynchronous processing associated with said at least one initiating task. In an alternative embodiment, several sets of execution tasks are configured to, together, perform all the asynchronous processing associated with said at least one initiating task. In other words, the execution tasks of the set or sets of execution tasks are configured to, together, perform all the asynchronous processing associated with said at least one initiating task.

[0018] For example, each implementation task in the same set is associated with the same level of automotive safety integrity, different from at least one other level of automotive safety integrity associated with the implementation tasks in at least one other set of implementation tasks. For example, a first and a second set of implementation tasks are configured, the implementation tasks in the first set of implementation tasks being configured to perform at least one asynchronous process associated with a first level of automotive safety integrity, and the implementation tasks in the second set of implementation tasks being configured to perform at least one asynchronous process associated with a second level of automotive safety integrity different from the first level.

[0019] A third aspect of this description relates to a computer program comprising instructions for implementing a method for managing a multicore processor as described above, when executed by a processor.

[0020] A fourth aspect of this description relates to a motor vehicle comprising a multi-core processor computer system as described above.

[0021] In the scheduling strategy described here, primary tasks are performed by a primary core, while other tasks, which do not need to be synchronized with these primary tasks, are assigned to one or more other cores, thus optimizing the use of the different processor cores. For example, this makes it possible to offload heavily loaded cores and / or to use cores that are little or not used at all.

[0022] When a new task is activated, it starts to run after a certain delay, called a waiting time, which depends on the other tasks in progress or waiting to be executed on the same core and their priority relative to that of the new task.

[0023] The system and method described herein comprise several execution tasks, allocated to different cores and configured to perform the same asynchronous processing. When the asynchronous processing is initiated by an initiating task, all corresponding execution tasks are activated. The asynchronous processing is then performed by the execution task that is ready first.

[0024] The described solution enables dynamic selection at runtime of the core responsible for executing a given asynchronous process, even though the tasks are statically defined. This minimizes the waiting time.

[0025] The initiating task, which is configured to initiate asynchronous processing, can be associated with one or more sets of implementing tasks. When only one When a set of tasks is used, the tasks within that set are configured to perform all the asynchronous processes associated with the initiating task. When multiple sets are used, the sets as a whole must be able to perform all the asynchronous processes associated with the initiating task. However, it is possible that the implementing tasks of a set, taken individually, may only be able to perform some of the asynchronous processes linked to the initiating task. Using multiple sets allows, for example, the management of specific needs related to certain asynchronous processes. For example, in the automotive field, the asynchronous processes related to a vehicle's safety functions may need to be executed by dedicated tasks with specific properties. In this case, it is advantageous to use one set of implementing tasks dedicated to the safety function and another set of implementing tasks dedicated to the other functions. Brief description of the Figures

[0026] Other features and advantages will become apparent upon reading the detailed description that follows, for an understanding of which reference should be made to the attached drawings, among which:

[0027] [Fig.1] - the [Fig.1] represents a state diagram of a task of a computer system as described herein.

[0028] [Fig.2] - [Fig.2] is a diagram representing the operation of a task in a computer system as described herein.

[0029] [Fig.3] - [Fig.3] is a flowchart representing an example of steps put in work through initiating tasks.

[0030] [Fig.4] - [Fig.4] is a flowchart representing an example of steps put in work through the realization tasks.

[0031] [Fig.5] - [Fig.5] is a diagram representing a first example of an embodiment, with a single set of realizing tasks.

[0032] [Fig.6] - [Fig.6] is a diagram representing a second example of realization, with two sets of realization tasks. Detailed description

[0033] In the description that follows, identical, similar or analogous elements will be designated by the same reference signs.

[0034] The present description relates to a multi-core processor computer system and proposes a task scheduling strategy allowing asynchronous processing to be executed by a core different from the core that executes the initiating task of the asynchronous processing.

[0035] Without being limiting, it applies, for example, in the automotive field. For example, a vehicle control system is configured to The system acquires input data from the vehicle, for example via sensors, and processes this data to determine a vehicle response (braking, changing trajectory, etc.). These processes generally follow a specific sequence. These are called synchronous processes. The vehicle also performs processes that can be executed independently without requiring a strict order of execution or a blocking wait. This is the case, for example, with processes that diagnose the vehicle's condition. These are called asynchronous processes.

[0036] This description applies to a multi-core processor computer system in which tasks are statically defined, that is, at the time of system configuration. The tasks are configured to call executables stored in non-volatile memory, which perform processing when executed by a core of the multi-core processor. The tasks have properties that are fixed in a static configuration file before system deployment. These properties include, in particular, a fixed priority, an initial state of the task from among several possible states, and the hardware and software resources required for task execution.

[0037] Conventionally, the system ensures the order in which tasks are executed using a fixed-priority arbitration mechanism. As shown in [Fig. 1], a task can have several states, including: "suspended," "ready," or "in progress." When a task is activated (step 100), it transitions from the "suspended" state 110 to the "ready" state 120. However, the task is not executed immediately: it must wait for higher-priority tasks to be completed. The task is then started (step 130) and transitions to the "in progress" state 140, during which it is executed. When execution is complete, the task returns to the "suspended" state 110 (step 150).

[0038] In some systems, a higher priority task can interrupt a lower priority task, according to a mechanism called preemption and represented on [Fig.1] by an arrow 180 going from the "in progress" state 140 to the "ready" state 120.

[0039] As illustrated in [Fig. 2], a task in the "suspended" state 110 transitions to the "ready" state 120 following an activation 100. It then waits for a delay 210, called the waiting time, before transitioning to the "running" state 140. The time 220 that elapses between the activation 100 and the completion of execution 150 is called the response time. The time constraint to be met for the execution of the task is called the deadline, and is referenced 240 in [Fig. 2]. In a real-time system, the response time 220 must be less than the deadline 240 to meet real-time constraints.

[0040] The waiting time 210 before the start of task execution depends on several parameters, including: the execution time of the current task, the scheduling strategy used (for example, the use of preemption mechanisms) (by the highest priority tasks), other potentially higher priority tasks already activated that are in the "ready" state, and external stimuli. The task's response time is therefore directly dependent on other tasks that are ready or running on the same core. This can lead to missed deadlines and thus to failure to meet the system's real-time constraints.

[0041] It is therefore important to minimize the waiting time 210 of the implementing task which will perform asynchronous processing.

[0042] In the system and method described herein, at least one initiating task is defined to initiate one or more processes, including one or more asynchronous processes, and at least one set of several execution tasks configured to perform the same asynchronous process(es), each of said execution tasks in the same set being allocated to a different core of the multi-core processor. The initiating task is configured to activate all the execution tasks in a given set when a given asynchronous process is to be initiated, and the execution tasks are configured such that the execution task in the given set that is ready first performs the given asynchronous process, while the other execution task(s) in the given set ignore the given asynchronous process.

[0043] Although the tasks are defined statically, the core that offers the shortest waiting time can thus be selected dynamically at execution time.

[0044] For a given initiating task, the realizing tasks are said to be identical because they call the same executable(s) which are stored in non-volatile memory and which are executed by the core on which the realizing task is launched (one or more executables per asynchronous processing associated with the initiating task).

[0045] Advantageously, the initiating task is allocated to a different core than the cores allocated to the realizing tasks associated with it.

[0046] When a single game is configured, each execution task of the game is configured to perform all the asynchronous processing associated with the initiating task(s) that may activate it.

[0047] When several sets are configured, the sets taken as a whole must be able to perform all the asynchronous processing associated with the initiating task(s). For example, the executing tasks can be divided into two groups according to a given criterion (for example, the type of processing). A first set can be configured to perform the processing of the first group and a second set can be configured to perform the processing of the second group. For example, in the automotive field, the criterion can be the Automotive Safety Integrity Level (ASIL), a classification defined by ISO 26262 that determines the level of risk associated with a safety failure in automotive systems.

[0048] As stated above, the initiating task is configured to activate all the realizing tasks of a given set, when a given asynchronous process is to be initiated, and the realizing tasks are configured such that the realizing task of the given set which is ready first performs the given asynchronous process, while the other realizing task(s) of the given set ignore the given asynchronous process.

[0049] For example, the initiating task is configured to generate an initiation request for the given asynchronous process, and the implementing tasks are configured to check, before performing the given asynchronous process, that an initiation request for the given asynchronous process is pending execution. The initiating and implementing tasks are then, for example, configured to manage information representing the number of initiation requests pending execution for each asynchronous process. The request count information is updated by the initiating task when it initiates a given asynchronous process to increment the number of initiation requests pending execution for the given asynchronous process. And it is updated by the implementing tasks when they perform the given asynchronous process to decrement the number of initiation requests pending execution for the given asynchronous process.

[0050] In a first embodiment, the number of requests is represented by a flag, thus indicating in binary form whether an initiation request is waiting to be executed for a given asynchronous process. In a second embodiment, the number of requests is represented by a counter, allowing the management of multiple initiation requests waiting to be executed for the same asynchronous process. In a third embodiment, the number of requests is represented by a table, thus allowing the management of multiple initiation requests waiting to be executed for multiple given asynchronous processes. Indeed, an initiating task can generate a second initiation request for the same asynchronous process while the first request is still being executed.Or an initiating task can generate an initiation request for an asynchronous process while an initiation request has already been generated by another initiating task for the same asynchronous process. Or one or more initiating tasks can generate an initiation request for different asynchronous processes without the previous ones having finished.

[0051] Figure 3 shows the steps implemented by any initiating task, that is, any task capable of requesting the execution of asynchronous processing. At step 310, the initiating task increments the request number information (i.e., the flag, the counter, or the table in the example described below). above) to request a new execution of the asynchronous processing. At step 320, it activates all the realizing tasks of a given set of realizing tasks.

[0052] Figure 4 shows the steps implemented in any realization task, That is, any task capable of performing the requested asynchronous processing. At step 410, the executing task is in the "running" state. It reads the request count information to check if there is an asynchronous processing initiation request waiting to be executed. If one exists (active flag, positive counter, positive value in a table cell in the example described above), at step 420, the executing task positions itself to execute this request by decrementing the corresponding request count information. Then, at step 430, the executing task executes the asynchronous processing. If, on the other hand, there is no initiation request waiting to be executed, the executing task terminates without doing anything.

[0053] Figure 5 is a diagram describing a first example of an embodiment with two Initiating tasks 501 and 502 are associated with a single set of three implementing tasks 511, 512, and 513. Initiating task 501 is configured to initiate asynchronous processing TL. Initiating task 502 is configured to initiate asynchronous processing T2. The three implementing tasks 511, 512, and 513 call the same executable ER, which is capable of performing both asynchronous processing T1 and T2. The executables that perform the processing of the first and second initiating tasks 501 and 502 are referenced EU and EI2, respectively.

[0054] The first and second initiating tasks 501 and 502 are allocated respectively to a first and second core 521 and 522 of the multi-core processor. The three executing tasks 511, 512 and 513 are allocated respectively to a third, fourth and fifth core of the multi-core processor, referenced 523, 524 and 525.

[0055] As illustrated in [Fig. 5], at step 540, the initiating task 501 calls the executable EU to initiate the asynchronous processing TL. An instance 541 of the executable EU increments the request count information for the asynchronous processing Tl and activates the set of implementing tasks 511, 512, and 513. In the example described in [Fig. 5], implementing task 511 is ready first. It therefore calls the executable ER. An instance 542 of the executable ER checks the request count information, determines that the asynchronous processing Tl is waiting to be executed, decrements the request count information for processing Tl, and executes the processing TL. When implementing tasks 512 and 513 are ready in turn, they call the executable ER.Two new instances of the ER executable, referenced 543 and 544 respectively, check the request count information, find that no asynchronous processing is waiting to be executed, and terminate.

[0056] At step 550, the initiating task 502 calls the executable EI2 to initiate the asynchronous processing T2. An instance 551 of the executable EU increments the request count information for the asynchronous processing T2 and activates the set of implementing tasks 511, 512, and 513. Implementing task 512 is ready first. It therefore calls the executable ER. An instance 553 of the executable ER checks the request count information, determines that the asynchronous processing T2 is waiting to be executed, decrements the request count information for processing T2, and executes processing T2. When implementing tasks 511 and 513 are ready in turn, they call the executable ER.Two new instances of the ER executable, referenced 552 and 554 respectively, check the request count information, find that no asynchronous processing is waiting to be executed (process T1 has been executed by implementing task 511 and process T2 has been executed or is being executed by implementing task 512) and terminate.

[0057] At step 560, the initiating task 501 again calls the executable EU to initiate the asynchronous processing TL. An instance 561 of the executable EU increments the request count information for the asynchronous processing Tl and activates the set of implementing tasks 511, 512, and 513. Implementing task 513 is ready first. It therefore calls the executable ER. An instance 564 of the executable ER checks the request count information, notes that the asynchronous processing Tl is waiting to be executed, decrements the request count information corresponding to the processing Tl, and executes the processing TL. When implementing tasks 511 and 512 are ready in turn, they call the executable ER. Two new instances of the ER executable, referenced as 562 and 563 respectively, check the request count information, find that no asynchronous processing is waiting to be executed, and terminate.

[0058] In the example in [Fig. 5], the request count information is a table [ni; n2], where ni is the number of requests in progress for the asynchronous processing T1 and n2 is the number of requests in progress for the asynchronous processing T2. The executable EU increments the value of ni, the executable EI2 increments the value of n2, and the executable ER decrements the value of ni before executing processing T1 and the value of n2 before executing processing T2.

[0059] Figure 6 is a diagram describing a second embodiment with two initiating tasks 601 and 602. The initiating task 601 is configured to initiate an asynchronous process T1 and is associated with a first set 606 of three implementing tasks 611, 612, and 613. The initiating task 602 is configured to initiate an asynchronous process T2 and is associated with a second set 608 of two implementing tasks 614 and 615. The three implementing tasks 611, 612, and 613 call a The same executable ER1 is capable of performing the asynchronous processing T1. The two execution tasks 614 and 615 call the same executable ER2, which is capable of performing the asynchronous processing T2. The executables that perform the processing of the first and second initiating tasks 601 and 602 are referenced EU and EI2 respectively in [Fig.6].

[0060] The first and second initiating tasks 601 and 602 are allocated respectively to a first and second core 621 and 622 of the multicore processor. The execution task 611 is allocated to a third core 623 of the multicore processor. The two execution tasks 612 and 614 are allocated to a fourth core 624 of the multicore processor. And the two execution tasks 613 and 615 are allocated to a fifth core 625 of the multicore processor.

[0061] As illustrated in [Fig. 6], at step 640, the initiating task 601 calls the executable EU to initiate the asynchronous processing TL. An instance 641 of the executable EU increments the request count information for the asynchronous processing TL and activates the implementing tasks 611, 612, and 613 of the first set of implementing tasks 606. In the example shown in [Fig. 6], implementing task 611 is ready first. It therefore calls the executable ER1. An instance 642 of the executable ER1 checks the request count information, notes that the asynchronous process Tl is waiting to be executed, decrements the request count information corresponding to the process Tl, and executes the process TL. When the realizing tasks 612 and 613 are ready in turn, they call the executable ER1.Two new instances of the ER1 executable, referenced 643 and 644 respectively, check the request count information, find that no asynchronous processing is waiting to be executed, and terminate.

[0062] At step 650, the initiating task 602 calls the executable EI2 to initiate the asynchronous processing T2. An instance 651 of the executable EI2 increments the request count information for the asynchronous processing T2 and activates the implementing tasks 614 and 615 of the second set of implementing tasks 608. Implementing task 614 is ready first. It therefore calls the executable ER2. An instance 652 of the executable ER2 checks the request count information, determines that the asynchronous processing T2 is waiting to be executed, decrements the request count information corresponding to the processing T2, and executes the processing T2. When implementing task 615 is ready in turn, it calls the executable ER2.A new instance 653 of the ER2 executable checks the request count information, finds that no asynchronous processing is waiting to be executed (process T1 has been executed by implementing task 611 and process T2 has been executed or is being executed by implementing task 614) and terminates.

[0063] In the example in [Fig. 6], the request number information is a table [ni; n2], where ni is the number of requests in progress for the asynchronous processing T1 and n2 is the number of requests in progress for the asynchronous processing T2. The executable EU increments the value of ni, the executable EI2 increments the value of n2, the executable ER1 decrements the value of ni before executing the processing T1 and the executable ER2 decrements the value of n2 before executing the processing T2.

[0064] The functional diagrams presented here represent conceptual views given by way of non-limiting example to illustrate the principles of this disclosure. These principles can be implemented in devices with multiple variations.

[0065] The terminology used here is solely for the purpose of describing particular embodiments and is not limiting.

[0066] In particular, the terms "includes", "comprising", "includes" and / or "including", specify the presence of given characteristics, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other characteristics, steps, operations, elements, components.

Claims

Demands

1. A multi-core processor computer system configured to activate statically defined tasks, said tasks comprising: - at least one initiator task (501, 601, 602) configured to initiate one or more processes, including one or more asynchronous processes, and - at least one set of execution tasks (511, 512, 513, 611, 612, 613, 614, 615), comprising at least two execution tasks configured to perform the same asynchronous process(es), each allocated to a different core of the multi-core processor, the initiator task being configured to activate the execution tasks of a given set of execution tasks when a given asynchronous process is to be initiated (310, 320), and the execution tasks being configured such that the execution task of the given set of execution tasks that is ready first performs the process asynchronous given,while the other realizing task(s) of the given set of realizing tasks ignore the given asynchronous processing (410, 420, 430, 440).

2. Multi-core processor computer system according to claim 1, characterized in that each of the initiating (501, 601, 602) and performing (511, 512, 513, 611, 612, 613, 614, 615) tasks is allocated to a different core of the multi-core processor.

3. Multi-core processor computer system according to any one of claims 1 or 2, characterized in that it comprises a single set of execution tasks (511, 512, 513), configured to perform all of the asynchronous processing associated with said at least one initiating task.

4. Multi-core processor computer system according to any one of claims 1 or 2, characterized in that it comprises several sets of execution tasks (611, 612, 613, and 614, 615), configured to, together, perform all of the asynchronous processing associated with said at least one initiating task (601, 602).

5. A multi-core processor computer system according to claim 4, characterized in that each realization task (611, 612, 613, and 614, 615) of the same set is associated with the same level of automotive safety integrity, different from at least one other level of automotive safety integrity associated with the realization tasks (614, 615 and 611, 612, 613) of at least one other set of realizing tasks.

6. Multi-core processor computer system according to claim 5, characterized in that it comprises a first (611,612, 613) and a second (614, 615) set of realizing tasks, the realizing tasks of the first set of realizing tasks (611, 612, 613) being configured to perform at least one asynchronous processing associated with a first level of automotive safety integrity, and the realizing tasks of the second set of realizing tasks (614, 615) being configured to perform at least one asynchronous processing associated with a second level of automotive safety integrity different from the first level.

7. A multi-core processor computer system according to any one of claims 1 to 6, characterized in that the initiating task (501, 601, 602) is configured to generate a request to initiate the given asynchronous processing, and the implementing tasks are configured to check, before performing the given asynchronous processing, that there is a request to initiate the given asynchronous processing waiting to be executed (410).

8. A multi-core processor computer system according to any one of claims 1 to 7, characterized in that the initiator (501, 601, 602) and implementer (611, 612, 613, and 614, 615) tasks are configured to manage information representing a number of initiation requests pending execution for each asynchronous process, said information being updated on the one hand, by the initiator task when it initiates a given asynchronous process to increment the number of initiation requests pending execution for the given asynchronous process (310), and on the other hand, by the implementer tasks when they perform the given asynchronous process to decrement the number of initiation requests pending execution for the given asynchronous process (420).

9. A method for managing a multicore processor configured to execute statically defined tasks, said tasks comprising at least one initiator task (501, 601, 602) configured to initiate one or more processes, including one or more asynchronous processes, and at least one set of execution tasks (611, 612, 613, and 614, 615) comprising at least two execution tasks configured to perform the same asynchronous processing, and each allocated to a different core of the multi-core processor, said process comprising the following steps: - when a given asynchronous processing is to be performed, an activation (320) of each of the realizing tasks of a given set of realizing tasks by the initiating task, - a realization (430) of the given asynchronous processing by that of the realizing tasks of the given set of realizing tasks which is ready first to perform it, the other realizing tasks ignoring the given asynchronous processing.

10. Method according to claim 9, characterized in that each of the initiating (501, 601, 602) and performing (611, 612, 613, and 614, 615) tasks is allocated to a different core of the multi-core processor.

11. A method according to any one of claims 9 or 10, wherein the realizing tasks (611, 612, 613, and 614, 615) of the set or sets of realizing tasks are configured to, together, perform all of the asynchronous processing associated with said at least one initiating task.

12. A method according to any one of claims 9 to 11, characterized in that it comprises a generation, by the initiating task (501, 601, 602), of a request to initiate the given asynchronous processing, and a verification, by the implementing tasks (611, 612, 613, and 614, 615), before carrying out a given asynchronous processing, that there is a request to initiate the given asynchronous processing awaiting execution.

13. A method according to any one of claims 9 to 12, characterized in that it comprises: - when the initiating task initiates a given asynchronous process, an update by the initiating task of information representing a number of pending initiation requests for each asynchronous process, to increment the number of pending initiation requests for the given asynchronous process (310), - when a given implementing task performs the given asynchronous process, an update of said information 16 by the given realizing task, to decrement the number of initiation requests waiting to be executed for the given asynchronous processing (420).

14. Computer program comprising instructions for carrying out a method according to claims 9 to 13 when executed by a processor.

15. Motor vehicle comprising a multi-core processor computer system according to any one of claims 1 to 8.

Images