boost.interprocess共享内存中构建的vector是否具备崩溃安全性？

写入进程在更新vector过程中崩溃时，读取进程大概率无法正常读取该vector，甚至会触发未定义行为

• 首先是共享互斥锁的状态问题
  如果你使用的不是健壮互斥锁（robust mutex），写入进程持有锁的期间崩溃，锁会永久处于锁定状态，读取进程申请锁时会无限阻塞，根本无法访问到vector。就算你用了健壮互斥锁，获取锁时也会收到EOWNERDEAD的错误返回，必须手动调用锁的恢复接口才能继续操作，否则也无法正常访问。
• 其次是vector本身处于不一致的中间态
  vector的更新操作（比如示例代码里的push_back）不是原子操作，会拆分多步执行：检查剩余容量、容量不足时重新申请内存、拷贝原有元素、写入新元素、更新size字段。如果写入进程在任意两步中间崩溃，vector的内部指针（begin、end、capacity对应的指针）会处于不匹配的状态，此时读取要么拿到脏数据，要么直接越界访问触发段错误。
• 还有可能共享内存段本身损坏
  如果崩溃刚好发生在共享内存分配器修改段元数据的阶段，整个共享内存段的管理结构都会损坏，你连vector对象本身的地址都无法正常解析。

• 优先选用健壮互斥锁，获取锁时主动处理EOWNERDEAD返回值，拿到锁后先校验vector的状态合法性：比如end指针 >= begin指针、size值不超过capacity、内部地址都落在共享内存段的合法范围内，校验通过再读取，校验失败就直接销毁重建整个vector或共享内存段。
• 采用事务式更新逻辑：提前在进程本地内存完成所有数据修改，再批量写入共享内存的vector，尽量缩短持有锁的时间，降低崩溃发生在更新中间阶段的概率。
• 可以使用双备份切换方案：在共享内存中维护两份vector，写入进程先更新备用vector，确认写入完成后再原子切换生效指针，哪怕写入过程崩溃，也不会影响正在对外提供读取的主vector。

#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/containers/vector.hpp>
#include <boost/interprocess/allocators/allocator.hpp>
#include <string>

using namespace boost::interprocess;

//Define an STL compatible allocator of ints that allocates from the managed_shared_memory.
//This allocator will allow placing containers in the segment
typedef allocator<int, managed_shared_memory::segment_manager>  ShmemAllocator;

//Alias a vector that uses the previous STL-like allocator so that allocates
//its values from the segment
typedef vector<int, ShmemAllocator> MyVector;

//Create a new segment with given name and size
managed_shared_memory segment(create_only, "MySharedMemory", 65536);

//Initialize shared memory STL-compatible allocator
const ShmemAllocator alloc_inst (segment.get_segment_manager());

//Construct a vector named "MyVector" in shared memory with argument alloc_inst
MyVector *myvector = segment.construct<MyVector>("MyVector")(alloc_inst);

for (int i = 0; i < 100; ++i)  //Insert data in the vector
     myvector->push_back(i);

内容的提问来源于stack exchange，提问作者spockwang