Cross-virtual-machine communication method, vehicle machine and storage medium

Abstract

The invention discloses a cross-virtual-machine communication method, an in-vehicle machine and a storage medium, the method is applied to the in-vehicle machine running M virtual machines, and the method comprises the following steps: a first virtual machine creates a conditional variable in a shared memory, the shared memory is shared by N virtual machines, the data structure of the conditional variable comprises a variable name of the conditional variable, a first variable and a second variable, the first variable is used for specifying that N virtual machines have use permission to the conditional variable, the second variable is used for recording the virtual machine using the conditional variable, and N is smaller than or equal to M; all the virtual machines except the first virtual machine in the M virtual machines are matched with the variable names by transmitting to-be-verified names, and if matching succeeds, the addresses of conditional variables are obtained; and performing thread synchronization on the N virtual machines based on the address of the condition variable so as to support DDS communication among the N virtual machines.

Description

Technical Field

[0001] This specification relates to the field of virtual machine technology, and in particular to a cross-virtual machine communication method, vehicle infotainment system, and storage medium. Background Technology

[0002] Condition variables are a mechanism for thread synchronization that utilizes shared variables between threads. Traditional condition variables can only be used between threads within the same Virtual Machine (VM), and cannot be used between threads of two VMs. Currently, in the automotive infotainment system field, multiple VMs run on the same system. Condition variables are used within each VM to achieve thread synchronization, enabling DDS communication between VMs via Data Distribution Service (DDS). However, traditional condition variables cannot be used between threads of two VMs, necessitating a method that uses condition variables to achieve thread synchronization between VMs to support DDS communication. Summary of the Invention

[0003] This specification provides an embodiment of a cross-virtual machine communication method, a vehicle-mounted system, and a storage medium to solve the thread synchronization problem in DDS communication between virtual machines.

[0004] In a first aspect, embodiments of this specification provide a cross-virtual machine communication method applied to a vehicle-mounted system running M virtual machines. The method includes: a first virtual machine creating a condition variable in shared memory, the shared memory being shared by the M virtual machines; the data structure of the condition variable including a variable name, a first variable, and a second variable; the first variable specifying N virtual machines with access to the condition variable; and the second variable recording the virtual machines currently using the condition variable, where N is less than or equal to M; each of the N virtual machines, excluding the first virtual machine, obtaining the address of the condition variable by passing in the variable name; and the N virtual machines performing thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines.

[0005] In conjunction with the first aspect, in some embodiments, the data structure of the condition variable further includes: a third variable for recording the number of threads waiting for the condition variable in each of the N virtual machines; a fourth variable for recording the thread to which the condition variable belongs in the current iteration; and a fifth variable for recording the thread to which the condition variable belongs in the next iteration.

[0006] In conjunction with the first aspect, in some embodiments, the first virtual machine creates a condition variable in shared memory, including: the first virtual machine specifying a variable name and a first bitmap data, wherein the first virtual machine is any one of the M virtual machines, and the first bitmap data is used to specify the virtual machine with access to the condition variable; the first virtual machine calling a variable creation interface to create an empty structure of the condition variable; the first virtual machine initializing the first variable and the variable name of the condition variable in the empty structure according to the specified variable name and the first bitmap data, so as to initialize the first variable as a first bitmap; the first virtual machine initializing the second variable in the empty structure as a second bitmap, initializing the values ​​of the third variable and the fourth variable to 0, and initializing the value of the fifth variable to 1; and the first virtual machine returning the address of the condition variable.

[0007] In conjunction with the first aspect, in some embodiments, the N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, including: an application running on a second virtual machine initiates a system call; in response to the system call, switching from user mode to kernel mode, wherein the second virtual machine is any one of the M virtual machines; in the kernel mode, if it is determined according to the first variable that the second virtual machine has the right to use the condition variable, obtaining an electronic credential from the fifth variable according to the address of the condition variable, and atomically incrementing the value of the fifth variable; if the electronic credential is equal to the value of the fourth variable, switching back from the kernel mode to the user mode; if the electronic credential is not equal to the value of the fourth variable, causing the current thread in the second virtual machine waiting for the condition variable to enter a sleep state, and atomically incrementing the value of the third variable.

[0008] In conjunction with the first aspect, in some embodiments, the N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, further comprising: if the second virtual machine specifies a timeout threshold, after waiting for the current thread of the condition variable to enter a sleep state in the second virtual machine, if the timeout period for the current thread to be in the sleep state exceeds the timeout threshold, waking up the current thread, returning a timeout flag, and switching back from the kernel mode to the user mode; if the second virtual machine does not specify a timeout threshold, waking up the current thread and switching back from the kernel mode to the user mode until the electronic credential is equal to the value of the fourth variable.

