Relación entre los subprocesos de Haskell y los subprocesos de sistema operativo en el GHC
concurrency (1)
Intenté averiguar cómo se asignan los hilos de Haskell (los generados por forkIO ) a los hilos del sistema operativo.
La primera fuente de información que encontré,
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#g:11
Especifica que todos los subprocesos ligeros se ejecutan realmente en un subproceso del sistema operativo y solo cuando un subproceso de Haskell se bloquee con una operación segura de E / S, el tiempo de ejecución de GHC generará un nuevo subproceso del sistema operativo para ejecutar los otros subprocesos de Haskell para que la llamada de E / S no bloquee el programa completo
La segunda fuente de información viene de aquí,
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/using-smp.html
lo que indica claramente que los subprocesos de Haskell se asignan a un número predefinido de subprocesos de sistema operativo creados previamente de forma equilibrada. Eso significa más o menos, que si tengo 80 subprocesos ligeros y pasé la opción + RTS -N 8 al ejecutar mi programa, se crearán al menos 8 subprocesos del sistema operativo y cada subproceso ejecutará 10 subprocesos ligeros. En una máquina con 8 núcleos de CPU que significaría aproximadamente 10 hilos / núcleo de Haskell.
La segunda fuente de información parece ser la más precisa y es este comportamiento exacto el que deseo que el tiempo de ejecución de GHC se manifieste al ejecutar un programa compilado con la bandera de -threaded .
Alguien puede confirmar esto ? Y también, si la segunda versión es la correcta, ¿cuál es el propósito de un subproceso enlazado, uno que se genera con forkOS , es solo para manejar código nativo que usa datos de subprocesos locales?
Los programas compilados sin -threaded utilizan un único subproceso del sistema operativo para ejecutar todos los subprocesos de Haskell. Las llamadas externas bloquearán todos los hilos de ejecución de Haskell.
Los programas compilados con -threaded pueden usar varios subprocesos del sistema operativo para ejecutar varios subprocesos de Haskell en paralelo (el número de subprocesos del sistema operativo puede controlarse mediante la opción +RTS -N ). Las llamadas extranjeras marcadas como safe no bloquearán otros subprocesos Haskell en ejecución (por lo tanto, puede ser beneficioso utilizar -threaded incluso con +RTS -N1 si tiene varios subprocesos Haskell y emitir llamadas externas que pueden llevar mucho tiempo). Las llamadas extranjeras que están marcadas como unsafe se implementan como simples llamadas de función en línea en GHC y bloquearán el hilo del sistema operativo desde el que se llama.
Con respecto a su primera fuente, describe lo que sucede cuando se emite una llamada externa desde el punto de vista de una sola capacidad . Una capability se define como una CPU virtual para ejecutar el código de Haskell, y en el RTS de subprocesos corresponde a una colección de subprocesos del sistema operativo, solo uno de los cuales ejecuta el código de Haskell en cualquier momento (los otros subprocesos del sistema operativo se utilizan para realizar llamadas externas sin bloquear Haskell trapos). Cuando un hilo de Haskell realiza una llamada externa safe , se coloca en la lista de hilos suspendidos y la capacidad se otorga a un hilo de Haskell diferente .
Un hilo de Haskell vinculado tiene un hilo de SO asociado fijo para hacer llamadas externas. Un hilo no vinculado no tiene un hilo de sistema operativo asociado: las llamadas externas desde este hilo se pueden hacer en cualquier hilo de sistema operativo. Los subprocesos enlazados se utilizan para interactuar con las bibliotecas para las que es importante, y las llamadas a la biblioteca se realizan a partir de qué subproceso del sistema operativo, como OpenGL, que almacena su contexto de representación en el estado del subproceso del sistema operativo.
Puede encontrar más información en el manual de GHC y en el siguiente documento:
Ampliación de la interfaz de función extranjera de Haskell con concurrencia
Simon Marlow, Simon Peyton Jones y Wolfgang Thaller, Haskell''04