¿Por qué nos dicen que reiniciemos el ordenador cuando se queda colgado?

¡Feliz año nuevo!

Acabo de ver un vídeo de esos divulgativos (o mejor dicho: vulgarizantes) que "explica" por qué se cuelgan los ordenadores y por qué ctr+alt+del sirve para reiniciarlos :-|

Aquí lo tenéis para echaros unas risas http://www.elmundo.es/elmundo/2011/11/24/ciencia/1322158317.html

Como este blog siempre ha tenido vocación de culturizar al personal (aunque también me vanaglorio de que mis lectores son la hostia y no necesitan ser culturizados), vamos a proceder a intentar arreglar el desaguisado que comete este hombre con su "hesplicasion".

Lo más absurdo es empezar atribuyendo una única causa a los cuelgues y pensar que hay un único tipo de cuelgue. El cuelgue que parece preocupar a nuestro catedrático parece ser simplemente que el ordenador se ralentice cuando hay muchos programas abiertos, por lo visto este hombre nunca ha visto un BSOD (pantallazo azul de la muerte por sus siglas en inglés), o se le ha quedado el ordenador tan tostado que ni siquiera responde al sortilegio de ctrl+alt+del... Y también piensa que los Unix están hechos a prueba de bombas: no señor, también se cuelgan.

Vamos a identificar las barbaridades que dice el amigo:

Empecemos por la memoria caché, que parece que según este hombre es el origen de todos los males, la pobre. La caché es un tipo (conceptualmente) de memoria que sirve para guardar cosas que vas a usar más adelante.

La más famosa es la caché de los procesadores, que se suele dividir en dos tipos funcionales (de datos y de instrucciones); pero realmente podemos considerar que la RAM puede hacer de caché del disco duro (ya que es más rápida), o el disco duro puede hacer de caché de datos en la red, etc

El problema es que este señor está confundiendo "la caché" (como si sólo hubiese una) con varias cosas:

• Memoria swap: este es el espacio de disco destinado para simular que tenemos más memoria RAM de la que físicamente disponemos.
• Cola de eventos: es una estructura de datos donde se van guardando las acciones del usuario (pulsaciones de teclas, movimiento del ratón) para su posterior procesado.