[0009] In conjunction with the first aspect, in some embodiments, the N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, further comprising: an application running on a third virtual machine initiating a system call; responding to the system call, switching from user mode to kernel mode, wherein the third virtual machine is any one of the M virtual machines; in the kernel mode, if it is determined based on the first variable that the third virtual machine has permission to use the condition variable, atomically incrementing the value of the fourth variable by 1; notifying each target virtual machine among the N virtual machines to wake up the thread waiting for the condition variable, wherein the target... The target virtual machine is the virtual machine among the N virtual machines where the number of threads waiting for the condition variable is greater than 0; each target virtual machine determines whether a target thread exists in the target virtual machine, the target thread being the thread holding an electronic certificate whose value is equal to the fourth variable; if the target thread exists, the target thread is woken up; after waking up the target thread, if the target thread's electronic certificate is equal to the value of the fourth variable, the value of the third variable is atomically decremented by 1 and the kernel mode is switched back to the user mode; if the target thread's electronic certificate is not equal to the value of the fourth variable, the target thread remains in a sleep state.

[0010] In conjunction with the first aspect, in some embodiments, each target virtual machine determines whether a target thread exists in the target virtual machine. If the target thread exists, it wakes up the target thread, including: if the target virtual machine is the third virtual machine, and the target thread exists in the third virtual machine, directly waking up each thread in the third virtual machine that is waiting for the condition variable; if the target virtual machine is a virtual machine other than the third virtual machine, an interrupt is triggered by the interrupt number configured for the target virtual machine, so that after receiving the interrupt, the target virtual machine determines whether a target thread exists in the target virtual machine, and wakes up the target thread if it exists. The shared memory stores N interrupt numbers corresponding one-to-one with the N virtual machines, and each interrupt number is used to notify the corresponding virtual machine to wake up the thread waiting for the condition variable.

[0011] In conjunction with the first aspect, in some embodiments, for a virtual machine other than the third virtual machine, before waking up the target thread, the method further includes: determining whether the value of the fourth variable is less than the minimum electronic voucher stored in the linked list, wherein the waiting queue stores the electronic vouchers of each thread waiting for the condition variable; if the value of the fourth variable is less than the minimum electronic voucher stored in the linked list, the target thread remains in a sleep state; if the value of the fourth variable is not less than the minimum electronic voucher stored in the linked list, the target thread is woken up.

[0012] In conjunction with the first aspect, in some embodiments, before switching back from the kernel mode to the user mode, the method further includes: determining whether there are threads waiting for the condition variable; if there are no threads waiting for the condition variable, switching back from the kernel mode to the user mode; if there are threads waiting for the condition variable, waking up all threads waiting for the condition variable and switching back from the kernel mode to the user mode.

[0013] In conjunction with the first aspect, in some embodiments, the method further includes: clearing the values ​​of the corresponding bits of the N virtual machines in the second bitmap in the data structure of the condition variable; and clearing the values ​​of the first variable, the third variable, the fourth variable and the fifth variable in the data structure of the condition variable to zero when the value of each bit in the second bitmap is 0.

[0014] According to a second aspect of the embodiments of this specification, a vehicle infotainment system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the cross-virtual machine communication method described in any embodiment of the first aspect.

[0015] According to a third aspect provided in the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the cross-virtual machine communication method described in any embodiment of the first aspect.

[0016] The one or more technical solutions provided in the embodiments of this specification have at least the following technical effects or advantages:

[0017] A condition variable is created in shared memory by a first virtual machine. The data structure of the created condition variable includes a first variable to specify the N virtual machines that have the right to use the condition variable, and a second variable to record the virtual machines that are currently using the condition variable, where N is less than or equal to M. Each of the N virtual machines other than the first virtual machine obtains the address of the condition variable by passing in the variable name. This realizes cross-virtual machine condition variables. The N virtual machines perform thread synchronization based on cross-virtual machine condition variables to support DDS communication between the N virtual machines, thus realizing DDS communication between virtual machines based on condition variables. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0019] Figure 1A system architecture diagram of the cross-virtual machine communication method according to an embodiment of this specification is shown;

[0020] Figure 2 A flowchart of a cross-virtual machine communication method according to an embodiment of this specification is shown;

[0021] Figure 3 A schematic diagram of a vehicle infotainment system according to an embodiment of this specification is shown. Detailed Implementation

[0022] To better understand the above technical solutions, the technical solutions of the embodiments of this specification will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of this specification and the specific features in the embodiments are detailed descriptions of the technical solutions of the embodiments of this specification, rather than limitations on the technical solutions of this specification. Unless otherwise specified, the embodiments of this specification and the technical features in the embodiments can be combined with each other.

