升压共享向量的大小不断波动 [英] Size of the Boost shared vector keeps fluctuating
问题描述
我用 A 加速基于共享载体为 IPC 我的应用程序。
在那里我试图读取共享内存的大小应用程序的内存，m_size，或病媒＆GT;大小，保持2之间波动（即我分享向量的数量）和0。我不知道为什么会这样。也许这是一个同步的问题？但即使是这样的话，内存的大小不应该来为0，因为它只是读什么是有在内存中。它可能是无效的（即，旧的数据），但不为0。
In the application where I'm trying to read the shared memory, the size of the memory, m_size, or vector->size, keeps fluctuating between 2 ( i.e. the number of vectors I'm sharing ),and 0. I've no idea why this is happening. Maybe it's a synchronization issue? But even if this is the case, the size of the memory should not come to 0, as it's just reading whatever is there in the memory. It may be invalid ( i.e. old data ), but not 0.
另外，该写入到共享存储器中的应用重复地输出2，作为共享存储器的大小...
Also, the application which writes to the shared memory repeatedly outputs 2, as the size of the shared memory...
这可能是什么错误？
这造成了额外的问题，因为我使用的共享内存的大小，是否有任何的被写在里面。如果这是不正确的，我可以用什么其他的参数呢？
This creates additional problems, as I'm using the size of the shared memory to see if anything's been written inside it. If that is not correct, what other parameter can I use for it?
请告知。
感谢您。
编辑：
应用程序，它写入：
创建
shared_memory_object::remove("MySharedMemory"); // CREATION
m_bIsConnectionActive = false;
srvConnections = new PwServerCheckClass();
managed_shared_memory segment(create_only, "MySharedMemory", 65536);
const ShmemAllocator alloc_inst (segment.get_segment_manager());
vector_to_send = segment.construct<VECTOR_TO_SEND>("VECTOR_TO_SEND")(alloc_inst);
和现在正在写
m_vector_to_send = srvConnections->getServerList(); //Vector whose contents are to be copied into shared vector
for(UINT loopCounter = 0; loopCounter < m_vector_to_send.size(); loopCounter++)
{
SERVER_INFO_TYPE_CHAR TestSrv;
<Some code>
vector_to_send->push_back(TestSrv); //Pushing vector back into shared memory
wcout<<endl<<"Size of the vector is::"<<vector_to_send->size();
}
应用内容是：
阅读：
managed_shared_memory segment(open_only, "MySharedMemory");
m_serverVector = segment.find<VECTOR_TO_SEND>("VECTOR_TO_SEND").first;
//int checkSrvSize = m_serverVector->shrink_to_fit;
if(m_serverVector == NULL)
return;
int SrvSizeCheck = 1;
do
{
if(!(m_serverVector->empty()))
continue;
for(auto it = m_serverVector->begin() ; it != m_serverVector->end() ; ++it, ++SrvSizeCheck)
<Some code>
这里就是行为变得古怪。有时病媒＆GT;空（）满意，尽管一些被写入存储器。有时候，它会过去空（）检查和代替失败它= m_serverVector-＆GT;！到底（）条件。我不知道是怎么打出来的。
Here is where the behaviour becomes odd. Sometimes the vector->empty() is satisfied, though something is being written into the memory. Sometimes it goes past the empty() check and instead fails at the it != m_serverVector->end() condition. I don't know what to make out of it.
编辑2
我看了一下文档。根据它，该信号量部分，实际的互斥与共享存储器相关联。因此，一个结构创建，里面有一个数组，有的sempahores。而最终正是这种结构是在内存中共享。
I took a look at the documentation. According to it, for the semaphore section, the actual mutex is associated with the shared memory. So a struct is created, there is an array inside it, and some sempahores. And eventually it is this structure which is shared in memory.
在我的情况，我在共享共享内存的向量。将同样的原理工作的，即我创建里面载体的结构，非常久远互斥的成员，并在分享吗？在这种情况下，结构被映射，因此内存分配器，将是的结构并不算矢量，作为我在$所做C $ C，是否正确？
In my case, I'm sharing a vector in shared memory. Would the same principle work, i.e. I create a structure with a vector inside it, alongwith the mutex members, and share it across? In this case, the structure to be mapped, and consequently the memory allocator, would be that of the struct and not that of the Vector, as I've done in my code, correct?
请告知。
推荐答案
是的，你似乎没有在任何地方锁定。
Yes, you don't seem to have any locking in place.
进程间共享内存并行的风险突变/访问。为此，您需要锁定。否则，你介绍的数据竞争的这个调用未定义行为按照该C ++标准。
Sharing memory between processes risks concurrent mutation/access. For this you need locking. Otherwise you introduce a data race and this invokes Undefined Behaviour as per the c++ standard.
在事实上 - 在大多数现实生活中你确实需要一个互斥对象锁定共享内存区域的创建（除非你能证明创造是单线程）
In fact - in most real-life situations you'd actually need a mutex locking the creation of the shared memory area (unless you can prove that the creation is single-threaded).
在
- 命名的互斥体（<一个href=\"http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_named_example\" rel=\"nofollow\">http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_named_example)
- 匿名互斥体（<一个href=\"http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_anonymous_example\" rel=\"nofollow\">http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_anonymous_example)
- named mutex (http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_named_example)
- anonymous mutex (http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_anonymous_example)
如果你愿意，你可以使用一个信号量与消息准备通知一个有效的消息队列。见<一href=\"http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.semaphores\"相对=nofollow> BIP旗语
If you want, you can use a semaphore to have an efficient message queue with 'message ready' notification. See BIP Semaphore
最后，您可以使用无锁进入您IFF使用专为此，例如设计了一个lockfree容器<一href=\"http://stackoverflow.com/questions/22207546/shared-memory-ipc-synchronization-lock-free/22209595#22209595\">Shared-memory IPC同步（无锁）
Finally, you can use lock-free access iff you use a lockfree container specifically designed for this, e.g. Shared-memory IPC synchronization (lock-free)
这篇关于升压共享向量的大小不断波动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
