为了实现每个月发几篇的目的，这眼见着已是下半个月了，还一个没有呢。没有原创，就拿翻译顶数，力争将Boost.Interprocess部分都翻译出来。 翻译起因，我在boost的目录上飘荡了几个来回，拣感兴趣的看了看，发现这个Boost.Interprocess，这不是俺梦里想要实现的东西吗(现实中没这个能力)，学习学习它，争取在造车的时候用上这个轮子。
Boost.Interprocess does not work only with processes but also with threads. Boost.Interprocess synchronization mechanisms can synchronize threads from different processes, but also threads from the same process.
Boost.Interprocess不仅适合进程也适合线程。 Boost.Interprocess同步机制能够同步不同进 程中的线程，也可以同步同一个进程内的线程。
In the traditional programming model an operating system has multiple processes running and each process has its own address space. To share information between processes we have several alternatives:
在传统的编程模型中操作系统有多个进程同时运行，并且每个进程有它 自己的地址空间。对于在两个进程间共享信息，我们有以下几个办法：
- Two processes share information using a file. To access to the data, each process uses the usual file read/write mechanisms. When updating/reading a file shared between processes, we need some sort of synchronization, to protect readers from writers.
- Two processes share information that resides in the kernel of the operating system. This is the case, for example, of traditional message queues. The synchronization is guaranteed by the operating system kernel.
- Two processes can share a memory region. This is the case of classical shared memory or memory mapped files. Once the processes set up the memory region, the processes can read/write the data like any other memory segment without calling the operating system's kernel. This also requires some kind of manual synchronization between processes.
- 两个进程使用文件(file)共享信息. 为了访问数据，每个进程使用通用的文件read/write 机制，在两个进程之间updating/reading文件时，我们需要一些同步的次序 来保护读操作，免受写操作的干扰。
- 两个进程共享的信息位于操作系统的内核(kernel)中。 这种情况下，比如说，可能是传统的消息队列。同步由操作系统内核来保证。
- 两个进程可以共享一块span class="bold">内存(memory)区域。 这就是传统的共享内存或内存映射文件，一旦进程建立了一块内存区域， 进程就能够读写其中的数据，就跟读写其他内存一样， 不必调用操作系统的内核，这也需要一些进程间的手工同步。
One of the biggest issues with interprocess communication mechanisms is the lifetime of the interprocess communication mechanism. It's important to know when an interprocess communication mechanism disappears from the system. In Boost.Interprocess, we can have 3 types of persistence:
进程间通讯机制的一个最大的问题是进程间通讯机制的生命周期。 了解进程间通讯机制何时从系统中删除是很重要的,在 Boost.Interprocess上们有3种 类型的持久性：
- Process-persistence: The mechanism lasts until all the processes that have opened the mechanism close it, exit or crash.
- Kernel-persistence: The mechanism exists until the kernel of the operating system reboots or the mechanism is explicitly deleted.
- Filesystem-persistence: The mechanism exists until the mechanism is explicitly deleted.
- 进程持久性Process-persistence: 通讯机制一直存在，直到打开这个机制的所有进程关闭它， 或者进程退出，或者进程崩溃掉
- 内核持久性Kernel-persistence: 这个机制一直存在，直到操作系统重新启动，或者这个机制 被明确地删除。
- 文件系统持久性Filesystem-persistence: 这个机制一直存在，知道这个机制被明确地删除。
Some native POSIX and Windows IPC mechanisms have different persistence so it's difficult to achieve portability between Windows and POSIX native mechanisms. Boost.Interprocess classes have the following persistence:
POSIX和windows系统的IPC机制有不同的持久性，所以很难达到在Windows和POSIX系统做到这些机制的可移植性。 Boost.Interprocess 类具有以下持久性：
Table.1 boost.Interprocess Persistence Table
| Mechanism | Persistence |
|---|---|
| Shared memory | Kernel or Filesystem |
| Memory mapped file | Filesystem |
| Process-shared mutex types | Process |
| Process-shared semaphore | Process |
| Process-shared condition | Process |
| File lock | Process |
| Message queue | Kernel or Filesystem |
| Named mutex | Kernel or Filesystem |
| Named semaphore | Kernel or Filesystem |
| Named condition | Kernel or Filesystem |
Table.1 boost.Interprocess 持久性表
| 通讯机制 | 持久性 |
|---|---|
| 共享内存(Shared memory) | 内核或文件系统Kernel or Filesystem |
| 内存映射文件(Memory mapped file) | 文件系统(Filesystem) |
| 进程共享的互斥类型(Process-shared mutex types) | 进程(Process) |
| 进程共享的信号量(Process-shared semaphore) | 进程 |
| 进程共享的条件变量(Process-shared condition) | 进程 |
| 文件锁(File lock) | 进程 |
| 消息队列(Message queue) | 内核或文件系统 |
| 命名互斥量(Named mutex) | 内核或文件系统 |
| 命名信号量(Named semaphore) | 内核或文件系统 |
| 命令条件变量(Named condition) | 内核或文件系统 |
As you can see, Boost.Interprocess defines some mechanisms with "Kernel or Filesystem" persistence. This is because POSIX allows this possibility to native interprocess communication implementations. One could, for example, implement shared memory using memory mapped files and obtain filesystem persistence (for example, there is no proper known way to emulate kernel persistence with a user library for Windows shared memory using native shared memory, or process persistence for POSIX shared memory, so the only portable way is to define "Kernel or Filesystem" persistence).
正如你所见，Boost.Interprocess 定义了一些带有“内核或文件系统”的持久性，这是因为POSIX允许进程间通讯机制 实现这种可能性(既可以是内核持久性，也可以是文件系统持久性)。比如，你可以 用内存映射文件实现共享内存来获得文件系统的持久性。 （我们没有确切的好办法来在Windows系统上，用它的共享内存库模拟实现共享内存的内核 持久性。也不能在POSIX实现进程持久性的共享内存，所以唯一的移植方式是定义 “内核或文件系统”的持久性。
Some interprocess mechanisms are anonymous objects created in shared memory or memory-mapped files but other interprocess mechanisms need a name or identifier so that two unrelated processes can use the same interprocess mechanism object. Examples of this are shared memory, named mutexes and named semaphores (for example, native windows CreateMutex/CreateSemaphore API family).
一些进程间通讯机制是在共享内存或者内存映射文件上创建的匿名对象。 但其他进程间通讯机制需要名称或者标识符，以便两个不相关的进程能使用 这些进程间通讯机制对象。比如，共享内存，命名互斥量，和命名信号量。 （如windows系统的CreateMutex/CreateSemaphore）
The name used to identify an interprocess mechanism is not portable, even between UNIX systems. For this reason, Boost.Interprocess limits this name to a C++ variable identifier or keyword:
用来识别进程间通讯机制的名称是不可移植的，即使是在UNIX系统之间也是如此。 因此Boost.Interprocess，对名称 有限制，要求这些名字为c++变量标识符或关键字。 （想使用uuid格式的名称看来有些困难啊，因为变量名称中不能出现'-'）
- Starts with a letter, lowercase or uppercase, such as a letter from a to z or from A to Z. Examples: Sharedmemory, sharedmemory, sHaReDmEmOrY...
- Can include letters, underscore, or digits. Examples: shm1, shm2and3, ShM3plus4...
Named Boost.Interprocess resources (shared memory, memory mapped files, named mutexes/conditions/semaphores) have kernel or filesystem persistency. This means that even if all processes that have opened those resources end, the resource will still be accessible to be opened again and the resource can only be destructed via an explicit to their static member remove function. This behavior can be easily understood, since it's the same mechanism used by functions controlling file opening/creation/erasure:
命名的Boost.Interprocess资源(共享内存， 内存映射文件，命名互斥量/条件变量/信号量) 具有内核或文件系统的持久性. 这意味着几十所有打开这些资源的进程结束，这些资源还将存在并可以被再次打开(open)和访问， 并且这些资源仅在明确地经由调用它们的静态成员 函数remove来析构。 这个行为很容易理解，因为它使用和文件操作相同的机制，即打开/创建/删除。
Table.2 boost.Interprocess-Filesystem Analogy
| Named Interprocess resource | Corresponding std file | Corresponding POSIX operation |
|---|---|---|
| Constructor | std::fstream constructor | open |
| Destructor | std::fstream destructor | close |
| Member | None. | unlink |
Table.2 boost.Interprocess-Filesystem Analogy文件系统模拟
| 命名的进程间资源(Named Interprocess resource) | 相应的std file (Corresponding std file) | 相应的POSIX操作(Corresponding POSIX operation) |
|---|---|---|
| Constructor | std::fstream constructor | open |
| Destructor | std::fstream destructor | close |
| Member | None. | unlink |
Now the correspondence between POSIX and Boost.Interprocess regarding shared memory and named semaphores:
下面是POSIX 和 Boost.Interprocess的共享内存和命名信号相应的操作:
Table.3 boost.Interprocess-POSIX shared memory
| | POSIX operation |
|---|---|
| Constructor | shm_open |
| Destructor | close |
| Member | shm_unlink |
Table.4 boost.Interprocess-POSIX named semaphore
| | POSIX operation |
|---|---|
| Constructor | sem_open |
| Destructor | close |
| Member | sem_unlink |
The most important property is that destructors of named resources don't remove the resource from the system, they only liberate resources allocated by the system for use by the process for the named resource. To remove the resource from the system the programmer must use remove.
最重要的特点是命名资源的析构函数不从系统中删除资源，而只是释放（还资源以自由）系统分配给进程使用的命名资源。 为了从系统上删除资源，必须调用 remove。
扫一扫
1170
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