[0023] This specification provides an embodiment of a cross-virtual machine communication method, applied to a vehicle-mounted system running M virtual machines. For example: Figure 1 As shown, the vehicle's infotainment system runs virtual machines VM0 and VM1. These M virtual machines share the same shared memory area, meaning a single memory region is mapped to all M virtual machines so that they can all access the same memory. A Virtual Machine Monitor (VMM), also known as a Hypervisor, creates and manages these M independent virtual machines on the infotainment system. Each virtual machine runs an independent operating system and application. For example, application a runs in virtual machine VM0, and application b runs in virtual machine VM1. The N virtual machines communicate with each other using their respective virtual network drivers and virtual machine managers.

[0024] like Figure 2 As shown in the embodiments of this specification, the cross-virtual machine communication method includes the following steps:

[0025] S201. The first virtual machine creates a condition variable in shared memory. The shared memory is shared by M virtual machines. The data structure of the condition variable includes the variable name of the condition variable, a first variable, and a second variable. The first variable is used to specify the N virtual machines that have the right to use the condition variable, and the second variable is used to record the virtual machines that are currently using the condition variable.

[0026] It should be noted that N is less than or equal to M, and N and M are positive integers.

[0027] In some embodiments, the data structure of the condition variable may further include a third variable, a fourth variable, and a fifth variable. The third variable is used to record the number of threads waiting for the condition variable in each of the N virtual machines; the fourth variable is used to record the thread to which the condition variable belongs in the current iteration; and the fifth variable is used to record the thread to which the condition variable belongs in the next iteration.

[0028] Understandably, in the condition variable data structure, the variable name is of character type. The variable name and the value of the first variable are passed in when the condition variable is created. The second, third, and fourth variables, as well as their values, do not need to be passed in; they are maintained in the kernel. The data types of the first, second, third, fourth, and fifth variables are all integer types.

[0029] The first variable specifies the N virtual machines (VMs) that have permission to use the condition variable; that is, it specifies which VMs out of M VMs can use the condition variable. The first variable is initialized as a first bitmap (vm_bitmap1). Starting from the least significant bit, each bit (each bit is one bit) corresponds to a VM. For example, if two VMs, VM0 and VM1, have permission to use the condition variable, starting from the least significant bit, the first bit (bit0) corresponds to VM0, and the second bit (bit1) corresponds to VM1. To create a condition variable that can be used by both VM0 and VM1, the first bitmap (vm_bitmap) is 0b11, meaning the first bitmap data equals 3. To create a condition variable that can be used by VM0, VM1, and VM2, the first bitmap (vm_bitmap1) is 0b111, meaning the first bitmap data equals 7.

[0030] The second variable is used to record which virtual machines are using the condition variable; that is, which of the N virtual machines are using the condition variable. The second variable is initialized as the second bitmap (vm_bitmap2). Taking three virtual machines, VM0, VM1, and VM3, as an example where they have access to the condition variable, starting from the least significant bit, the first bit (bit0) corresponds to VM0, the second bit (bit1) corresponds to VM1, and the third bit (bit2) corresponds to VM2. If the second bitmap is 0b011, meaning the data is 3, it indicates that virtual machines VM0 and VM1 are using the condition variable, while virtual machine VM2 is not.

[0031] The third variable represents the number of threads waiting for the condition variable in each virtual machine. For example, wait_cnt[0] is 5, which means that there are 5 threads waiting for the condition variable in virtual machine VM0.

[0032] In some embodiments, the step of the first virtual machine creating a condition variable in shared memory may include: the first virtual machine specifying a variable name and a bitmap data, wherein the bitmap data is used to specify the virtual machine with the right to use the condition variable, and the first virtual machine is any one of the M virtual machines; the first virtual machine calling the variable creation interface for creating the condition variable to create an empty structure of the condition variable; the first virtual machine initializing the empty structure according to the variable name specified by the first virtual machine and the passed bitmap data, so as to initialize the first variable as a bitmap; initializing the second variable in the empty structure as a second bitmap, initializing the values ​​of the third and fourth variables to 0, and initializing the value of the fifth variable to 1, wherein initializing the second variable as a second bitmap means setting the bit corresponding to the first virtual machine in the second bitmap to 1, and the other bits to 0; the first virtual machine returning the address of the condition variable so that each virtual machine other than the first virtual machine among the N virtual machines can obtain the address of the condition variable created by the first virtual machine.

[0033] For example, the data structure of the condition variable created by the first virtual machine can be as follows:

