shared-memory - sistema - que es una memoria compartida

Eliminando memoria compartida con ipcrm en Linux

Question

Estoy trabajando con una aplicación de memoria compartida, y para eliminar los segmentos, uso el siguiente comando:

 ipcrm -M 0x0000162e (this is the key)

Pero no sé si estoy haciendo lo correcto, porque cuando ejecuto ipcs veo el mismo segmento pero con la clave 0x0000000. Entonces, ¿el segmento de memoria realmente se borró? Cuando ejecuto mi aplicación varias veces veo diferentes segmentos de memoria con la clave 0x000000, así:

 key shmid owner perms bytes nattch status
0x00000000 65538 me 666 27 2 dest
0x00000000 98307 me 666 5 2 dest
0x00000000 131076 me 666 5 1 dest
0x00000000 163845 me 666 5 0

¿Qué está sucediendo realmente? ¿El segmento de memoria realmente está borrado?

Editar: El problema fue que, como se menciona a continuación en la respuesta aceptada, que había dos procesos que usaban la memoria compartida, hasta que todo el proceso se cerró, el segmento de memoria no va a desaparecer.

Answer 1

Dijiste que usaste el siguiente comando

ipcrm -M 0x0000162e (this is the key)

Desde la página man para ipcrm

 -M shmkey
Mark the shared memory segment associated with key shmkey for
removal. This marked segment will be destroyed after the
last detach.

Entonces, el comportamiento de las opciones -M hace exactamente lo que usted observó, es decir, establece que el segmento se destruirá solo después de la última separación.

Answer 2

Recuerdo vagamente de mi UNIX (AIX y HPUX, admitiré que nunca he usado memoria compartida en Linux) días en los que la eliminación simplemente marca el bloque como que ya no puede ser conectado por nuevos clientes.

Solo se eliminará físicamente en algún momento después de que no haya más procesos asociados.

Esto es lo mismo que con los archivos normales que se eliminan, su información de directorio se elimina pero el contenido del archivo solo desaparece después de que el último proceso lo cierra. Esto a veces lleva a archivos de registro que ocupan más y más espacio en el sistema de archivos incluso después de que se eliminan ya que los procesos todavía están escribiéndoles, una consecuencia de la "separación" entre un puntero de archivo (cero o más entradas de directorio señalando a un inodo) y el contenido del archivo (el inodo mismo).

Puede ver en su salida de ipcs que 3 de los 4 todavía tienen procesos conectados, por lo que no irán a ningún lado hasta que esos procesos se separen de los bloques de memoria compartida. El otro probablemente esté esperando una función de ''barrido'' para limpiarlo, pero eso, por supuesto, dependería de la implementación de la memoria compartida.

Un cliente bien escrito de la memoria compartida (o archivos de registro para el caso) debe volver a adjuntar (o renovar) periódicamente para garantizar que esta situación sea transitoria y no afecte al funcionamiento del software.