2012-07-19 27 views
5

Después de pensar en todo el concepto de memoria compartida, surgió una pregunta:Hilo de proceso VS: ¿dos procesos pueden compartir la misma memoria compartida? ¿Pueden dos hilos?

¿Pueden dos procesos compartir el mismo segmento de memoria compartida? ¿Pueden dos hilos compartir la misma memoria compartida?

Después de pensarlo un poco más claro, estoy casi seguro de que dos procesos pueden compartir el mismo segmento de memoria compartida, donde el primero es el padre y el segundo es el hijo, que se creó con fork(), pero ¿Qué hay de dos hilos?

Gracias

Respuesta

10

dos procesos pueden compartir el mismo segmento de memoria compartida?

Sí y no. Normalmente, con los sistemas operativos modernos, cuando otro proceso es forked desde el primero, comparten el mismo espacio de memoria con un conjunto de "copy-on-write" en todas las páginas. Cualquier actualización realizada en cualquiera de las páginas de memoria de lectura/escritura hace que se realice una copia para la página, por lo que habrá dos copias y la página de memoria ya no se compartirá entre el proceso principal y el secundario. Esto significa que solo se compartirán las páginas o páginas de solo lectura que no se hayan escrito.

Si un proceso tiene no sido bifurcado de otro, entonces no comparten ninguna memoria. Una excepción es si está ejecutando dos instancias del mismo programa, entonces pueden compartir code and maybe even static data segments pero no se compartirán otras páginas.

También hay specific memory-map calls para compartir el mismo segmento de memoria. La llamada designa si el mapa es de solo lectura o de lectura-escritura. Cómo hacer esto depende mucho del sistema operativo.

dos hilos pueden compartir la misma memoria compartida?

Ciertamente. Normalmente, todos los subprocesos comparten "todas las memorias dentro de un proceso de subprocesos múltiples". Esa es generalmente la definición de subprocesos en el sentido de que todos se ejecutan dentro del mismo espacio de memoria.

Los subprocesos también tienen la complejidad adicional de tener cached memory segments en la memoria de alta velocidad vinculada al procesador/núcleo. Esta memoria en caché es no compartida y las actualizaciones de las páginas de memoria se descargan en el almacenamiento central dependiendo de las operaciones de sincronización.

+0

Re "Esta memoria en caché no se comparte y las actualizaciones de las páginas de memoria se descargan en el almacenamiento central dependiendo de las operaciones de sincronización": ¿algo bueno o malo? – Pacerier

+0

Re "Los subprocesos también tienen la complejidad adicional de tener segmentos de memoria en caché en la memoria de alta velocidad vinculada al procesador/núcleo": ¿esto es incluso algo del kernel del sistema operativo ?, ¿o simplemente una función de biblioteca de lenguaje de software? – Pacerier

+0

Es algo muy bueno @Pacerier. La memoria caché de la memoria local de la CPU es lo que proporciona la mayor parte del rendimiento que se ve en los programas multiproceso. Esto es compatible con _hardware_, no con el sistema operativo ni el software. El software necesita tener en cuenta los cachés de memoria en términos de barreras de memoria que controlan el enjuague y la actualización, pero suceden automágicamente debido al diseño de la CPU. – Gray

1

Sí, dos procesos se pueden unir a un segmento de memoria compartida. Un segmento de memoria compartida no sería de mucha utilidad si eso no fuera cierto, ya que esa es la idea básica detrás de un segmento de memoria compartida, es por eso que es una de varias formas de IPC (comunicación entre procesos).

Dos subprocesos en el mismo proceso también podrían adjuntarse a un segmento de memoria compartida, pero dado que ya comparten todo el espacio de direcciones del proceso del que forman parte, es probable que no tenga mucho sentido (aunque es probable que alguien ver eso como un desafío para llegar a un caso de uso más o menos válido para hacerlo).

+0

Sospecho más cercano "menos válido" que más :) Por favor, no sugiera a los desarrolladores que hagan cosas aún más extrañas con los hilos, ya es suficientemente malo como lo es

2

En general, un punto importante de los procesos es evitar que se comparta la memoria. Las comunicaciones entre procesos a través de un segmento de memoria compartida son ciertamente posibles en el SO más común, pero los mecanismos no están ahí por defecto. Si no se configura y gestiona correctamente el área compartida, es probable que tenga un segFault/AV si tiene suerte y UB si no.

Los subprocesos que pertenecen al mismo proceso, sin embargo, no tienen dicha memoria de hardware. La protección de administración puede prácticamente compartir lo que quieran, el inconveniente obvio es que pueden dañar casi todo lo que quieran. Nunca he encontrado realmente que esto sea un gran problema, esp. con lenguajes OO modernos que tienden a 'estructurar' punteros como instancias de objetos, (Java, C#, Delphi).

0

En términos generales, cada proceso ocupa un espacio de memoria aislado de todos los demás para evitar interacciones no deseadas (incluidas aquellas que representarían problemas de seguridad). Sin embargo, generalmente hay un medio para que los procesos compartan partes de la memoria. A veces, esto se hace para reducir la huella de RAM ("archivos instalados" en VAX/VMS es/fue uno de esos ejemplos). También puede ser una forma muy eficiente para que los procesos cooperativos se comuniquen. La forma en que se implementa/estructura/gestiona (por ejemplo, padres/hijos) depende de las características proporcionadas por el sistema operativo específico y de las elecciones de diseño implementadas en el código de la aplicación.

Dentro de un proceso, cada subproceso tiene acceso exactamente al mismo espacio de memoria que el resto de subprocesos del mismo proceso. Lo único que tiene un hilo único es el "contexto de ejecución", parte del cual es su pila (aunque nada impide que un hilo acceda o manipule la pila "perteneciente" a otro hilo del mismo proceso).

Cuestiones relacionadas