[0034] “struct shm_lock_info{

[0035] char name[SHM_MAX_NAME_BYTES]; / / The name of the condition variable

[0036] unsigned int vm_bitmap; / / Records which virtual machines have permission to use condition variables.

[0037] unsigned int use; / / Records which virtual machines are using the condition variable.

[0038] int wait_cnt[SHM_MAX_VM_NUM]; / / Records the number of threads waiting for the condition variable for each virtual machine.

[0039] unsigned int owner; / / Records the current thread to which the condition variable belongs.

[0040] unsigned int next; / / Records the thread to which the condition variable will belong next.

[0041] After the first virtual machine returns the address of the condition variable, step S202 is executed: each of the N virtual machines other than the first virtual machine obtains the address of the condition variable by passing in the variable name.

[0042] In some embodiments, each of the M virtual machines other than the first virtual machine is designated as the current virtual machine. The current virtual machine matches the name to be verified with the name of the condition variable, and verifies whether the current virtual machine has permission to use the condition variable based on the first bit map of the condition variable. If the match is successful and the current virtual machine has permission to use the condition variable, the current virtual machine obtains the address of the condition variable and sets the corresponding bit of the current virtual machine to 1 in the second bit map.

[0043] Below, taking the creation of a condition variable between VM0 and VM1 as an example, the specific implementation of steps S201-S202 for creating a condition variable is as follows:

[0044] Step S201: VM0 specifies the variable name and first bitmap data of the condition variable, calls the interface for creating the condition variable, and creates the shm_lock_info structure of the condition variable in shared memory. The variable name (name) and the first variable (vm_bitmap) of the condition variable are initialized according to the specified values, so that the first variable is initialized to the first bitmap: 0b11; the second variable in the shm_lock_info structure is initialized to the second bitmap: 0b01; the third variable (wait_cnt) and the fourth variable (owner) in the shm_lock_info structure are initialized to 0, and the fifth variable (next) is initialized to 1. Then, VM0 returns the address of the struct vm_lock structure of the condition variable.

[0045] Step S202: VM 1 inputs the name to be verified, calls the matching interface to match the name to be verified with the variable name of the condition variable, and verifies whether VM 1 has the right to use the condition variable based on the first bit diagram in the condition variable. If the name to be verified is the same as the name of the condition variable, and it is verified based on the first bit diagram that VM 1 has the right to use the condition variable, the address of the condition variable is obtained.

[0046] Mutexes are used to protect shared resources, ensuring that only one thread can access the shared resource at a time. Mutexes have two states: locked and unlocked. Locked means that a thread is accessing the shared resource, and other threads must wait until the locked thread unlocks before they can access the shared resource. Read-write locks are a special type of mutex that allows multiple threads to read from a shared resource simultaneously, but only one thread can write to the shared resource at a time. Read-write locks improve concurrent read performance while guaranteeing the atomicity of write operations. Condition variables are used to wait for a condition to be met under the protection of a mutex. Threads can use the `cond wait` method of a condition variable to wait for the condition to be met, and use the `cond signal` or `cond boardcast` methods to wake up other waiting threads.

[0047] S203: N virtual machines perform thread synchronization based on the address of condition variables to support DDS communication between the N virtual machines.

[0048] In some embodiments, N virtual machines synchronize threads based on the address of a condition variable to support DDS communication between the N virtual machines. This includes: synchronizing threads among the N virtual machines based on the address of a condition variable by calling at least two of a first type wait function (cond wait), a second type wait function (cond wait timeout), a first type wake-up function (cond signal), and a second type wake-up function (condboardcast); wherein the first type wait function is used for unconditionally waiting on the condition variable, the second type wait function is used for timed waiting on the condition variable, the first type wake-up function is used to wake up one thread waiting on the condition variable, and the second type wake-up function is used to wake up all threads waiting on the condition variable.

[0049] Since DDS communication relies on condition variables, the embodiments in this specification create a cross-virtual machine condition variable through the above steps S201 to S202, which can be used to realize cross-virtual machine thread synchronization, thereby realizing DDS communication between multiple virtual machines.

[0050] In some embodiments, the implementation of the first type of wait function may include the following steps A1-A5:

[0051] Step A1: The application running on the second virtual machine initiates a system call, and in response to the system call, switches from user mode to kernel mode. The second virtual machine can be any one of the M virtual machines.

[0052] Step A2: In kernel mode, determine whether the second virtual machine has permission to use the condition variable based on the first diagram; if not, return an error; if yes, that is, the second virtual machine has permission to use the condition variable, obtain an electronic ticket based on the address of the condition variable, and the value of the obtained electronic ticket is the value stored in the fifth variable in the condition variable. In other words, obtain the electronic ticket used to authorize the second virtual machine to use the condition variable from the fifth variable.

[0053] Step A3: After obtaining an electronic voucher, perform an atomic increment operation on the value of the fifth variable;

[0054] Step A4: If the obtained electronic voucher is equal to the value of the fourth variable, it indicates that the condition variable was successfully obtained, and then switch from kernel mode back to user mode;

[0055] Step A5: If the obtained electronic voucher is not equal to the value of the fourth variable, it indicates that the condition variable acquisition has failed. The current thread waiting for the condition variable in the second virtual machine enters a sleep state and performs an atomic increment operation on the value of the third variable through an atomic operation.

[0056] It should be noted that atomic operation is a memory operation mechanism provided by the vehicle's infotainment system chip. It can ensure that the memory operation is not interrupted by other CPUs or interrupts. Atomic operation includes atomic read and write operations, atomic addition and subtraction operations, etc. The atomic increment and atomic decrement operations in the embodiments of this specification are atomic addition and subtraction operations.

[0057] The first type of wait function described above can add the current thread in the second virtual machine to the wait queue of the condition variable, causing the current thread in the second virtual machine to be blocked until it is woken up by the condition variable through the first type of wake-up function or the second type of wake-up function.

[0058] In some embodiments, the implementation of the second type of wait function may include the following steps A1-A7, wherein steps A1-A5 are the same as the implementation process of the first type of function:

[0059] Step A1: The application running on the second virtual machine initiates a system call, and in response to the system call, switches from user mode to kernel mode. The second virtual machine can be any one of the M virtual machines.

[0060] Step A2: In kernel mode, determine whether the second virtual machine has permission to use the condition variable based on the first diagram; if it does not have permission to use the condition variable, return an error; if it has permission to use the condition variable, obtain an electronic ticket based on the address of the condition variable. The value of the obtained electronic ticket is the value stored in the fifth variable of the condition variable. In other words, obtain the electronic ticket used to authorize the second virtual machine to use the condition variable from the fifth variable.

[0061] Step A3: After obtaining an electronic voucher, perform an atomic increment operation on the value of the fifth variable;

[0062] Step A4: If the obtained electronic voucher is equal to the value of the fourth variable, it indicates that the condition variable was successfully obtained, and then switch from kernel mode back to user mode;

[0063] Step A5: If the obtained electronic voucher is not equal to the value of the fourth variable, it indicates that the condition variable acquisition has failed. The current thread waiting for the condition variable in the second virtual machine enters a sleep state and performs an atomic increment operation on the value of the third variable through an atomic operation.

[0064] Step A6: If the second virtual machine specifies a timeout threshold, after the current thread waiting for the condition variable in the second virtual machine enters a sleep state, determine whether the duration of the current thread's sleep state exceeds the specified timeout threshold.

[0065] Step A7: If the timeout period for the current thread waiting for the condition variable in the second virtual machine to be in a sleep state exceeds the specified timeout threshold, wake up the current thread waiting for the condition variable in the second virtual machine, return the timeout flag, and switch back from kernel mode to user mode.

[0066] As can be seen, the second type of wait function, compared to the first type, adds a timeout mechanism. It automatically wakes the thread if the timeout period after the current thread enters a sleep state exceeds a specified timeout threshold, even if neither the first nor the second type wake-up function is implemented and the thread is woken by a condition variable, thus preventing indefinite waiting. If the second virtual machine does not specify a timeout threshold, the current thread will only be woken up and switched back from kernel mode to user mode when the electronic certificate equals the value of the fourth variable.

[0067] It should be noted that in the first type of wait function and the second type of wait function, the current thread belongs to the second virtual machine and is the first thread to enter the wait queue of the condition variable. The timing can be strictly guaranteed so that the thread that enters the wait first is awakened first, and the thread that enters the wait later is awakened later.

[0068] In some embodiments, the implementation of the first type of wake-up function may include the following steps B1-B5:

[0069] Step B1: The application running on the third virtual machine initiates a system call, and in response to the system call, switches from user mode to kernel mode. The third virtual machine can be any one of the M virtual machines.

[0070] Step B2: In kernel mode, determine whether the third virtual machine has permission to use the condition variable based on the first graph; if it does not have permission to use the condition variable, return an error; if it has permission to use the condition variable, proceed to step B3.

[0071] Step B3: Perform an atomic increment operation on the value of the fourth variable, and notify each of the N target virtual machines to wake up the threads waiting for the condition variable. The target virtual machine is the virtual machine among the N virtual machines where the number of threads waiting for the condition variable is greater than 0.

[0072] Step B4: For each target virtual machine, determine whether a target thread exists. The target thread is the thread that holds the electronic voucher and the value of the fourth variable. If a target thread exists, wake it up.

[0073] Step B5: After waking up the target thread, if the target thread's electronic certificate is equal to the value of the fourth variable, perform an atomic decrement operation on the value of the third variable and switch back from kernel mode to user mode. If the target thread's electronic certificate is not equal to the value of the fourth variable, keep the target thread in a sleep state.

[0074] It should be noted that before entering a sleep state, each thread waiting for the condition variable in the N virtual machines stores the thread information waiting for the condition variable in a linked list according to the electronic voucher from smallest to largest.

[0075] The first type of wake-up function mentioned above implements the notification to the threads in the waiting queue of the condition variable that when the condition may have been met, it wakes up the threads in the waiting queue of the condition variable, allowing the multiple threads to be woken up to compete for the lock again and check the condition.

[0076] In some embodiments, the implementation of waking up the target thread differs depending on whether the target virtual machine is a third virtual machine:

[0077] If the target virtual machine is a third virtual machine, and the target thread exists in the third virtual machine, then all threads waiting for the condition variable in the third virtual machine are directly woken up. If the target virtual machine is a virtual machine other than the third virtual machine, an interrupt is triggered by the interrupt number configured for the target virtual machine. After receiving the interrupt, the target virtual machine determines whether the target thread exists in the target virtual machine and wakes up the target thread if it exists. In the shared memory, there are N interrupt numbers that correspond one-to-one with N virtual machines. Each interrupt number is used to notify the corresponding virtual machine to wake up the threads waiting for the condition variable.

[0078] It should be noted that each virtual machine has a dedicated interrupt number for condition variable notification. This interrupt number is configured in the virtual machine's device tree source (DTS) file and written into shared memory during initialization. This way, when a virtual machine needs to be notified, it is only necessary to find the interrupt number of the virtual machine to be notified in shared memory and trigger the interrupt to notify the virtual machine.

[0079] In some embodiments, for a virtual machine other than a third virtual machine as the target virtual machine, after determining that a target thread exists but before waking up the target thread, the method further includes: determining whether the value of a fourth variable is less than the minimum electronic voucher stored in the linked list; if the value of the fourth variable is less than the minimum electronic voucher stored in the linked list, the target thread does not need to be woken up; if the value of the fourth variable is not less than the minimum electronic voucher stored in the linked list, the target thread is woken up. By waking up the target thread only when the value of the fourth variable is not less than the minimum electronic voucher stored in the linked list, invalid wake-up overhead can be avoided, and efficiency can be improved.

[0080] In some embodiments, the implementation process of the second type of wake-up function is basically the same as that of the first type of wake-up function. The difference is that before switching from kernel mode back to user mode, it is necessary to determine whether there are threads waiting for the condition variable. If there are no threads waiting for the condition variable, the step of switching from kernel mode back to user mode is performed. If there are threads waiting for the condition variable, all threads waiting for the condition variable are woken up and then the process of switching from kernel mode back to user mode is performed.

[0081] To better understand the implementation process of the second type of wake-up function, the following is a detailed description of the implementation process:

[0082] Step B1: The application running on the third virtual machine initiates a system call, and in response to the system call, switches from user mode to kernel mode. The third virtual machine can be any one of the M virtual machines.

[0083] Step B2: In kernel mode, determine whether the third virtual machine has permission to use the condition variable based on the first diagram; if the third virtual machine does not have permission to use the condition variable, return an error; if the third virtual machine has permission to use the condition variable, proceed to step B3.

[0084] Step B3: Atomically increment the value of the fourth variable by 1; notify each of the N target virtual machines to wake up the thread waiting for the condition variable (threads inside the third virtual machine can be woken up directly, while threads in other virtual machines are woken up by triggering their corresponding interrupts);

[0085] Step B4: After receiving the wake-up interrupt, other virtual machines wake up the interrupt service thread, which in turn wakes up the thread waiting for the condition variable. After the current thread is woken up, it compares the electronic certificate of the current thread with the value in the fourth variable. If they are not equal, the current thread continues to sleep. If they are equal, the value of the corresponding third variable is atomically decremented by 1 and the process returns to step B3 to take over the task of waking up the thread waiting for the condition variable from the third virtual machine.

[0086] Step B5: After executing step B3, the third virtual machine returns from kernel mode to user mode, and the other virtual machines also return from kernel mode to user mode after executing step B3.

[0087] Step B6: If the last awakened thread finds no other threads waiting for condition variables when executing step B3, it does not need to perform a wake-up action and directly returns from kernel mode to user mode.

[0088] In some embodiments, before waking up other virtual machines or the current thread waiting for the condition variable in the current virtual machine in steps B3 and B4, it can also be detected whether the electronic certificate held by the thread is equal to the fourth variable. If they are equal, the current thread is woken up; if they are not equal, the current thread is not woken up, thereby improving efficiency.

[0089] In some embodiments, when the condition variable is no longer needed, the condition variable created by the first virtual machine needs to be destroyed. Destroying the condition variable created by the first virtual machine may include: clearing the values ​​of the corresponding bits of N virtual machines in the second bitmap in the condition variable's data structure; and, if the value of each bit in the second bitmap is 0, clearing the values ​​of the first, third, fourth, and fifth variables in the condition variable's data structure to zero, thereby destroying the condition variable.

[0090] When clearing the values ​​of the corresponding bits of N virtual machines in the second bitmap, the current virtual machine initiates a system call to switch from user mode to kernel mode. The current virtual machine is any one of the N virtual machines. In kernel mode, if it is determined that the current virtual machine has the right to use the condition variable based on the first variable, the value of the corresponding bit of the current virtual machine in the second bitmap is cleared, that is, the value of the corresponding bit of the current virtual machine in the second bitmap is changed from 1 to 0. If every bit in the second bitmap is 0, it indicates that no virtual machine is using the condition variable. Therefore, the values ​​of the first, third, fourth and fifth variables in the condition variable data structure are all cleared to zero, thereby destroying the condition variable.

[0091] If the condition variable is a condition variable between three virtual machines, a second bitmap of 0b000 indicates that no virtual machine is using the condition variable; if the condition variable is a condition variable between two virtual machines, a second bitmap of 0b00 indicates that no virtual machine is using the condition variable.

[0092] The cross-virtual machine communication method provided in the embodiments of this specification achieves cross-virtual machine thread synchronization by creating condition variables between multiple virtual machines, thereby realizing cross-virtual machine DDS communication; and by using a combination of shared memory and atomic operations, cross-virtual machine DDS communication is highly efficient.

[0093] Based on the same inventive concept, this specification also provides an in-vehicle infotainment system. Figure 3 A schematic diagram of the vehicle system in an embodiment of this specification is shown. Figure 3 As shown, the vehicle system includes a memory 304, a processor 302, and a computer program stored in the memory 304 and executable on the processor 302. When the processor 302 executes the computer program, it implements the cross-virtual machine communication method of any of the above embodiments.

[0094] Among them, Figure 3 In this document, a bus architecture (represented by bus 300) is used. Bus 300 may include any number of interconnected buses and bridges, connecting various circuits including one or more processors represented by processor 302 and memory represented by memory 304. Bus 300 may also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 305 provides an interface between bus 300 and receiver 301 and transmitter 303. Receiver 301 and transmitter 303 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 302 is responsible for managing bus 300 and general processing, while memory 304 can be used to store data used by processor 302 during operation.

[0095] Based on the same inventive concept, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cross-virtual machine communication method described in any of the above embodiments.

[0096] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 Devices that specify the functions in one or more boxes.

[0097] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction device, which is implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0098] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0099] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this specification.

