In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-03-27 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/03 Report--
This article mainly introduces "what is inter-process communication". In daily operation, I believe that many people have doubts about what is inter-process communication. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "what is inter-process communication"! Next, please follow the editor to study!
Multi-process collaboration has the following three main advantages.
Modularize the function to avoid repeating the wheel.
Enhance the isolation between modules and provide stronger security.
Improve the fault tolerance of the application.
Inter-process communication (Inter-Process Communication,IPC) is the basis of multi-process cooperation. Generally speaking, IPC requires at least two parties (such as two processes) to participate. According to the direction of information flow, these two parties are often called senders and receivers. In practical use, IPC is often used for service invocation, so the two parties involved in IPC are also called caller and callee, or client and server.
Figure 7-1 is a simple IPC design. It assumes that the kernel has mapped a piece of shared memory for the two processes, and that the shared memory is just enough to hold two messages (sender and receiver messages).
01 important functions of inter-process communication
1. Data transmission
Message passing is a common way of data transmission in IPC, which abstracts the data into individual messages for transmission. Different IPC designs have different message abstractions, and messaging often requires a "middleman" (such as shared memory).
two。 Control flow transfer
When a communication occurs, the kernel switches the control flow from the sender process to the receiver process (the return process is similar). The control flow transfer in IPC is usually realized by using the kernel to control the running state and running time of the process.
02 Classification of interprocess communication
1. One-way IPC, two-way IPC, single / two-way IPC
One-way IPC usually means that messages can only be sent from one end to the other on a connection, while two-way IPC allows both parties to send messages to each other. On the other hand, the one-way / two-way IPC will judge whether it is necessary to support one-way or two-way communication according to the specific configuration options in the communication. In practice, many systems choose single / two-way IPC, which can better support a variety of scenarios. Of course, mechanisms such as pipes and signals that only support one-way IPC are also widely used in practice.
two。 Synchronous IPC and Asynchronous IPC
To put it simply, synchronous IPC means that its IPC operation (such as Send) blocks the process until the operation is complete, while asynchronous IPC is usually non-blocking, and the process can return after initiating one operation without waiting for it to complete.
Synchronous IPC has a better programming abstraction than asynchronous. However, synchronous IPC gradually shows some shortcomings in the development of operating system. A typical problem is concurrency. Generally speaking, most operating system kernels choose to implement synchronous and asynchronous IPC at the same time to meet different application needs.
03 related mechanisms of inter-process communication
1. Timeout mechanism
The timeout mechanism extends the interface of both sides of the IPC communication, allowing the sender / receiver to specify the waiting time for them to send / receive requests. For example, an application can spend 5 seconds waiting for the IPC request processing operation of the file system process. If there is still no feedback for more than 5 seconds, the operating system kernel ends the IPC call and returns a timeout error.
two。 Communication connection management
For the inter-process communication scheme based on shared memory, the communication connection is usually established in the moment of establishing the shared area, while for the communication involving the control flow transfer of the kernel, communication connection management is a very important part of the kernel IPC module.
Although there are different implementations in the actual system, most of them can be classified into two categories-direct communication and indirect communication. Direct communication means that one side of the communication process needs to explicitly identify the other party. Indirect communication needs to be completed through an intermediate mailbox, each mailbox has its own unique identifier, and messages are exchanged by sharing a mailbox between processes.
3. Permission check
Inter-process communication usually depends on a set of permission checking mechanism to ensure the security of the connection. For example, the Capability mechanism in microkernel systems such as seL4 abstracts all communication connections into individual kernel objects. The access rights of each process to the kernel object (and the actions that can be performed on that kernel object) are characterized by Capability.
When a process attempts to communicate with another process, the kernel checks whether the process has a Capability, has sufficient permissions to access a connection object, and that the object points to the target process. Similarly, the macro kernel, such as the Linux system, usually reuses the file permissions of its valid users / groups to depict the permissions of the process on a connection.
4. Naming service
A naming service is like a global Kanban that coordinates information between server and client processes. To put it simply, the server process can tell the naming service process about the services it provides, for example, the file system process can register a "file system service" and the network system process can register a "network service".
On the other hand, the client process can query the current service on the naming service and select the service to which it wants to establish a connection to try to obtain permissions. Whether or not to distribute permissions to the corresponding client process is determined by the naming service and the corresponding server process according to a specific policy.
04 Macro Kernel Interprocess Communication
Typical inter-process communication mechanisms under the macro kernel include pipes, message queues, semaphores, shared memory in System V, Linux signaling mechanism, and socket mechanism (socket).
The communication between processes in the macro kernel operating system is more about the interaction between applications, so the focus of the design is usually on the ease of use and stability of the interface. Figure 7-5 shows a comparison of typical macro kernel inter-process communication mechanisms.
As you can see, although there are similarities and differences in several design perspectives of IPC, the main difference between them is in data abstraction. In practical applications, although a variety of IPC schemes can be used as communication options, applications often choose specific solutions according to the requirements of data abstraction.
05 microkernel inter-process communication
Because of the importance of interprocess communication to the performance of microkernel system, most microkernel operating systems give priority to the design and implementation of interprocess communication from the perspective of performance.
1. Mach: the early design of interprocess communication in microkernel
Mach designs and implements an indirect communication IPC through two basic abstractions, port (port) and message (message): both sides of communication do not need to explicitly specify the other party, but communicate through the port (corresponding to "mailbox"). The data that flows through the port between processes is the message.
As an early micro-kernel system, the performance of Mach system is still not small compared with that of macro-kernel system (such as UNIX) at that time. One of the reasons is that Mach has a complex kernel and a large amount of code in order to achieve a large number of goals, such as clippability, portability and so on. However, Mach's IPC design still had a significant impact on many later systems.
The design of ports and messages in Mach separates the communication between processes and specific processes. As long as a process has a port, it can communicate with the process on the "other side" through that port. Most of the subsequent microkernel system designs take into account the idea of Mach, whether drawing lessons from its design or taking its defects as a warning.
2. L4: a microkernel system designed around the optimization of inter-process communication
Based on the experience of Mach, Liedtke and other researchers began to develop L4 series of microkernel systems. A prominent idea of L4 series microkernel system is that interprocess communication is the core function of microkernel, which needs to be designed and implemented around communication. L4 is still a very mainstream microkernel system, especially the subsequent derivation of a variety of variants and related systems.
In the L4 microkernel, the kernel only retains the basic functions, including address space, threads, inter-process communication, etc., and does not consider the requirements such as compatibility, but chooses to do extreme performance optimization for specific hardware. The advantage of this is that the kernel has a very small amount of code, and a small amount of functionality can be supported as well as possible.
3. LRPC: migrating threading model
Migration Thread (thread migration) is a relatively "extreme" IPC design that optimizes performance. So far, we have learned that most of the work on optimizing IPC performance focuses on two parts: optimizing the performance of control flow switching and optimizing the performance of data transmission.
The migration thread believes that other IPC designs can be seen as sending data that needs to be processed to another process and letting it process it. This is why control flow switching and data transmission are the main bottlenecks.
If, on the other hand, the code of another process processing data is pulled to the current process, can we avoid the switching of the control flow (still processed by the current process) and data transfer (the data is ready in the current process)? The migration thread is designed around this new perspective.
The migration thread scheme is used in LRPC, Mach (optimized version) and other systems, and it is one of the most effective designs in the optimization of pure software inter-process communication. The basic principles for migrating threads are:
Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community
Simplify control flow switching and let client threads execute "server-side code"
Simplify data transfer and share parameter stacks and registers
Simplify interfaces and reduce serialization and other overhead
Optimize concurrency to avoid shared global data structures. Among them, the first two principles are based on the new perspective of "pulling code locally".
The comparison between migration thread IPC and mainstream IPC designs is shown in figure 7-13. To "pull the code locally", the migration thread first needs to decouple the thread structure and identify which parts of the thread play a key role in the processing of communication requests. This part then allows the callee (the logic responsible for handling the request) to run in the caller's context, turning the cross-process call into a more similar form of a function call.
If the migration thread model is used, the kernel does not block the caller thread during interprocess communication, but causes the caller thread to execute the callee's code. The whole process is not awakened by the caller thread, on the contrary, the callee is more like a "code provider".
In addition, the kernel does not do a complete context switch, but only switches the address space (page table) and other system states related to request processing. The thread and priority switching is not involved, and the scheduler is not called. The advantage of migrating threads is that it reduces the time of kernel scheduling and simplifies IPC processing in the kernel. In multi-core scenarios, the migration thread scheme can also avoid the overhead introduced by cross-core communication.
06 case study: Android Binder
In the Android scenario, interprocess communication is actually "remote procedure call" in most cases. The server process is responsible for providing specific services, while the client process initiates the service request through inter-process communication and obtains the results processed by the server process.
In addition to communicating with both parties, a Context Manager process is introduced in Binder IPC. Context Manager provides naming services, and its task is to establish communication connections.
In the kernel design of Binder IPC, an abstraction of handle is provided to represent IPC objects (that is, a communication connection). The handle is actually very similar to the familiar file descriptor, in which the user initiates communication to a specific process through the operation of the handle.
Different from the previous interprocess communication design, the server-side model of "thread pool" is adopted in Binder IPC. In other words, on the server side, the user mode and kernel of Binder will have a concept of response thread pool. When a client process initiates communication, the kernel selects an available thread from the thread pool (on the server side) to respond. This design can better handle concurrent communication requests in the case of synchronous inter-process communication.
At this point, the study on "what is interprocess communication" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 302
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.