Tema 3: Sistemas Operativos Distribuidos Procesos

(1)

Tema 3: Sistemas Operativos Distribuidos

Procesos

Sistemas Distribuidos Enrique Soriano LS, GSYC 28 de septiembre de 2015

(2)

(cc) 2015 Grupo de Sistemas y Comunicaciones.

-NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, v´ease

http://creativecommons.org/licenses/by-sa/2.1/es. Tambi´en puede solicitarse a Creative Commons, 559 Nathan

(3)

(4)

Procesos

Repaso: ¿Qu´e es un proceso?

I transparencia de concurrencia.

I El OS mantiene una tabla de procesos para almacenar el estado del proceso: los registros de la CPU, la tabla de p´aginas, ficheros abiertos, etc.

I Crear un proceso es caro: crear/copiar los segmentos, inicializar estructuras,

I Cambiar de contexto es caro tambi´en: salvar y cargar los registros de la CPU, invalidar entradas de la TBL, cambiar la tabla de p´aginas...

(5)

Procesos

Threads: su contexto es b´asicamente el estado de la CPU.

I ↓ transparencia de concurrencia ⇒ ↑ complejidad.

I Dos tipos de threads:

I Threads de biblioteca (usuario).

(6)

Threads de biblioteca

I Modelo N-1.

I Cada thread tiene su propio contador de programa y pila.

I El contexto del thread se gestiona ´area de usuario. El OS no sabe nada de los threads.

Thread Thread Thread Thread Thread

Process USERSPACE

(7)

Threads de biblioteca

I Es barato crear, destruir y conmutar threads.

I Los threads no pueden ejecutar en paralelo en un multiprocesador.

I Si se bloquea el proceso se bloquean todos los threads. P. ej. I/O.

(8)

Mecanismo: longjmp y setjmp

i n t s e t j m p ( j m p b u f e n v ) ;

v o i d l o n g j m p ( j m p b u f env , i n t v a l ) ;

I Lo que hay dentro de un jmp buf depende de la arquitectura, no es portable (son detalles internos de la implementaci´on de la Glibc).

I Hay que tener mucho cuidado: no usarlas en manejadores de señales o de salida, no usar después de un salto las variables que pueden haber sido modificadas, no saltar a una función que ha retornado, etc.

I Hay una versión especial para guardar además la máscara de señales: sigsetjmp.

(9)

Mecanismo: getcontext y cia.

Si queremos modificar a mano el contexto de forma portable, debemos usar estas funciones en lugar de setjmp/longjmp:

i n t g e t c o n t e x t ( u c o n t e x t t ∗ ucp ) ; i n t s e t c o n t e x t ( c o n s t u c o n t e x t t ∗ ucp ) ;

v o i d m a k e c o n t e x t ( u c o n t e x t t ∗ ucp , v o i d ( ∗ f u n c ) ( ) , i n t a r g c , . . . ) ; i n t s w a p c o n t e x t ( u c o n t e x t t ∗ oucp , c o n s t u c o n t e x t t ∗ ucp ) ;

I Un ucontext t es an´alogo a un jmp buf, tiene los siguientes campos (entre otros):

I uc link: puntero al siguiente contexto.

I uc stack: informaci´on sobre la pila.

I uc sigmask: m´ascara de se˜nales.

I uc mcontext: contexto, dependiente de m´aquina y debe ser

(10)

Threads de kernel

I Modelo 1-1.

I Los threads son en realidad procesos que comparten memoria (y otras cosas).

I Crear, destruir y conmutar threads m´as caro: hay que entrar al kernel.

I P. ej. Linux 2.6 NPTL (Native Posix Thread Library).

User

Thread ThreadUser ThreadUser ThreadUser ThreadUser

Kernel

Thread ThreadKernel ThreadKernel ThreadKernel ThreadKernel USERSPACE

(11)

Threads de kernel

I Modelo N-M.

I Un proceso puede albergar uno o varios threads.

I Es un modelo h´ıbrido que mezcla las dos aproximaciones anteriores.

User

Thread ThreadUser ThreadUser ThreadUser ThreadUser

Kernel

Thread ThreadKernel ThreadKernel USERSPACE

(12)

Ejemplo M-N: libthread de Plan 9

I Una aplicaci´on puede crear uno o m´as procs, que comparten memoria (segmento de datos y BSS).

I Hay un proc por proceso.

I Un proc puede albergar 1 o m´as threads.

I Los threads son corrutinas colaborativas (non-preemptive).

I Si un proceso se bloquea, se bloquean todos los threads de ese proc.

(13)

Ejemplo M-N: libthread de Plan 9

Process Process Process USERSPACE

KERNEL

PROC PROC

(14)

Ejemplo M-N: SunOS LWP

I Un proceso se compone de un espacio de direcciones y un conjunto de LWPs, que el kernel planificar´a por separado.

I Un thread est´a totalmente representado en espacio de usuario.

I Un LWP es como una CPU virtual para un thread.

I Los LWP planifican los threads sin necesidad de entrar al kernel.

I Si un LWP se bloquea, otro LWP puede ejecutar el resto de threads del proceso. Cada LWP puede hacer llamadas al sistema, tener fallos de p´agina y ejecutar en paralelo independientemente.

(15)

Ejemplo M-N: SunOS LWP

LWP LWP LWP

USERSPACE

KERNEL

(16)

Ejemplo M-N: Go

I Las G (goroutines) son en realidad corutinas colaborativas (threads de usuario).

I Los M (worker thread, machine) son threads de kernel que van ejecutando Gs.

