[Solar-tecnica] Algo de teoria de procesos

Lun Nov 26 17:41:21 CET 2007

Les adjunto un resumen de procesos en Unix, que realice en el día de hoy. Espero les
sirva.

 Saludos.

Hernán López Pardo
http://otrodiaparaser.blogspot.com
---------------------------------------------------------------------
"La ciencia no tiene patria, pero el hombre de ciencia si"
BERNARDO A. HOUSSAY - (1887-1971)

      Compartí video en la ventana de tus mensajes (y también tus fotos de Flickr). 
Usá el nuevo Yahoo! Messenger versión Beta. http://ar.beta.messenger.yahoo.com/
------------ próxima parte ------------
PROCESOS EN UNIX

	Ha llegado el momento de profundizar en el kernel y examinar más de cerca los conceptos básicos que maneja UNIX, es decir, procesos,memoria, el sistema de archivos y entrada/salida. Estos conceptos son importantes porque los manipulan las llamadas al sistema. Por ejemplo, hay llamadas al sistema para crear procesos, asignar memoria, abrir archivos y efectuar E/S.
	Por desgracia, al existir tantas versiones de UNIX es inevitable que haya algunas diferencias entre ellas. En este capítulo haremos énfasis en las funciones comunes a todas las versiones, sin concentrarnos en una específica. Por lo tanto, en ciertas secciones es posible que la explicacioón no sea igual de válida para todas las versiones.

CONCEPTOS FUNDAMENTALES

	Las únicas entidades activas de un sistema UNIX son los procesos. Cada proceso ejecuta un solo programa y en un principio tiene un solo subproceso de control. Dicho de otro modo, tiene un contador de programa., que indica cuál instrucción se ejecutará a continuación. Casi todas las versiones de UNIX permiten a un proceso crear subprocesos adicionales  una vez que comienza a ejecutarse.
	UNIX es un sistema de multiprogrmación, asi que cabe la posibilidad de que multiples procesos independientes se estén ejecutando al mismo tiempo. Cada usuario podria tener varios procesos activos en un momento dado, por lo que en un sistema grande podrian estarse ejecutando cientos o incluso miles de procesos. De hecho, en la mayoria de las estaciones de trabajo monousuario, incluso cuando el usuario está ausente, se ejecutan docenas de procesos en segundo plano, llamados demonios (daemons). Éstos se inician en forma automática cuando se arranca el sistema. (Se usa demonio por su connotación de espíritu maligno qu trabaja por su cuenta).
	Un demonio representativo es cron, que se activa cada minuto para ver si tiene trabajo. Si lo tiene, lo efectúa, y luego se desactiva otra vez hata la siguiente verificación. 
	Este demonio es necesario porque en UNIX es posible calendarizar actividades a realizar en minutos, horas, días o incluso meses en el futuro. 
	El demonio cron también sirve para inicia actividades periódicas, como efectuar respaldos de disco diarios. Otros demonios se encargan del correo electrónico enviado y recibido, administran la cola de la impresora, verifican si hay suficientes páginas libres en la memoria, etc. La implementación de los demonios e sencilla en UNIX porque cada uno es un proceso individual, independiente de todos los demás.
	La creación de procesos en UNIX es excepcionalmente sencilla. La llamada al sistema fork (bifurcarse) crea una copia exacta del proceso original. El proceso que se bifurcó se donomina  proceso padre ; el nuevo es el proceso hijo. Tanto el padre como el hijo tienen su propia imagen de memoria privada. Si el padre cambia después calquiera de sus variables, el hijo no verá los cambios y viceversa.
	El padre y el hijo comparte los archivos que estén abiertos. Es decir , si cierto archivo estaba abierto en el padre antes del fork, seguirá estando abierto después, tanto en el padre como en el hijo. Los cambios efectuados al archivo por cualquiera de ellos serán visibles para el otro. Este comportamiento es razonable porque dichos cambios también serán visibles apara cualquier proceso no relacionado que abra el archivo.
	El hecho de que las imágenes de memoria, variables, registros y todo los demás sean idénticos en el padre y el hijo da pie a una pequeña dificultad: ¿cómo saben los procesos cuál de ellos debe ejecutar el código del padre y cuál el código del hijo?. El secreto es que la llamada al sistema fork ; devuelve un 0 al hijo y un valor distinto de cero, el  identificador de proceso ó PID, al padre. Lo norma es que ambos procesos verifiquen el valor devuelto y actúen de manera acorde, como se muestra en la figura 10-4.
	El nombre de un proceso es su PID. Cuando se crea un proceso, el padre recibe el PID del hijo, como ya dijimios. Si el hijo quiere conocer su propio PID, hay una llamada al sistema, getpid, que lo proporciona. Los PID´s se usan en varias maneras. Por ejemplo, cuando un hijo termina, el padre recibe el PID del hijo que acaba de terminar. Esto puede ser importante porque un padre podria tener muchos hijos. Puesto que los hijos también pueden tener hijos, un proceso original puede generar todo un árbol de hijos, nietos y demas descendientes.
	Los procesos en UNIX pueden comunicarse entre si empleando una forma de transferencia de mensajes. Es posible crear un canal entre dos procesos en elq ue un proceso pueda escribir un flujo de bytes para que el otro lo lea. Estos canales se denominan canalizaciones. Puede haber sincronización porque cuando un proceso trata de leer de una canalización vacia se bloquea hasta que haya datos.

				pid = fork();		/*si fork se logra, pid>0 en el padre */
				if (pid < 0);		
					handle_error( );	/*fork falló (por ejemplo, memoria ó tabla llena */
				} else if (pid > 0) ; {
							/*el código del padre va aqui. /*/
				} else {			
							/*el código del hijo va aqui. /*/
				}

					FIGURA 10-4 Creación de procesos en UNIX.

	Las canalizaciones del shell se implementan asi. Cuando el  shell  ve una linea como 

