SHARED DATA MANAGEMENT PROCESS
The method addresses LWW problems by prioritizing tasks and executables to determine the final value of shared variables, ensuring consistent data management in multi-core environments.
Patent Information
- Application Number
- FR2023000953
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-02-02
- Publication Date
- 2025-01-10
- Estimated Expiration
- 2043-02-02
AI Technical Summary
Last Writer Win (LWW) problems arise when multiple software tasks concurrently access and modify shared variables, leading to inconsistent and unpredictable data values due to the temporal overlap of read and write operations, particularly in multi-core processor environments.
A method for managing shared data by assigning priority constants to tasks and executables, ensuring that the task with the highest priority determines the final value of the shared variable, using a two-step process: offline priority assignment and real-time priority management during execution, with optional buffering to manage data consistency.
Ensures consistent and predictable data values by prioritizing tasks based on their assigned priorities, preventing the Last Writer Win issue and maintaining data integrity across concurrent executions.
Smart Images
Figure 00000016_0000 
Figure 00000017_0000 
Figure 00000018_0000
Abstract
Description
Title of the invention: METHOD FOR MANAGING SHARED DATA Technical field
[0001] The present disclosure relates to the field of software tasks performed in parallel. Prior art
[0002] Multi-core processors allow the parallel execution of several software tasks. The execution of software tasks in parallel is useful, for example, in the field of embedded systems.
[0003] The response time of software tasks is an important element in order to ensure correct functional behavior (for example the control of a combustion engine) and safety (for example the injection cut-off for combustion engines must be very fast to guarantee the safety of the driver).
[0004] Software tasks (or functions) typically include one or more algorithms called executables (or runnables in English) which are executed when the task itself is triggered by an event (e.g. event linked to the position of the motor) of the time signals.
[0005] The same variable can be used by several executables that are executed at different times, sometimes in parallel, and the value of the variable can change over time depending on its value determined at the end of each executable. In some cases, the variable can even be made instantly available to other executables as soon as it is modified. The production of data based on this variable can then lead to concurrent access to the variable if it is read / write from concurrent tasks (for example, concurrent tasks executed in different cores, each task having one or more executables).
[0006] Last Writer Win (LWW) problems can then arise when there is an overlap between read and write accesses to the variable. This can lead to losing the value of the variable calculated by one task to the benefit of another concurrent task. Summary
[0007] The present disclosure improves the situation.
[0008] A computer-implemented method for managing shared data through a memory is proposed, in which a shared variable VAR is stored in the memory, the variable VAR is accessible by at least two tasks TASK_i (i=l.. .n, n>=2) executed in parallel with each other, each task TASK_i including at least one executable RUN_ij (j=1.. .k, k>=l), when the task TASK_i comprises at least two executables RUN_ij these are executed sequentially, a priority variable PRIO_DATA associated with the variable VAR being stored in the memory and initially taking a value PRIO_INI, a priority constant PRIO_i being stored in the memory for each of the tasks TASK_i, the priority constant PRIO_i characterizing the priority order of the task TASK_i, PRIO_INI being reserved for the lowest priority and being different from each of the priority constants PRIO_i, each of the executables RUN_ij having an associated priority constant PRIO_RUN_ij characterizing the priority order of the executable RUN_ij producing the variable VAR, for each of the tasks TASK_i the priority constant PRIO_ i of the task TASK_i being the maximum of the priority constants PRIO_RUN_ij of the executables RUN_ij of this task, the method comprising the following steps: - at a time tl: . * initiate the i-th task TASK_i using the value of the shared variable VAR at tl in memory, and * if PRIO_i > PRIO_DATA at time tl then PRIO_DATA is updated to the value PRIO_i, - after the execution of the same i-th task TASK_i at a time t2>tl, the i-th task TASK_i generates a value VAR_UPDATE_i of the variable VAR, * if PRIO_DATA at time t2 = PRIO_i, then VAR is updated to the value VAR_UPDATE_i and PRIO_DATA is updated to the value PRIO_INI.
[0009] The method for managing shared data may have one or more of the following characteristics: * the values of each PRIO_i are strictly increasing according to the order of priority of the task TASK_i producing the variable VAR, PRIO_INI being smaller than each of the priority constants PRIO_i, preferably PRIO_INI=0. * each of the TASK_i tasks is executed on its own CORE_i core. * the method further comprises a first buffer BUFF_1 arranged between the memory and a first core CORE_1 on which a first task TASK_1 is executed, and / or a second buffer BUFF_2 arranged between the memory and a second core CORE_2 on which a second task TASK_2 is executed, the first and second buffers BUFF_1, BUFF_2 comprising copies of the values of the VAR variables used by the tasks TASK_1, TASK2 as input and output of the tasks TASK_1, TASK2, the first and second buffers BUFF_1, BUFF_2 being able to interact with the memory to modify the VAR variable as output of the tasks TASK_i. * the first and second buffers BUFF_1, BUFF_2 comprising copies of the values of the input and output VAR variables of the executables RUN_lj, RUN_2j of each of the tasks TASK_1, TASK2. * the creation of the priority constant PRIO_i is done offline. * memory is a live memory, in particular a RAM (random access memory).
[0010] According to another aspect, there is provided a computer program comprising instructions for implementing all or part of a method as defined herein when this program is executed by a processor. According to another aspect, there is provided a non-transitory, computer-readable recording medium on which such a program is recorded.
[0011] According to another aspect, there is provided a computer device comprising: a memory for storing at least instructions of the computer program of the preceding claim, and a processor accessing the memory to read the aforementioned instructions and then execute the above method.
[0012] According to another aspect, there is provided a non-transitory computer-readable recording medium on which a computer program is recorded for implementing the above method, when the computer program is executed by a processor.
[0013] According to another aspect, there is provided a vehicle with an on-board system comprising the above computing device. Brief description of the drawings
[0014] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l
[0015] [Fig.l] shows an example of a shared variable on which there is a LWW problem. Fig. 2
[0016] [Fig.2] shows another example of a shared variable on which there is a LWW problem. Fig. 3
[0017] [Fig.3] shows yet another example of a shared variable on which there is a LWW problem. Fig. 4
[0018] [Fig.4] shows an example of priority allocation between several tasks each having one or more executables. Fig. 5
[0019] [Fig.5] shows a flowchart for priority management between several tasks using a shared variable. Fig. 6
[0020] [Fig.6] shows a first example of priority management between two concurrent tasks using a shared variable. Fig. 7
[0021] [Fig.7] shows a second example of priority management between two concurrent tasks using a shared variable. Fig. 8
[0022] [Fig.8] shows a third example of priority management between two concurrent tasks using a shared variable. Fig. 9
[0023] [Fig.9] shows a fourth example of priority management between two concurrent tasks using a shared variable. Fig. 10
[0024] [Fig. 10] shows a fifth example of priority management between two concurrent tasks using a shared variable. Fig. 11
[0025] [Fig. 11] shows a sixth example of priority management between two concurrent tasks using a shared variable. Fig. 12
[0026] [Fig. 12] shows an example of priority management between two non-concurrent tasks using a shared variable. Description of the embodiments
[0027] Reference is now made to Figures 1 and 2 which illustrate scenarios where Last Writer Win (LWW) problems may then occur.
[0028] A core CORE1 contains a task TASK A which contains an executable RUNNABLE A. A core CORE 2 in parallel with the core CORE1 contains a task TASK B which contains an executable RUNNABLE B. Each executable RUNNABLE A, RUNNABLE B accesses a variable VAR at the beginning of execution and updates the value of the variable VAR with the value they calculated, at the end of execution. The executables RUNNABLE A, RUNNABLE B access and update the variable VAR at different times.
[0029] Thus, for the case of [Fig. 1], the variable VAR is accessed first by the executable RUNNABLE A, then by the executable RUNNABLE B. The executable RUNNABLE B ends before the executable RUNNABLE A, and the value of the variable VAR is therefore updated sequentially by the executable RUNNABLE B and then the executable RUNNABLE A. Thus, when the tasks TASK A and TASK B are completed, the variable has the value updated by the task TASK A.
[0030] In the opposite case, in [Fig.2], the executable RUNNABLE A ends before the executable RUNNABLE B, and the value of the variable VAR is therefore updated sequentially by the executable RUNNABLE A then the executable RUNNABLE B. Thus, when the tasks TASK A and TASK B are completed, the variable has the value updated by the task TASK B.
[0031] We therefore see that the priority of the tasks TASK A and TASK B is not defined by their intrinsic priority but is determined by their temporality. A Last Writer Win (LWW) problem may therefore arise on the value of the variable VAR since it will be the last executable to update the value of the variable VAR which will determine the value of the variable VAR when the tasks TASK A and TASK B are completed.
[0032] With reference to [Fig.3], the case of [Fig.l] is now illustrated with buffer memories, or buffers, BUF1, BUF2, interacting respectively between the memory containing the variable VAR and the tasks TASK A and TASK B.
[0033] The buffers BUF1, BUF2 are used to ensure the consistency of data accessed in concurrent tasks (usually from different cores). A buffering mechanism is commonly used to ensure the stability of a variable read multiple times in one task and written in other concurrent tasks, and the consistency of a set of variables that are read in one task and written in other concurrent tasks.
[0034] The buffers BUF1, BUF2 are created on each simultaneous task TASK A and TASK B. FILL and FLUSH routines are generated to manage access to data in global memory, and in particular the variable VAR, and to fill and empty the buffers (read and write). Simultaneous access of these FILL and FLUSH routines to global memory is avoided by the use of semaphores. FILL routine: under the semaphore, it copies the data from global memory to the local buffer (instruction to fill the buffer). FLUSH routine: under the semaphore, it copies the local buffer to the data in global memory (instruction to empty the buffer).
[0035] It is noted that the use of buffers accentuates the LWW problem on the variable VAR because it increases the temporality between the read and write accesses carried out in concurrent tasks for this variable. Instead of reading and writing being done at the time of execution of the executable, they are done when the buffer memory is emptied, a few moments after the end of the executable. Thus, in the case of [Fig.3], the variable VAR updated by the executable RUNNABLE A is not updated at the end of execution of RUNNABLE A as in the case of [Fig.l], but at the time of emptying the buffer BUF1.
[0036] In response to these cases, a priority management method is proposed. The invention consists of managing certain priorities for variables, optionally buffered, shared which could be overwritten by concurrent tasks. For To avoid the LWW situation, a priority order is managed for each shared variable associated with concurrent tasks.
[0037] The method essentially consists of 2 steps. The first step is done during the design of the algorithm and consists of assigning / determining the priority orders of the tasks (and executables). This first step can be performed offline or in real time. The second is performed dynamically, during the execution of the executables, and consists of assigning a value of the variable VAR in real time according to the priorities of the executables / tasks.
[0038] Referring now to [Fig.4], the first step corresponding to the allocation of priority orders will be described.
[0039] In a general case with n tasks executed TASK_i (i=l.. .n, n>=2) in parallel, each having j executables RUN_ij (j=1.. .k, k>=l), the shared variable VAR is recorded in the memory and is accessible by the tasks TASK_i executed in parallel. According to one embodiment, each of the tasks TASK_i is executed on a core CORE_i of its own. The memory on which the variable VAR is recorded is for example a random access memory, in particular a RAM (random access memory).
[0040] Each TASK_i task comprises at least one RUN_ij executable. When the TASK_i task comprises two or more RUN_ij executables, these are executed sequentially. A priority constant PRIO_i is stored in the memory for each of the TASK_i tasks. The priority constant PRIO_i characterizes the priority order of the TASK_i task producing the variable VAR. A constant PRIO_INI is reserved for the lowest priority and is different from each of the PRIO_i priority constants. Each of the RUN_ij executables has an associated PRIO_RUN_ij priority constant. The priority constant PRIO_RUN_ij characterizes the priority order of the RUN_ij executable producing the variable VAR. For each of the TASK_i tasks, the priority constant PRIO_i of the TASK_i task is the maximum of the priority constants PRIO_RUN_ij of the RUN_ij executables of this task.
[0041] Thus, if we refer to the particular case of [Fig.4], the task TASK A is executed in parallel with the task TASK B. The task TASK A comprises two executables RUNNABLE 1 and RUNNABLE 2 which are executed sequentially. The task TASK B comprises an executable RUNNABLE 3.
[0042] Each executable RUNNABLE 1, RUNNABLE 2, RUNNABLE 3 has an associated priority constant PRIO_RUN_A1, PRIO_RUN_A2, PRIO_RUN_B3. In order to determine the overall priority of task TASK A relative to task TASK B, the priority constant PRIO A of task TASK A is the maximum of the priority constants PRIO_RUN_A1, PRIO_RUN_A2 of the executables RUNNABLE 1, RUNNABLE 2 of this task. For task TASK B, the priority constant PRIO B is simply the priority constant PRI0_RUN_B3 of the executable RUNNABLE 3, since this task does not have any other executable than RUNNABLE 3. None of the constants of PRIO A, PRIO B has the value of the initiation constant PRIO_INI reserved for the lowest priority.
[0043] The priority constants are, according to one embodiment, positive and strictly increasing. According to one embodiment, PRIO_INI=0.
[0044] Thus, for the subsequent management of the priority of the task TASK A in relation to the task TASK B, the constants PRIO A and PRIO B will be compared. If PRIO A > PRIO B then, the task TASK A will have priority over the task TASK B for the production of the variable VAR. And if PRIO B > PRIO A then, the task TASK B will have priority over the task TASK A for the production of the variable VAR.
[0045] Referring now to [Fig.5], the second step corresponding to the real-time allocation of a value of the variable VAR according to the priority orders of the tasks TASK A, TASK B will be described.
[0046] In step S1, at a time t1, the i-th task TASK_i having the priority PRIO_i is initiated using the value of the shared variable VAR at t1 in the memory (reading of the variable VAR by the task TASK_i), and if PRIO_i > PRIO_DATA at time t1 (i.e. the priority of the task TASK_i is higher than the current one at time t1, see arrow "Y" in [Fig.5]) then PRIO_DATA is updated to the value PRIO_i (i.e. the new priority is the priority of task TASK_i).
[0047] The instant tl of reading the variable VAR can be the instant of initiation of execution of the task or an earlier instant, such as for example the instant of filling the buffer (FILL routine) if a buffer is used.
[0048] In step S2, after the execution of the same i-th task TASK_i at a time t2>tl, the i-th task TASK_i generates a value VAR_UPDATE_i of the variable VAR, if PRIO_DATA at time t2 = PRIO_i (see arrow “Y” in [Fig.5]), then VAR is updated to the value VAR_UPDATE_i and PRIO_DATA is updated to the value PRIO_INI (writing in the memory of the variable VAR calculated by the task TASK_i).
[0049] The instant t2 of writing the variable VAR can be the instant of end of execution of the task or a later instant, such as for example the instant of emptying the buffer (FLUSH routine) if a buffer is used.
[0050] Different applicable cases of the second step will be illustrated with reference to Figures 6 to 12 for the case of [Fig.4] where the core CORE A contains a task TASK A with two executables RUNNABLE 1, RUNNABLE 2, and the core CORE B parallel to the core CORE A contains a task TASK B with an executable RUNNABLE 3. For consistency with a numerical numbering as used in the definition of the algorithm, in Figures 6 to 12, the core CORE A will be identified by CORE_1, task TASK A by task TASK_1, and the executables of task TASK_1 will be RUN_11 and RUN_12. Similarly, core CORE B will be identified by CORE_2, task TASK B by task TASK_2, and the executable of task TASK_2 will be RUN_21.
[0051] Figures 6 to 12 illustrate an embodiment where buffers BUFF_1, BUFF_2 (similar to the buffers BUF1, BUF2 of [Fig.3]) are present. However, there may be only one or no buffers. The times of reading and writing the variable VAR correspond to the filling (FILL routine) and emptying (FLUSH routine) of the buffer when buffers are present. If the buffers are not present, the times of reading and writing the variable VAR may be the times of the start and end of the tasks.
[0052] In the case of [Fig.6], it is defined that the priority PRIO_2 of the task TASK_2 is higher than the priority PRIO_1 of the task TASK_1. Initially in the RAM memory, the variable PRIO_DATA is at 0 (because in this particular case, it was therefore chosen that PRIO_INI=0). The task TASK_1 starts before the task TASK_2. When the task TASK_1 starts at time tl, the priority of the task TASK_1 is compared to the value of the variable PRIO_DATA at that time. Since PRIO_DATA=0, PRIO_1>PRIO_DATA and therefore PRIO_DATA is updated with the value PRIO_1. The step IF described above has just been completed.
[0053] Simultaneously, the variable VAR which is at x at this time is copied into the buffer BUFF_1. The first executable RUN_11 of the task TASK_1 is initiated with the value x of the variable VAR copied into the buffer BUFF_1 at this time. When the first executable RUN_11 finishes, it produces an updated value xl of the variable VAR, which is copied into the buffer BUFF_1, but not into memory because the buffer BUFF_1 is not yet instructed to empty. When the second executable RUN_12 of the task TASK_1 is initiated, it takes the value xl of the variable VAR available in the BUFF_1 at this time. When the second executable RUN_12 finishes, it produces an updated value x2 of the variable VAR, which is copied into the buffer BUFF_1. There are no other executables in this buffer.
[0054] Priority management in accordance with step S2 takes place when the buffer BUFF_1 is emptied in order to determine whether the value x2 of the variable VAR can be copied into the memory for use by other tasks. At time t2 (which is the time when the buffer BUFF_1 is emptied), the priority PRIO_1 of the task TASK_1 is compared to PRIO_DATA. If PRIO_DATA=PRIO_1, this means that no other concurrent task of higher priority has been initiated between times t1 and t2. In this case, the value x2 of the variable VAR can be copied into the memory. But this is not the case in [Fig.6], where the task TASK_2 with higher priority PRIO_2 was initiated at a time t3 between t1 and t2. Thus, at time t2, PRIO_DATA is not plus PRIO_1, and therefore the value x2 of the variable VAR is not copied into memory and remains in the buffer BUFF_2.
[0055] In the case of [Fig.6], at time t2, PRIO_DATA has the value of PRIO_INI (i.e. 0) because at time t2 the task TASK_2 is already completed (at t4 between t1 and t2). If the task TASK_2 was not already completed, PRIO_DATA would have the value PRIO_2, and the result for copying or not the variable x2 would be the same since at time t2, PRIO_DATA is still not PRIO_1.
[0056] Priority management from the point of view of task TASK_2 is also managed by steps S1 and S2. Thus, in step S1, at time t3, the variable VAR has the value x and PRIO_DATA has the value PRIO_1. PRIO_DATA is compared to PRIO_2. Since PRIO_2 > PRIO_1, task TASK_2 takes priority over task TASK_1 for managing the variable VAR and PRIO_DATA is updated with the value PRIO_2.
[0057] The value x of the variable VAR is copied into the buffer BUFF_2. The executable RUN_21 of the task TASK_2 is initiated with the value x of the variable VAR copied into the buffer BUFF_2. When the executable RUN_21 terminates, it produces an updated value y of the variable VAR, which is copied into the buffer BUFF_2.
[0058] Priority management in accordance with step S2 then takes place, in order to determine whether the value y of the variable VAR can be copied into the memory in order to be used by other tasks. At time t4 (which is the time of emptying the buffer BUFF_2), the priority PRIO_2 of the task TASK_2 is compared to PRIO_DATA. If PRIO_DATA=PRIO_2, this means that no other concurrent task of higher priority has been initiated between times t3 and t4. In this case, the value y of the variable VAR can be copied into the memory. But this is not the case in [Fig.6], where the task TASK_2 is the task with the highest priority PRIO_2. So, at time t4, PRIO_DATA is still PRIO_2, and so the value y of the variable VAR is copied into memory, and PRIO_DATA is reset to PRIO_INI.This value will remain even at the end of execution of task TASK_1, which clearly reflects the fact that task TASK_2 has priority for the value of the variable VAR over task TASK_1 when task TASK_1 temporally competes with task TASK-2.
[0059] [Fig.7] presents a case similar to that of [Fig.6], except that the priority PRIO_1 of task TASK_1 is higher than the priority PRIO_2 of task TASK-2.
[0060] Thus, at the level of task TASK_1, at time tl, the value x of the variable VAR is copied into the buffer BUFF_1. As for PRIO_DATA, at time tl PRIO_DATA = 0, therefore PRIO_DATA < PRIO_1, and therefore PRIO_DATA is updated with the value PRIO_1. At time t2 of the end of execution of task TASK_1, PRIO_DATA is still equal to PRIO_1, since no other concurrent task of higher priority was initiated between times tl and t2. Thus, PRI0_DATA is updated to PRI0_INI (i.e. 0), and the value x2 obtained at the end of the second RUN_12 executable is copied into memory to become the new value of the variable VAR.
[0061] Regarding priority management at the task TASK_2 level, at time t3, the value x of the variable VAR is copied into the buffer BUFF_2. Regarding PRIO_DATA, at time t3 PRIO_DATA = PRIO_1, therefore PRIO_DATA > PRIO_2, and therefore PRIO_DATA is not updated with the value PRIO_2. At time t4 of emptying of the buffer BUFF_2 of the task TASK_2, PRIO_DATA is still equal to PRIO_1, and the value y obtained at the end of the second executable RUN_21 is not copied into the memory to become the new value of the variable VAR.
[0062] The value of VAR at the end of execution of task TASK_1 will be the value x2 of task TASK_1, which clearly reflects the fact that task TASK_1 has priority for the value of the variable VAR over task TASK_2 when task TASK_2 temporarily competes with task TASK_1.
[0063] In the case of [Fig.8], the priority PRIO_2 of the task TASK_2 is higher than the priority PRIO_1 of the task TASK_1 as in the case of [Fig.6]. On the other hand, unlike the case of [Fig.6], the task TASK_2 is initiated temporally before the task TASK_1. The priority management is therefore as follows by applying steps S1 and S2:
[0064] As regards priority management at the level of task TASK_1, at time t1 which is later than t3, the value x of the variable VAR is copied into the buffer BUFF_1. The value of the variable VAR has not been modified at this time by task TASK_2 since the latter has not yet finished at time t1.
[0065] Regarding PRIO_DATA, at time t1 PRIO_DATA = PRIO_2. As PRIO_1 < PRIO_DATA, PRIO_DATA is not updated with the value PRIO_1, because the task TASK_1 does not have priority over the task TASK_2. At time t2 of emptying the buffer BUFF_1 of the task TASK_1, PRIO_DATA = 0 (as the task TASK_2 is completed and has reset the variable PRIO_DATA), and the value x2 obtained at the end of the second executable RUN_12 is not copied into memory to become the new value of the variable VAR.
[0066] Regarding priority management at the level of task TASK_2, at time t3, the value x of the variable VAR is copied into the buffer BUFF_2. Regarding PRIO_DATA, at time t3 PRIO_DATA = PRIO_INI (=0), therefore PRIO_DATA < PRIO_2, and therefore PRIO_DATA is updated with the value PRIO_2. At time t4 of emptying of the buffer BUFF_2 of task TASK_2, PRIO_DATA is still equal to PRIO_2, and the value y obtained at the end of the second executable RUN_21 is copied into memory to become the new value of the variable VAR, and PRIO_DATA is reset to PRIO_INI.
[0067] This value will remain the same at the end of execution of task TASK_1, which clearly reflects the fact that task TASK_2 has priority for the value of the variable VAR over task TASK_1 when task TASK_1 temporally competes with task TASK_2.
[0068] The case of [Fig.9] is similar to that of [Fig.8], except that the priority PRIO_1 of task TASK_1 is higher than the priority PRIO_2 of task TASK_2. The priority management is therefore as follows by applying steps S1 and S2:
[0069] Regarding priority management at the level of task TASK_1, at time t1 which is later than t3, the value x of the variable VAR is copied into the buffer BUFF_1. Regarding PRIO_DATA, at time t1 PRIO_DATA = PRIO_2. As PRIO_1 > PRIO_DATA, PRIO_DATA is updated with the value PRIO_1, because task TASK_1 has priority over task TASK_2. At time t2 of emptying of the buffer BUFF_1 of task TASK_1, PRIO_DATA still has the value of PRIO_1. The value x2 obtained at the end of the second executable RUN_12 is therefore copied into the memory to become the new value of the variable VAR, and PRIO_DATA is reset to PRIO_INI.
[0070] Regarding priority management at the level of task TASK_2, at time t3, the value x of the variable VAR is copied into the buffer BUFF_2. Regarding PRIO_DATA, at time t3 PRIO_DATA = PRIO_INI (=0), therefore PRIO_DATA < PRIO_2, and therefore PRIO_DATA is updated at t3 with the value PRIO_2. At time t4 of emptying of the buffer BUFF_2 of task TASK_2, PRIO_DATA has been updated to PRIO_1 at t1 because task TASK_1 has priority over task TASK_2. As at t4, PRIO_DATA is not PRIO_2, the value y of the variable VAR obtained at the end of the second executable RUN_21 is not copied into the memory when emptying the buffer BUFF_2 to become the new value of the variable VAR.
[0071] The value of VAR at the end of execution of tasks TASK_1 and TASK_2 is the value at the end of execution of task TASK_1, which clearly reflects the fact that task TASK_1 has priority for the value of the variable VAR over task TASK_2 when task TASK_1 temporally competes with task TASK_2.
[0072] In the case of [Fig. 10], the priority PRIO_2 of the task TASK_2 is higher than the priority PRIO_1 of the task TASK_1, and the task TASK_2 starts temporally after the task TASK_1 as in the case of [Fig.6]. On the other hand, unlike the case of [Fig.6], the task TASK_2 ends temporally after the task TASK_1 at the buffer level. The priority management is therefore as follows by applying steps S1 and S2:
[0073] Regarding priority management at the level of task TASK_1, at time t1, the value x of the variable VAR is copied into the buffer BUFF_1. Regarding PRIO_DATA, at time t1 PRIO_DATA = PRIO_INI (=0). As PRIO_1 > PRIO_DATA, PRIO_DATA is updated with the value PRIO_1. At time t2 of emptying of the buffer BUFF_1 of task TASK_1, PRIO_DATA = PRIO_2 (as task TASK_2 is initiated after task TASK_1 and it has priority over task TASK_1), and the value x2 obtained at the end of the second executable RUN_12 is not copied into the memory to become the new value of the variable VAR.
[0074] As regards priority management at the level of task TASK_2, at time t3 after t1 and before t2, the time at which the buffer BUFF_2 of task TASK_2 is filled, the value x of the variable VAR is copied into the buffer BUFF_2. As regards PRIO_DATA, at time t3 PRIO_DATA = PRIO_1, therefore PRIO_DATA < PRIO_2, and therefore PRIO_DATA is updated with the value PRIO_2, since task TASK_2 is initiated after task TASK_1. At time t4 of emptying of the buffer BUFF_2 of the task TASK_2, PRIO_DATA is still equal to PRIO_2, and the value y obtained at the end of the second executable RUN_21 is copied into memory to become the new value of the variable VAR, and PRIO_DATA is reset to PRIO_INI (in this case 0).
[0075] Thus, the value of the variable VAR at the end of execution of the tasks TASK_1 and TASK_2 is the value of the variable VAR at the end of execution of the task TASK_2, which clearly reflects the fact that the task TASK_2 has priority for the value of the variable VAR over the task TASK_1 when the task TASK_1 temporally competes with the task TASK_2.
[0076] The case of [Fig.l 1] is similar to that of [Fig.10], except that the priority PRIO_1 of task TASK_1 is higher than the priority PRIO_2 of task TASK_2. The priority management is therefore as follows by applying steps S1 and S2:
[0077] Regarding priority management at the level of task TASK_1, at time tl, the value x of the variable VAR is copied into the buffer BUFF_1. Regarding PRIO_DATA, at time tl PRIO_DATA = PRIO_INI = 0. As PRIO_1 > PRIO_DATA, PRIO_DATA is updated with the value PRIO_1. At time t2 of emptying of the buffer BUFF_1 (after execution of task TASK_1), PRIO_DATA still has the value of PRIO_1, because even if task TASK_2 was initiated at t3 between tl and t2, its priority is lower, and PRIO_DATA has not been updated. The value x2 obtained at the end of the second RUN_12 executable is copied to t4 in memory to become the new value of the VAR variable, and PRIO_DATA is reset to PRIO-INI.
[0078] Regarding priority management at the level of task TASK_2, at time t3, the value x of the variable VAR is copied into the buffer BUFF_2. Regarding PRIO_DATA, at time t3 PRIO_DATA = PRIO_1, therefore PRIO_DATA > PRIO_2 because task TASK_1 has priority over task TASK_2, and therefore PRIO_DATA is not updated at t3 with the value PRIO_2. At time t4 of emptying the buffer BUFF_2 (after execution of task TASK_2), PRIO_DATA has been updated to PRIO_INI=0 at t2. As at t4, PRIO_DATA is not PRIO_2, the value y of the variable VAR obtained at the end of the second executable RUN_21 of the task TASK_2 is not copied into memory to become the new value of the variable VAR.
[0079] The value of VAR at the end of execution of tasks TASK_1 and TASK_2 is the value at the end of execution of task TASK_1, which clearly reflects the fact that task TASK_1 has priority for the value of the variable VAR over task TASK_2 when task TASK_1 temporally competes with task TASK_2.
[0080] For illustration purposes, [Fig. 12] shows a case where there is no temporal competition between tasks TASK_1 and TASK_2, and where task TASK_1 is performed temporally before TASK_2. Regardless of the priorities of TASK_1 and TASK_2 relative to each other, the value of the variable VAR at the end of execution of tasks TASK_1 and TASK_2 is the value of the variable VAR at the end of execution of task TASK_2, because task TASK_2 is initiated temporally after the execution of task TASK_1. When each non-concurrent task TASK_1 or TASK_2 starts, the value of PRIO_DATA in memory being equal to PRIO_INI, each task has priority in the assignment of the variable VAR.
Claims
Claims
1. A computer-implemented method for managing shared data through a memory, wherein a shared variable VAR is stored in the memory, the variable VAR is accessible by at least two tasks TASK_i (i=1.. .n, n>=2) executed in parallel with each other, each task TASK_i comprising at least one executable RUN_ij (j=1.. .k, k>=l), when the task TASK_i comprises at least two RUN_ij executables, these are executed sequentially, a priority variable PRIO_DATA associated with the variable VAR being stored in the memory and initially taking a value PRIO_INI, a priority constant PRIO_i being stored in the memory for each of the tasks TASK_i, the priority constant PRIO_i characterizing the priority order of the task TASK_i, PRIO_INI being reserved for the lowest priority and being different from each of the priority constants PRIO_i, each of the executables RUN_ij having an associated priority constant PRIO_RUN_ij characterizing the priority order of the executable RUN_ij producing the variable VAR, for each of the tasks TASK_i the priority constant PRIO_i of the task TASK_i being the maximum of the priority constants PRIO_RUN_ij of the executables RUN_ij of this task, the method comprising the steps following:. - at a time tl: * initiate the i-th task TASK_i using the value of the shared variable VAR at tl in memory, and * if PRIO_i > PRIO_DATA at time tl then PRIO_DATA is updated to the value PRIO_i, - after the execution of the same i-th task TASK_i at a time t2>tl, the i-th task TASK_i generates a value VAR_UPDATE_i of the variable VAR, * if PRIO_DATA at time t2 = PRIO_i, then VAR is updated to the value VAR_UPDATE_i and PRIO_DATA is updated to the value PRIOJNI.
2. Method for managing shared data according to claim 1, in which the values of each PRIO_i are strictly increasing according to the order of priority of the task TASK_i producing the variable VAR, PRIO_INI being smaller than each of the priority constants PRIO_i, preferably PRIO_INI=0.
3. Method for managing shared data according to claim 1 or 2, in which each of the tasks TASK_i is executed on a core CORE_i which is specific to it.
4. Method for managing shared data according to one of the preceding claims, further comprising a first buffer BUFF_1 arranged between the memory and a first core CORE_1 on which a first task TASK_1 is executed, and / or a second buffer BUFF_2 arranged between the memory and a second core CORE_2 on which a second task TASK_2 is executed, the first and second buffers BUFF_1, BUFF_2 comprising copies of the values of the VAR variables used by the tasks TASK_1, TASK2 as input and output of the tasks TASK_1, TASK2, the first and second buffers BUFF_1, BUFF_2 being able to interact with the memory to modify the VAR variable as output of the tasks TASK_i.
5. Method for managing shared data according to claim 4, in which the first and second buffers BUFF_1, BUFF_2 comprise copies of the values of the input and output VAR variables of the executables RUN_lj, RUN_2j of each of the tasks TASK_1, TASK2.
6. Method for managing shared data according to one of the preceding claims, in which the creation of the priority constant PRIO_i is done offline.
7. A computer program, comprising instructions for implementing at least part of the method according to any one of the preceding claims when the software is executed by a processor.
8. A computer device comprising: - a memory for storing at least instructions of the computer program of the preceding claim, - a processor accessing the memory to read the aforementioned instructions and then execute the method according to any one of claims 1 to 6
9. 1 d O. A non-transitory computer-readable recording medium on which a computer program is recorded for carrying out the method according to any one of claims 1 to 6, when the computer program is executed by a processor.
10. Vehicle with an on-board system comprising the computing device of claim 8.