Linux Funder
  1. Linux Funder
  3. ¿Los hilos del kernel de Linux son realmente processs del kernel?
Intereting Posts
¿Cómo puedo resolver el MAC conociendo el command ipv6 addr w / o ip? ¿Tiene un extremo de una tubería tanto lectura como escritura fd? ¿Cómo forzar al ventilador a girar siempre? ¿Cuál es la diferencia entre "realpath" y "readlink -f" Cómo configurar la date con el formatting Epoch Es seguro ejecutar este command desde / como root Otorgando a los contenedores OVZ su propia IP ¿Cómo se compara el núcleo de Linux con las architectures de microkernel? grep el bloque exacto de líneas (contenido del file1) del file2 Cómo eliminar loggings en function de la frecuencia de interacción de tres vías con awk Eliminar pausas mayores que x del file pcap Múltiples files: filter de command awk Sistema de files corrupto después de la hibernación No se puede hacer que el touchpad funcione El reenvío de X11 falla al cambiar de usuario

¿Los hilos del kernel de Linux son realmente processs del kernel?

He leído en muchos lugares que Linux crea una cadena de kernel para cada subprocess de usuario en una VM Java. (Veo el término "hilo del kernel" usado de dos maneras diferentes:

  1. un hilo creado para hacer el trabajo principal del sistema operativo y
  2. un hilo que el SO conoce y progtwig para realizar el trabajo del usuario.

Estoy hablando del último tipo).

¿Es una cadena del núcleo lo mismo que un process de kernel, ya que los processs de Linux admiten espacios de memory compartida entre padres e hijos, o es realmente una entidad diferente?

No hay absolutamente ninguna diferencia entre un hilo y un process en Linux. Si observa clone (2) , verá un set de indicadores que determinan qué se comparte y qué no se comparte entre los hilos.

Los processs clásicos son solo hilos que no comparten nada; puedes compartir qué componentes quieres en Linux.

Este no es el caso en otras implementaciones del sistema operativo, donde existen diferencias mucho más sustanciales.

Los hilos son processs bajo Linux. Se crean con la llamada al sistema de clone , que devuelve un ID de process al que se puede enviar una señal mediante la llamada al sistema kill , como un process. Los processs de subprocesss son visibles en la salida ps . La llamada de clone se pasa indicadores que determinan qué parte del entorno del process principal se comparte con el process de subprocesss.

La documentation puede ser bastante confusa, así que aquí está el verdadero model de Linux:

  • dentro del kernel de Linux, algo que se puede ejecutar (y progtwigr) se llama un "process",
  • cada process tiene un ID de process (PID) exclusivo del sistema y un ID de grupo de subprocesss (TGID),
  • un process "normal" tiene PID = TGID y ningún otro process comparte este valor de TGID,
  • un process "enhebrado" es un process cuyo valor TGID es compartido por otros processs,
  • varios processs que comparten el mismo TGID también comparten, al less, el mismo espacio de memory y manejadores de señal (a veces más),
  • si un process "enhebrado" tiene PID = TGID, se puede llamar "el hilo principal",
  • llamando a getpid() desde cualquier process devolverá su TGID (= "PID principal" PID),
  • llamando a gettid() desde cualquier process devolverá su PID (!),
  • cualquier tipo de process se puede crear con la llamada al sistema clone(2) ,
  • los nombres numéricos de las carpetas que puede listr con ls /proc como /proc/NUMBER son TGID,
  • los nombres numéricos de las carpetas en /proc/TGID/task como /proc/TGID/task/NUMBER son PID,
  • aunque no vea todos los PID existentes con ls /proc , aún puede hacer cd /proc/any_PID .

Conclusión : desde el punto de vista del núcleo, solo existen processs, cada uno con su propio PID único, y un llamado hilo es simplemente un tipo diferente de process.

Nota: la implementación del concepto "hilo" en Linux ha llevado a una confusión de vocabulario, y si getpid() le miente no hace lo que usted pensaba, es porque su comportamiento sigue la compatibilidad POSIX (se supone que los hilos comparten un PID común).