sort <f | head

crea dos procesos,  sort y head, y establece una canalización entre ellos de foma que la salida estándar de sort se conecte con la entrada estándar de  head. Así, todos los datos que  sort escriba se envian de manera directa a  head , en vez de enviarse a un archivo. Si la canalizacón se llena, el sistema dejará de ejeutar sort  hasta que  head haya retirado datos de ella.
	Los procesos también pueden comunicarse de otra manera: con interrupciones de software. Un proceso puede enviar una señal  a otro proceso. Los procesos pueden indicarle al sistema qué quieren que suceda cuando llegue una señal. Las opciones son: ignorlarla, atraparla o dejar que la señal elimine al proceso. Si un proceso opta por atrapar las señales que le envien, debe especificar un procedimiento de manejo de señales. Cuando llegue la señal, el control pasará de inmediato al manejador. Al terminar y regresar el manejador, el control vuelve al punto dende estaba antes de la señal, como sucede con las interrupciones de E/S  por hardware. Un proceso sólo puede enviar señales a miembros de su grupos de procesos, que consta de su padre, hermanos e hijos. Un proceso también puede enviar una señal a todos los miembros de su grupo de procesos con una sola llamada al sistema.
	Las señales también se usan con otros fines. Por ejemplo, si un proceso está efectuando operaciones aritméticas de punto flotante, y sin querer divide entre cero; obtiene una señal SIGPFE (exepción de punto flotante). Las señales que exige POSIX se enumeran en la figura 10-5. Muchos sistemas UNIX tiene además otras señales, pero los programas que las usan podrian no ser trasladables a otras versiones de UNIX.

			SEÑAL				CAUSA
			SIGABRT			Enviada para abortar un proceso y realizar un vaiado de memoria.
			SIGALRM			El relojo de alarma "sonó"
			SIGFPE			Hubo un error de punto flotante
			SIGHUP			Se colgó la linea elefónica que usaba el proceso
			SIGILL				Elusuario oprimió SUPR para interrumpir el proceso
			SIGQUIT			El usuario oprimioó la tecla que pide un vaciado de memoria.
			SIGKILL			Enviada para elminar un proceso
			SIGPIPE			El proceso escribió en una canalización que no tieene lectores
			SIGSEGV			El proceso hizo referencia a una dirección de momoria no válida
			SIGTERM			Empleado para solicitar que un proceso termine de manera ordenada
			SIGUSR1			Disponible parausos definidos por la aplicación
			SIGUSR2			Dispobible para usos definidos por la aplicación.

					FIGURA 10-5  Señales requeridas por POSIX.

Bibliografia

Sistemas Operativos Modernos
Andrew Tanenbaum
Editorial: Pearson/Prentice-Hall