[0100] Obviously, those skilled in the art can make various modifications and variations to this specification without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims and their equivalents, this specification is also intended to include such modifications and variations.

Claims

1. A cross-virtual machine communication method, applied to a vehicle-mounted system running M virtual machines, characterized in that, The method includes: The first virtual machine creates a condition variable in shared memory, which is shared by the M virtual machines. The data structure of the condition variable includes the variable name of the condition variable, a first variable and a second variable. The first variable is used to specify the N virtual machines that have the right to use the condition variable, and the second variable is used to record the virtual machines that are using the condition variable. N is less than or equal to M. Each of the N virtual machines, excluding the first virtual machine, obtains the address of the condition variable by passing in the variable name; The N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines.

2. The cross-virtual machine communication method as described in claim 1, characterized in that, The data structure for the condition variable also includes: The third variable is used to record the number of threads in each of the N virtual machines that are waiting for the condition variable; The fourth variable is used to record the thread to which the condition variable belongs in the current iteration; The fifth variable is used to record the thread to which the condition variable will belong next.

3. The cross-virtual machine communication method as described in claim 2, characterized in that, The first virtual machine creates condition variables in shared memory, including: The first virtual machine specifies the variable name and the first bitmap data. The first virtual machine is any one of the M virtual machines. The first bitmap data is used to specify the virtual machine that has the right to use the condition variable. The first virtual machine calls the variable creation interface to create an empty structure for the condition variable; The first virtual machine initializes the variable names of the first variable and the condition variable in the empty structure according to the specified variable name and the first bitmap data, so as to initialize the first variable as a bitmap; The first virtual machine initializes the second variable in the empty structure to a second bitmap, initializes the values ​​of the third and fourth variables to 0, and initializes the value of the fifth variable to 1; The first virtual machine returns the address of the condition variable.