El problema que describe en su segundo intento de aclarar las cosas (http://www.elmundo.es/elmundo/2011/11/26/ciencia/1322320450.html y por cierto, caché viene del francés, no del inglés) está relacionado con el swap y es lo que técnicamente se conoce como Hiperpaginación. Básicamente es que el working set (que es como se llama a la memoria que están usando los procesos activos) es mayor que la memoria física de la que disponemos, por lo que el sistema necesita mover páginas de memoria (una página es simplemente un cacho de un tamaño fijo) entre la RAM (que es rápida pero no muy grande) y el disco duro (que es muy grande pero no muy rápido).

Esto ocurre en todos los sistemas operativos con memoria virtual y swap si se "fuerzan". Ya sean Unix o Windows. Lo único que se puede hacer para evitarlo es:

• Prescindir del swap y si el sistema se queda sin memoria matar procesos para liberarla.
• Aumentar la RAM (pero no lo va a solucionar definitivamente, eventualmente podemos volver a llenarla si abrimos muchos procesos).
• Usar una configuración del planificador del sistema menos interactiva, para que los cambios de proceso sean menos frecuentes (aunque esto causará que la sensación sea de que el ordenador responde peor ante cosas como movimientos del ratón)... Y tampoco es una solución definitiva, únicamente hace que el tiempo perdido moviendo páginas entre el disco y la RAM sea menor en proporción al tiempo útil de proceso.

Volvamos al tema de lo que es un verdadero cuelgue. Cuando el ordenador deja de responder de verdad, no hay ni siquiera huevos de que funcione el teclado y lo único que nos salvará es darle al botón de reset (o liarse a patadas con la caja e irnos a vivir a un monasterio).

Un ordenador es una de las creaciones más complejas jamás diseñadas por el ser humano. Para que nos hagamos una idea, la Torre Eiffel, una imponente obra de ingeniería, tiene unos 2.600.000 tornillos y unos 18.000 bloques de metal. El primer procesador Pentium (de 1993) ya tenía unos 3.000.000 de transistores, y ese número se ha ido doblando cada 18 meses aproximadamente (la llamada Ley de Moore). Actualmente un Xeon de 10 cores tiene unos 2.600.000.000 transistores.

Y al contrario que la Torre Eiffel, un procesador no es algo estático, tiene un comportamiento dependiente del tiempo (por eso llevan un reloj que va marcando el ritmo a altísimas velocidades, del orden de Gigahertzios=miles de millones de veces por segundo).

Así que es sencillo de comprender lo fácil que resulta que algo vaya mal en esa maraña electrónica miniaturizada. Por suerte los diseños de hardware suelen estar bastante acotados en lo que pueden hacer y se pueden hacer pruebas aisladas, por lo que si hay defectos no suelen ser de diseño (que también los puede haber), sino en el proceso de fabricación (es difícil que de una oblea no salga algún bicho defectuoso, por suerte, la mayor superficie suele estar destinada a memorias caché [esta vez sí], con lo que desactivando parte de ella se pueden salvar muchos micros pasándolos a una gama inferior).

Luego está el dichoso software. Aquí es donde empiezan los problemas serios. Porque al fin y al cabo, a pesar de que el nivel de integración del hardware es brutal, en gran parte se trata de bloques idénticos replicados (aunque también tiene su miga), es decir, que tener 1MiB de caché no hace el chip esencialmente más complejo que uno que sólo tenga 256KiB. Sin embargo, el software es distinto, porque no está acotado por una estructura física donde colocarlo; su única limitación es el pensamiento humano... Y el pensamiento humano puede ser muy enrevesado (y en muchas ocasiones defectuoso).

Espero que esto haya servido para hacernos una idea de la magnitud del asunto que tenemos entre manos.

Centrémonos ahora en el Sistema Operativo. En los tiempos del MS-DOS, el sistema operativo realmente no tenía mucho que hacer, puesto que como no había múltiples usuarios ni múltiples procesos simultáneos, cuando ejecutábamos un programa tenía prácticamente acceso total a todo el ordenador. Hoy en día no es así, el PC es un pequeño ecosistema donde conviven cientos (y hasta miles) de programas ejecutándose simultáneamente. Para que no se den de hostias entre ellos, el Sistema Operativo tiene que mediar entre ellos, para dar acceso ordenado a cada uno de los recursos.

Ahora vamos a analizar los 5 tipos de errores (bugs) típicos que hacen que un programa falle:

• Acceso a una dirección de memoria incorrecta.
• Desbordamiento de pila.
• Intentar ejecutar una instrucción incorrecta.
• Excepción no tratada (e.g. dividir entre cero).
• Entrar en un bucle infinito.

Los cuatro primeros errores harán que el programa se detenga inesperadamente y que el Sistema Operativo le dé matarile sin más. En el último, el Sistema Operativo no tiene manera de saber si ese comportamiento es normal o anómalo (hay programas que están diseñados para no terminar nunca), así que es responsabilidad del usuario identificarlos y matarlos.

A esa lista podríamos añadir otro tipo de errores lógicos, que si bien no harán que el ordenador explote, harán que funcione de forma errática. Los más típicos son las race conditions, que son interacciones inesperadas entre software que se ejecuta de forma concurrente (esto está a la orden del día en cuanto intentas escribir código paralelo a no ser que te andes con pies de plomo).

Pues bien, el pobre Sistema Operativo no está exento de esos errores de programación. Quizá algo menos que el resto de programas, porque están diseñados y programados por los mejores profesionales del mundo; pero cualquier pequeño fallo es más evidente porque si el Sistema Operativo falla, el ordenador entero se suele colgar: no hay nadie más que tome las riendas.

Y por muy robustos que sean los sistemas operativos según vienen de fábrica, siempre hay algún driver chapucerillo que puede cargarse la integridad del mismo. Este es uno de los mayores puntos a favor de Linux (y MacOS) en cuanto a estabilidad frente a Windows. En Windows, cada vez que instalamos el driver de algún cacharrito que hemos comprado en los chinos (como una webcam, por ejemplo), estamos dejando que nuestro ordenador ejecute con todos los privilegios código escrito por vaya-usted-a-saber-quién, que si tiene algún bug es posible que nos fastidie el ordenador, porque los drivers se ejecutan (casi todos) en el mismo espacio de memoria que el sistema operativo y con sus mismos permisos. En el caso de Linux, la mayoría de los drivers están integrados en el código del propio kernel y están bastante bien auditados, por lo que las fuentes de fallos son menores. Para Mac, ni que decir queda que sólo hay drivers para el hardware que pasa por la caja de Cupertino y ya se encargan ellos de que funcione bien.

Hay algunas técnicas para incrementar la fiabilidad de los sistemas operativos, como ejecutarlos en máquinas virtuales o los basados en micro-kernels, pero desgraciadamente traen aumentos de complejidad en las interrelaciones entre componentes que pueden ser también fuentes de bugs.

Así que queridos lectores, como véis no es un tema sencillo ni mucho menos que se pueda explicar en un momento, de ser así los ordenadores seguramente no se colgarían tanto. Pero lo más importante es que no es lo mismo una degradación del rendimiento debido a un uso intensivo o excesivo que un error en el software o en el hardware. El primero se suele solucionar dejándole tiempo para que algunas tareas terminen o matándolas directamente con el task manager (no hace falta reinicar el ordenador normalmente), ante lo segundo lo único que podemos hacer es cruzar los dedos para que no nos toque o que saquen un parche lo antes posible.