¿Cuánta memoria debe asignar 'managed_shared_memory'? (Impulso)

Question

Busco una respuesta definitiva (si es que existe uno) de la cantidad de memoria debe asignarse al crear unos trozos estáticos de memoria compartida a través de boost::interprocess 's managed_shared_memory. Incluso official examples parecen asignar arbitrarily large trozos de memoria.

Considérese la siguiente estructura:

// Example: simple struct with two 4-byte fields 
struct Point2D { 
    int x, y; 
}; 

Mi reacción inicial es que el tamaño necesario sería de 8 bytes, o sizeof(Point2D). Esto falla miserablemente cuando intento construir un objeto, dándome seg-faults en tiempo de ejecución.

// BAD: 8 bytes is nowhere near enough memory allocated. 
managed_shared_memory segment(create_only, "My shared memory", sizeof(Point2D)); 

¿Qué operación de lectura/escritura está causando seg-faults? Operaciones de pila? ¿Asignaciones temporales dentro de segment.construct()? ¿Cuánta sobrecarga es necesaria al asignar memoria compartida?

Por prueba y error Descubrí que multiplicar el tamaño por 4 puede funcionar para la estructura anterior, pero se desmorona cuando empiezo a agregar más campos a mi struct. Entonces, eso apesta a un hack malo.

Algunos podrían argumentar que "la memoria es barata" en la PC moderna, pero estoy en desacuerdo con esta filosofía y no me gusta asignar más de lo que necesito, si puedo evitarlo. Cavé alrededor de los documentos de Boost ayer y no pude encontrar ninguna recomendación. ¡Aquí hay algo de aprendizaje hoy!

Answer 1

De this paragraph de la documentación:

El algoritmo de la memoria es un objeto que se coloca en los primeros bytes de un segmento de archivo memoria compartida/memoria mapeada.

diseño del segmento de memoria:

____________ __________ ____________________________________________ 
|   |   |           | 
| memory | reserved | The memory algorithm will return portions | 
| algorithm |   | of the rest of the segment.    | 
|____________|__________|____________________________________________| 

La biblioteca cuenta con una memoria adicional sobrecarga reunión al comienzo del segmento, por lo que ocupan unos pocos bytes de su tamaño solicitado. De acuerdo con this post y this post, este número exacto de bytes adicionales que no se puede determinar:

no se puede calcular, porque no son memoria bookeeping asignación y problemas de fragmentación que cambian en tiempo de ejecución en función de su asignación /patrón de desasignación. Y de memoria compartida se asigna por páginas por el sistema operativo (4K en 64k Linux en ventanas), por lo que cualquier asignación será en la práctica asignada redondeado a una página :

managed_shared_memory segment(create_only, "name", 20); 

será un desperdicio de la misma memoria que :

managed_shared_memory segment(create_only, "name", 4096); 

Answer 2

Algo así como el uso de las obras de tamaño de página de memoria OS'es. En mi caso, esto funciona ...

off_t size = sizeof(class1) + (sizeof(class2) * 3); 
// round up to the OS page size. 
long page_size = sysconf(_SC_PAGE_SIZE); 
size = ((size/page_size) + (size % page_size ? 1 : 0)) * page_size; 

El uso de boost :: managed_shared_memory le permite construir objetos en el espacio resultante. Algo así como ...

shared_memory_object::remove(m_name.c_str()); 
m_shared.reset(new managed_shared_memory(create_only, "myspace", size)); 
m_class1 = m_shared->construct<class1>("class1")(); 
m_class2 = m_shared->construct<class2>("class2")[3]();