I Los P (logic processor ) son colas de planificaci´on de Gs sobre Ms.

I Los Ps cogen Gs de una cola global.

I Cuando un P se queda sin Gs que ejecutar, se los roba a otro P (balanceo).

I Las llamadas al sistema se manejan de forma especial para evitar bloqueos: la G que se bloquea se queda con el M despu´es de llamar al planificador, que sigue planificando Gs en los otros Ms.

(17)

Ejemplo M-N: Go

G G G G G USERSPACE KERNEL P P M (Kernel Thread) M (Kernel Thread) M (Kernel Thread) G: Goroutine

P: Logic Processor (sched queue) M: Process (kernel thead)

(18)

(19)

Ejecuci´

on remota

Migraci´on de procesos 6= ejecuci´on remota de procesos:

I Cl´asica: rlogin, rexec, ssh, etc.

I Plan 9: cpu.

ssh bash

DISPLAY KEYBOARD AUDIO PRINTER bash sshd stdin stdout stderr mp3player stdin stdout stderr kernel kernel userland userland rc DISPLAY KEYBOARD rc mp3player kernel kernel userland userland AUDIO cpu DATA FILES DATA

FILES FILESDATA

stdout stderr stdin

(20)

Migraci´

on

I Esto es bastante costoso.

I Tipos de movilidad:

I Débil (weak mobility): migración de código.

I Fuerte (strong mobility): migraci´on de procesos.

I Motivos:

I Balancear carga (cpu, red, etc.).

I Acercarse a una fuente de datos.

I Tolerar el fallo parcial de la m´aquina.

I Computaci´on m´ovil.

I Puede ser transparente para la aplicación/usuario (transparencia de migración/relocalización).

(21)

Migraci´

on de procesos

Parar → Capturar proceso → Mover → Continuar ¿Qu´e hay que mover?

I C´odigo: instrucciones. ¿Entorno heterog´eneo?

I Estado: pila, registros, datos privados, PC, etc. Si la infraestructura es distinta, es un problema.

I Endianness.

I Tipos de datos.

(22)

Migraci´

on de procesos

¿Qu´e podemos hacer con la memoria?

Coste inicial vs. Coste en ejecuci´on

I Eager (all): copiar toda la memoria.

I Eager (dirty): copiar s´olo las p´aginas sucias, el resto copiarlas de almacenamiento (no se hace en demanda).

I Copy On Reference (COR): paginación en demanda, reclamando las páginas a la máquina origen.

I Flushing: las p´aginas del proceso van a ´area de intercambio (swap) antes de migrar.

I Precopy: se van copiando las p´aginas sucias de memoria de forma especulativa a otra m´aquina, aunque el proceso no haya migrado todav´ıa.

(23)

Migraci´

on de procesos

Parar → Capturar proceso → Mover → Continuar ¿Qu´e hay que mover?

I Recursos: referencias a dispositivos, conexiones abiertas, descriptores de ficheros, etc. ← dif´ıcil.

La vinculaci´on puede ser m´as fuerte o menos:

I Por identificador (p.ej. URL)

I Por valor (p.ej. libsec.1.12.so)

(24)

Migraci´

on de procesos

I ¿Qu´e podemos hacer con los recursos? Depende de la vinculaci´on:

I Usar una referencia global (p. ej. URL).

I Mover el recurso (p.ej. mover un fichero de log).

I Copiar el valor del recurso (p.ej. copiar una biblioteca).

I Vincular a otro recurso local (p.ej. audio).

(25)

Migraci´

on de procesos: Caso de estudio

Sprite (1990s):

I Home machine: cada usuario tiene una. Da la sensaci´on de que sus procesos ejecutan all´ı, pero no siempre es as´ı.

I Foreign process: un proceso del usuario que se va a ejecutar a otra m´aquina. En el home machine se queda un shadow process que lo representa y mantiene su estado (PID, status de salida, etc).

I Shadow process: transparencia de relocalizaci´on.

(26)

Migraci´

on de procesos: Caso de estudio

Sprite (1990s):

I Kernel-to-Kernel RPCs.

I Llamadas al sistema: algunas en la Home machine (p. ej. time()), otras en la m´aquina remota (p.ej. read()), y otras mediante la cooperaci´on de ambas (p.ej. fork(), exec()).

I Reparto de carga: el demonio migd.

I Transparencia de acceso y localizaci´on: FS ´unico en red.

(27)

¿Hoy en d´ıa?

I Lo más fácil es pausar , migrar y reanudar máquinas virtuales / contenedores completos con el servicio corriendo dentro.

(28)

Bibliograf´ıa

I A. S. Tanenbaum. Operating Systems, design and implementaiton. Pearson Prentice Hill.

I A. S. Tanenbaum. Distributed Systems. Pearson Prentice Hill.

I A. S. Tanenbaum. Modern Operating Systems. Pearson Prentice Hill.

I A. Silberschatz. Operating Systems. Wiley.

I M. L. Powell , S. R. Kleiman , S. Barton , D. Shah , D. Stein , M. Weeks. SunOS Multi-thread Architecture. Winter 1991 USENIX Conference.

I D. S. Milojiˇci´c, F. Douglis, Y. Paindaveine, R. Wheeler, S. Zhou. 2000. Process migration. ACM Comput. Surv. 32, 3, 241-299.

I John K. Ousterhout, Andrew R. Cherenson, Frederick Douglis, Michael N. Nelson and Brent B. Welch, The Sprite Network Operating System, IEEE Computer, 21. 1988.