|
- UID
- 1029342
- 性别
- 男
|
这样会导致什么问题？
当多个进程都能创建共享内存的时候，如果key出现相同的情况，并且一个进程需要创建的共享内存的大小要比另外一个进程要创建的共享内存小，共享内存大的进程先创建共享内存，共享内存小的进程后创建共享内存，小共享内存的进程就会获取到大的共享内存进程的共享内存， 并修改其共享内存的大小和内容（留意下面的评论补充），从而可能导致大的共享内存进程崩溃。
解决方法：
方法一：
在所有的共享内存创建的时候，使用排他性创建，即使用IPC_EXCL标记：
Shmget(key, size,IPC_CREATE|IPC_EXCL);
在共享内存挂接的时候，先使用排他性创建判断共享内存是否已经创建，如果还没创建则进行出错处理，若已经创建，则挂接：
Shmid = Shmget(key, size,IPC_CREATE|IPC_EXCL);
If (-1 != shmid)
{
Printf("error");
}
Shmid = Shmget(key, size,IPC_CREATE);
方法二：
虽然都希望自己的程序能和其他的程序预先约定一个唯一的键值，但实际上并不是总可能的成行的，因为自己的程序无法为一块共享内存选择一个键值。因此，在此把key设为IPC_PRIVATE，这样，操作系统将忽略键，建立一个新的共享内存，指定一个键值，然后返回这块共享内存IPC标识符ID。而将这个新的共享内存的标识符ID告诉其他进程可以在建立共享内存后通过派生子进程，或写入文件或管道来实现，即这种方法不使用key来创建共享内存，由操作系统来保证唯一性。
ftok是否一定会产生唯一的key值？
系统建立IPC通讯（如消息队列、共享内存时）必须指定一个ID值。通常情况下，该id值通过ftok函数得到。
ftok原型如下：
key_t ftok( char * pathname, int proj_id)
pathname就时你指定的文件名，proj_id是子序号。
在一般的UNIX实现中，是将文件的索引节点号取出，前面加上子序号得到key_t的返回值。如指定文件的索引节点号为65538，换算成16进制为0×010002，而你指定的proj_id值为38，换算成16进制为0×26，则最后的key_t返回值为0×26010002。
查询文件索引节点号的方法是： ls -i
但当删除重建文件后，索引节点号由操作系统根据当时文件系统的使用情况分配，因此与原来不同，所以得到的索引节点号也不同。
根据pathname指定的文件（或目录）名称，以及proj_id参数指定的数字，ftok函数为IPC对象生成一个唯一性的键值。在实际应用中，很容易产生的一个理解是，在proj_id相同的情况下，只要文件（或目录）名称不变，就可以确保ftok返回始终一致的键值。然而，这个理解并非完全正确，有可能给应用开发埋下很隐晦的陷阱。因为ftok的实现存在这样的风险，即在访问同一共享内存的多个进程先后调用ftok函数的时间段中，如果pathname指定的文件（或目录）被删除且重新创建，则文件系统会赋予这个同名文件（或目录）新的i节点信息，于是这些进程所调用的ftok虽然都能正常返回，但得到的键值却并不能保证相同。由此可能造成的后果是，原本这些进程意图访问一个相同的共享内存对象，然而由于它们各自得到的键值不同，实际上进程指向的共享内存不再一致；如果这些共享内存都得到创建，则在整个应用运行的过程中表面上不会报出任何错误，然而通过一个共享内存对象进行数据传输的目的将无法实现。
所以如果要确保key_t值不变， 要么确保ftok的文件不被删除，要么不用ftok，指定一个固定的key_t值。
如果存在生成key_t值的文件被删除过，则很有可能自己现在使用的共享内存key_t值会和另外一个进程的key_t值冲突，如下面这种情况：
进程1使用文件1来ftok生成了key10000，进程2使用文件2来ftok生成了key 11111，此时如果进程1和进程2都需要下载文件，并将文件的内容更新到共享内存，此时进程1和2都需要先下文件，再删掉之前的共享内存，再使用ftok生成新的key，再用这个key去申请新的共享内存来装载新的问题，但是可能文件2比较大，下载慢，而文件1比较小，下载比较慢，由于文件1和文件2都被修改，此时文件1所占用的文件节点号可能是文件2之前所占用的，此时如果下载的文件1的ftok生成的key为11111的话，就会和此时还没有是否11111这个key的进程2的共享内存冲突，导致出现问题。
解决方法：
方法一：
在有下载文件操作的程序中，对下载的文件使用ftok获取key的时候，需要进行冲突避免的措施，如使用独占的方式获取共享内存，如果不成功，则对key进行加一操作，再进行获取共享内存，一直到不会产生冲突为止。
方法二：
下载文件之前，将之前的文件进行mv一下，先“占”着这个文件节点号，防止其他共享内存申请key的时候获取到。
另外：
创建进程在通知其他进程挂接的时候，建议不使用ftok方式来获取Key，而使用文件或者进程间通信的方式告知。
共享内存删除的陷阱？
当进程结束使用共享内存区时，要通过函数 shmdt 断开与共享内存区的连接。该函数声明在 sys/shm.h 中，其原型如下：
#include
#include
int shmdt(const void *shmaddr);
参数 shmaddr 是 shmat 函数的返回值。
进程脱离共享内存区后，数据结构 shmid_ds 中的 shm_nattch 就会减 1 。但是共享段内存依然存在，只有 shm_attch 为 0 后，即没有任何进程再使用该共享内存区，共享内存区才在内核中被删除。一般来说，当一个进程终止时，它所附加的共享内存区都会自动脱离。
我们通过：
int shmctl( int shmid , int cmd , struct shmid_ds *buf );
来删除已经存在的共享内存。
第一个参数，shmid，是由shmget所返回的标记符。
第二个参数，cmd，是要执行的动作。他可以有三个值：
命令 描述
IPC_STAT 设置shmid_ds结构中的数据反射与共享内存相关联的值。
IPC_SET 如果进程有相应的权限，将与共享内存相关联的值设置为shmid_ds数据结构中所提供的值。
IPC_RMID 删除共享内存段。
第三个参数，buf，是一个指向包含共享内存模式与权限的结构的指针，删除的时候可以默认为0。
如果共享内存已经与所有访问它的进程断开了连接，则调用IPC_RMID子命令后，系统将立即删除共享内存的标识符，并删除该共享内存区，以及所有相关的数据结构；
如果仍有别的进程与该共享内存保持连接，则调用IPC_RMID子命令后，该共享内存并不会被立即从系统中删除，而是被设置为IPC_PRIVATE状态，并被标记为”已被删除”（使用ipcs命令可以看到dest字段）；直到已有连接全部断开，该共享内存才会最终从系统中消失。
需要说明的是：一旦通过shmctl对共享内存进行了删除操作，则该共享内存将不能再接受任何新的连接，即使它依然存在于系统中！所以，可以确知， 在对共享内存删除之后不可能再有新的连接，则执行删除操作是安全的；否则，在删除操作之后如仍有新的连接发生，则这些连接都将可能失败！
Shmdt和shmctl的区别：
Shmdt 是将共享内存从进程空间detach出来，使进程中的shmid无效化，不可以使用。但是保留空间。
而shmctl(sid,IPC_RMID,0)则是删除共享内存，彻底不可用，释放空间。 |
|
