¿Son las llamadas mmap atómicas en su efecto?
Es decir, ¿un cambio de mapeo realizado por mmap aparece atómicamente a otros subprocesos que acceden a la región afectada?
Como prueba de fuego, considere el caso de que haga un mmap en un archivo de todos ceros (desde el subproceso T1 que en este punto es el único subproceso), luego inicie una segunda lectura del subproceso T2 desde la región. Luego, nuevamente en T1 (el subproceso original) haga una segunda llamada mmap para la misma región, reemplazando el mapeo con uno nuevo contra un archivo de todos unos.
¿Es posible que el subproceso del lector lea un uno de alguna página (es decir, vea el segundo mmap en efecto) y luego lea un cero en alguna página (es decir, vea el primer mapeo en efecto)?
Puede suponer que las lecturas en el subproceso del lector están delimitadas correctamente, es decir, que el efecto anterior no se produce únicamente debido a la reordenación del acceso a la memoria del nivel de coherencia/CPU.
El mapeo de memoria ocurre a nivel de proceso y, por lo tanto, todos los subprocesos que forman parte de ese mismo proceso lo ven instantáneamente.
Mmap(2) es atómico con respecto a las asignaciones en todos los subprocesos; en parte, al menos, porque unmap(2) también lo es. Para desglosarlo, el escenario descrito se parece a:
MapRegion(from, to, obj) { Lock(&CurProc->map) while MapIntersect(&CurProc->map, from, to, &range) { MapUnMap(&CurProc->map, range.from, range.to) MapObjectRemove(&CurProc->map, range.from, range.to) } MapInsert(&CurProcc->map, from, to, obj) UnLock(&CurProc->map) } Después de esto, map_unmap debe asegurarse de que, mientras elimina las asignaciones, ningún subproceso pueda acceder a ellas. Observe el Lock(&thisproc->map) .
MapUnMap(map, from, to) { foreach page in map.mmu[from .. to] { update page structure to invalidate mapping } foreach cpu in map.HasUsed { cause cpu to invoke tlb cache invalidation for (map, from, to) } }La primera fase es volver a escribir las tablas de páginas específicas del procesador para invalidar las áreas.
La segunda fase es obligar a cada CPU que alguna vez haya cargado este mapa en su caché de traducción a invalidar ese caché. Este bit depende en gran medida de la arquitectura. En un x86 más antiguo, la reescritura de cr3 suele ser suficiente, por lo que HasUsed es realmente CurrentlyUsing ; mientras que un amd64 más nuevo podría almacenar en caché múltiples identificadores de espacio de direcciones, también lo sería HasUsed . En un ARM, la invalidación de tlb local se transmite al clúster local; por lo que HasUsed se referiría a los ID de clúster en lugar de a los de CPU. Para obtener más detalles, busque tlb shootdown , como se lo conoce coloquialmente.
Una vez que se completan estas dos fases, ningún thread puede acceder a este rango de direcciones. Cualquier intento de hacerlo provocará una falla, lo que hará que el faulting thread bloquee su estructura de mapeo, que ya está bloqueada por el mapping thread , por lo que esperará hasta que se complete el mapeo. Cuando se completa la asignación, todas las asignaciones antiguas se han eliminado y reemplazado por asignaciones nuevas, por lo que no hay forma de recuperar una asignación anterior después de este punto.
¿Qué pasa si otro thread hace referencia al rango de direcciones durante la actualización? Continuará con datos obsoletos o fallará. En este sentido, los datos obsoletos no son una inconsistencia, es como si hubieran sido referenciados justo antes de que el mapping thread hubiera ingresado mmap(2) . El caso de fallo es el mismo que para el faulting thread de fallo anterior.
En resumen, la actualización de las asignaciones se implementa mediante una serie de transacciones que garantizan una vista uniforme del espacio de direcciones. El costo de estas transacciones es específico de la arquitectura. El código para implementar esto puede ser bastante complejo, ya que debe protegerse contra las operaciones implícitas, como la recuperación especulativa, así como contra las explícitas.