4. The cross-virtual machine communication method as described in claim 3, characterized in that, The N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, including: The application running on the second virtual machine initiates a system call; In response to the system call, the system switches from user mode to kernel mode, and the second virtual machine is any one of the M virtual machines; In the kernel mode, if it is determined from the first bitmap that the second virtual machine has the right to use the condition variable, an electronic certificate is obtained from the fifth variable according to the address of the condition variable, and the value of the fifth variable is atomically incremented by 1; If the electronic certificate is equal to the value of the fourth variable, switch back from kernel mode to user mode; If the electronic certificate is not equal to the value of the fourth variable, the current thread in the second virtual machine that is waiting for the condition variable will enter a sleep state, and the value of the third variable will be atomically incremented by 1.

5. The cross-virtual machine communication method as described in claim 4, characterized in that, The N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, and also include: If the second virtual machine specifies a timeout threshold, after the current thread of the condition variable enters a sleep state in the second virtual machine, if the timeout period of the current thread in the sleep state exceeds the timeout threshold, the current thread is woken up, the timeout flag is returned, and the kernel mode is switched back to the user mode. If the second virtual machine does not specify a timeout threshold, the current thread will be woken up and switched back from the kernel mode to the user mode when the electronic certificate is equal to the value of the fourth variable.

6. The cross-virtual machine communication method as described in claim 2, characterized in that, The N virtual machines perform thread synchronization based on the address of the condition variable to support DDS communication between the N virtual machines, and also include: An application running on a third virtual machine initiates a system call; In response to the system call, the system switches from user mode to kernel mode, wherein the third virtual machine is any one of the M virtual machines; In the kernel mode, if it is determined from the first bitmap that the third virtual machine has permission to use the condition variable, the value of the fourth variable is atomically incremented by 1; Notify each of the N virtual machines to wake up the threads waiting for the condition variable, wherein the target virtual machine is the virtual machine among the N virtual machines in which the number of threads waiting for the condition variable is greater than 0; Each target virtual machine determines whether a target thread exists within it. The target thread is the thread that holds the electronic credential with a value equal to the fourth variable. If the target thread exists, it is woken up. After waking up the target thread, if the target thread's electronic credentials are equal to the value of the fourth variable, perform an atomic decrement operation on the value of the third variable and switch back from the kernel mode to the user mode. If the target thread's electronic credentials are not equal to the value of the fourth variable, keep the target thread in a sleep state.

