Boost.Interprocess翻译-一些基本概念

为了实现每个月发几篇的目的，这眼见着已是下半个月了，还一个没有呢。没有原创，就拿翻译顶数，力争将Boost.Interprocess部分都翻译出来。 翻译起因，我在boost的目录上飘荡了几个来回，拣感兴趣的看了看，发现这个Boost.Interprocess，这不是俺梦里想要实现的东西吗(现实中没这个能力)，学习学习它，争取在造车的时候用上这个轮子。

Some basic explanations

一些基本概念

Processes And Threads

Sharing information between processes
Persistence
Of Interprocess Mechanisms
Names Of
Interprocess Mechanisms

Constructors, destructors and lifetime of Interprocess named resources

进程和线程

进程间共享信息

进程间通讯机制的持久性

进程间通讯机制的名称

构造函数，析构函数和进程间命名资源的生命周期

Processes And Threads

进程和线程

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同步机制能够同步不同进
程中的线程，也可以同步同一个进程内的线程。

Sharing information between processes

进程间共享信息

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)区域。
这就是传统的共享内存或内存映射文件，一旦进程建立了一块内存区域，
进程就能够读写其中的数据，就跟读写其他内存一样，
不必调用操作系统的内核，这也需要一些进程间的手工同步。

Persistence
Of Interprocess Mechanisms

进程间通讯机制的持久性

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实现进程持久性的共享内存，所以唯一的移植方式是定义
“内核或文件系统”的持久性。

Names Of
Interprocess Mechanisms

进程间通讯机制的名称

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...

Constructors, destructors and lifetime of Interprocess named resources

构造函数，析构函数和进程间命名资源的生命周期

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 remove	None. std::remove	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 remove	None. std::remove	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

shared_memory_object operation	POSIX operation
Constructor	shm_open
Destructor	close
Member remove	shm_unlink

Table.4 boost.Interprocess-POSIX named semaphore

named_semaphore operation	POSIX operation
Constructor	sem_open
Destructor	close
Member remove	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

。