Data transmission method based on multi-thread IPC message channel
By using the data transmission method of IPC message channel in a multi-threaded environment, data conflicts and deadlock problems caused by multi-threaded access to shared resources are solved, system performance and robustness are improved, and data transmission security and consistency are ensured.
Patent Information
- Application Number
- CN202411285269.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-13
- Publication Date
- 2025-01-07
AI Technical Summary
In a multi-threaded environment, multiple threads may access shared resources at the same time, resulting in data conflicts and race conditions, and may cause deadlocks, which may block thread execution, reduce system performance, and even lead to system crashes.
Using a data transmission method based on multi-threaded IPC message channel, by selecting appropriate IPC mechanisms (such as pipelines, named pipes, message queues, sockets, shared memory), defining message formats, creating IPC objects, and setting access permissions and synchronization Mechanisms to ensure the atomicity and security of data transmission, monitor thread status, detect potential deadlocks, and configure preventive measures.
It significantly improves system performance and response speed, prevents data competition and conditions, ensures the integrity and consistency of shared resources, promptly discovers and responds to potential problems, improves system robustness, and ensures continuous operation and data integrity.
Smart Images

Figure CN119271431A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data transmission, and in particular to a data transmission method based on a multi-threaded IPC message channel. Background Art
[0002] In a complex system architecture, multiple processes or multiple threads are often required to handle tasks in parallel. In order to improve system efficiency and response speed, data exchange and synchronization are required frequently between processes or threads. The IPC message channel provides an efficient and reliable communication mechanism to meet this demand. Compared with traditional file transfer or network request methods, the IPC message channel usually has lower communication latency, and the IPC message channel supports multiple data transmission modes (such as shared memory, message queues, etc.). You can choose the appropriate data transmission method according to the specific application scenario, which can significantly improve the efficiency and throughput of data transmission.
[0003] In a multi-threaded environment, multiple threads may access shared resources at the same time, which may easily lead to data conflicts and competition conditions. In addition, when operating synchronously, threads hold and request resources in a circular waiting manner, which may cause deadlock, thereby blocking the execution of threads, reducing the overall performance of the system, and even causing the system to crash. Therefore, a data transmission method based on a multi-threaded IPC message channel is proposed. Summary of the invention
[0004] To achieve the above objectives, the present invention is implemented through the following technical solutions: a data transmission method based on a multi-threaded IPC message channel, comprising the following steps:
[0005] Step 1: Select the IPC mechanism according to application requirements, define the message format, create an IPC object, and set the corresponding access rights and properties;
[0006] Step 2: Initialize the IPC object, create multiple threads based on task requirements, assign corresponding tasks to each thread, and set up a synchronization mechanism to control access to shared resources;
[0007] Step 3: Lock the shared resources and IPC objects to ensure the atomicity of the sending operation, construct the data message to be sent according to the defined message format, and write the data message into the IPC object;
[0008] Step 4: The receiving thread receives messages from the message channel, polls the IPC object to check whether new messages have arrived, reads messages from the IPC object, implements the message queue reading mechanism, and ensures that the thread can correctly process the received data;
[0009] Step 5: Parse the received message according to the defined message format and execute corresponding tasks or processing logic according to the message content;
[0010] Step 6: Monitor the execution status of threads, analyze the risks of thread execution status, perform risk assessment, detect potential deadlock situations, configure deadlock prevention and recovery measures, and release all occupied resources when the thread ends or the system is shut down.
[0011] Preferably, in step 1, the process of creating an IPC object and setting corresponding access rights and attributes is as follows:
[0012] According to the data sharing requirements, task coordination requirements, performance requirements, and security requirements of the application, a demand analysis is conducted and an IPC mechanism is selected. The IPC mechanisms include: pipes, named pipes, message queues, sockets, and shared memory. Pipes are suitable for communication between processes with affinity. Named pipes allow communication between processes without affinity and support bidirectional transmission of data streams. Message queues allow processes to exchange data asynchronously in the form of messages and are suitable for distributed systems. Sockets provide a network communication interface that can be used for process communication between different hosts. Shared memory allows multiple processes to access the same memory area and is one of the fastest IPC mechanisms, but requires additional synchronization mechanisms to avoid data conflicts.
[0013] Define the message format according to the selected IPC mechanism. The message format includes: message header, message body and message trailer. The message header contains the metadata of the message, such as message type, length, priority, timestamp, etc. The message body is the actual data content, which may be a string, binary data or structured data. The message trailer is used for message integrity verification, such as checksum or end mark.
[0014] According to the selected IPC mechanism and the defined message format, use the API provided by the operating system to create the corresponding IPC object, and determine the access rights of the IPC object according to the security and concurrency requirements of the application. In the process of creating IPC objects, for named pipes, on Windows, you can use the CreateNamedPipe function; on Unix-like systems, you can use the mkfifo command or the posix_mkfifo function; for message queues, in POSIX systems, you can use the mq_open function to create message queues; for sockets, you can use the socket function to create sockets, and prepare for communication through bind and listen (for servers) or connect (for clients); for shared memory, on Windows, you can use CreateFileMapping and MapViewOfFile; on Unix-like systems, you can use functions such as shmget and shmat;
[0015] Set the properties of the IPC object and set the user and group permissions for the IPC object to ensure that only authorized users or processes can access the object;
[0016] Before actual deployment, test the configuration of the IPC object to ensure that it meets the application requirements and can correctly communicate between processes. After the test is completed, integrate the IPC mechanism into the application and deploy it. Record the creation process, configuration details and usage methods of the IPC object to provide a reference for development and maintenance.
[0017] Preferably, in step 2, the process of setting a synchronization mechanism to control access to shared resources is as follows:
[0018] According to the selected IPC mechanism, use the API provided by the operating system to create an IPC object and configure its size and permission attributes;
[0019] Design the tasks that each thread needs to perform, including reading data from the IPC object, processing the data, and writing the results back to the IPC object. Use the multithreading library to create the required number of threads, provide execution functions and parameters for each thread, and each thread will perform a specific task;
[0020] By passing parameters (such as function pointers, lambda expressions, or object methods), specify the tasks that each thread should perform, and assign the designed tasks to the corresponding threads, ensuring that the distribution of tasks can balance the load of the threads and avoid overloading some threads while other threads are idle;
[0021] According to the access requirements of shared resources, a synchronization mechanism is set up. Since multiple threads will access shared resources at the same time, a synchronization mechanism is set up to avoid data competition and condition competition. The synchronization mechanism includes mutex locks, semaphores, condition variables and read-write locks. Mutex locks are used to protect shared resources to ensure that only one thread can access it at the same time. Semaphores are used to control concurrent access to multiple shared resources. Condition variables are used together with mutex locks to allow threads to wait for a condition to be true. Read-write locks allow multiple threads to read shared resources at the same time, but exclusive access is required when writing;
[0022] In the execution function of the thread, for shared resources, a synchronization mechanism is used to access the IPC object to ensure that only one thread can access the resource at the same time to prevent data competition, and call the start function of each thread to execute their respective tasks.
[0023] Preferably, in step 3, the process of locking the shared resources and IPC objects is:
[0024] Before sending data, the thread needs to request a lock to ensure that no other threads interfere when operating shared resources or IPC objects, and construct the data message to be sent according to the defined message format, fill in the message header, and copy the actual data into the message body;
[0025] After acquiring the lock, the message is constructed and the thread sends the data message to the IPC object, copies the byte representation of the data to the IPC mechanism, calls the msgsnd function in the message queue-based IPC, and copies the message to the shared memory area in the shared memory IPC.
[0026] After the send operation is completed, the thread releases the lock so that other threads can access shared resources or IPC objects and perform corresponding error handling or status updates based on the results of the send operation.
[0027] Preferably, in step 4, the process of polling the IPC object is:
[0028] Create one or more threads to receive messages according to system requirements, initialize IPC objects, set the read and write permissions and capacity of the message queue, prepare to enter the polling state, and wait for receiving messages;
[0029] In the receiving thread, a loop is used to continuously check whether there are new messages in the IPC object, and blocking reading is used, that is, the thread goes into a dormant state when there is no message to read, and is awakened when a new message arrives, to improve efficiency;
[0030] Read messages from IPC objects, take data out of the buffer, and parse the message content according to the protocol. Handle errors that occur during the reading process, such as IPC object not ready, read timeout, etc., execute corresponding business logic processing according to the message content, and send a response message to the sender.
[0031] After processing the message, the thread backtracks and continues polling to check if more messages have arrived.
[0032] Preferably, in step 5, the process of executing corresponding tasks or processing logic according to the message content is:
[0033] Waiting for new messages to arrive, the receiving thread takes the message data from the IPC object and checks whether the received message is complete, whether the length of the message meets the expectation, whether the checksum is correct, etc., to ensure that the message has not been damaged or tampered with during transmission;
[0034] The message is verified to be complete and parsed. According to the predefined message format, the message header is extracted from the message to obtain the message metadata, including the message type, length, priority, and timestamp.
[0035] Separate the message body according to the length information in the message header. The message body is the part that actually carries the data. If the message body is in an encoded or serialized format, decode or deserialize it to restore the original data format.
[0036] Perform access control checks based on the message type or sender to ensure that the thread has the right to process the message, and execute corresponding tasks or processing logic based on the message type and content, including data storage, forwarding, calculation or other business logic;
[0037] Update the system status or response based on the result of message processing. If the processing result needs to be fed back to the sender, construct and send a response message, and release temporary resources used in the message processing process.
[0038] Records information related to message processing, including the content of the received message, processing results, and any abnormal conditions, to facilitate problem diagnosis and performance monitoring, and returns the processing results to the caller or notifies other threads and processes.
[0039] Preferably, in step 6, the process of analyzing the risk of the thread execution state and performing risk assessment is as follows:
[0040] Use the API of the thread pool execution class ThreadPoolExecutor to monitor the number of active threads, queued threads, and completed threads in the thread pool, obtain the current status of the thread pool in real time, record logs at the key execution points of each thread to track the execution path and state changes of the thread, monitor CPU usage and memory usage performance indicators to identify potential problems in thread execution;
[0041] Identify resources shared between threads and resources that cause race conditions or deadlocks, analyze dependencies between threads, and identify potential circular wait situations;
[0042] Determine the risk assessment index based on the severity and probability of potential problems, and define the risk level. Analyze the lock contention intensity, number of threads, lock holding time, system load, and thread response time, and evaluate the risk of thread execution status. The risk levels are low risk level, medium risk level, and high risk level, and set corresponding assessment thresholds for each risk level.
[0043] Preferably, the risk assessment index is obtained by calculating the comprehensive lock contention intensity, the number of threads, the lock holding time, the system load, and the thread response time, and its expression is:
[0044]
[0045] Among them, R is the risk assessment index, LC i is the lock contention intensity of the i-th thread, AC iis the lock holding time for the i-th thread, BT i is the total blocked time that thread i has waited, ST i is the system load on the i-th thread, RT i is the response time of the i-th thread, n is the total number of threads, for LC i is for AC i , a higher value means the thread is more likely to face contention and hold resources for a longer time, increasing the risk, BT i and ST i The increase of will reduce the contribution of this item, because long-term blocking and system load may lead to uncertainty and risk in thread execution, RT i As the response time, the increase of its logarithm reflects the impact of the thread response time on risk assessment. The longer the response time, the slower the risk value increases.
[0046] Preferably, multiple said risk levels correspond to multiple said evaluation thresholds, wherein, said evaluation thresholds include an upper threshold and a lower threshold;
[0047] Multiple said risk levels and multiple said evaluation thresholds satisfy the following relationship:
[0048] Low risk level 0 < R < R1; The risk value being in the low risk level indicates that the thread execution state is relatively safe, without immediate concerns, the system runs stably, and resource contention and lock waiting times are short;
[0049] Medium risk level R1 ≤ R < R2; The risk value being in the medium risk level indicates that there are certain risks in the thread execution state, such as increased resource contention and longer lock waiting times, etc. It is necessary to pay attention to system performance indicators and consider optimizing the thread synchronization strategy;
[0050] High risk level R ≥ R2; The risk value being in the high risk level indicates that the thread execution state faces high risks, such as serious resource contention, long lock waiting times or deadlocks, etc. Immediate measures need to be taken, such as optimizing resource allocation, increasing resources, adjusting the thread pool size or redesigning the thread synchronization mechanism;
[0051] Wherein, R is the risk assessment index, R 11 is the lower threshold corresponding to the medium risk level and the upper threshold corresponding to the low risk level, and R2 is the lower threshold corresponding to the high risk level and the upper threshold corresponding to the medium risk level.
[0052] Preferably, step six further includes:
[0053] Use a deadlock detection algorithm for deadlock detection and prevention, detect potential deadlock situations during runtime, and set a timeout for lock operations to avoid indefinite waiting of threads;
[0054] Based on the risk assessment results, configure corresponding deadlock prevention measures and prepare deadlock recovery measures;
[0055] When the thread ends or the system is shut down, all resources allocated by the thread are released, including threads and IPC objects in the thread pool. The Actuator component of Spring Boot is used to dynamically monitor the running status of the thread pool and adjust the thread pool parameters according to the monitoring data to optimize performance.
[0056] The present invention provides a data transmission method based on a multi-threaded IPC message channel, which has the following beneficial effects:
[0057] 1. This data transmission method based on multi-threaded IPC message channel significantly improves the performance and response speed of the system by optimizing thread management and resource utilization. Threads in the thread pool can be reused to reduce the complexity of thread life cycle management. In addition, by reasonably configuring the size of the thread pool, the number of threads is dynamically adjusted according to the system load, while avoiding the context switching overhead caused by too many threads. The efficient resource management mechanism enables the system to respond to external requests and process data more quickly, thereby providing faster response time and higher throughput.
[0058] 2. The data transmission method based on the multi-threaded IPC message channel ensures safe access to shared resources through a synchronization mechanism, prevents data competition and conditional competition problems, and through mutual exclusion locks, read-write locks, and semaphore synchronization tools, the system can ensure that only one thread can access the critical area at any time, thereby protecting the integrity and consistency of shared data.
[0059] 3. The data transmission method based on the multi-threaded IPC message channel can timely discover and respond to potential problems by real-time monitoring of thread status, analyzing performance indicators and risk assessment, identifying resource bottlenecks and performance degradation problems by monitoring performance indicators such as CPU usage and memory usage, predicting the risks of thread execution status through risk assessment, and taking preventive measures. When deadlock or resource competition is detected, corresponding recovery strategies can be adopted to quickly restore to normal status. The active error detection and recovery mechanism improves the robustness of the system and ensures the continuous operation of the system and the integrity of the data. BRIEF DESCRIPTION OF THE DRAWINGS
[0060] Figure 1 A method flow chart of a data transmission method based on a multi-threaded IPC message channel of the present invention;
[0061] Figure 2 The present invention is a flow chart for analyzing the risk of thread execution status and performing risk assessment. DETAILED DESCRIPTION
[0062] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. The embodiments of the present invention are provided for the purpose of illustration and description, and are not intended to be exhaustive or to limit the present invention to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to better illustrate the principles and practical applications of the present invention, and to enable those of ordinary skill in the art to understand the present invention and thereby design various embodiments with various modifications suitable for specific uses.
[0063] The first embodiment, as Figure 1 As shown, the present invention provides a technical solution: a data transmission method based on a multi-threaded IPC message channel, comprising the following steps:
[0064] Step 1. Select an IPC mechanism according to application requirements, define the message format, create an IPC object, set the corresponding access rights and attributes, and perform a demand analysis based on the application's data sharing requirements, task coordination requirements, performance requirements, and security requirements. Select an IPC mechanism, where the IPC mechanism includes: pipes, named pipes, message queues, sockets, and shared memory. Pipes are suitable for communication between processes with affinity, named pipes allow communication between processes without affinity, and support bidirectional transmission of data streams, message queues allow processes to asynchronously exchange data in the form of messages, and are suitable for distributed systems, and sockets provide a network communication interface that can be used for non-affinity processes. Process communication between hosts. Shared memory allows multiple processes to access the same memory area. It is one of the fastest IPC mechanisms, but requires additional synchronization mechanisms to avoid data conflicts. According to the selected IPC mechanism, define the message format. The message format includes: message header, message body and message tail. The message header contains the metadata of the message, such as message type, length, priority, timestamp, etc. The message body is the actual data content, which may be a string, binary data or structured data. The message tail is used for message integrity verification, such as checksum or end mark. According to the selected IPC mechanism and the defined message format, use the API provided by the operating system to create the corresponding IPC object and According to the security and concurrency requirements of the application, determine the access rights of the IPC object. In the process of creating the IPC object, for named pipes, on Windows, you can use the CreateNamedPipe function; on Unix-like systems, you can use the mkfifo command or the posix_mkfifo function. For message queues, in POSIX systems, you can use the mq_open function to create message queues. For sockets, you can use the socket function to create sockets and prepare for communication through bind and listen (for servers) or connect (for clients). For shared memory, on Windows, you can use CreateFileMapping and MapViewOfFile; on Unix-like systems, you can use functions such as shmget and shmat to set the properties of the IPC object and set user and group permissions for the IPC object to ensure that only authorized users or processes can access the object. Before actual deployment, test the configuration of the IPC object to ensure that it meets the application requirements and can correctly communicate between processes. After the test is completed, integrate the IPC mechanism into the application and deploy it. Record the creation process, configuration details and usage methods of the IPC object to provide a reference for development and maintenance.
[0065] Step 2: Initialize the IPC object, create multiple threads based on task requirements, assign corresponding tasks to each thread, and set up synchronization mechanisms to control access to shared resources. According to the selected IPC mechanism, use the API provided by the operating system to create an IPC object and configure its size and permission attributes. Design the tasks that each thread needs to perform, which include reading data from the IPC object, processing data, and writing the results back to the IPC object. Use the multi-threaded library to create the required number of threads, provide execution functions and parameters for each thread, and each thread will perform a specific task. Specify the tasks that each thread should perform by passing parameters (such as function pointers, lambda expressions, or object methods), and assign the designed tasks to the corresponding threads to ensure that the distribution of tasks can balance the load of threads and avoid certain When a thread is overloaded and other threads are idle, a synchronization mechanism is set up according to the access requirements of shared resources. Since multiple threads will access shared resources at the same time, a synchronization mechanism is set up to avoid data competition and condition competition. The synchronization mechanism includes mutex locks, semaphores, condition variables and read-write locks. Mutex locks are used to protect shared resources to ensure that only one thread can access it at the same time. Semaphores are used to control concurrent access to multiple shared resources. Condition variables are used together with mutex locks to allow threads to wait for a condition to be true. Read-write locks allow multiple threads to read shared resources at the same time, but exclusive access is required when writing. In the execution function of the thread, for shared resources, a synchronization mechanism is used to access the IPC object to ensure that only one thread can access the resource at the same time to prevent data competition, and call the start function of each thread to perform their respective tasks;
[0066] Step 3: Lock the shared resources and IPC objects to ensure the atomicity of the sending operation, build the data message to be sent according to the defined message format, and write the data message into the IPC object. Before sending the data, the thread needs to request to acquire the lock to ensure that there will be no interference from other threads when operating on the shared resources or IPC objects, and build the data message to be sent according to the defined message format, fill in the message header, and copy the actual data into the message body. After acquiring the lock, the message construction is completed, and the thread sends the data message to the IPC object, and copies the byte representation of the data into the IPC mechanism. In the IPC based on the message queue, the msgsnd function is called; in the shared memory IPC, the message is copied to the shared memory area, the sending operation is completed, and the thread releases the lock so that other threads can access the shared resources or IPC objects, and perform corresponding error handling or status updates according to the result of the sending operation;
[0067] Step 4. The receiving thread receives messages from the message channel and polls the IPC object to check whether new messages have arrived. It reads messages from the IPC object, implements the message queue reading mechanism, ensures that the thread can correctly process the received data, creates one or more threads responsible for message reception according to system requirements, initializes the IPC object, sets the read and write permissions and capacity of the message queue, prepares to enter the polling state, and waits for receiving messages. In the receiving thread, it continuously checks whether there are new messages in the IPC object through a loop, and uses blocking reading, that is, the thread enters a dormant state when there are no messages to read until it is awakened when a new message arrives, in order to improve efficiency. It reads messages from the IPC object, takes data out of the buffer, and parses the message content according to the protocol, handles errors that occur during the reading process, such as IPC object not ready, read timeout, etc., performs corresponding business logic processing according to the message content, and sends a response message to the sender at the same time. After the message processing is completed, the thread backtracks and continues to poll to check whether more messages have arrived;
[0068] Step 5. Parse the received message according to the defined message format, and execute the corresponding tasks or processing logic according to the message content, wait for the new message to arrive, the receiving thread takes the message data from the IPC object, and checks whether the received message is complete, whether the length of the message meets the expectation, whether the checksum is correct, etc., to ensure that the message has not been damaged or tampered with during transmission. The message is verified to be complete and parsed. According to the pre-defined message format, the message header part is extracted from the message to obtain the message metadata, including the message type, length, priority, and timestamp. According to the length information in the message header, the message body is separated. The message body is the part that actually carries the data. If the message body is coded or sequenced format, decode or deserialize to restore the original data format, perform access control checks according to the message type or sender to ensure that the thread has the right to process the message, and perform corresponding tasks or processing logic according to the message type and content, including data storage, forwarding, calculation or other business logic, update the system status or response according to the result of message processing, if the processing result needs to be fed back to the sender, construct a response message and send it, and release temporary resources used in the message processing process, record relevant information about message processing, including the received message content, processing results and any abnormal conditions, to facilitate problem diagnosis and performance monitoring, and return the processing results to the caller or notify other threads and processes;
[0069] Step 6: Monitor the execution status of threads, analyze the risks of thread execution status, perform risk assessment, detect potential deadlock situations, configure deadlock prevention and recovery measures, and release all occupied resources when the thread ends or the system is shut down.
[0070] The second embodiment is based on the first embodiment. Figure 2As shown, in step 6, the risk of analyzing the thread execution state and the process of risk assessment are as follows:
[0071] Use the API of the thread pool execution class ThreadPoolExecutor to monitor the number of active threads, queued threads, and completed threads in the thread pool, obtain the current state of the thread pool in real time, record logs at the key execution points of each thread to track the execution path and state changes of the thread, monitor CPU usage and memory usage performance indicators to identify potential problems in thread execution, identify resources shared between threads, and resources that cause competition conditions or deadlocks, analyze dependencies between threads, identify potential circular waiting situations, determine risk assessment indexes based on the severity and probability of potential problems, define risk levels, and analyze lock contention. Contention intensity, number of threads, lock holding time, system load, and thread response time are used to evaluate the risk of thread execution status. The risk levels are low risk, medium risk, and high risk, and corresponding assessment thresholds are set for each risk level. Deadlock detection and prevention are performed using a deadlock detection algorithm. Potential deadlock situations are detected during runtime, and a timeout is set for lock operations to prevent threads from waiting indefinitely. Based on the risk assessment results, corresponding deadlock prevention measures are configured and deadlock recovery measures are prepared. When a thread ends or the system is shut down, all resources allocated by the thread are released, including threads and IPC objects in the thread pool. The Actuator component of Spring Boot is used to dynamically monitor the running status of the thread pool, and thread pool parameters are adjusted according to monitoring data to optimize performance.
[0072] Furthermore, the risk assessment index is obtained by calculating the comprehensive lock contention intensity, number of threads, lock holding time, system load, and thread response time, and its expression is:
[0073]
[0074] Among them, R is the risk assessment index, LC i is the lock contention intensity of the i-th thread, AC i is the lock holding time of the i-th thread, BT i is the total blocking time that thread i has been waiting for, ST i is the system load on the i-th thread, RT i is the response time of the i-th thread, n is the total number of threads, for LC i For and AC i ,A higher value means that threads are more likely to face contention and hold ,resources for longer times, increasing the risk of ,BT i and ST i The increase of will reduce the contribution of this term, because long blocking time and system load may lead to uncertainty and risk of thread execution, RTi As the response time, the increase in its logarithm reflects the impact of the thread response time on risk assessment. The longer the response time, the slower the risk value increases. It should be noted that when the value of R tends to 0, it indicates a lower risk; a larger value indicates a higher risk. As each influencing factor increases, the risk value will increase;
[0075] Furthermore, multiple risk levels correspond to multiple evaluation thresholds, where the evaluation thresholds include upper thresholds and lower thresholds;
[0076] The relationship between multiple risk levels and multiple evaluation thresholds is as follows:
[0077] Low risk level: 0 < R < R1; When the risk value is in the low risk level, it indicates that the thread execution state is relatively safe, there is no immediate concern, the system runs stably, and the resource competition and lock waiting time are short;
[0078] Medium risk level: R1 ≤ R < R2; When the risk value is in the medium risk level, it indicates that there are certain risks in the thread execution state, such as increased resource competition and longer lock waiting time. It is necessary to pay attention to system performance indicators and consider optimizing the thread synchronization strategy;
[0079] High risk level: R ≥ R2; When the risk value is in the high risk level, it indicates that the thread execution state faces high risks, such as serious resource competition, long lock waiting, or deadlocks. Immediate measures need to be taken, such as optimizing resource allocation, increasing resources, adjusting the thread pool size, or redesigning the thread synchronization mechanism;
[0080] Among them, R is the risk assessment index, R1 is the lower threshold corresponding to the medium risk level and the upper threshold corresponding to the low risk level, and R2 is the lower threshold corresponding to the high risk level and the upper threshold corresponding to the medium risk level.
[0081] Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art and related fields without creative efforts shall fall within the protection scope of the present invention. Structures, devices, and operation methods not specifically described and explained in the present invention, unless otherwise specified and limited, are implemented according to conventional means in the art.
Claims
1. A data transmission method based on a multi-threaded IPC message channel, characterized in that: The following steps are involved: Step 1: Select the IPC mechanism according to application requirements, define the message format, create an IPC object, and set the corresponding access rights and properties; Step 2: Initialize the IPC object, create multiple threads based on task requirements, assign corresponding tasks to each thread, and set up a synchronization mechanism to control access to shared resources; Step 3: Lock the shared resources and IPC objects, construct the data message to be sent according to the defined message format, and write the data message into the IPC object; Step 4: The receiving thread receives messages from the message channel, polls the IPC object to check whether new messages have arrived, reads messages from the IPC object, and implements the message queue reading mechanism; Step 5: Parse the received message according to the defined message format and execute corresponding tasks or processing logic according to the message content; Step 6: Monitor the execution status of threads, analyze the risks of thread execution status, perform risk assessment, detect potential deadlock situations, configure deadlock prevention and recovery measures, and release all occupied resources when the thread ends or the system is shut down.
2. A data transmission method based on a multi-threaded IPC message channel according to claim 1, characterized in that: In step 1, the process of creating an IPC object and setting corresponding access rights and attributes is as follows: According to the application's data sharing requirements, task coordination requirements, performance requirements, and security requirements, conduct demand analysis and select IPC mechanisms, including pipes, named pipes, message queues, sockets, and shared memory. Define the message format according to the selected IPC mechanism. The message format includes: message header, message body and message trailer. The message header contains the metadata of the message, the message body is the actual data content, and the message trailer is used for message integrity verification. Based on the selected IPC mechanism and the defined message format, use the API provided by the operating system to create the corresponding IPC object, and determine the access rights of the IPC object based on the security and concurrency requirements of the application; Set the properties of the IPC object and set the user and group permissions for the IPC object; Before actual deployment, test the configuration of the IPC object. After the test is completed, integrate the IPC mechanism into the application and deploy it, recording the creation process, configuration details and usage of the IPC object.
3. A data transmission method based on a multi-threaded IPC message channel according to claim 2, characterized in that: In step 2, the process of setting a synchronization mechanism to control access to shared resources is as follows: According to the selected IPC mechanism, use the API provided by the operating system to create an IPC object and configure its size and permission attributes; Design the tasks that each thread needs to perform, including reading data from the IPC object, processing the data, and writing the results back to the IPC object. Use the multithreading library to create the required number of threads and provide execution functions and parameters for each thread. By passing parameters to specify the tasks that each thread should perform, the designed tasks are assigned to the corresponding threads; According to the access requirements of shared resources, a synchronization mechanism is set up, wherein the synchronization mechanism includes a mutex lock, a semaphore, a conditional variable, and a read-write lock; In the execution function of the thread, for shared resources, a synchronization mechanism is used to access the IPC object, and the start function of each thread is called to perform their respective tasks.
4. A data transmission method based on a multi-threaded IPC message channel according to claim 3, characterized in that: In step 3, the process of locking shared resources and IPC objects is as follows: Before sending data, the thread needs to request a lock, build the data message to be sent according to the defined message format, fill in the message header, and copy the actual data into the message body; After acquiring the lock, the message is constructed, the thread sends the data message to the IPC object, copies the byte representation of the data to the IPC mechanism, and calls the msgsnd function in the message queue-based IPC; In shared memory IPC, the message is copied to the shared memory area; After the sending operation is completed, the thread releases the lock and performs corresponding error handling or status update based on the result of the sending operation.
5. A data transmission method based on a multi-threaded IPC message channel according to claim 4, characterized in that: In step 4, the process of polling the IPC object is: Create one or more threads to receive messages according to system requirements, initialize IPC objects, set the read and write permissions and capacity of the message queue, prepare to enter the polling state, and wait for receiving messages; In the receiving thread, a loop is used to continuously check whether there are new messages in the IPC object, and blocking reading is used, that is, the thread goes into sleep mode when there is no message to read, and is awakened when a new message arrives; Read messages from IPC objects, extract data from the buffer, parse the message content according to the protocol, handle errors that occur during the reading process, execute corresponding business logic processing according to the message content, and send a response message to the sender; After processing the message, the thread backtracks and continues polling to check if more messages have arrived.
6. A data transmission method based on a multi-threaded IPC message channel according to claim 5, characterized in that: In step 5, the process of executing corresponding tasks or processing logic according to the message content is as follows: Waiting for a new message to arrive, the receiving thread takes the message data from the IPC object and checks whether the received message is complete; The message is verified to be complete and parsed. According to the predefined message format, the message header is extracted from the message to obtain the message metadata, including the message type, length, priority, and timestamp. Separate the message body according to the length information in the message header. The message body is the part that actually carries the data. If the message body is in an encoded or serialized format, decode or deserialize it to restore the original data format. Perform access control checks based on the message type or sender to ensure that the thread has the right to process the message, and execute corresponding tasks or processing logic based on the message type and content, including data storage, forwarding, calculation or other business logic; Update the system status or response based on the result of message processing. If the processing result needs to be fed back to the sender, construct and send a response message, and release temporary resources used in the message processing process. Records relevant information about message processing, including the content of the received message, processing results, and any exceptions, and returns the processing results to the caller or notifies other threads and processes.
7. A data transmission method based on a multi-threaded IPC message channel according to claim 6, characterized in that: In step 6, the process of analyzing the risk of the thread execution state and performing risk assessment is as follows: Use the thread pool execution class API to monitor the number of active threads, queued threads, and completed threads in the thread pool, obtain the current status of the thread pool in real time, record logs at key execution points of each thread, and monitor CPU usage and memory usage performance indicators to identify potential problems in thread execution; Identify resources shared between threads and resources that cause race conditions or deadlocks, analyze dependencies between threads, and identify potential circular wait situations; Determine the risk assessment index based on the severity and probability of potential problems, and define the risk level. Analyze the lock contention intensity, number of threads, lock holding time, system load, and thread response time, and evaluate the risk of thread execution status. The risk levels are low risk level, medium risk level, and high risk level, and set corresponding assessment thresholds for each risk level.
8. A data transmission method based on a multi-threaded IPC message channel according to claim 7, characterized in that: The risk assessment index is obtained by calculating the comprehensive lock contention intensity, number of threads, lock holding time, system load, and thread response time, and its expression is: Among them, R is the risk assessment index, LC i is the lock contention intensity of the i-th thread, AC i is the lock holding time of the i-th thread, BT i is the total blocking time that thread i has been waiting for, ST i is the system load on the i-th thread, RT i is the response time of the i-th thread, and n is the total number of threads.
9. A data transmission method based on a multi-threaded IPC message channel according to claim 8, characterized in that: A plurality of the risk levels correspond to a plurality of the assessment thresholds, wherein the assessment thresholds include an upper threshold and a lower threshold; The multiple risk levels and the multiple assessment thresholds satisfy the following relationship: Low risk level 0 <R<R1; Medium risk level R1≤R <R2; High risk level R ≥ R2; Among them, R is the risk assessment index, R1 is the lower threshold corresponding to the medium risk level and the upper threshold corresponding to the low risk level, and R2 is the lower threshold corresponding to the high risk level and the upper threshold corresponding to the medium risk level.
10. A data transmission method based on a multi-threaded IPC message channel according to claim 7, characterized in that: The step six also includes: Use deadlock detection algorithms for deadlock detection and prevention, detect potential deadlock situations at runtime, and set timeouts for lock operations to prevent threads from waiting indefinitely; Based on the risk assessment results, configure corresponding deadlock prevention measures and prepare deadlock recovery measures; When the thread ends or the system is shut down, all resources allocated by the thread are released, including threads and IPC objects in the thread pool. The Actuator component of Spring Boot is used to dynamically monitor the running status of the thread pool and adjust the thread pool parameters according to the monitoring data to optimize performance.
Citation Information
Cited By
Water body pollution tracing method and system based on multi-source heterogeneous data analysis
CN121141986A