7. The cross-virtual machine communication method as described in claim 6, characterized in that, Each target virtual machine determines whether a target thread exists within it. If the target thread exists, it is woken up, including: If the target virtual machine is the third virtual machine, and the target thread exists in the third virtual machine, then all threads in the third virtual machine that are waiting for the condition variable are directly woken up. For a virtual machine other than the third virtual machine, an interrupt is triggered by the interrupt number configured for the target virtual machine. After receiving the interrupt, the target virtual machine determines whether a target thread exists in the target virtual machine and wakes up the target thread if it exists. In the shared memory, N interrupt numbers are stored, each corresponding to one of the N virtual machines. Each interrupt number is used to notify the corresponding virtual machine to wake up the thread waiting for the condition variable.

8. The cross-virtual machine communication method as described in claim 7, characterized in that, If the target virtual machine is a virtual machine other than the third virtual machine, before waking up the target thread, the following steps are also included: Determine whether the value of the fourth variable is less than the smallest electronic voucher stored in the linked list. The waiting queue stores the electronic vouchers of each thread waiting for the condition variable. If the value of the fourth variable is less than the smallest electronic voucher stored in the linked list, the target thread continues to sleep. If the value of the fourth variable is not less than the smallest electronic voucher stored in the linked list, wake up the target thread.

9. The cross-virtual machine communication method as described in claim 7, characterized in that, Before switching back from kernel mode to user mode, the following is also included: Determine if there is a thread waiting for the condition variable; If there are no threads waiting for the condition variable, switch back from kernel mode to user mode; If there are threads waiting for the condition variable, then all threads waiting for the condition variable are woken up and the kernel mode is switched back to the user mode.

10. The cross-virtual machine communication method as described in claim 3, characterized in that, The method further includes: In the data structure of the condition variable, clear the values ​​of the corresponding bits of the N virtual machines in the second bitmap; When the value of each bit in the second bitmap is 0, the values ​​of the first, third, fourth, and fifth variables in the data structure of the condition variable are all cleared to zero.

11. A vehicle infotainment system, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the cross-virtual machine communication method according to any one of claims 1-10.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the cross-virtual machine communication method as described in any one of claims 1-10.

Images