lunes, 30 de junio de 2008

Terminator (Kill 'Em All)

JKS [jksware@gmail.com]

Ten sangre fría. No dejes vivo a ninguno. ¡Mátalos ya!

Erradicar de la faz de tu computadora un proceso de Windows NT que te esté molestando no es tarea fácil. A menudo ocurren incidentes desagradables: eliminamos al proceso equivocado y, en consecuencia, muchos programas dependientes sufren por ello. Descubrir cuál es la causa de dicha desventura conlleva un análisis detallado, y una explicación intuitiva y minuciosa para conocer en qué consiste un proceso, y respecto a qué se diferencia de un hilo de ejecución.

INTRO

Los procesos tienen una vida propia y aparte en nuestra computadora: Nacen, viven para servirnos – en la mayoría de los casos – y mueren – al final de muchos ciclos de cómputo.

Cada proceso cuenta con su propio hilo de ejecución. Un hilo de ejecución es aquello que ayuda a mantener el orden en nuestro procesador. Cuando nuestra PC es encendida – es decir, en el momento en que la CPU empieza a funcionar a plena capacidad – la misma trabajará durante los primeros segundos que anteceden y suceden al pitido inicial del POST – que significa: “¡hey!, estoy bien” – en sólo un par de tareas muy importantes antes de entregar control al SO – o lo que sea que venga detrás – : quizá mientras una tarea se encargue de mapear la memoria en busca de errores, otro imprima los caracteres del POST en pantalla y otro espere por que se presione F12 en el teclado para rápidamente llamar al selector de booteo. Cada tarea de las anteriores tienen algo muy importante en común: todas son necesarias, y todas deben ejecutarse de manera simultánea para que la “operación” de arranque sea satisfactoria.

El problema consiste en cómo programar lo anterior: cómo hacer que, independientemente de lo que suceda con una tarea determinada – es decir del camino que su algoritmo tome –, las demás tareas sigan ejecutándose al pie de la letra. En la mayoría de los casos esto implica que por muy ocupada que esté una tarea procesando información, no debe consumir todo el tiempo en el microprocesador para que otra se ejecute. Normalmente, si contáramos con un sistema operativo moderno – es decir, que este posea capacidades de multitasking o multitarea – podríamos crear un hilo de ejecución en un proceso y asignarle la tarea a realizar. Con esto, nuestro sistema operativo se encargará de hacer toda la planificación del tiempo de uso del “micro” por nosotros.

EL PROCESO PADRE

Una aplicación de computadora no es más que un conjunto de instrucciones de microprocesador almacenadas en memoria, dígase cualquier tipo de memoria, aleatoria o no, disco rígido o no. Dichas instrucciones son ejecutadas mediante un proceso, que es el nombre que se le designa en un sistema operativo a ese “espacio” que ocupan las instrucciones a ejecutar en el tiempo de CPU.

Un hilo permite la ejecución de distintos “tareas” dentro de un proceso, o diferentes procesos dentro del tiempo limitado de CPU de una computadora. Veamos con detenimiento lo anterior: un microprocesador se encarga de ejecutar cualquier instrucción que se “le aparezca por delante”, con lo que se van cumpliendo las órdenes del programador a la manera que el algoritmo indique. Ahora bien, cuando el programador hizo dicho programa, no se encargó de definir el espacio en memoria que dicho programa va a ocupar, ni cuándo ni cómo se va a ejecutar. El programador sencillamente se abstrajo de todo lo que no fuera el algoritmo de su aplicación.

10 000 A.C.

Antes de que existieran como hoy la conocemos, las máquinas computadoras, además de ser pesadas, generar calor y consumir “toneladas” de energía, carecían por completo de sistemas operativos. Pero a diferencia de lo que muchos pensarán, aquellas máquinas carecían de sistema no porque fueran torpes y tenían poca capacidad, sino por que un sistema operativo no era – por aquel tiempo de la década de los 40 – una necesidad tecnológica. Los programas – sin entrar en mucho detalle – se escribían pensando en todo lo que la máquina hacía: desde la velocidad rotación de las cintas de datos que interactuaban con los cabezales de lectura y escritura, hasta las funciones que implementaría el enésimo controlador de los LED indicadores del panel izquierdo del tercer cuarto de la segunda planta del “armatoste”. Al momento que los programadores – y los encargados de mantenimiento, reparación y los operarios de los diversos periféricos – se devanaban los sesos tratando de adivinar cual sería la reacción de un coloso de 5000 válvulas al vacío cuando se le introdujera determinada instrucción – por medio de tarjetas perforadas – no se había pensado que una supercomputadora pudiera “correr” más de un programa a la vez, ya que, “¿para qué, para que se rompa y vuele por los aires?”

El problema de los filósofos cenando es un problema clásico de las ciencias de la computación propuesto por Edsger Dijkstra para representar el problema de la sincronización de procesos en un sistema operativo. (Extraído de Wikipedia WikiCommons)

Sin embargo – y saltando muchas etapas interesantes de la historia de la computadora – con la diversificación de dichos mainframes en universidades y centros de cálculo de diversas instituciones científicas en años posteriores, fue necesario ir pensando en un “programa rector” de lo que los demás hacían o podían hacer. Era ya una necesidad que había sido puesta en tierra por medio de grandes computadoras con grandes capacidades, que para su mejor aprovechamiento y por lo costoso que resultaba mantenerlas encendidas, era necesario que existiera más que un solo puesto de trabajo en el que los usuarios pudieran trabajar. Resulta que lo que ahora conocemos por estación de trabajo o workstation, hace un tiempo atrás no era más que un teclado con un monitor monocromático ejecutando una “terminal” de un sistema multitarea y más importante multiusuario, como UNIX, antecesor de toda la familia de Linux que hoy conocemos.

Si alguna vez pasa por sus manos un libro de arquitectura de sistemas operativos – como aquellos Tanenbaum de la editora Prentice Hall – notarán que la sección principal del libro se la dedica al sistema UNIX, ya que es el modelo de construcción de muchos otros, por ser el que más se apega a todos los estándares que, formulados en la década de 1950, aún se respetan y son norma.

MULTIUSUARIOS

Cada usuario que se sentara – por aquel entonces – delante de una estación de trabajo, debía tener iguales derechos de uso del supercomputador que aquel otro que llevaba ya rato trabajando. El sistema operativo moderno, distribuido y multiusuario, se encarga entonces de “negociar” los recursos – que incluye como se ha dicho anteriormente memoria y tiempo de cómputo – asignados por unidad de tiempo a cada programa. Para eso se necesita hacer una abstracción y considerar que el programa ya cargado en memoria y ejecutándose se denomina proceso, y cada proceso tiene un tiempo reducido para “mandar” sobre el procesador bastante reducido. El tiempo que cada proceso pueda ejecutarse lo comanda el kernel del sistema operativo que lo está corriendo. Como un microprocesador común sólo puede llevar a cabo una instrucción por vez, que en dependencia de lo que haga lleva uno o más ciclos de procesador, la planificación que haga el sistema operativo de dichos procesos es medido por la cantidad de instrucciones que un programa adquiera, y por los ciclos que el sistema operativo opine que se llevará ejecutar cada una de esas instrucciones.

La afinidad de un proceso para ejecutarse en un u otro
núcleo de procesador puede ser configurada
mediante el Administrador de Tareas de Windows.

Por ejemplo, si las próximas 5 instrucciones de un programa que procesa estadísticas numéricas se basan en leer datos de una cinta magnética – proceso bastante engorroso dado que no se contaban con índices como ahora – y el programa está esperando que el controlador del cabezal reportara haber alcanzado determinado punto, el kernel entonces determina que el tiempo intermedio en que dicho programa está esperando por datos se le puede “conceder” a otro programa, que según su lista de instrucciones entrantes, va a utilizar la unidad aritmética, de manera que no se pierda por completo el tiempo de espera. Más o menos así es como funcionaría un sistema operativo bastante básico, corriendo más de una aplicación.



Artículos relacionados


No hay comentarios: