Boost. interprocess user manual translation 3: some basic explanations (some basic explanations)

Iii. Some basic explanations

Processes and threads Information sharing between processes Inter-process mechanism persistence Inter-process mechanism naming Construction, analysis, and lifecycle of inter-process named Resources License

 

Processes and threads

Boost. interprocess can not only work between processes, but also between threads. The synchronization mechanism of boost. interprocess can synchronize threads between different processes and threads in the same process.

 

Information sharing between processes

In traditional programming mode, an operating system has multiple processes running, and each process has its own address space. To share information between processes, we have the following options:

• The two processes use file sharing information. To obtain data, each process uses a common file read/fetch mechanism. When updating/reading a file shared by a multi-process, we need some synchronization mechanism to protect reading and writing.
• The two processes share information that resides in the operating system kernel. For example, traditional message queues. The synchronization mechanism is maintained by the operating system kernel.
• The two processes share a memory area. This is the common shared memory or memory ing file. Once a process creates a memory area, the process can read/write data like other memory segments without calling the operating system kernel. This method also requires manual synchronization between processes.

Inter-process mechanism persistence

One of the biggest problems with inter-process communication mechanisms is the lifecycles of inter-process communication mechanisms. It is critical to understand when inter-process communication mechanisms disappear from the system. In boost. interprocess, we have three persistence measures:

• Process Persistence:The Mechanism is retained until all processes that open the mechanism are closed, exited, or crashed.
• Kernel Persistence:The Mechanism persists until the operating system kernel is restarted or the mechanism is explicitly deleted.
• File system Persistence:The Mechanism persists until it is explicitly deleted.

Some native POSIX and Windows IPC Mechanisms have different persistence methods, so it is very difficult to achieve compatibility between windows and POSIX local mechanisms.

The boost. interprocess class family has the following persistence methods:

Table 12.1. Boost. interprocess persistence table

Mechanism	Persistence
Shared Memory	Kernel or File System
Memory ing File	File System
Process share mutex type	Process
Process shared semaphores	Process
Process sharing condition variable	Process
File lock	Process
Message Queue	Kernel or File System
Name mutex count	Kernel or File System
Named semaphores	Kernel or File System
Name condition variable	Kernel or File System

As shown above, boost. interprocess defines some mechanisms that use the "kernel or file system" method for persistence. This is because POSIX is possible to allow communication between local processes. For example, you can use a memory ing file to execute shared memory and obtain file system persistence (for example, there is no proper way to use the Windows Shared Memory user library that uses local shared memory to simulate kernel persistence, or for POSIX shared memory process persistence, the only portable way is to define "kernel or file system" persistence .)

 

Inter-process mechanism naming

Some inter-process mechanisms are anonymous objects created in shared memory or memory ing files, but other inter-process mechanisms need a name or definition, so that two unrelated processes can use the same inter-process mechanism object. Examples include shared memory, named mutex, and named semaphores (for example, the createmutex/createsemaphore API family exclusive to Windows ).

Indicates that the name of an inter-process mechanism cannot be transplanted, or even between UNIX systems. For this reason, boost. interprocess limits the name to the C ++ variable identifier or Keyword:

Start with an uppercase or lowercase letter, such as a-Z or a A-Z. Example: sharedmemory, sharedmemory, and sharedmemory.

It can contain letters, underscores, or numbers. Example: shm1, shm2and3, shm3plus4, and so on.

 

Construction, analysis, and lifecycle of inter-process named Resources

The specified boost. interprocess resources (shared memory, memory ing files, and named mutex/conditional variables/semaphores) have the persistence of the kernel or file system. This means that even if all the processes that open these resources are finished, these resources can be opened again, in addition, these resources can only be analyzed explicitly through their static member deletion functions. This line is easy to understand because it uses the same mechanism as the control file opening/creating/deleting function:

Table 12.2. Comparison between boost. interprocess and filesystem

Inter-Process Resource Name	Corresponding STD File	Corresponding POSIX operations
Constructor	STD: fstream Constructor	Open
Destructor	STD: fstream destructor	Close
Member remove	None. STD: Remove	Unlink

The relationship between the shared memory and the named semaphore in POSIX and boost. interprocess

Table 12.3. Boost. interprocess and POSIX shared memory

Shared_memory_object operation	POSIX operations
Constructor	Shm_open
Destructor	Close
Member remove	Shm_unlink

 

Table 12.4. Boost. interprocess and POSIX named semaphores

Named_semaphore operation	POSIX operations
Constructor	Sem_open
Destructor	Close
Member remove	Sem_unlink

The most important feature is the structure of a named resource.The resource is not deleted from the system.They only release resources allocated by the operating system for the resources used by the named resource process.To delete a named resource from the system, the programmer must use the delete function.

 

License

The resources provided by boost. interprocess depend on the platform-related license. The same problem occurs when files are created. If a programmer wants to share shared memory, memory ing files, or a named synchronization mechanism (mutex, semaphores, etc.) among users, these permits must be clarified. It is frustrating that traditional UNIX and Windows licenses are very different, and boost. interprocess does not try to unify these licenses, but does not ignore them.

All the named resource BUILD functions contain an optional license object that can be configured with the Platform relevance license.

Because each mechanism can be simulated by other different mechanisms (a semaphore may be replaced by a ing file or a local semaphore), when the execution mode of the named resource changes, the license type is also different (for example, the synchronization license is required for Windows mutex, but this is different from the file license type ). To avoid this, boost. interprocess depends on the file-like license and requires the file read-write-delete license to enable the named synchronization mechanism (mutex, semaphore, etc) and a suitable read or read-write-delete license for the shared memory. This method has two advantages: it is similar to the Unix principle, and the programmer does not need to know how the name resource is executed.