FUNDAMENTO DE SISTEMA OPERATIVO

Fundamentos de sistemas operativos Séptima edición

Fundamentos de sistemas operativos Séptima edición

ABRAHAM SILBERSCHATZ Yale University

PETER BAER GALVIN C orporate Technologies, Inc.

GREG GAGNE W estm inster College

Traducción VUELAPLUMA, S. L.

Revisión técnica JESÚS SÁNCHEZ ALLENDE D octor Ingeniero de Telecom unicación Dpto. de Electrónica y Sistemas Universidad Alfonso X El Sabio

Me G raw Hill MADRID BOGOTA • BUENOS AIRES • CARACAS • GUATEMALA • LISBOA MÉXICO • NUEVA YORK • PANAMÁ • SAN JUAN • SANTIAGO • SAO PAULO

AUCKLAND • HAMBURGO • LONDRES • MILÁN • MONTREAL • NUEVA DELHI • PARÍS SAN FRANCISCO • SIDNEY • SINGAPUR • ST. LOUIS • TOKIO • TORONTO

La inform ación contenida en este libro procede de una obra o rig in al publicada por Jo h n W ile y & So ns, In c. N o o b s­ tante, M cG raw -H ill/Interam ericana de España no garan tiza la exactitu d o p erfecció n de la inform ación publicada. T am p oco asum e ningún tipo de garantía sobre los contenid os y las op iniones vertidas en d ichos textos. E ste trabajo se publica con el recon o cim ien to exp reso de que se está proporcionando una inform ación , pero no tra­ tando de prestar ningún tipo de serv icio p ro fesion al o técn ico . L o s proced im ientos y la inform ación que se presen­ tan en este libro tienen só lo la intención de serv ir co m o guía general. M cG raw -H ill ha solicitad o los perm isos oportunos para la realización y el desarrollo d e esta obra.

FUNDAMENTOS DE SISTEMAS OPERATIVOS, T EDICIÓN N o está perm itida la reproducción total o parcial de este libro/ni su tratam iento in fo rm ático , ni la transm isión de ninguna form a o por cu alquier m edio, ya sea e le ctró n ico , m ecán ico , por fotocop ia, por reg istro u otros m étodos, sin el perm iso previo y por escrito de los titulares del C opyright.

Me Graw Hill

McGraw-Hill / Interamericana de España, S. A. U.

D E R E C H O S R E S E R V A D O S © 2 0 0 6 , respecto a la sép tim a ed ición en español, por M cG R A W -H IL L / lN T E R A M E R IC A N A D E E S P A Ñ A , S . A . U. E d ificio Valrealty, Ia planta B asau ri, 17 2 8 0 2 3 A ravaca (M adrid)

http://www. mcgraw-hill. es universidad&mcgraw-hill.com T rad ucido de la séptim a ed ición en inglés de

OPERATING SYSTEM CONCEPTS IS B N : 0 -4 7 1 -6 9 4 6 6 -5 C opyright © 2 0 0 5 por John W iley & So n s, Inc. IS B N : 8 4 -4 8 1 -4 6 4 1 -7 D ep ósito legal: M . 7 .9 5 7 -2 0 0 6 E ditor: C arm elo Sán ch ez G on zález C om p u esto por: Vuelaplum a, S. L. Im preso en: C o fas. S . A. IM P R E S O EN E SPA Ñ A - P R IN T E D 1N SPA IN

A mi hijos, Lemor, Sivan y Aaron Avi Silberschatz

A mi esposa Carla, y a mis hijos, Gioen Owen y M addie Peter Baer Galvin

A la m emoria del tío Sonny, Robert Jon Heileman 1933 -2 0 0 4 Greg Gagne

Abraham S i/b ersch a fz es catedrático de Informática en la Universidad de Yale. Antes de entrar en esa universidad, fue vicepresidente del laboratorio Information Sciencies Research Center de Bell Laboratories, Murray Hill, New Jersey, Estados Unidos. Con anterioridad, fue profesor en el Departamento de Ciencias de la Computación de la Universidad de Texas, en Austin. Entre sus intereses-de investigación se incluyen los sis­ temas operativos, los sistemas de bases de datos, los sistemas de tiempo real, los sistemas de almacenamiento, la gestión de red y los sistemas distribuidos. Además de los puestos que ha ocupado dentro del mundo académico e industrial, el profesor Silberschatz ha sido miembro del Panel de Biodiversidad y Ecosistemas del Comité de Asesores Científicos y Tecnológicos del Presidente Clinton, además de ser Consejero de la organización National Science Foundation y consultor para diversas empresas industriales. El profesor Silberschatz es socio de ACM y del IEEE. En 2002, recibió el premio IEEE Taylor L. Booth Education Award, en 1998 el ACM Karl V. Karlstom Outstanding Educator Aw ard y en 1997 el ACM SIGMOND Contribution Award; también ha sido galardonado por la organi-zación IEEE Computer Society por el artículo “Capability M anager” que apareció en la revista IEEE Transactions on Software Engineering. Sus escri­ tos han sido publicados en numerosas revistas de ACM y del IEEE, además de en otras revistas y conferencias de carácter profesional. Es coautor del libro de texto Fundamentos de bases de datos publicado también en castellano por McGraw-Hill.

G reg G agne es jefe del departamento de Informática y Matemáticas de Westminster College en Salt Lake City (Estados Unidos), donde ha estado impartiendo clases desde 1990. Además de enseñar sistemas operativos, también imparte clases sobre redes infor­ máticas, sistemas distribuidos, programación orientada a objetos y estructuras de datos. También imparte seminarios a profesores de informática y profesionales de la industria. Los intereses de investigación actuales del profesor Gagne incluyen los sistemas operati­ vos de nueva generación y la informática distribuida.

P e fe r B a er GaMn es Director técnico de Corporate Technologies (www.cptech.com). Con anterioridad, Peter era administrador de sistemas del Departamento de Informática de la Universidad de Brown. También es editor asociado de la revista SysAdmin. Peter Galvin ha escrito artículos para Byte y otras revistas y, anteriormente, se encargaba de las colum ­ nas sobre seguridad y administración de sistemas en ITWorld. Como consultor y formador, Peter ha impartido numerosas conferencias y cursos en todo el mundo sobre seguridad y administración de sistemas.

Prefacio

Los sistem as operativos son una parte esencial de cualquier sistem a inform ático. Del mismo modo, un curso sobre sistem as operativos es una parte esencial de cualquier carrera de Inform ática. Este cam po está cam biando m uy rápidam ente, ya que ahora las com putadoras se encuentran prácticam ente en cualquier aplicación, desde juegos para niños hasta herram ientas de planificación extrem adam ente sofisticadas para los gobiernos y las grandes m ultinacionales. Sin em bargo, los conceptos fundam entales siguen siendo bastante claros y es en ellos en los que se basa este libro. Hem os escrito esta obra com o libro de texto para un curso de introducción a los sistem as ope­ rativos para estudiantes universitarios de primer y segundo ciclo. Esperam os asim ism o que los profesionales tam bién lo encuentren útil, ya que proporciona una clara descripción de los concep­ tos que subyacen a los sistem as operativos. Como prerrequisitos, suponem os que el lector está fam iliarizado con las estructuras de datos básicas, la organización de una com putadora y algún lenguaje de alto nivel, com o por ejem plo C. En el Capítulo 1 se han incluido los conceptos sobre hardware necesarios para poder com prender los sistem as operativos. En los ejem plos de código se ha utilizado fundam entalm ente el lenguaje C, con algo de Java, pero el lector podrá com pren­ der los algoritm os sin tener un conocim iento profundo de estos lenguajes. Los conceptos se presentan m ediante descripciones intuitivas. El libro aborda algunos resulta­ dos teóricos im portantes, aunque las dem ostraciones se han omitido. Las notas bibliográficas pro­ porcionan inform ación sobre los libros o artículos de investigación en la aparecieron y se dem ostraron los conceptos por prim era vez, así com o referencias a material de lectura adicional. En lugar de dem ostraciones, se han utilizado figuras y ejem plos para indicar por qué debemos esperar que el resultado en cuestión sea cierto. Los conceptos y algoritm os fundam entales cubiertos en el libro están basados, a m enudo, en aquéllos que se em plean en los sistem as operativos com erciales existentes. N uestro objetivo ha sido presentar estos conceptos y algoritm os para una configuración general que no estuviera liga­ da a un sistem a operativo concreto. Hemos presentado gran cantidad de ejem plos que pertenecen a los m ás populares e innovadores sistem as operativos, incluyendo Solaris de Sun M icrosystem s; Linux; M ach; MS-DOS, W indows NT, W indows 2000 y W indows XP de M icrosoft; VMS y TOPS-20 de DEC; O S / 2 de IBM y M ac OS X de Apple. En este texto, cuando utilizam os W indows XP com o sistem a de operativo de ejem plo, quere­ mos hacer referencia tanto a W indows XP como a W indow s 2000. Si existe una característica en W indows XP que no está disponible en W indows 2000, se indica de forma explícita. Si una carac­ terística existe en W indow s 2000 pero no en W indows XP, entonces hacem os referencia específica­ mente a W indow s 2000.

viii

Prefacio

Organización de este libro La organización de este texto refleja nuestros m uchos años de im partición de cursos sobre siste­ mas operativos. Tam bién hem os tenido en cuenta las aportaciones proporcionadas por los reviso­ res del texto, así como los comentarios enviados por los lectores de las ediciones anteriores. Además, el contenido -del tekto se corresponde con las sugerencias de la recom endación Computing Curricula 2001 para la enseñanza de sistem as operativos, publicado por la Joint Task Forcé de la sociedad IEEE Com puting Society y la asociación ACM (Association for Computing M achinery). En la página w eb en inglés com plem entaria de este texto proporcionam os diversos planes de estudios que sugieren varios métodos para usar el texto, tanto en cursos de introducción como avanzados sobre sistemas operativos. Como regla general, anim am os a los lectores a avanzar de form a secuencial en el estudio de los sistem as operativos. Sin em bargo, utilizando un plan de estudios de ejem plo, un lector puede seleccionar un orden diferente de los capítulos (o de las subsecciones de los capítulos).

Contenido del libro El texto está organizado en ocho partes: • Introducción. Los Capítulos 1 y 2 explican lo que son los sistem as operativos, lo que hacen y c ó m o se diseñan y construyen. Se explican las características com unes de un sistem a opera­ tivo, lo que un sistem a operativo hace por el usuario y lo que hace para el operador del sis­ tema inform ático. La presentación es de naturaleza m otivadora y explicativa. En estos capí­ tulos hem os evitado exponer cómo ocurren las cosas internam ente. Por tanto, son adecua­ dos para lectores individuales o para estudiantes de prim er ciclo que deseen aprender qué es un sistem a operativo sin entrar en los detalles de los algoritm os internos. • G estió n de procesos. Los Capítulos 3 a 7 describen los conceptos de proceso y de concu­ rrencia com o corazón de los sistem as operativos m odernos. Un proceso es la unidad de tra­ bajo de un sistema. U n sistema consta de una colección de procesos que se ejecutan concu­ rrentemente, siendo algunos de ellos procesos del sistem a operativo (aquéllos que ejecutan código del sistema) y el resto, procesos de usuario (aquéllos que ejecutan código del usua­ rio). Estos capítulos exponen los métodos para la sincronización de procesos, la com unica­ ción interprocesos y el tratamiento de los interbloqueos. Tam bién se incluye dentro de este tema una explicación sobre las hebras. • G estión de m em oria. Los Capítulos.8 y 9 se ocupan de la gestión de la m em oria principal durante la ejecución de un proceso. Para mejorar tanto la utilización de la CPU como su velo­ cidad de respuesta a los usuarios, la com putadora debe m antener varios procesos en memo­ ria. Existen m uchos esquem as diferentes de gestión de m em oria, que se reflejan en diversas técnicas de gestión de memoria. Adem ás, la efectividad de cada algoritmo concreto depen­ de de la situación. • G estió n de alm acenam iento. Los Capítulos 10 a 13 describen cómo se gestionan el siste­ ma de archivos, el alm acenam iento masivo y las operaciones de E /S en un sistem a informá­ tico m oderno. El sistem a de archivos proporciona el m ecanism o para el alm acenam iento y el acceso en línea a los datos y programas que residen en los discos. Estos capítulos descri­ ben los algoritm os y estructuras clásicos internos para gestión del alm acenamiento. Proporcionan un firm e conocim iento práctico de los algoritm os utilizados, indicando las propiedades, las ventajas y las desventajas. Puesto que los dispositivos de E/S que se conec­ tan a una com putadora son m uy variados, el sistem a operativo tiene que proporcionar un am plio rango de funcionalidad a las aplicaciones, para perm itirlas controlar todos los aspec­ tos de los dispositivos. Se expone en profundidad la E /S del sistema, incluyendo el diScuo del sistem a de E /S , las interfaces y las estructuras y funciones internas del sistema. En m uchos sentidos, los dispositivos de E /S también constituyen los com ponentes más lentos

Prefacio

ix

de la com putadora. Puesto que son un cuello de botella que lim ita las prestaciones del sis­ tem a, abordam os tam bién estos problem as de prestaciones. Tam bién se explican los temas relativos a los alm acenam ientos secundario y terciario. • Protección y segu ridad. Los Capítulos 14 y 15 se ocupan de los procesos de un sistem é ope­ rativo que deben protegerse frente a otras actividades. Con propósitos de protección y segu­ ridad, utilizam os m ecanism os que garanticen que sólo los procesos que hayan obtenido la apropiada autorización del sistem a operativo puedan operar sobre los archivos, la m emo­ ria, la CPU y otros recursos. La protección es un m ecanism o que perm ite controlar el acceso de procesos, program as o usuarios a los recursos definidos por el sistem a inform ático. Este m ecanism o debe proporcionar un medio de especificar los controles que se han de imponer, asi com o un m edio de im ponerlos. Los m ecanism os de seguridad protegen la inform ación alm acenada en el sistem a (tanto los datos com o el código) y los recursos físicos del sistema inform áticos frente a accesos no autorizados, destrucción o m odificación m aliciosas e intro­ ducción accidental de incoherencias. • Sistem as d istribu id o s. Los Capítulos 16 a 18 se ocupan de una colección de procesadores que no com parten la m em oria, ni tampoco un reloj: un sistem a distribuido. Proporcionando al usuario acceso a los diversos recursos que mantiene, un sistem a distribuido puede aum entar la velocidad de cálculo y la disponibilidad y fiabilidad de los datos. Una arquitec­ tura de este tipo tam bién proporciona al usuario un sistem a de archivos distribuido, que es un sistem a del servicio de archivos cuyos usuarios, servidores y dispositivos de alm acena­ m iento se encuentran distribuidos por los distintos nodos de un sistem a distribuido. Un sis­ tem a distribuido debe proporcionar diversos m ecanism os para la sincronización y com uni­ cación de procesos y para tratar el problem a de los interbloqueos y diversos tipos de fallos que no aparecen en los sistem as centralizados. • Sistem as de propósito esp ecial. Los Capítulos 19 y 20 se ocupan de los sistem as utilizados para propósitos específicos, incluyendo los sistem as de tiem po real y los sistem as m ultim e­ dia. Estos sistem as tienen requisitos específicos que difieren de los de los sistem as de pro­ pósito general, en los que se centra el resto del texto. Los sistem as de tiempo real pueden necesitar no sólo que los resultados calculados sean "correctos", sino que tam bién se obten­ gan dentro de un plazo de tiem po especificado. Los sistem as m ultim edia requieren garan­ tías de calidad de servicio, para garantizar que los datos m ultim edia se entreguen a los clientes dentro de un periodo de tiempo específico. • C asos de estudio. Los Capítulos 21 a 23 del libro y los A péndices A y C (disponibles en inglés en el sitio w eb), integran los conceptos descritos en el libro abordando el estudio de sistem as operativos reales. Entre estos sistem as se incluyen Linux, W indows XP, FreeBSD, M ach y W indow s 2000. H em os elegido Linux y FreeBSD porque UNIX (en tiempos) resulta­ ba lo suficientem ente pequeño com o para resultar com prensible, sin llegar a ser un sistema operativo “de ju g u ete”. La m ayor parte de sus algoritm os internos fueron seleccionados por su simplicidad, en lugar de por su velocidad o su sofisticación. Tanto Linux com o FreeBSD pueden obtenerse fácilm ente y a un bajo coste, por lo que puede que m uchos estudiantes tengan acceso a estos sistem as. Hemos seleccionado W indows XP y W indows 2000 porque nos proporcionan una oportunidad de estudiar un sistema operativo m oderno con un di­ seño y una im plem entación drásticam ente diferentes a los de UNIX. El Capítulo 23 describe de form a breve algunos otros sistem as operativos que han tenido históricam ente cierta influencia.

Entornos de sistemas operativos Este libro utiliza ejem plos de m uchos sistemas operativos del m undo real para ilustrar los concep­ tos fundam entales. Sin em bargo, se ha puesto una atención especial en la fam ilia de sistem as ope­ rativos de M icrosoft (incluyendo W indows NT, W indow s 2000 y W indows XP) y varias versiones de UNIX (Solaris, BSD y Mac). Tam bién hemos cubierto una parte significativa del sistema opera-

Prefacio

tivo Linux, utilizando la versión más reciente del kem el, que era la versión 2.6 en el m om ento de escribir este libro. El texto tam bién proporciona varios program as de ejem plo escritos en C y en Java. Estos pro­ gramas pueden ejecutarse en los siguientes entornos de program ación: • Sistem as W indow s. El entorno de program ación principal para los sistem as W indow s es la API (application program m ing interface) W in32, que proporciona un amplio conjunto de funciones para gestionar los procesos, las hebras, la m em oria y los dispositivos periféricos. Facilitam os varios program as en C que ilustran el uso de la API W in32. Los program as de ejem plo se han probado en sistemas W indow s 2000 y W indow s XP. • POSIX. POSIX (Portable Operating System Interface, interfaz portable de sistem a operativo)

representa un conjunto de estándares im plementados principalm ente en sistem as operati­ vos basados en UNIX. Aunque los sistem as W indows XP y W indow s 2000 tam bién pueden ejecutar ciertos program as POSIX, aquí nos hemos ocupado de POSIX principalm ente cen­ trándonos en los sistem as UNIX y Linux. Los sistem as com patibles con POSIX deben im plem entar el estándar fundam ental de POSIX (POSIX .1); Linux, Solaris y M ac son ejem plos de sistem as com patibles con POSIX. POSIX tam bién define varias extensiones de los estándares, incluyendo extensiones de tiempo real (POSIX l.b ) y una extensión para una biblioteca de hebras (POSIX l.c, m ás conocida como Pthreads). Proporcionam os tam bién varios ejem plos de program ación escritos en C con el fin de ilustrar la API básica de POSIX, así com o Pthreads y las extensiones para programación de tiempo real. Estos program as de ejem plo se han probado en sistem as D ebian Linux 2.4 y 2.6, Mac OS X y Solaris 9 utilizando el com pilador g c c 3.3. • Java. Java es un lenguaje de program ación am pliam ente utilizado con una rica API y sopor­ te integrado de lenguaje para la creación y gestión de hebras. Los program as Java se ejecu­ tan sobre cualquier sistem a operativo que perm ita el uso de una m áquina virtual Java (JVM, Java virtual m achine). Hemos ilustrado los diversos sistem as operativos y los conceptos de redes con varios program as Java que se han probado utilizando la JVM Java 1.4. Hem os elegido tres entornos de program ación porque, en nuestra opinión, son los que m ejor representan los dos m odelos más populares de sistemas operativos: W indows y U N IX/ Linux, junto con el popular entorno Java. La mayor parte de los ejem plos de program ación están escritos en C, y esperam os que los lectores se sientan cóm odos con este lenguaje; los lectores fam iliariza­ dos con am bos lenguajes, C y Java, deberían com prender con facilidad la mayor parte de los pro­ gramas proporcionados en este texto. En algunos casos, com o por ejemplo con la creación de hebras, ilustram os un concepto especí­ fico utilizando todos los entornos de program ación, lo que perm ite al lector com parar el m odo en que las tres bibliotecas diferentes llevan a cabo una misma tarea. En otras situaciones, sólo hem os em pleado una de las API para demostrar un concepto. Por ejem plo, hem os ilustrado el tema de la m em oria com partida usando sólo la API de POSIX; la program ación de sockets en TCP/IP se expo­ ne utilizando la API de Java.

séptima edición A la hora de escribir la séptim a edición de Fundamentos de sistemas operativos nos hem os guiado por los m uchos com entarios y sugerencias que hemos recibido de los lectores de las ediciones anteriores; tam bién hemos procurado reflejar los cambios tan rápidos que se están produciendo en los cam pos de los sistem as operativos y las com unicaciones por red. Hem os reescrito el m ate­ rial de la m ayor parte de los capítulos, actualizando el m aterial m ás antiguo y elim inando aquél que actualm ente ya no tiene interés o es irrelevante. Se han hecho im portantes revisiones y cam bios en la organización de m uchos capítulos. Los cambios más destacables son la completa reorganización del m aterial de introducción de los Capítulos 1 y 2 y la adición de dos capítulos nuevos sobre los sistem as de propósito especial (los

Prefacio

xi

sistem as integrados de tiempo real y los sistem as m ultim edia). Puesto que la protección y la segu­ ridad han cobrado una gran relevancia en los sistem as operativos, hemos decidido incluir el tra­ tam iento de estos tem as más al principio del texto. Adem ás, se ha actualizado y ampliado sustancialm ente el estudio de los m ecanism os de seguridad. A continuación se proporciona un breve esquem a de los principales cambios introducidos en los distintos capítulos: . • El Capítulo 1, Introducción, se ha revisado por completo. En las versiones anteriores, el capítulo abordaba desde un punto de vista histórico el desarrollo de los sistem as operati­ vos. Ahora, el capítulo proporciona una exhaustiva introducción a los com ponentes de un sistem a operativo, junto con inform ación básica sobre la organización de un sistem a infor­ mático. • El Capítulo 2, Estructuras de los sistemas operativos, es una versión revisada del antiguo Capítulo 3 en la que se ha incluido inform ación adicional, como una exposición m ejorada sobre las llam adas al sistem a y la estructura del sistema operativo. Tam bién se proporciona inform ación actualizada sobre las m áquinas virtuales. • El Capítulo 3, Procesos, es el antiguo Capítulo 4. Incluye nueva inform ación sobre cóm o se representan los procesos en Linux e ilustra la creación de procesos usando las API de POSIX y W in32. El m aterial dedicado a la m emoria com partida se ha mejorado m ediante un pro­ grama que ilustra la API de m em oria com partida disponible para los sistem as POSIX. • El Capítulo 4, Hebras, se corresponde con el antiguo Capítulo 5. El capítulo presenta y am plía el tema de las bibliotecas de hebras, incluyendo las bibliotecas de hebras de POSIX, la API W in32 y Java. Tam bién proporciona inform ación actualizada sobre las hebras en Linux. • El Capítulo 5, Planificación, es el antiguo Capítulo 6. El capítulo ofrece una exposición sig­ nificativam ente actualizada sobre tem as de planificación en sistem as m ultiprocesador, incluyendo los algoritm os de afinidad del procesador y de equilibrado de carga. Tam bién se ha incluido una nueva sección sobre la planificación de hebras, incluyendo Pthreads e inform ación actualizada sobre la planificación dirigida por tablas en Solaris. La sección dedicada a la planificación en Linux se ha revisado para incluir el planificador utilizado en el kem el 2.6. • El Capítulo 6, Sincronización de procesos, se corresponde con el antiguo Capítulo 7. Se han elim inado las soluciones para dos procesos y ahora sólo se explica la solución de Peterson, ya que los algoritm os para dos procesos no garantizan su funcionam iento en los procesado­ res modernos. El capítulo tam bién incluye nuevas secciones sobre cuestiones de sincroniza­ ción en el kem el de Linux y en la API de Pthreads. • El Capítulo 7, Interbloqueos, es el antiguo Capítulo 8. El nuevo m aterial incluye un progra­ ma de ejem plo que ilustra los interbloqueos en un programa multihebra Pthread. • El Capítulo 8, M em oria principal, se corresponde con el antiguo Capítulo 9.E1 capítulo ya no se ocupa del tema de las secciones de m emoria superpuestas. Además, el m aterial dedi­ cado a la segm entación se ha m odificado considerablem ente, incluyendo una explicación m ejorada sobre la segm entación en los sistem as Pentium y una exposición sobre el diseño en Linux para tales sistem as segm entados. • El Capítulo 9, M em oria virtual, es el antiguo Capítulo 10. El capítulo am plía el material dedicado a la m em oria virtual, asi como a los archivos mapeados en m em oria, incluyendo un ejem plo de program ación que ilustra la memoria com partida (a través de los archivos m apeados en m emoria) usando la API W in32. Los detalles sobre el hardw are de gestión de m em oria se han actualizado. Se ha añadido una nueva sección dedicada a la asignación de m emoria dentro del kem el, en la que se explican el algoritm o de descom posición binaria y el asignador de franjas.

xii

Prefacio

• El Capítulo 10, Interfaz del sistem a de archivos, se corresponde con el antiguo Capítulo 11. Se ha actualizado y se ha incluido un ejem plo sobre las listas ACL de W indows XP. • El Capítulo 11, Im plem entación de los sistem as de archivos, es el antiguo Capítulo 12. Se ha añadido una descripción com pleta sobre el sistem a de archivos WAFL y se ha incluido el sistem a de archivos ZFS de Sun. • El Capítulo 12, Estructura de alm acenam iento m asivo, se corresponde con el antiguo Capítulo 14. Se ha añadido un tem a nuevo, las m atrices de almacenamiento modernas, incluyendo la nueva tecnología RAID y características tales como las redes de área de alm a­ cenam iento. • El Capítulo 13, Sistem as de E/S, es el antiguo Capítulo 13 actualizado, en el que se ha inclui­ do m aterial nuevo. • El Capítulo 14, Protección, es el antiguo Capítulo 18, actualizado con inform ación sobre el principio de m ínim o privilegio. • El Capítulo 15, Seguridad, se corresponde con el antiguo Capítulo 19. El capítulo ha expe­ rim entado una revisión im portante, habiéndose actualizado todas las secciones. Se ha incluido un ejem plo com pleto sobre el ataque por desbordam iento de búfer y se ha am plia­ do la inform ación sobre herram ientas de seguridad, cifrado y hebras. • Los Capítulos 16 a 18 se corresponden con los antiguos Capítulos 15 a 17, y se han actuali­ zado con m aterial nuevo. • El Capítulo 19, Sistem as de tiem po real, es un capítulo nuevo centrado en los sistemas inform áticos integrados de tiem po real, sistem as que tienen requisitos diferentes a los de los sistem as tradicionales. El capítulo proporciona una introducción a los sistemas inform áticos de tiem po real y describe cóm o deben construirse estos sistem as operativos para cumplir los plazos de tem porización estrictos de estos sistem as. • El Capítulo 20, Sistem as m ultim edia, es un capítulo nuevo que detalla los desarrollos en el área, relativam ente nueva, de los sistem as m ultim edia. Los datos multimedia se diferencian de los datos convencionales en que los prim eros, com o por ejemplo imágenes de vídeo, deben sum inistrarse de acuerdo con ciertas restricciones de tiempo. El capítulo explora cóm o afectan estos requisitos al diseño de los sistem as operativos. • El Capítulo 21, El sistem a Linux se corresponde con el antiguo Capítulo 20. Se ha actuali­ zado para reflejar los cambios en el kernel 2.6, el kernel más reciente en el momento de escri­ bir este libro. • El Capítulo 22, W indow s XP, se ha actualizado tam bién en esta versión. •

El

Capítulo

23,

Sistem as operativos influyentes, se ha actualizado.

El antiguo Capítulo 21 (W indows 2000) se ha transform ado en el Apéndice C. Al igual que en las versiones anteriores, los apéndices están disponibles en línea, aunque solamente en su versión original en inglés.

Proyectos y ejercicios de program ación Para reforzar los conceptos presentados en el texto, hem os añadido diversos proyectos y ejercicios de program ación que utilizan las API de POSIX y W in32, así com o Java. Hemos añadido 15 nuevos ejercicios de program ación que se centran en los procesos, las hebras, la memoria com partida, la sincronización de procesos y las com unicaciones por red. Adem ás, hemos añadido varios proyec­ tos de program ación que son más com plicados que los ejercicios de programación estándar. Estos proyectos incluyen la adición de una llam ada al sistema al kernel de Linux, la creación de una shell de UNIX utilizando la llam ada al sistem a f o r k ( ) , una aplicación multihebra de tratamiento de m atrices y el problem a del productor-consum idor usando m emoria compartida.

Prefacio

xiii

Suplementos y página web La página w eb (en inglés) asociada al libro contiene m aterial organizado como un conjunto de dia­ positivas para acom pañar al libo, planes de estudios para el curso m odelo, todo el código fuente en C 'y Java y una relación actualizada de las erratas. La página web también contiene los apéndi­ ces de los tres casos de estudio del libro y un apéndice dedicado a la com unicación distribuida. La URL es: http://www.os-book.com

Lista de correo Hem os cam biado el sistem a de com unicación entre los usuarios de Fundamentos de sistem as ope­ rativos. Si desea utilizar esta función, visite la siguiente URL y siga las instrucciones para suscri­ birse: http://m ailm an.cs.yale.edu/mailm an/listinfo/os-book-list El sistem a de lista de correo proporciona m uchas ventajas, como un archivo de m ensajes y varias opciones de suscripción, incluyendo suscripciones con envío de resúmenes o con acceso Web. Para m andar m ensajes a la lista, envíe un m ensaje de correo electrónico a: [email protected] Dependiendo del m ensaje, le responderem os personalm ente o enviarem os el m ensaje a toda la lista de correo. La lista está moderada, por lo que no recibirá correo inapropiado. Los estudiantes que utilicen este libro com o texto en sus clases no deben utilizar la lista para preguntar las respuestas a los ejercicios, ya que no se les facilitarán.

Sugerencias Hemos intentado elim inar todos los errores en esta nueva edición pero, como ocurre con los sis­ temas operativos, es posible que queden algunas erratas. Agradeceríam os que nos com unicaran cualquier error u omisión en el texto que puedan identificar. Si desea sugerir m ejoras o contribuir con ejercicios, tam bién se lo agradecemos de antemano. Puede enviar los mensajes a [email protected].

Agradecimientos Este libro está basado en las ediciones anteriores y Jam es Peterson fue coautor de la prim era de ellas. Otras personas que ayudaron en las ediciones anteriores son Hamid Arabnia, Rida Bazzi, Randy Bentson, David Black, Joseph Boykin, Jeff Brum field, Gael Buckley, Roy Campbell, P. C. Capón, John Carpenter, G il Carrick, Thom as Casavant, Ajoy Kum ar Datta, Joe Deck, Sudarshan K. Dhall, Thom as Doeppner, Caleb Drake, M. Racsit Eskicioglu, Hans Flack, Robert Fowler, G. Scott G raham , Richard G uy, M ax Hailperin, Rebecca Hartm an, W ayne Hathaway, Christopher Haynes, Bruce Hillyer, M ark Holliday, Ahm ed Kamel, Richard Kieburtz, Carol Kroll, Morty Kwestel, Thom as LeBlanc, John Leggett, Jerrold Leichter, Ted Leung, Gary Lippman, Carolyn M iller, M ichael M olloy, Yoichi M uraoka, Jim M. Ng, Banu Ózden, Ed Posnak, Boris Putañee, Charles Qualline, John Quarterm an, M ike Reiter, Gustavo Rodriguez-Rivera, Carolyn J. C. Schauble, Thom as P. Skinner, Yannis Sm aragdakis, Jesse St. Laurent, John Stankovic, Adam Stauffer, Steven Stepanek, Hal Stern, Louis Stevens, Pete Thom as, David Umbaugh, Steve Vinoski, Tommy W agner, Larry L. W ear, John W erth, Jam es M. W estall, J. S. W eston y Yang Xiang Partes del Capítulo 12 están basadas en un artículo de Hillyer y Silberschatz [1996], Partes del Capítulo 17 están basadas en un artículo de Levy y Silberschatz [1990], El Capítulo 21 está basa­ do en un m anuscrito no publicado de Stephen Tweedie. El Capítulo 22 está basado en un manus-

xiv

Prefacio

crito no publicado de Dave Probert, Cliff Martin y A vi Silberschatz. El A péndice C está basado en un m anuscrito no publicado de C liff Martin. Cliff M artin tam bién ha ayudado a actualizar el apéndice sobre UNIX para cubrir FreeBSD. Mike Shapiro, Bryan Cantrill y Jim M auro nos han ayu­ dado respondiendo a diversas cuestiones relativas a Solaris. Josh Dees y Rob Reynolds han con­ tribuido al tratam iento de M icrosoft .NET. El proyecto de diseño y m ejora de la interfaz shell de UNIX ha sido aportado por John Trono de St. M ichael's College, W inooski, Vermont. Esta edición contiene m uchos ejercicios nuevos, con sus correspondientes soluciones, los cua­ les han sido proporcionadas por Arvind Krishnamurthy. Querem os dar las gracias a las siguientes personas que revisaron esta versión del libro: Bart Childs, Don Heller, D ean Hougen M ichael Huangs, M orty Kewstel, Eurípides M ontagne y John Sterling. N uestros editores, Bill Zobrist y Paul Crockett, han sido una experta guía a m edida que íbamos preparando esta edición. Sim ón Durkin, ayudante de nuestros editores, ha gestionado m uy am a­ blem ente m uchos de los detalles de este proyecto. El editor de producción sénior ha sido Ken Santor. Susan Cyr ha realizado las ilustraciones de la portada y M adelyn Lesure es la diseñadora de la m isma. Beverly Peavler ha copiado y m aquetado el m anuscrito. Katrina Avery es la revisora de estilo externa que ha realizado la corrección de estilo del texto y la realización del índice ha corrido a cargo de la colabora externa Rosem ary Sim pson. M arilyn Tum am ian ha ayudado a generar las figuras y las diapositivas de presentación. Por último, nos gustaría añadir algunas notas personales. Avi está com enzando un nuevo capí­ tulo en su vida, volviendo al mundo universitario e iniciando una relación con Valerie. Esta com ­ binación le ha proporcionado la tranquilidad de espíritu necesaria para centrarse en la escritura de este libro. Pete desea dar las gracias a su fam ilia, a sus am igos y sus com pañeros de trabajo por su apoyo y com prensión durante el desarrollo del proyecto. G reg quiere agradecer a su fam ilia su continuo interés y apoyo. Sin embargo, desea dar las gracias de modo m uy especial a su amigo Peter Orm sby que, no im porta lo ocupado que parezca estar, siempre pregunta en prim er lugar “¿Qué tal va la escritura del libro?”. Abraham Silberschatz, New Haven, CT, 2004 Peter Baer Galvin, Burlington, MA, 2004 G reg G agne, Salt Lake City, UT, 2004

Contenido PARTE UNO

■

INTRODUCCIÓN

Capítulo 1 Introducción 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

¿Qué hace un sistema operativo? 3 O rganización de una com putadora 6 Arquitectura de un sistema informático 11 Estructura de un sistema operativo 14 Operaciones del sistema operativo 16 Gestión de procesos 19 Gestión de mem oria 19 Gestión de almacenamiento 20

1.9 1.10 1.11 1.12 1.13

Protección y seguridad 24 Sistemas distribuidos 25 Sistemas de propósito general Entornos inform áticos 28 Resumen 31 Ejercicios 32 N otas bibliográficas 34

Capítulo 2 Estructuras de sistemas operativos 2.1 2.2 2.3 2.4 2.5 2.6

Servicios del sistema operativo 35 Interfaz de usuario del sistema operativo 37 Llam adas al sistema 39 Tipos de llamadas al sistema 42 Program as del sistema 49 Diseño e implementación del sistema operativo 5 0

PARTE DOS

■

2.7 2.8 2.9 2.10 2.11

Estructura del sistema operativo 52 M áquinas virtuales 58 Generación de sistemas operativos 63 Arranque del sistema 64 Resumen 65 Ejercicios 65 N otas bibliográficas 70

GESTION DE PROCESOS

Capítulo 3 Procesos 3.1 3.2 3.3 3.4 3.5

Concepto de proceso 73 Planificación de procesos 77 O peraciones sobre los procesos 81 Com unicación interprocesos 86 Ejemplos de sistemas ipc 92

3.6 3.7

Com unicación en los sistemas clienteservidor 96 Resumen 103 Ejercicios 104 Notas bibliográficas 111

Capítulo 4 Hebras 4.1 4.2 4.3 4.4

Introducción 113 M odelos multihebra 115 Bibliotecas de hebras 117 Consideraciones sobre las hebras 123

4.5 4.6

Ejemplos de sistemas operativos 128 Resumen 130 Ejercicios 130 Notas bibliográficas 135

xvi

Contenido

Capítulo 5 Planificación de la CPU 5.1 5.2 5.3 5.4 5.5

Conceptos básicos 137 Criterios de planificación 140 Algoritmos de planificación 142 Planificación de-sistem as'm ultiprocesador 151 Planificación de hebras 153

5.6 5.7 5.8

Ejemplos de sistemas operativos 156 Evaluación de algoritmos 161 Resumen 165 Ejercicios 166 Notas bibliográficas 169

6.7 6.8 6.9 6.10

Monitores 186 Ejemplos de sincronización 194 Transacciones atómicas 197 Resumen 204 Ejercicios 205 Notas bibliográficas 214

7.6 7.7 7.8

Detección de interbloqueos 232 Recuperación de un interbloqueo 235 Resumen 236 Ejercicios 237 Notas bibliográficas 239

Capítulo 6 Sincronización de procesos 6.1 6.2 6.3 6.4 6.5 6.6

Fundam entos 171 El problema de la sección crítica 173 Solución de Peterson 174 H ardw are de sincronización 175 Semáforos 17S Problemas clásicos de sincronización 182

Capítulo 7 Interbloqueos 7.1 7.2 7.3 7.4 7.5

M odelo de sistem a 217 Caracterización de los interbloqueos 219 M étodos para tratar los interbloqueos 223 Prevención de interbloqueos 224 Evasión de interbloqueos 226

PARTE TRES

■

GESTIÓN DE MEMORIA

Capítulo 8 Memoria principal S.l S.2 8.3 8.4 8.5

Fundamentos 243 Intercambio 249 Asignación de m em oria contigua 252 Paginación 255 Estructura de la tabla de paginas 264

8.6 8.7 8.8

Segmentación 269 Ejemplo: Intel Pentium 271 Resumen 275 Ejercicios 276 Notas bibliográficas 278

9.8 9.9 9.10 9.11

Asignación de la mem oria del kemel Otras consideraciones 317 Ejemplos de sistemas operativos 323 Resumen 325 Ejercicios 326 Notas bibliográficas 330

Capítulo 9 Memoria virtual 9.1 9.2 9.3 9.4 9.5 9.6 9.7

Fundam entos 279 Paginación bajo dem anda 282 Copia durante la escritura 289 Sustitución de páginas 2°Ü Asignación de m arcos 302 Sobre paginación 305 Archivos m.apeados en memoria

PARTE CUATRO Capítulo 10 10.1 10.2 10.3 10.4 10.5

■

309

GESTIÓN DE ALMACENAMIENTO

Interfaz del sistema de archivos

Concepto Je archivo 33? M étodos ce acceso 342 Estructura Je directorios 34? Montaje de sistemas de archivos 354 Compartición de archivos 355

10.6 10.7

Protección 361 Resumen 365 Ejercicios 366 Notas bibliográficas 367

Contenido

xvii

Capítulo 11 Implementación de sistemas de archivos 11.1 11.2 11.3 11.4 11.5 11.6 11.7

Estructura de un sistema de archivos 369 Im plem entación de sistemas de archivos 371 Im plementación de directorios 377 M étodos de asignación 378 Gestión del espacio libre 386 Eficiencia y prestaciones 388 Recuperación 392

11.8 11.9 11.10 11.11

Sistemas de archivos con estructura de registro 393 NFS 395 Ejemplo: el sistema de archivos W A FL 400 Resumen 402 Ejercicios 403 Notas bibliográficas 405

Capítulo 12 Estructura de almacenamiento masivo 12.1 12.2 12.3 12.4 12.5 12.6 12.7

Panorám ica de la estructura de alm acena­ m iento m asivo 407 Estructura de un disco 409 Conexión de un disco 410 Planificación de disco 412 Gestión del disco 418 Gestión de espacio de intercambio 421 Estructuras RAID 423

12.8 12.9 12.10

Implementación de un almacenamiento estable 432 Estructura de almacenamiento terciario 433 Resumen 442 Ejercicios 444 Notas bibliográficas 447

Capítulo 13 Sistemas de E/S 13.1 13.2 13.3 13.4 13.5

Introducción 449 H ardw are de E /S 450 Interfaz de E /S de las aplicaciones 458 Subsistema de E /S del kernel 464 Transform ación de las solicitudes de E /S en operaciones hardw are 471

PARTE CINCO Capítulo 14 14.1 14.2 14.3 14.4 14.5 14.6

■

13.6 13.7 13.8

Stream s 473 Rendimiento 475 Resumen 478 Ejercicios 478 N otas bibliográficas 479

PROTECCIÓN Y SEGURIDAD

Protección

Objetivos de la protección 483 Principios de la protección 484 Dominio de protección 485 M atriz de acceso 489 Im plementación de la matriz de acceso 493 Control de acceso 495

14.7 14.8 14.9 14.10

Revocación de derechos de acceso 496 Sistemas basados en capacidades 497 Protección basada en el lenguaje 500 Resumen 505 Ejercicios 505 Notas bibliográficas 506

15.7

Cortafuegos para proteger los sistemas y redes 546 Clasificaciones de seguridad informática Un ejemplo: Windows XP 549 Resumen 550 Ejercicios 551 Notas bibliográficas 552

Capítulo 15 Seguridad 15.1 15.2 15.3 15.4 15.5 15.6

El problema de la seguridad 509 A m enazas relacionadas con los program as 513 A m enazas del sistema y de la red 520 La criptografía com o herram ienta de seguridad 525 Autenticación de usuario 535 im plementación de defensas de seguridad 539

15.8 15.9 15.10

xviii

Contenido

PARTE SEIS Capítulo 16 16.1 ,1 6 .2 16.3 16.4 16.5 16.6

■

SISTEMAS DISTRIBUIDOS

Estructuras de los sistemas distribuidos

Motivación 557 Tipos de sistemas distribuidos 559 Estructura de una red 563 Topología de red 565 Estructura de comunicaciones 567 Protocolos de comunicaciones 572

16.7 16.8 16.9 16.10

Robustez 575 Cuestiones de diseño 577 Un ejemplo: conexión en red Resumen 581 Ejercicios 581 Notas bibliográficas 583

Capítulo 17 Sistemas de archivos distribuidos 17.1 17.2 17.3 17.4 17.5

Conceptos esenciales 585 Nom brado y transparencia 586 Acceso rem oto a archivos 590 Servicios con y sin memoris del estado 594 Replicación de archivos 597

17.6 17.7

Un ejemplo: AFS 598 Resumen 602 Ejercicios 603 Notas bibliográficas 604

18.6 18.7 18.8

Algoritmos de elección 623 Procedim ientos de acuerdo Resumen 627 Ejercicios 627 Notas bibliográficas 629

Capítulo 18 Coordinación distribuida 18.1 18.2 18.3 18.4 18.5

Ordenación de sucesos 605 Exclusión m utua 607 Atom icidad 610 Control de concurrencia 612 Gestión de interbloqueos 616

PARTE SIETE Capítulo 19 19.1 19.2 19.3 19.4

■

SISTEMAS DE PROPÓSITO ESPECIAL

Sistemas de tiempo real

Introducción 633 Características del sistema 634 Características de un k em el de tiempo real 636 Im plementación de sistemas operativos de tiempo real 637

19.5 19.6 19.7

Planificación de la CPU en tiempo real 641 VxW orks 5.x 645 Resumen 648 Ejercicios 649 Notas bibliográficas 650

20.6 20.7 20.8

Gestión de red 660 Un ejemplo: CineBlitz 663 Resumen 665 Ejercicios 666 Notas bibliográficas 667

Capítulo 20 Sistemas multimedia 20.1 20.2 20.3 20.4 20.5

¿Qué es la multimedia? 651 Com presión 654 Requisitos de los kernels multimedia 655 Planificación de la CPU 658 Planificación de disco 658

PARTE OCHO Capítulo 21 21.1 21.2 21.3 21.4

■

CASOS DE ESTUDIO

El sistema Linux

Historia de Linux 671 Principios de diseño 675 Módulos del kem el 678 Gestión de procesos 681

21.5 21.6 21.7 21.8

Planificación 684 Gestión de m em oria 6SS Sistemas de archivos 696 Entrada y salida 702

Contenido

21.9 21.10 21.11

Comunicación interprocesos 704 Estructura de red 705 Seguridad 707

21.12

Resumen 709 Ejercicios 710 N otas bibliográficas 711

22.6 22.7 22.8

Conexión de red 749 Interfaz de program ación 756 Resumen 763 Ejercicios 763 Notas bibliográficas 764

Capítulo 22 Windows XP 22.1 22.2 22.3 22.4 22.5

Historia 713 Principios de diseño 714 Componentes del sistema 717 Subsistemas de entorno 739 Sistema de archivos 742

Capítulo 23 Sistemas operativos influyentes 23.1 23.2 23.3 23.4 23.5 23.6

Sistemas pioneros 765 A tlas 771 XDS-940 771 THE 772 RC 4000 773 CTSS 773

Bibliografía Créditos índice

803 805

779

23.7 23.8 23.9 23.10

MULTICS .774 IBM O S /360 774 M ach 776 Otros sistemas 777 Ejercicios 777

Parte Uno

Introducción Un sistem a o p erativo actúa com o un intermediario entre el usuario de una com putadora y el hardware de la misma. El propósito de un sistema operativo es proporcionar un entorno en el que el usuario pueda ejecutar program as de una m anera p rá ctica y eficiente. Un sistem a operativo es software que gestiona el hardware de la com puta­ dora. El hardware debe proporcionar los m ecanismos apropiados para asegu­ rar el correcto funcionam iento del sistem a inform ático e impedir que los program as de usuario interfieran con el apropiado funcionam iento del sistema. Internamente, los sistem as operativos varían enorm em ente en lo que se refiere a su configuración, dado que están organizados según muchas líneas diferentes. El diseño de un nuevo sistema operativo es una tarea de gran enver­ gadura. Es fundam ental que los objetivos del sistem a estén bien definidos antes de com enzar el diseño. Estos objetivos constituyen la base para elegir entre los distintos algoritm os y estrategias. Dado que un sistem a operativo es un software grande y complejo, debe cre­ arse pieza por pieza. Cada una de estas piezas debe ser una parte perfecta­ mente perfilada del sistema, estando sus entradas, salidas y funciones cuidadosam ente definidas.

C A W T U L O

Introducción Un sistem a operativo es un program a que adm inistra el hardware de una com putadora. Tam bién proporciona las bases para los program as de aplicación y actúa como un interm ediario entre el usuario y el hardw are de la com putadora. Un aspecto sorprendente de los sistem as operativos es la gran variedad de form as en que llevan a cabo estas tareas. Los sistemas operativos para mainfram e están diseñados principalm ente para optim izar el uso del hardware. Los sistem as operati­ vos de las com putadoras personales (PC) soportan desde com plejos juegos hasta aplicaciones de negocios. Los sistem as operativos para las com putadoras de mano están diseñados para propor­ cionar un entorno en el que el usuario pueda interactuar fácilm ente con la com putadora para eje­ cutar program as. Por tanto, algunos sistem as operativos se diseñan para ser prácticos, otros para ser eficientes y otros para ser am bas cosas. Antes de poder explorar los detalles de funcionam iento de una com putadora, necesitam os saber algo acerca de la estructura del sistema. Com enzarem os la exposición con las funciones bási­ cas del arranque, E/S y alm acenam iento. Tam bién vam os a describir la arquitectura básica de una com putadora que hace posible escribir un sistem a operativo funcional. Dado que un sistema operativo es un softw are grande y complejo, debe crearse pieza por pieza. Cada una de estas piezas deberá ser una parte bien diseñada del sistema, con entradas, sali­ da y funciones cuidadosam ente definidas. En este capítulo proporcionamos una introducción general a los principales com ponentes de un sistem a operativo.

OBJETIVOS DEL CAPÍTULO • Proporcionar una visión general de los principales componentes de los sistemas operativos. • Proporcionar una panorámica sobre la organización básica de un sistema informático.

1.1

¿Qué hace un sistema operativo? Com enzam os nuestra exposición fijándonos en el papel del sistema operativo en un sistem a infor­ mático global. Un sistem a inform ático puede dividirse a grandes rasgos en cuatro com ponentes: el hardware, el sistema operativo, los programas de aplicación y los usuarios (Figura 1.1). El hardware, la unidad cen tral de procesam iento, UCP o CPU (central processing unit), la m em oria y los dispositivos de I/S (entrada/salida), proporciona los recursos básicos de cóm pu­ to al sistema. Los program as de aplicación, com o son los procesadores de texto, las hojas de cál­ culo, los com piladores y los exploradores web, definen las formas en que estos recursos se em plean para resolver los problem as inform áticos de los usuarios. El sistema operativo controla y coordina ei uso del hardw are entre los diversos program as de aplicación por parte de los distin­ tos usuarios.

Capítulo 1 Introducción

F ig u ra 1.1

Esquema de los componentes de un sistema informático.

Tam bién podem os ver un sistem a inform ático com o hardware, software y datos. El sistema operativo proporciona los m edios para hacer un uso adecuado de estos recursos durante el fu n­ cionam iento del sistem a inform ático. U n sistem a operativo es similar a un gobierno. Como un gobierno, no realiza ninguna función útil por sí m ismo: sim plem ente proporciona un entorno en el que otros programas pueden llevar a cabo un trabajo útil. Para comprender mejor el papel de un sistem a operativo, a continuación vamos a abordar los sistemas operativos desde dos puntos de vista: el del usuario y el del sistema.

1.1.1 Punto de vista del usuario La visión del usuario de la com putadora varía de acuerdo con la interfaz que utilice. La mayoría de los usuarios que se sientan frente a un PC disponen de un monitor, un teclado, un ratón y una unidad de sistema. Un sistem a así se diseña para que un usuario m onopolice sus recursos. El obje­ tivo es m axim izar el trabajo (o el juego) que el usuario realice. En este caso, el sistem a operativo se diseña principalm ente para que sea de fá c il uso, prestando cierta atención al rendim iento y nin­ guna a la u tilización de recursos (el m odo en que se com parten los recursos hardw are y softw a­ re). Por supuesto, el rendim iento es im portante para el usuario, pero más que la utilización de recursos, estos sistem as se optim izan para el uso del m ism o por un solo usuario. En otros casos, un usuario se sienta frente a un term inal conectado a un m ainfram e o una m icrocom putadora. Otros usuarios acceden sim ultáneam ente a través de otros terminales. Estos usuarios com parten recursos y pueden intercam biar inform ación. En tales casos, el sistema ope­ rativo se diseña para m axim izar la utilización de recursos, asegurar que todo el tiempo de CPU, m em oria y E/S disponibles se usen de form a eficiente y que todo usuario disponga sólo de la parte equitativa que le corresponde. En otros casos, los usuarios usan estaciones de trabajo conectadas a redes de otras estaciones de trabajo y servidores. Estos usuarios tienen recursos dedicados a su disposición, pero también tienen recursos com partidos com o la red y los servidores (servidores de archivos, de cálculo y de impresión). Por tanto, su sistem a operativo está diseñado para llegar a un com prom iso entre la usabilidad individual y la utilización de recursos. Recientem ente, se han puesto de m oda una gran variedad de com putadoras de mano. La mayor parte de estos dispositivos son unidades autónom as para usuarios individuales. Algunas se conectan a redes directam ente por cable o, m ás a m enudo, a través de redes y modems inalám ­

1.1 ¿Qué hace un sistema operativo?

5

bricos. Debido a las lim itaciones de alimentación, velocidad e interfaz, llevan a cabo relativam en­ te pocas operaciones remotas. Sus sistem as operativos están diseñados principalm ente en función de la usabilidad individual, aunque el rendim iento, m edido según la duración de la batería, es tam bién im portante. A lgunas com putadoras tienen poca o ninguna interacción con el usuario. Por ejem plo, las com ­ putadoras incorporadas en los electrodom ésticos y en los autom óviles pueden disponer de tecla­ dos num éricos e indicadores lum inosos que se encienden y apagan para mostrar el estado, pero tanto estos equipos com o sus sistem as operativos están diseñados fundam entalm ente para fun­ cionar sin intervención del usuario.

1.1.2 Vista del sistema Desde el punto de vista de la com putadora, el sistem a operativo es el program a m ás íntim am en­ te relacionado con el hardware. En este contexto, podem os ver un sistem a operativo como un asignador de recursos. Un sistem a inform ático tiene m uchos recursos que pueden ser necesarios para solucionar un problem a: tiempo de CPU, espacio de m emoria, espacio de alm acenam iento de archivos, dispositivos de E/S, etc. El sistema operativo actúa com o el adm inistrador de estos recursos. Al enfrentarse a num erosas y posiblem ente conflictivas solicitudes de recursos, el siste­ m a operativo debe decidir cóm o asignarlos a program as y usuarios específicos, de m odo que la com putadora pueda operar de forma eficiente y equitativa. Como hem os visto, la asignación de recursos es especialm ente im portante cuando m uchos usuarios aceden al m ism o mainframe o m inicom putadora. U n punto de vista ligeram ente diferente de un sistem a operativo hace hincapié en la necesidad de controlar los distintos dispositivos de E /S y program as de usuario. U n sistem a operativo es un program a de control. Com o program a de control, gestiona la ejecución de los program as de usua­ rio para evitar errores y m ejorar el uso de la com putadora. Tiene que ver especialm ente con el fun­ cionam iento y control de los dispositivos de E /S .

1.1.3 Definición de sistemas operativos H em os visto el papel de los sistem as operativos desde los puntos de vista del usuario y del siste­ ma. Pero, ¿cóm o podem os definir qué es un sistem a operativo? En general, no disponem os de nin­ guna definición de sistema operativo que sea com pletam ente adecuada. Los sistem as operativos existen porque ofrecen una forma razonable de resolver el problem a de crear un sistem a inform á­ tico utilizable. El objetivo fundamental de las com putadoras es ejecutar programas de usuario y resolver los problem as del mismo fácilmente. Con este objetivo se construye el hardw are de la com putadora. Debido a que el hardware por sí solo no es fácil de utilizar, se desarrollaron pro­ gram as de aplicación. Estos programas requieren ciertas operaciones com unes, tales com o las que controlan los dispositivos de E /S . Las operaciones habituales de control y asignación de recursos se incorporan en una misma pieza del software: el sistem a operativo. Adem ás, no hay ninguna definición universalmente aceptada sobre qué forma parte de un sis­ tema operativo. Desde un punto de vista simple, incluye todo lo que un distribuidor sum inistra cuando se pide “el sistema operativo”. Sin em bargo, las características incluidas varían enorm e­ m ente de un sistema a otro. Algunos sistemas ocupan menos de 1 m egabyte de espacio y no pro­ porcionan ni un editor a pantalla completa, m ientras que otros necesitan gigabytes de espacio y están com pletam ente basados en sistemas gráficos de ventanas. (Un kilobyte, Kb, es 1024 bytes; un m egabyte, MB, es 10242 bytes y'un gigabyte, GB, es 10243 bytes. Los fabricantes de com puta­ doras a m enudo redondean estas cifras y dicen que 1 m egabyte es un m illón de bytes y que un gigabyte es mil millones de bytes.) Una definición más com ún es que un sistema operativo es aquel program a que se ejecuta continuam ente en la com putadora (usualm ente denom inado kerrtel), siendo todo lo demás programas del sistema y programas de aplicación. Esta definición es la que generalm ente seguiremos. La cuestión acerca de qué constituye un sistema operativo está adquiriendo una im portancia creciente. En 1998, el Departamento de Justicia de Estados Unidos entabló un pleito c'Ontra

6

Capítulo 1 Introducción

M icrosoft, aduciendo en esencia que M icrosoft incluía demasiada funcionalidad en su sistem a operativo, im pidiendo a los vendedores de aplicaciones competir. Por ejemplo, un explorador web era una parte esencial del sistem a operativo. Com o resultado, M icrosoft fue declarado culpa­ ble de usar su m onopolio en los sistem as operativos para lim itar la com petencia.

1.2 Organización de una com putadora Antes de poder entender cómo funciona una com putadora, necesitam os unos conocim ientos generales sobre su estructura. En esta sección, verem os varias partes de esa estructura para com ­ pletar nuestros conocim ientos. La sección se ocupa principalm ente de la organización de una com putadora, así que puede hojearla o saltársela si ya está fam iliarizado con estos conceptos.

1.2.1 Funcionamiento de una computadora Una com putadora m oderna de propósito general consta de una o más CPU y de una serie de con­ troladoras de dispositivo conectadas a través de un bus com ún que proporciona acceso a la m em oria com partida (Figura 1.2). Cada controladora de dispositivo se encarga de un tipo especí­ fico de dispositivo, por ejem plo, unidades de disco, dispositivos de audio y pantallas de vídeo. La CPU y las controladoras de dispositivos pueden funcionar de forma concurrente, com pitiendo por los ciclos de m em oria. Para asegurar el acceso de form a ordenada a la m em oria com partida, se proporciona una controladora de m em oria cuya función es sincronizar el acceso a la misma. Para que una com putadora com ience a funcionar, por ejem plo cuando se enciende o se reinicia, es necesario que tenga un program a de inicio que ejecutar. Este program a de inicio, o p ro g ra­ m a de a rran q u e, suele ser simple. Normalmente, se alm acena en la m em oria ROM (read only m em ory, m em oria de sólo lectura) o en una m em oria EEPROM (electrically erasable programm able read-only m em ory, m em oria de sólo lectura program able y eléctricam ente borrable), y se conoce con el térm ino general firm w are, dentro del hardw are de la com putadora. Se inicializan todos los aspectos del sistem a, desde los registros de la CPU hasta las controladoras de dispositi­ vos y el contenido de la memoria. El programa de arranque debe saber cóm o cargar el sistema operativo e iniciar la ejecución de dicho sistema. Para conseguir este objetivo, el program a de arranque debe localizar y cargar en m em oria el kernel (núcleo) del sistem a operativo. Después, el sistem a operativo com ienza ejecutando el primer proceso, com o por ejem plo “init”, y espera a que se produzca algún suceso. La ocu rren cia de u n suceso norm alm ente se indica m ediante una in terru p ción bien h ard w are o bien softw are. El h ard w are puede activar una interrupción en cualquier instante enviando una señal a la CPU, n orm alm en te a través del bus del sistem a. El softw are p uede activar una in terru p ­ ción ejecutando una op eración especial denom inada llam ad a del sistem a (o también llam ad a de m on itor). ratón

dtSCQS

0 0

^

o

tecla d o

/".y

,yV

im presora

/—Uvtfnea ~~\

(£ 0 3

Figura 1.2 Una computadora moderna.

monitor

1.2 Organización de una computadora

CPU

dispositivo de E/S

7

ejecución de proceso de usuario procesamiento de interrupción de E/S inactividad transferencia

solicitud de E/S F ig u ra 1.3

transferencia hecha

solicitud de E/S

transferencia hecha

Diagrama de tiempos de una interrupción para un proceso de salida.

Cuando se interrum pe a la CPU, deja lo que está haciendo e inm ediatam ente transfiere la eje­ cución a una posición fijada (establecida). Normalmente, dicha posición contiene la dirección de inicio de donde se encuentra la rutina de servicio a la interrupción. La rutina de servicio a la inte­ rrupción se ejecuta y, cuando ha terminado, la cpu reanuda la operación que estuviera haciendo. En la Figura 1.3 se m uestra un diagram a de tiempos de esta operación. Las interrupciones son una parte im portante de la arquitectura de una com putadora. Cada diseño de com putadora tiene su propio m ecanism o de interrupciones, aunque hay algunas fun­ ciones com unes. La interrupción debe transferir el control a la rutina de servicio apropiada a la interrupción. El m étodo m ás sim ple para tratar esta transferencia consiste en invocar una rutina genérica para exam inar la inform ación de la interrupción; esa rutina genérica, a su vez, debe llam ar a la rutina específica de tratam iento de la interrupción. Sin em bargo, las interrupciones deben tratar­ se rápidam ente y este m étodo es algo lento. En consecuencia, com o sólo es posible un núm ero pre­ definido de interrupciones, puede utilizarse otro sistem a, consistente en disponer una tabla de punteros a las rutinas de interrupción, con el fin de proporcionar la velocidad necesaria. De este m odo, se llama a la rutina de interrupción de forma indirecta a través de la tabla, sin necesidad de una rutina interm edia. Generalm ente, la tabla de punteros se alm acena en la zona inferior de la m emoria (las prim eras 100 posiciones). Estas posiciones alm acenan las direcciones de las ruti­ nas de servicio a la interrupción para los distintos dispositivos. Esta m atriz, o vector de interrup­ ciones, de direcciones se indexa m ediante un número de dispositivo unívoco que se proporciona con la solicitud de interrupción, para obtener la dirección de la rutina de servicio a la interrupción para el dispositivo correspondiente. Sistem as operativos tan diferentes com o W indow s y UNIX m anejan las interrupciones de este modo. La arquitectura de servicio de las interrupciones tam bién debe alm acenar la dirección de la ins­ trucción interrum pida. M uchos diseños antiguos sim plem ente alm acenaban la dirección de inte­ rrupción en una posición fija o en una posición indexada m ediante el núm ero de dispositivo. Las arquitecturas m ás recientes alm acenan la dirección de retom o en la pila del sistema. Si la rutina de interrupción necesita m odificar el estado del procesador, por ejem plo m odificando valores del registro, debe guardar explícitam ente el estado actual y luego restaurar dicho estado antes de vol­ ver. Después de atender a la interrupción, la dirección de retorno guardada se carga en el conta­ dor de program a y el cálculo interrum pido se reanuda com o si la interrupción no se hubiera producido.

1.2.2

Estructura de almacenamiento

Los program as de la com putadora deben hallarse en la m em oria principal (también llamada memoria RA M , random -access memory, memoria de acceso aleatorio) para ser ejecutados. La m emoria principal es el único área de alm acenam iento de gran tamaño (m illones o miles de m illo­ nes de bytes) a la que el procesador puede acceder directam ente. Habitualm ente, se implementa con una tecnología de sem iconductores denom inada D R A M (dynam ic random -access m emory,

Capítulo 1 Introducción

m em oria dinámica de acceso aleatorio), que form a una m atriz de palabras de m emoria. Cada palabra tiene su propia dirección. La interacción se consigue a través de una secuencia de carga (lo a d ) o alm acenam iento ( s t o r e ) de instrucciones en direcciones específicas de m emoria. La ins­ trucción l o a d m ueve una palabra desde la memoria principal a un registro interno de la CPU, m ientras que la instrucción s t o r e m ueve el contenido de un registro a la m em oria principal. • Aparté de las cargas y alm acenam ientos explícitos, la CPU carga autom áticam ente instrucciones desde la m emoria principal para su ejecución. U n ciclo típico instrucción-ejecución, cuando se ejecuta en un sistem a con una arquitectura de von N eum ann, prim ero extrae una instrucción de m em oria y alm acena dicha instrucción en el registro de instru cciones. A continuación, la instrucción se decodifica y puede dar lugar a que se extraigan operandos de la m em oria y se alm acenen en algún registro interno. Después de ejecu­ tar la instrucción con los necesarios operandos, el resultado se alm acena de nuevo en memoria. Observe que la unidad de m emoria sólo ve un flujo de direcciones de m em oria; no sabe cómo se han generado (m ediante el contador de instrucciones, indexación, indirección, direcciones litera­ les o algún otro medio) o qué son (instrucciones o datos). De acuerdo con esto, podem os ignorar cómo genera un program a una dirección de memoria. Sólo nos interesarem os por la secuencia de direcciones de m em oria generada por el programa en ejecución. Idealm ente, es deseable que los program as y los datos residan en la m em oria principal de forma perm anente. U sualm ente, esta situación no es posible por las dos razones siguientes: 1. N orm alm ente, la m em oria principal es demasiado pequeña com o para alm acenar todos los program as y datos necesarios de form a permanente. 2. La m em oria principal es un dispositivo de alm acenam iento volátil que pierde su contenido cuando se quita la alim entación. Por tanto, la m ayor parte de los sistem as inform áticos proporcionan alm acenam iento secun­ dario com o una extensión de la m emoria principal. El requerim iento fundam ental de este alm a-' cenam iento secundario es que se tienen que poder alm acenar grandes cantidades de datos de form a perm anente. El dispositivo de alm acenam iento secundario más com ún es el disco m agnético, que propor­ ciona un sistema de alm acenam iento tanto para programas como para datos. La m ayoría de los program as (exploradores web, com piladores, procesadores de texto, hojas de cálculo, etc.) se alm acenan en un disco hasta que se cargan en memoria. M uchos program as utilizan el disco como origen y destino de la inform ación que están procesando. Por tanto, la apropiada adm inistración del alm acenam iento en disco es de im portancia crucial en un sistem a inform ático, com o veremos en el Capítulo 12. Sin em bargo, en un sentido amplio, la estructura de alm acenam iento que hemos descrito, que consta de registros, m em oria principal y discos m agnéticos, sólo es uno de los m uchos posibles sistem as de alm acenam iento. Otros sistem as incluyen la m em oria caché, los CD-ROM, cintas m ag­ néticas, etc. Cada sistem a de alm acenam iento proporciona las funciones básicas para guardar datos y m antener dichos datos hasta que sean recuperados en un instante posterior. Las principa­ les diferencias entre los distintos sistem as de alm acenam iento están relacionadas con la velocidad, el coste, el tamaño y la volatilidad. La am plia variedad de sistemas de alm acenam iento en un sistem a inform ático puede organi­ zarse en una jerarquía (Figura 1.4) según la velocidad y el coste. Los niveles superiores son caros, pero rápidos. A m edida que se desciende por la jerarquía, el coste por bit generalmente dism inu­ ye, m ientras que el tiem po de acceso habitualm ente aumenta. Este com prom iso es razonable; si un sistema de alm acenam iento determ inado fuera a la vez más rápido y barato que otro (siendo el resto de las propiedades las mismas), entonces no habría razón para em plear la memoria más cara y más lenta. De hecho, m uchos de los primeros dispositivos de alm acenam iento, incluyendo las cintas de papel y las m em orias de núcleo, han quedado relegadas a los museos ahora que las cin­ tas m agnéticas y las m em orias sem iconductoras son más rápidas y baratas. Los cuatro niveles de memoria superiores de la Figura 1.4 se pueden construir con m em orias semiconductoras. A dem ás de diferenciarse en la velocidad y en el coste, los distintos sistem as de alm acenam ien- ■, to pueden ser volátiles o no volátiles. Como hemos m encionado anteriormente, el alm acena-

1.2 Organización de una computadora

9

ZI registros

Ocaché B

E

memoria principal

I

i =

disco electrónico I

0

disco magnético /

disco óptico

TV V cintas magnéticas

/ F ig u ra 1 .4

Jerarquía de dispositivos de almacenamiento.

m ien to v o látil pierde su contenido cuando se retira la alim entación del dispositivo. En ausencia de baterías caras y sistem as de alim entación de reserva, los datos deben escribirse en alm acen a­ m ien to no vo látiles para su salvaguarda. En la jerarquía m ostrada en la Figura 1.4, los sistemas

de alm acenam iento que se encuentran por encim a de los discos electrónicos son volátiles y los que se encuentran por debajo son no volátiles. Durante la operación norm al, el disco electrónico alm a­ cena datos en una m atriz D RA M grande, que es volátil. Pero m uchos dispositivos de disco elec­ trónico contienen un disco duro m agnético oculto y una batería de reserva. Si la alimentación externa se interrumpe, la controladora del disco electrónico copia los datos de la RAM en el disco m agnético. Cuando se restaura la alim entación, los datos se cargan de nuevo en la RAM. Otra forma de disco electrónico es la m em oria flash, la cual es muy popular en las cám aras, los PDA (p erson al d igital assistan t) y en los robots; asim ism o, está aumentando su uso com o dispositivo de alm acenam iento extraíble en com putadoras de propósito general. La memoria flash es más lenta que la DRAM , pero no necesita estar alim entada para m antener su contenido. Otra forma de alm acenam iento no volátil es la N V R A M , que es una DRAM con batería de reserva. Esta m emo­ ria puede ser tan rápida com o una DRAM , aunque sólo m antiene su carácter no volátil durante un tiempo limitado. El diseño de un sistem a de m em oria com pleto debe equilibrar todos los factores mencionados hasta aquí: sólo debe utilizarse una m em oria cara cuando sea necesario y em plear m emorias más baratas y no volátiles cuando sea posible. Se pueden instalar m em orias caché para m ejorar el ren­ dimiento cuando entre dos com ponentes existe un tiem po de acceso largo o disparidad en la velo­ cidad de transferencia.

1.2.3 Estructura de E/S Los de alm acenam iento son sólo uno de los m uchos tipos de dispositivos de E /S que hay en un sistem a informático. G ran parte del código del sistem a operativo se dedica a gestionar la entrada y la salida, debido a su im portancia para la fiabilidad y rendim iento del sistema y debido también a la variada naturaleza de los dispositivos. Vamos a realizar, por tanto, un repaso introductorio del tema de la E/S. Una com putadora de propósito general consta de una o más CPU y de múltiples controladoras de dispositivo que se conectan a través de un bus com ún. Cada controladora de dispositivo se encarga de un tipo específico de dispositivo. Dependiendo de la controladora, puede haber más

Capítulo 1 Introducción

de un dispositivo conectado. Por ejem plo, siete o m ás dispositivos pueden estar conectados a la controladora S C S I (sm all com puter-system interface, interfaz para sistem as inform áticos de pequeño tamaño). U na controladora de dispositivo m antiene algunos búferes locales y un conjun­ to de registros de propósito especial. La controladora del dispositivo es responsable de transferir los datos entre los dispositivos periféricos que controla y su búfer local. N orm alm ente, los siste­ m as operativos tienen un controlador (d riv er) de dispositivo para cada controladora (controller) de dispositivo. Este softw are controlador del dispositivo es capaz de entenderse con la controla­ dora hardware y presenta al resto del sistem a operativo una interfaz uniform e m ediante la cual com unicarse con el dispositivo. Al iniciar una operación de E /S , el controlador del dispositivo carga los registros apropiados de la controladora hardware. Ésta, a su vez, exam ina el contenido de estos registros para determ i­ nar qué acción realizar (como, por ejem plo, “leer un carácter del teclado”). La controladora inicia entonces la transferencia de datos desde el dispositivo a su búfer local. Una vez com pletada la transferencia de datos, la controladora hardware inform a al controlador de dispositivo, a través de una interrupción, de que ha term inado la operación. El controlador devuelve entonces el control al sistem a operativo, devolviendo posiblem ente los datos, o un puntero a los datos, si la operación ha sido una lectura. Para otras operaciones, el controlador del dispositivo devuelve inform ación de estado. Esta form a de E / S controlada por interrupción resulta adecuada para transferir cantidades pequeñas de datos, pero representa un desperdicio de capacidad de proceso cuando se usa para m ovim ientos masivos de datos, com o en la E /S de disco. Para resolver este problema, se usa el acceso directo a m em oria (D M A , direct m em ory access). Después de configurar búferes, punte­ ros y contadores para el dispositivo de E /S , la controladora hardware transfiere un bloque entero de datos entre su propio búfer y la m em oria, sin que intervenga la CPU. Sólo se genera una inte­ rrupción por cada bloque, para decir al controlador softw are del dispositivo que la operación se ha com pletado, en lugar de la interrupción por byte generada en los dispositivos de baja veloci­ dad. M ientras la controladora hardw are realiza estas operaciones, la CPU está disponible para lle­ var a cabo otros trabajos. A lgunos sistem as de gam a alta em plean una arquitectura basada en conm utador, en lugar de en bus. En estos sistem as, los diversos com ponentes pueden com unicarse con otros com ponen­ tes de form a concurrente, en lugar de com petir por los ciclos de un bus com partido. En este caso,.

Figura 1.5 Funcionamiento de un sistema informático moderno.

1.3 Arquitectura de un sistema informático

11

el acceso directo a m em oria es incluso m ás eficaz. La Figura 1.5 m uestra la interacción de los dis­ tintos com ponentes de un sistem a inform ático.

Arquitectura de un sistema informático En la Sección 1.2 hem os presentado la estructura general de un sistem a inform ático típico. Un sis­ tem a inform ático se puede organizar de varias m aneras diferentes, las cuales podem os clasificar de acuerdo con el núm ero de procesadores de propósito general utilizados.

1.3.1 Sistemas de un solo procesador La m ayor parte de los sistem as sólo usan un procesador. N o obstante, la variedad de sistem as de un único procesador puede ser realm ente sorprendente, dado que van desde los PDA hasta los sistem as mainframe. En un sistem a de un único procesador, hay una CPU principal capaz de eje­ cutar un conjunto de instrucciones de propósito general, incluyendo instrucciones de los proce­ sos de usuario. Casi todos los sistem as disponen tam bién de otros procesadores de propósito especial. Pueden venir en form a de procesadores específicos de un dispositivo, com o por ejem ­ plo un disco, un teclado o una controladora gráfica; o, en m ainframes, pueden tener la form a de procesadores de propósito general, com o procesadores de E / S que transfieren rápidam ente datos entre los com ponentes del sistem a. Todos estos procesadores de propósito especial ejecutan un conjunto limitado de instrucciones y no ejecutan procesos de usuario. En ocasiones, el sistem a operativo los gestiona, en el sentido de que les envía inform ación sobre su siguiente tarea y m onitoriza su estado. Por ejem plo, un m icroprocesador incluido en una controladora de disco recibe una secuencia de solicitudes pro­ cedentes de la CPU principal e im plem enta su propia cola de disco y su algoritm o de program a­ ción de tareas. Este m étodo libera a la CPU principal del trabajo adicional de planificar las tareas de disco. Los PC contienen un m icroprocesador en el teclado para convertir las pulsaciones de tecla en códigos que se envían a la CPU. En otros sistem as o circunstancias, los procesadores de propósito especial son com ponentes de bajo nivel integrados en el hardware. El sistem a operati­ vo no puede com unicarse con estos procesadores, sino que éstos hacen su trabajo de form a autó­ noma. La presencia de m icroprocesadores de propósito especial resulta bastante com ún y no convierte a un sistem a de un solo procesador en un sistem a m ultiprocesador. Si sólo hay una CPU de propósito general, entonces el sistem a es de un solo procesador.

1.3.2 Sistemas multiprocesador Aunque los sistem as de un solo procesador son los m ás com unes, la im portancia de los sistem as m ultiprocesador (tam bién conocidos com o sistem as p aralelos o sistem as fu ertem ente acopla­ dos) está siendo cada vez mayor. Tales sistem as disponen de dos o más procesadores que se com unican entre sí, com partiendo el bus de la com putadora y, en ocasiones, el reloj, la memoria y los dispositivos periféricos. Los sistem as m ultiprocesador presentan tres ventajas fundam entales: 1. M ayor rendim iento. Al aum entar el número de procesadores, es de esperar que se realice m ás trabajo en menos tiempo. Sin em bargo, la m ejora en velocidad con N procesadores no es N, sino que es m enor que N. Cuando m últiples procesadores cooperan en una tarea, cierta carga de trabajo se emplea en conseguir que todas las partes funcionen correctam ente. Esta carga de trabajo, más la contienda por los recursos com partidos, reducen la ganancia espera­ da por añadir procesadores adicionales. De form a sim ilar, N program adores trabajando sim ultáneam ente no producen N veces la cantidad de trabajo que produciría un solo progra­ m ador . 2. Econom ía de escala. Los sistem as m ultiprocesador pueden resultar más baratos que su equivalente con múltiples sistem as de un solo procesador, ya que pueden com partir perifé­

Capítulo 1 Introducción

ricos, alm acenam iento m asivo y fuentes de alim entación. Si varios programas operan sobre el m ism o conjunto de datos, es m ás barato alm acenar dichos datos en un disco y que todos los procesadores los com partan, que tener m uchas com putadoras con discos locales y m uchas copias de los datos. 3. M ayor fiabilidad. Si las funciones se pueden distribuir de forma apropiada-entre varios procesadores, entonces el fallo de un procesador no hará que el sistem a deje de funcionar, sino que sólo se ralentizará. Si tenem os diez procesadores y uno falla, entonces cada uno de los nueve restantes procesadores puede asum ir una parte del trabajo del procesador que ha fallado. Por tanto, el sistem a com pleto trabajará un 10% más despacio, en lugar de dejar de funcionar. En m uchas aplicaciones, resulta crucial conseguir la m áxim a fiabilidad del sistema inform áti­ co. La capacidad de continuar proporcionando servicio proporcionalm ente al nivel de hardware superviviente se denom ina degradación suave. Algunos sistem as van más allá de la degradación suave y se denom inan sistem as tolerantes a fallos, dado que pueden sufrir un fallo en cualquier com ponente y continuar operando. O bserve que la tolerancia a fallos requiere un mecanismo que perm ita detectar, diagnosticar y, posiblem ente, corregir el fallo. El sistema H P NonStop (antes sis­ tema Tándem ) duplica el hardware y el softw are para asegurar un funcionam iento continuado a pesar de los fallos. El sistem a consta de m últiples parejas de CPU que trabajan sincronizadam ente. Am bos procesadores de la pareja ejecutan cada instrucción y com paran los resultados. Si los resultados son diferentes, quiere decir que una de las CPU de la pareja falla y ambas dejan de fun­ cionar. El proceso que estaba en ejecución se transfiere a otra pareja de CPU y la instrucción falli­ da se reinicia. Esta solución es cara, dado que implica hardw are especial y una considerable duplicación del hardware. Los sistem as m ultiprocesador actualm ente utilizados son de dos tipos. Algunos sistemas usan el m ultiprocesam iento asim étrico, en el que cada procesador se asigna a una tarea específica. Un procesador m aestro controla el sistem a y el resto de los procesadores esperan que el maestro les dé instrucciones o tienen asignadas tareas predefinidas. Este esquema define una relación m aes­ tro-esclavo. El procesador m aestro planifica el trabajo de los procesadores esclavos y se lo asigna. Los sistem as más com unes utilizan el m u ltip ro cesam ien to sim étrico (SMP), en el que cada pro­ cesador realiza todas las tareas correspondientes al sistem a operativo. En un sistema SMP, todos los procesadores son iguales; no existe una relación m aestro-esclavo entre los procesadores. La Figura 1.6 ilustra una arquitectura SMP típica. Un ejem plo de sistem a SMP es Solaris, una versión com ercial de UNIX diseñada por Sun M icrosystem s. Un sistem a Sun se puede configurar em ple­ ando docenas de procesadores que ejecuten Solaris. La ventaja de estos m odelos es que se pue­ den ejecutar sim ultáneam ente m uchos procesos (se pueden ejecutar N procesos si se tienen N CPU) sin que se produzca un deterioro significativo del rendim iento. Sin em bargo, hay que con­ trolar cuidadosam ente la E /S para asegurar que los datos lleguen al procesador adecuado. Tam bién, dado que las CPU están separadas, una puede estar en un período de inactividad y otra puede estar sobrecargada, dando lugar a ineficiencias. Estas situaciones se pueden evitar si los procesadores com parten ciertas estructuras de datos. Un sistem a m ultiprocesador de este tipo perm itirá que los procesos y los recursos (com o la m em oria) sean com partidos dinám icam ente entre los distintos procesadores, lo que perm ite dism inuir la varianza entre la carga de trabajo de los procesadores. Un sistem a así se debe diseñar con sum o cuidado, como verem os en el Capítulo 6. Prácticam ente todos los sistem as operativos m odernos, incluyendo W indow s, W indows XP, Mac OS X y Linux, proporcionan soporte para SMP.

Figura 1.6 Arquitectura de multiprocesamiento simétrico.

1.3 Arquitectura de un sistema informático

13

La diferencia entre m ultiprocesam iento sim étrico y asim étrico puede deberse tanto al hardw a­ re com o al softw are. Puede que haya un hardw are especial que diferencie los m últiples procesa­ dores o se puede escribir el softw are para que haya sólo un m aestro y m últiples esclavos. |'or ejem plo, el sistem a operativo SunOS Versión 4 de Sun proporciona m ultiprocesam iento asim étri­ co, m ientras que Solaris (Versión 5) es sim étrico utilizando el m ism o hardware. U na tendencia actual en el diseño de las CPU es incluir m últiples n úcleos de cálculo en un mismo chip. En esencia, se trata de chips m ultiprocesador. Los chips de dos vías se están convirtiendo en la corriente dom inante, m ientras que los chips de N vías están em pezando a ser habi­ tuales en los sistem as de gam a alta. Dejando aparte las consideraciones sobre la arquitectura, com o la caché, la memoria y la contienda de bus, estas CPU con m últiples núcleos son vistas por el sistem a operativo sim plem ente como N procesadores estándar. Por últim o, los servidores blade son un reciente desarrollo, en el que se colocan m últiples procesadores, tarjetas de E/S y tarjetas de red en un m ism o chasis. La diferencia entre estos sis­ tem as y los sistem as m ultiprocesador tradicionales es que cada tarjeta de procesador blade arran ­ ca independientem ente y ejecuta su propio sistem a operativo. Algunas tarjetas de servidor blade tam bién son m ultiprocesador, lo que difum ina la línea divisoria entre los distintos tipos de com ­ putadoras. En esencia, dichos servidores constan de m últiples sistem as m ultiprocesador inde­ pendientes.

1.3.3 Sistemas en cluster

\

Otro tipo de sistem a con m últiples CPU es el sistem a en clu ster. Como los sistem as m ultiproce­ sador, los sistem as en cluster utilizan m últiples CPU para llevar a cabo el trabajo. Los sistem as en cluster se diferencian de los sistem as de m ultiprocesam iento en que están form ados por dos o más sistem as individuales acoplados. La definición del térm ino en cluster no es concreta; m uchos paquetes com erciales argum entan acerca de qué es un sistem a en cluster y por qué una form a es m ejor que otra. La definición generalm ente aceptada es que las com putadoras en cluster com par­ ten el alm acenam iento y se conectan entre sí a través de una red de área local (LAN , local area netw ork), com o se describe en la Sección 1.10, o m ediante una conexión más rápida com o InfiniBand. N orm alm ente, la conexión en cluster se usa para proporcionar un servicio con alta d isp o n ib i­ lidad; es decir, un servicio que funcionará incluso si uno o más sistem as del cluster fallan. Generalm ente, la alta disponibilidad se obtiene añadiendo un nivel de redundancia al sistema. Sobre los nodos del cluster se ejecuta una capa de software de gestión del cluster. Cada nodo puede m onitorizar a uno o más de los restantes (en una LA N ). Si la m áquina m onitorizada fa lla , la m áqui­ na que la estaba m onitorizando puede tom ar la propiedad de su alm acenam iento v reiniciar las aplicaciones que se estuvieran ejecutando en la m áquina que ha fallado. Los usuarios y clientes de las aplicaciones sólo ven una breve interrupción del servicio. El cluster se puede estructurar simétrica o asim étricam ente. En un cluster asim étrico, una m áquina está en modo de espera en caliente, m ientras que la otra está ejecutando las aplicacio­ nes. La m áquina host en m odo de espera en caliente no hace nada más que m onitorizar al servi­ dor activo. Si dicho servidor falla, el host que está en espera pasa a ser el servidor activo. En el m odo sim étrico, dos o más hosts ejecutan aplicaciones y se monitorizan entre sí. Este m odo es obviam ente m ás eficiente, ya que usa todo el hardw are disponible. Aunque, desde luego, requie­ re que haya disponible m ás de una aplicación para ejecutar. Otras form as de cluster incluyen el cluster en paralelo y los clusters conectados a una red de área extensa (WAN, w ide area netw ork), com o se describe en la Sección 1.10. Los clusters en para­ lelo perm iten que m últiples hosts accedan a unos mismos datos, disponibles en el alm acenam ien­ to com partido. Dado que la m ayoría de los sistem as operativos no soportan el acceso sim ultáneo a datos por parte de m últiples hosts, norm alm ente los clusters en paralelo requieren em plear ver­ siones especiales de softw are y versiones especiales de las aplicaciones. Por ejemplo, Oracle Parallel Server es una versión de la base de datos de Oracle que se ha diseñado para ejecutarse en un cluster paralelo. Cada una de las m áquinas ejecuta Oracle y hay .una capa de software que con ­ trola el acceso al disco com partido. Cada m áquina tiene acceso total a todos los datos de la base

1,4 Estructura de un sistema operativo

15

Cuando dicho trabajo tiene que esperar, la CPU conm uta a otro trabajo, y así sucesivamente. Cuando el prim er trabajo deja de esperar, vuelve a obtener la CPU. Mientras haya al menos un tra­ bajo que necesite ejecutarse, la CPU nunca estará inactiva. Esta idea tam bién se aplica en otras situaciones de la vida. Por ejemplo, un abogado no traba­ ja para un único cliente cada vez. M ientras que un caso está a la espera de que salga el juicio o de que se rellenen determ inados papeles, el abogado puede trabajar en otro caso. Si tiene bastantes clientes, el abogado nunca estará inactivo debido a falta de trabajo. (Los abogados inactivos tien­ den a convertirse en políticos, por lo que los abogados que se m antienen ocupados tienen cierto valor social.) Los sistem as m ultiprogram ados proporcionan un entorno en el que se usan de form a eficaz los diversos recursos del sistem a, com o por ejem plo la CPU, la m em oria y los periféricos, aunque no proporcionan la interacción del usuario con el sistem a inform ático. El tiem po com p artid o (o m ultitarea) es una extensión lógica de la m ultiprogram ación. En los sistem as de tiempo compartido, la CPU ejecuta m últiples trabajos conm utando entre ellos, pero las conmutaciones se producen tan frecuentem ente que los usuarios pueden interactuar con cada program a mientras éste está en eje­ cución. El tiem po com partido requiere un sistem a in fo rm ático in teractiv o , que proporcione com uni­ cación directa entre el usuario y el sistema. El usuario sum inistra directamente instrucciones al sis­ tema operativo o a un program a, utilizando un dispositivo de entrada como un teclado o un ratón, y espera los resultados interm edios en un dispositivo de salida. De acuerdo con esto, el tiem po de resp u esta debe ser pequeño, norm alm ente m enor que un segundo. Un sistem a operativo de tiempo com partido perm ite que m uchos usuarios com partan sim ul­ táneam ente la com putadora. Dado que el tiem po de ejecución de cada acción o com ando en un sistem a de tiempo com partido tiende a ser pequeño, sólo es necesario un tiempo pequeño de CPU para cada usuario. Puesto que el sistem a cam bia rápidam ente de un usuario al siguiente, cada usuario tiene la im presión de que el sistem a inform ático com pleto está dedicado a él, incluso aun­ que esté siendo com partido por m uchos usuarios. Un sistem a de tiempo com partido em plea m ecanism os de m ultiprogram ación y de planifica­ ción de la CPU para proporcionar a cada usuario una pequeña parte de una com putadora de tiem ­ po com partido. Cada usuario tiene al m enos un program a distinto en memoria. Un programa cargado en memoria y en ejecución se denom ina p roceso. Cuando se ejecuta un proceso, norm al­ m ente se ejecuta sólo durante un período de tiem po pequeño, antes de terminar o de que necesi­ te realizar una operación de E/S. La E /S puede ser interactiva, es decir, la salida va a la pantalla y la entrada procede del teclado, el ratón u otro dispositivo del usuario. Dado que norm alm ente la E/3 interactiva se ejecuta a la “velocidad de las personas”, puede necesitar cierto tiempo para com ­ pletarse. Por ejem plo, la entrada puede estar lim itada por la velocidad de tecleo del usuario; escri­ bir siete caracteres por segundo ya es rápido para una persona, pero increíblem ente lento para una com putadora. En lugar de dejar que la CPU espere sin hacer nada mientras se produce esta entra­ da interactiva, el sistema operativo hará que la CPU conm ute rápidam ente al programa de algún otro usuario. El tiem po com partido y la m ultiprogram ación requieren m antener sim ultáneam ente en m emo­ ria varios trabajos. Dado que en general la m em oria principal es demasiado pequeña para acom o­ dar todos los trabajos, éstos se m antienen inicialm ente en el disco, en la denom inada cola de trab ajo s. Esta cola contiene todos los procesos que residen en disco esperando la asignación de la memoria principal. Si hay varios trabajos preparados para pasar a memoria y no hay espacio sufi­ ciente para todos ellos, entonces el sistem a debe hacer una selección de los mismos. La toma de esta decisión es lo que se denom ina p lan ificació n de trab ajo s, tem a que se explica en el Capítulo 5. Cuando el sistema operativo selecciona un trabajo de la cola de trabajos, carga dicho trabajo en memoria para su ejecución. Tener varios program as en m em oria al mismo tiempo requiere algún tipo de m ecanism o de gestión de la m emoria, lo que se cubre en los Capítulos 8 y 9. Además, si hay varios trabajos preparados para ejecutarse al m ism o tiem po, el sistema debe elegir entre ellos. La toma de esta decisión es lo que se denom ina p lan ificació n de la CPU. que se estudia también en el Capítulo 5. Por últim o, ejecutar varios trabajos concurrentem ente requiere que la capacidad de los trabajos pora afectarse entre sí esté limitada en todas las fases del sistema operativo, inclu-

16

Capítulo 1 Introducción

yendo la planificación de procesos, el alm acenam iento en disco y la gestión de la m emoria. Estas consideraciones se abordan a todo lo largo del libro. En un sistem a de tiem po com partido, el sistema operativo debe asegurar un tiem po de res­ puesta razonable, lo que en ocasiones se hace a través de un m ecanism o de intercam bio, donde los procesos se intercam bian entrando y saliendo de la m em oria al disco. Un m étodo m ás habitual de conseguir este objetivo es la m emoria virtual, una técnica que perm ite la ejecución de un pro­ ceso que no está com pletam ente en m em oria (Capítulo 9). La ventaja principal del esquem a de m em oria virtual es que perm ite a los usuarios ejecutar program as que sean m ás grandes que la m em oria física real. Adem ás, realiza la abstracción de la m em oria principal, sustituyéndola desde el punto de vista lógico por una m atriz uniform e de alm acenam iento de gran tam año, separando así la m em oria lógica, com o la ve el usuario, de la memoria física. Esta disposición libera a los pro­ gram adores de preocuparse por las lim itaciones de alm acenam iento en memoria. Los sistem as de tiem po com partido tam bién tienen que proporcionar un sistem a de archivos (Capítulos 10 y 11). El sistem a de archivos reside en una colección de discos; por tanto, deberán proporcionarse tam bién m ecanism os de gestión de discos (Capítulo 12). Los sistem as de tiempo com partido tam bién sum inistran un m ecanism o para proteger los recursos frente a usos inapro­ piados (Capítulo 14). Para asegurar una ejecución ordenada, el sistem a debe proporcionar m eca­ nism os para la com unicación y sincronización de trabajos (Capítulo 6) y debe asegurar que los trabajos no darán lugar a interbloqueos que pudieran hacer que quedaran en espera perm anente­ m ente (Capítulo 7).

1.5 Operaciones del sistema operativo Com o se ha m encionado anteriormente, los sistemas operativos m odernos están controlados m ediante interrupciones. Si no hay ningún proceso que ejecutar, ningún dispositivo de E/S al que dar servicio y ningún usuario al que responder, un sistema operativo debe perm anecer inactivo, esperando a que algo ocurra. Los sucesos casi siempre se indican m ediante la ocurrencia de una interrupción o una excepción. Una excepción es una interrupción generada por software, debida a un error (por ejem plo, una división por cero o un acceso a m em oria no válido) o a una solicitud específica de un program a de usuario de que se realice un servicio del sistem a operativo. La carac­ terística de un sistem a operativo de estar controlado m ediante interrupciones define la estructura general de dicho sistema. Para cada tipo de interrupción, diferentes segm entos de código del sis­ tema operativo determ inan qué acción hay que llevar a cabo. Se utilizará una rutina de servicio a la interrupción que es responsable de tratarla. Dado que el sistem a operativo y los usuarios com parten los recursos hardw are y softw are del sistem a inform ático, necesitam os asegurar que un error que se produzca en un program a de usua­ rio sólo genere problem as en el programa que se estuviera ejecutando. Con la com partición, m uchos procesos podrían verse afectados negativam ente por un fallo en otro programa. Por ejem ­ plo, si un proceso entra en un bucle infinito, este bucle podría im pedir el correcto funcionam ien­ to de m uchos otros procesos. En un sistem a de m ultiprogram ación se pueden producir errores más sutiles, pudiendo ocurrir que un program a erróneo m odifique otro program a, los datos de otro program a o incluso al propio sistema operativo. Sin protección frente a este tipo de errores, o la com putadora sólo ejecuta un proceso cada vez o todas las salidas deben considerarse sospechosas. Un sistem a operativo diseñado apropiada­ m ente debe asegurar que un programa incorrecto (ó malicioso) no pueda dar lugar a que otros programas se ejecuten incorrectam ente.

1.5.1 Operación en m odo dual Para asegurar la correcta ejecución del sistema operativo, tenemos que poder distinguir entre la ejecución del código del sistem a operativo y del código definido por el usuario. El m étodo que usan la m ayoría de los sistem as inform áticos consiste en proporcionar soporte hard\yare que nos perm ita diferenciar entre varios modos de ejecución.

1.5 Operaciones del sistema operativo

17

Com o m ínim o, necesitam os dos m odos diferentes de operación: m odo usuario y m odo k e m e l (tam bién denom inado m odo de supervisor, m odo del sistem a o m odo privilegiado). Un bit, denom inado b it de m odo, se añade al hardware de la com putadora para indicar el m odo actual: kernel (0) o usuario (1). Con el bit de m odo podem os diferenciar entre una tarea que se ejecute en nom bre del sistem a operativo y otra que se ejecute en nombre del usuario. Cuando el sistema inform ático está ejecutando una aplicación de usuario, el sistema se encuentra en m odo de usua­ rio. Sin em bargo, cuando una aplicación de usuario solicita un servicio del sistema operativo (a través de una llam ada al sistem a), debe pasar del modo de usuario al m odo kem el para satisfacer la solicitud. Esto se m uestra en la Figura 1.8. Como veremos, esta m ejora en la arquitectura resul­ ta útil tam bién para m uchos otros aspectos del sistema operativo. Cuando se arranca el sistem a, el hardw are se inicia en el modo kem el. El sistem a operativo se carga y se inician las aplicaciones de usuario en el modo usuario. Cuando se produce una excep­ ción o interrupción, el hardw are conm uta del modo de usuario al m odo kem el (es decir, cam bia el estado del bit de modo a 0). En consecuencia, cuando el sistema operativo obtiene el control de la com putadora, estará en el modo kem el. El sistema siem pre cambia al m odo de usuario (poniendo el bit de m odo a 1) antes de pasar el control a un programa de usuario. El m odo dual de operación nos proporciona los medios para proteger el sistem a operativo de los usuarios que puedan causar errores, y tam bién para proteger a los usuarios de los errores de otros usuarios. Esta protección se consigue designando algunas de las instrucciones de m áquina que pueden causar daño com o instrucciones privilegiadas. El hardw are hace que las instruccio­ nes privilegiadas sólo se ejecuten en el m odo kem el. Si se hace un intento de ejecutar una instruc­ ción privilegiada en m odo de usuario, el hardware no ejecuta la instrucción sino que la trata como ilegal y envía una excepción al sistem a operativo. La instrucción para conm utar al modo usuario es un ejemplo de instrucción privilegiada. Entre otros ejem plos se incluyen el control de E/S, la gestión del tem porizador y la gestión de interrup­ ciones. A m edida que avancem os a lo largo del texto, veremos que hay m uchas instrucciones pri­ vilegiadas adicionales. Ahora podem os ver el ciclo de vida de la ejecución de una instrucción en un sistem a inform á­ tico. El control se encuentra inicialm ente en manos del sistema operativo, donde las instrucciones se ejecutan en el modo kem el. Cuando se da el control a una aplicación de usuario, se pasa a modo usuario. Finalm ente, el control se devuelve al sistema operativo a través de una interrupción, una excepción o una llam ada al sistema. Las llam adas al sistem a proporcionan los medios para que un program a de usuario pida al sis­ tema operativo que realice tareas reservadas del sistema operativo en nom bre del program a del usuario. Una llam ada al sistem a se invoca de diversas maneras, dependiendo de la funcionalidad proporcionada por el procesador subyacente. En todas sus formas, se trata de un m étodo usado por un proceso para solicitar la actuación del sistema operativo. N orm alm ente, una llam ada al sis­ tema toma la form a de una excepción que efectúa una transferencia a una posición específica en el vector de interrupción. Esta excepción puede ser ejecutada m ediante una instrucción genérica t r a p , aunque algunos sistem as (como la familia M IPS R2000) tienen una instrucción s y s c a l l específica. Cuando se ejecuta una llam ada al sistema, el hardware la trata com o una interrupción softw a­ re. El control pasa a través del vector de interrupción a una rutina de servicio del sistem a opera-

Figura 1.8 Transición de¡ rr.odo usuario a! modo kernel.

Capítulo 1 Introducción

tivo, y el bit de modo se establece en el modo kem el. La rutina de servicio de la llam ada al siste­ ma es una parte del sistem a operativo. El kem el exam ina la instrucción que interrum pe para deter­ minar qué llamada al sistem a se ha producido; un parám etro indica qué tipo de servicio está requiriendo el program a del usuario. Puede pasarse la inform ación adicional necesaria para la solicitud mediante registros, m ediante la pila o m ediante la memoria (pasando en los registros una serie de punteros a posiciones de m emoria). El kem el verifica que los parám etros son correc­ tos y legales, ejecuta la solicitud y devuelve el control a la instrucción siguiente a la de la llamada de servicio. En la Sección 2.3 se describen de form a m ás com pleta las llam adas al sistema. La falta de un m odo dual soportado por hardware puede dar lugar a serios defectos en un sis­ tema operativo. Por ejem plo, MS-DOS fue escrito para la arquitectura 8088 de Intel, que no dispone de bit de modo y, por tanto, tam poco del modo dual. U n programa de usuario que se ejecute erróneamente puede corrom per el sistem a operativo sobreescribiendo sus archivos; y múltiples programas podrían escribir en un dispositivo al mismo tiempo, con resultados posiblem ente desas­ trosos. Las versiones recientes de la CPU de Intel, com o por ejemplo Pentium , sí que proporcionan operación en modo dual. De acuerdo con esto, la m ayoría de los sistem as operativos actuales, como M icrosoft W indow s 2000, W indow s XP, Linux y Solaris para los sistem as x86, se aprovechan de esta característica y proporcionan una protección m ucho mayor al sistema operativo. Una vez que se dispone de la protección hardware, el hardware detecta los errores de viola­ ción de los modos. N orm alm ente, el sistem a operativo se encarga de tratar estos errores. Si un pro­ grama de usuario falla de alguna form a, com o por ejem plo haciendo un intento de ejecutar una instrucción ilegal o de acceder a una zona se m em oria que no esté en el espacio de m em oria del usuario, entonces el hardw are envía una excepción al sistem a operativo. La excepción transfiere el control al sistem a operativo a través del vector de interrupción, igual que cuando se produce una interrupción. Cuando se produce un error de program a, el sistem a operativo debe terminar el programa anorm alm ente. Esta situación se trata con el m ism o código softw are que se usa en una term inación anorm al solicitada por el usuario. El sistem a proporciona un m ensaje de error apropiado y puede volcarse la m em oria del programa. Normalmente, el volcado de memoria se escribe en un archivo con el fin de que el usuario o program ador puedan exam inarlo y quizá corregir y reiniciar el programa.

1.5.2 Temporizador Debemos asegurar que el sistem a operativo m antenga el control sobre la CPU. Por ejemplo, debe­ mos impedir que un program a de usuario entre en un bucle infinito o que no llame a los servicios del sistema y nunca devuelva el control al sistema operativo. Para alcanzar este objetivo, podemos usar un tem porizador. Puede configurarse un tem porizador para interrum pir a la com putadora después de un período especificado. El período puede ser fijo (por ejem plo, 1/60 segundos) o variable (por ejem plo, entre 1 m ilisegundo y 1 segundo). Generalm ente, se im plem enta un tem ­ porizador variable m ediante un reloj de frecuencia fija y un contador. El sistema operativo confi­ gura el contador. Cada vez que el reloj avanza, el contador se decrementa. Cuando el contador alcanza el valor 0, se produce una interrupción. Por ejem plo, un contador de 10 bits con un reloj de 1 milisegundo perm ite interrupciones a intervalos de entre 1 m ilisegundo y 1.024 mil ¿segun­ dos, en pasos de 1 m ilisegundo. Antes de devolver el control al usuario, el sistem a operativo se asegura de que el tem poriza­ dor esté configurado para realizar interrupciones. Cuando el tem porizador interrumpe, el control se transfiere autom áticam ente al sistem a operativo, que puede tratar la interrupción como un error fatal o puede conceder más tiem po al programa. Evidentem ente, las instrucciones que m odi­ fican el contenido del tem porizador son instrucciones privilegiadas. Por tanto, podem os usar el tem porizador para im pedir que un programa de usuario se esté eje­ cutando durante un tiem po excesivo. Una técnica sencilla consiste en inicializar un contador con la cantidad de tiempo que esté perm itido que se ejecute un programa. Para un programa con un límite de tiempo de 7 m inutos, por ejem plo, inicializaríam os su contador con el valor 420. Cada segundo, el tem porizador interrum pé y el contador se decrementa en una unidad. Mientras que el valor del contador sea positivo, el control se devuelve al programa de usuario. Cuando el valor

1.7 Gestión de memoria

19

del contador pasa a ser negativo, el sistem a operativo term ina el programa, por haber sido exce­ dido el límite de tiempo asignado.

Gestión de procesos Un program a no hace nada a m enos que una CPU ejecute sus instrucciones. U n programa en eje­ cución, com o ya hemos dicho, es un proceso. Un program a de usuario de tiempo compartido, com o por ejem plo un com pilador, es un proceso. Un procesador de textos que ejecute un usuario individual en un PC es un proceso. Una tarea del sistem a, com o enviar datos de salida a una im presora, tam bién puede ser un proceso (o al m enos, una parte de un proceso). Por el momento, vamos a considerar que un proceso es un trabajo o un program a en tiempo com partido, aunque más adelante verem os que el concepto es m ás general. Como verem os en el Capítulo 3, es posible proporcionar llam adas al sistem a que perm itan a los procesos crear subprocesos que se ejecuten de form a concurrente. Un proceso necesita para llevar a cabo su tarea ciertos recursos, entre los que incluyen tiempo de CPU, m em oria, archivos y dispositivos de E /S . Estos recursos se proporcionan al proceso en el m om ento de crearlo o se le asignan m ientras se está ejecutando. Adem ás de los diversos recursos físicos y lógicos que un proceso obtiene en el m om ento de su creación, pueden pasársele diversos datos de inicialización (entradas). Por ejem plo, considere un proceso cuya función sea la de m os­ trar el estado de un archivo en la pantalla de un terminal. A ese proceso le proporcionaríam os como entrada el nom bre del archivo y el proceso ejecutaría las apropiadas instrucciones y llam a­ das al sistem a para obtener y m ostrar en el term inal la inform ación deseada. Cuando el proceso termina, el sistem a operativo reclam a todos los recursos reutilizables. H agam os hincapié en que un program a por sí solo no es un proceso; un program a es una enti­ dad pasiva, tal com o los contenidos de un archivo alm acenado en disco, mientras que un proceso es una entidad activa. Un proceso de una sola hebra tiene un contador de programa que especifi­ ca la siguiente instrucción que hay que ejecutar, (las hebras se verán en el Capítulo 4). La ejecu­ ción de un proceso así debe ser secuencial: la CPU ejecuta una instrucción del proceso después de otra, hasta com pletarlo. A dem ás, en cualquier instante, se estará ejecutando com o m ucho una ins­ trucción en nom bre del proceso. Por tanto, aunque pueda haber dos procesos asociados con el mismo programa, se considerarían no obstante com o dos secuencias de ejecución separadas. Un proceso m ultihebra tiene m últiples contadores de program a, apuntado cada uno de ellos a la siguiente instrucción que haya que ejecutar para una hebra determ inada. Un proceso es una unidad de trabajo en un sistema. Cada sistem a consta de una colección de procesos, siendo algunos de ellos procesos del sistem a operativo (aquéllos que ejecutan código del sistema) y el resto procesos de usuario (aquéllos que ejecutan código del usuario). Todos estos procesos pueden, potencialm ente, ejecutarse de form a concurrente, por ejemplo multiplexando la CPU cuando sólo se disponga de una. El sistem a operativo es responsable de las siguientes actividades en lo que se refiere a la ges­ tión de procesos: • Crear y borrar los procesos de usuario y del sistema. • Suspender y reanudar los procesos. •

Proporcionar

m ecanism os para la

sincronización de procesos.

•

Proporcionar

m ecanism os para la

com unicación entre procesos.

•

Proporcionar

m ecanism os para el

tratamiento de los interbloqueos.

En los Capítulos 3 a 6 se estudian las técnicas de gestión de procesos.

Gestión de memoria Como se ha visto en la Sección 1.2.2, la m em oria principal es fundam ental en la operación de un sistema inform ático moderno. La memoria principal es una m atriz de palabras o bytes cuyo tam a­

Capítulo 1 Introducción

ño se encuentra en el rango de cientos de miles a m iles de m illones de posiciones distintas. Cada palabra o byte tiene su propia dirección. La m emoria principal es un repositorio de datos rápida­ mente accesibles, com partida por la CPU y los dispositivos de E /S . El procesador central lee las ins­ trucciones de la m em oria principal durante el ciclo de extracción de instrucciones y lee y escribe datos en la m em oria principal durante el ciclo de extracción de datos (en una arquitectura Von^ N eum ann). La m em oria principal es, generalm ente, el único dispositivo de alm acenam iento de gran tam año al que la CPU puede dirigirse y acceder directamente. Por ejem plo, para que la CPU procese datos de un disco, dichos datos deben transferirse en primer lugar a la memoria principal m ediante llam adas de E / S generadas por la CPU. Del m ism o modo, las instrucciones deben estar en m em oria para que la CPU las ejecute. Para que un program a pueda ejecutarse, debe estar asignado a direcciones absolutas y carga­ do en m em oria. M ientras el programa se está ejecutando, accede a las instrucciones y a los datos de la m em oria generando dichas direcciones absolutas. Finalm ente, el program a termina, su espa­ cio de m em oria se declara disponible y el siguiente program a puede ser cargado y ejecutado. Para m ejorar tanto la utilización de la CPU como la velocidad de respuesta de la com putadora frente a los usuarios, las com putadoras de propósito general pueden m antener varios programas en m em oria, lo que crea la necesidad de m ecanism os de gestión de la m em oria. Se utilizan m uchos esquem as diferentes de gestión de la m emoria. Estos esquemas utilizan enfoques distin­ tos y la efectividad de cualquier algoritm o dado depende de la situación. En la selección de un esquem a de gestión de m em oria para un sistem a específico, debemos tener en cuenta muchos fac­ tores, especialm ente relativos al diseño hardware del sistem a. Cada algoritm o requiere su propio soporte hardware. El sistem a operativo es responsable de las siguientes actividades en lo que se refiere a la ges­ tión de m emoria: • C ontrolar qué partes de la m em oria están actualm ente en uso y por parte de quién. • D ecidir qué datos y procesos (o partes de procesos) añadir o extraer de la memoria. • A signar y liberar la asignación de espacio de m em oria según sea necesario. En los Capítulos 8 y 9 se estudian las técnicas de gestión de la memoria.

Gestión de almacenamiento Para que el sistem a inform ático sea cóm odo para los usuarios, el sistema operativo proporciona una vista lógica y uniform e del sistem a de alm acenam iento de la información. El sistema operati­ vo abstrae las propiedades físicas de los dispositivos de alm acenam iento y define una unidad de alm acenam iento lógico, el archivo. El sistem a operativo asigna los archivos a los soportes físicos y accede a dichos archivos a través de los dispositivos de almacenamiento.

1.8.1 Gestión del sistema de archivos La gestión de archivos es uno de los com ponentes más visibles de un sistema operativo. Las com ­ putadoras pueden alm acenar la inform ación en diferentes tipos de medios físicos. Los discos m ag­ néticos, discos ópticos y cintas m agnéticas son los m ás habituales. Cada uno de estos medios tiene sus propias características y organización física. Cada m edio se controla m ediante un dispositivo, tal com o una unidad de disco o una unidad de cinta, que tam bién tiene sus propias característi­ cas distintivas. Estas propiedades incluyen la velocidad de acceso, la capacidad, la velocidad de transferencia de datos y el m étodo de acceso (secuencial o aleatorio). Un archivo es una colección de inform ación relacionada definida por su creador. Común­ mente, los archivos representan programas (tanto en form ato fuente como objeto) y datos. Los archivos de datos pueden ser numéricos, alfabéticos, alfanum éricos o binarios. Los archivos pue­ den tener un form ato libre (como, por ejemplo, los archivos de texto) o un form ato rígido, como ppr ejem plo una serie de cam pos fijos. Evidentem ente, el concepto de archivo es extrem adam en­ te general.

1.8 Gestión de almacenamiento

21

El sistem a operativo im plem enta el abstracto concepto de archivo gestionando los medios de alm acenam iento m asivos, com o las cintas y discos, y los dispositivos que los controlan. Asimismo, los archivos norm alm ente se organizan en directorios para hacer más fácil su uso. Por último, cuando varios usuarios tienen acceso a los archivos, puede ser deseable controlar quién y en qué form a (por ejem plo, lectura, escritura o modificación) accede a los archivos. El sistem a operativo es responsable de las siguientes actividades en lo que se refiere a la ges­ tión de archivos: • Creación y borrado de archivos. • C reación y borrado de directorios para organizar los archivos. • Soporte de prim itivas para m anipular archivos y directorios. • A signación de archivos a ios dispositivos de alm acenam iento secundario. • Copia de seguridad de los archivos en medios de alm acenam iento estables (no volátiles). Las técnicas de gestión de archivos se tratan en los Capítulos 10 y 11.

1.8.2 Gestión del almacenamiento masivo Com o ya hem os visto, dado que la memoria principal es dem asiado pequeña para acomodar todos los datos y program as, y puesto que los datos que guarda se pierden al desconectar la ali­ m entación, el sistema inform ático debe proporcionar un alm acenam iento secundario com o respal­ do de la m em oria principal. La mayoría de los sistemas inform áticos m odernos usan discos como principal m edio de alm acenam iento en línea, tanto para los program as com o para los datos. La m ayor parte de los program as, incluyendo com piladores, ensam bladores o procesadores de texto, se alm acenan en un disco hasta que se cargan en m emoria, y luego usan el disco com o origen y destino de su procesam iento. Por tanto, la apropiada gestión del alm acenam iento en disco tiene una im portancia crucial en un sistema informático. El sistem a operativo es responsable de las siguientes actividades en lo que se refiere a la gestión de disco: • G estión del espacio libre. • A signación del espacio de almacenamiento. • Planificación del disco. . Dado que el alm acenam iento secundario se usa con frecuencia, debe em plearse de form a efi­ ciente. La velocidad final de operación de una com putadora puede depender de las velocidades del subsistem a de disco y de los algoritmos que m anipulan dicho subsistema. Sin em bargo, hay m uchos usos para otros sistemas de alm acenam iento más lentos y más bara­ tos (y que, en ocasiones, proporcionan una mayor capacidad) que el alm acenam iento secundario. La realización de copias de seguridad de los datos del disco, el alm acenam iento de datos raram en­ te utilizados y el alm acenam iento definitivo a largo plazo son algunos ejemplos. Las unidades de cinta m agnética y sus cintas y las unidades de CD y DVD y sus discos son dis­ positivos típicos de alm acenam iento terciario. Los soportes físicos (cintas y discos ópticos) varí­ an entre los form atos WORM (write-once, read-m any-tim es; escritura una vez, lectura muchas veces) y RW (read-write, lectura-escritura). El alm acenam iento terciario no es crucial para el rendim iento del sistem a, aunque tam bién es necesario gestionarlo. A lgunos sistemas operativos realizan esta tarea, m ientras que otros dejan el control del alm acenam iento terciario a los programas de aplicación. Algunas de las funciones que dichos sistem as operativos pueden proporcionar son el m ontaje y desm ontaje de medios en los dispositivos, la asignación y liberación de dispositivos para su uso exclusivo por los procesos, y la m igración de datos del alm acenam iento secundario a! terciario. Las técnicas para la gestión del alm acenam iento secundario y terciario se estudian en el Capítulo 12.

Capítulo 1 Introducción

1.8.3 Almacenamiento en caché E l alm acenam iento en cach é es una técnica im portante en los sistem as inform áticos. N orm alm ente, la inform ación se m antiene en algún sistem a de alm acenam iento, como por ejem ­ plo la m em oria principal. C uando se usa, esa inform ación se copia de form a tem poral en un sis­ tema de alm acenam iento m ás rápido, la caché. Cuando necesitam os una inform ación particular, prim ero com probam os si está en la caché. Si lo está, usamos directam ente dicha inform ación de la caché; en caso contrario, utilizam os la inform ación original, colocando una copia en la caché bajo la suposición de que pronto la necesitarem os nuevamente. Además, los registros program ables internos, como los registros de índice, proporcionan una caché de alta velocidad para la m em oria principal. El program ador (o com pilador) im plementa los algoritmos de asignación de recursos y de reem plazam iento de registros para decidir qué infor­ m ación m antener en los registros y cuál en la memoria principal. Tam bién hay disponibles caches que se im plem entan totalm ente m ediante hardware. Por ejem plo, la m ayoría de los sistemas dis­ ponen de una caché de instrucciones para alm acenar las siguientes instrucciones en espera de ser ejecutadas. Sin esta caché, la CPU tendría que esperar varios ciclos m ientras las instrucciones son extraídas de la m em oria principal. Por razones similares, la m ayoría de los sistem as disponen de una o más cachés de datos de alta velocidad en la jerarquía de memoria. En este libro no vam os a ocuparnos de estás cachés im plem entadas totalmente m ediante hardware, ya que quedan fuera del control del sistema operativo. Dado que las cachés tienen un tam año limitado, la gestión de la caché es un problem a de dise­ ño im portante. La selección cuidadosa del tamaño de la caché y de una adecuada política de reem ­ plazam iento puede dar com o un resultado un incremento enorm e del rendim iento. Consulte la Figura 1.9 para ver una com parativa de las prestaciones de alm acenam iento en las estaciones de trabajo grandes y pequeños servidores; dicha com parativa ilustra perfectam ente la necesidad de usar el alm acenam iento en caché. En el Capítulo 9 se exponen varios algoritm os de reem plaza­ miento para cachés controladas por softw are. La m em oria principal puede verse com o una caché rápida para el alm acenam iento secundario, ya que los datos en alm acenam iento secundario deben copiarse en la m em oria principal para poder ser utilizados, y los datos deben encontrarse en la memoria principal antes de ser pasados al alm acenam iento secundario cuando llega el momento de guardarlos. Los datos del sistema de archivos, que residen perm anentem ente en el alm acenam iento secundario, pueden aparecer en varios niveles de la jerarquía de alm acenam iento. En el nivel superior, el sistem a operativo puede m antener una caché de datos del sistem a de archivos en la memoria principal. Tam bién pueden utilizarse discos RAM (tam bién conocidos como discos de estado sólido) para alm acenam iento de alta velocidad, accediendo a dichos discos a través de la interfaz del sistem a de archivos. La mayor parte del alm acenam iento secundario se hace en discos m agnéticos. Los datos alm acena­ dos en disco magnético, a su vez, se copian a menudo en cintas m agnéticas o discos extraíbles con el fin de protegerlos frente a pérdidas de datos en caso de que un disco duro falle. Algunos siste­ mas realizan autom áticam ente un archivado definitivo de los datos correspondientes a los archi­ vos antiguos, transfiriéndolos desde el alm acenam iento secundario a un alm acenam iento terciario, com o por ejem plo un servidor de cintas, con el fin de reducir costes de alm acenam iento (véase el Capítulo 12). El m ovim iento de inform ación entre niveles de una jerarquía de alm acenam iento puede ser explícito o implícito, dependiendo del diseño hardware y del software del sistem a operativo que controle dicha funcionalidad. Por ejem plo, la transferencia de datos de la caché a la CPU y los registros es, norm alm ente, una función hardware en la que no interviene el sistema operativo. Por el contrario, la transferencia de datos de disco a memoria norm alm ente es controlada por el siste­ ma operativo. En una estructura de alm acenam iento jerárquica, los m ismos datos pueden aparecer en dife­ rentes niveles del sistem a de alm acenam iento. Por ejemplo, suponga que un entero A que hay que increm entar en 1 se encuentra alm acenado en el archivo B, el cual reside en un disco magnético. La operación de increm ento ejecuta prim ero una operación de E/S para copiar el bloque de disco en el que reside A a la m em oria principal. A continuación se copia A en la caché y en un registro

1.8 Gestión de almacenamiento

Nivel

1

2

Nombre

registros':*''-'

caché

Tamaño típico

< ! iS

í

1n 1

u

'^

3 ~

>■

> 16 MB,

23

4

memoria pnndpel almacenamiento en disco

> 100 GB

> 16GBí"&. r * -.-i

'-SBAti^CtfOSgk . imptementación

müifipfespoertos, CMOS on-chip u oftchip

Tiempo de acceso (ns)

0 2 5 - O S * * 1,

0 ,5 -2 5 » '

Ancho de banda (Mfi/s)

20000-100000

5000-10000

1000 - 5000"'

Gestionado por

compilador ~

hardware

stóiemropBraBvo

■*

.v .. . ’/C » v 8 0 * 2 5 0 ^ ü ^ fr . 5,000000*-

memoria principal disco

Copiado en

2 0 -1 5 0 sistema operat$brr "’

■ CD’ o.cmta U J♦A /s• » o - 2*,vw-

Figura 1.9. Prestaciones de los distintos niveles de almacenamiento.

Figura 1.10 Migración de un entero A del disco a un registro. interno. Por tanto, la copia de A aparece en varios lugares: en el disco magnético, en la memoriaprincipal, en la caché y en un registro interno (véase la Figura 1.10). Una vez que se hace el incre­ mento en el registro interno, el valor de A es distinto en los diversos sistemas de alm acenam iento. El valor de A sólo será el m ismo después de que su nuevo valor se escriba desde el registro inter­ no al disco magnético. En un entorno inform ático donde sólo se ejecuta un proceso cad a vez, este proceso no plantea ninguna dificultad, ya que un acceso al entero A siem pre se realizará a la copia situada en el nivel m ás alto de la jerarquía. Sin em b argo, en un entorno m ultitarea, en el que la CPU conm uta entre varios procesos, hay que tener un extrem o cu id ad o p ara asegu rar que, si varios procesos desean acceder a A, cad a uno de ellos obtenga el valor m ás recientem ente actualizado de A.

La situación se hace más com plicada en un entorno m ultiprocesador donde, adem ás de m an­ tener registros internos, cada una de las CPU tam bién contiene una caché local. En un entorno de este tipo, una copia de A puede encontrarse sim ultáneam ente en varias cachés. Dado que las diversas CPU puede ejecutar instrucciones concurrentem ente, debem os asegurarnos de que una actualización del valor de A en una caché se refleje inm ediatam ente en las restantes cachés en las que reside A. Esta situación se denom ina co h eren cia de cach é y, norm alm ente, se trata de un pro­ blema de hardware, que se gestiona por debajo del nivel del sistem a operativo. En un entorno distribuido, la situación se hace incluso más com pleja. En este tipo de entorno, varias copias (o réplicas) del m ism o archivo pueden estar en diferentes com putadoras distribui­ das geográficam ente. Dado que se puede acceder de form a concurrente a dichas réplicas y actua­ lizarlas, algunos sistemas distribuidos garantizan que, cuando una réplica se actualiza en un sitio, todas las dem ás réplicas se actualizan lo más rápidam ente posible. Existen varias form as de pro­ porcionar esta garantía, com o se verá en el Capítulo 17.

1.8.4 Sistemas de E/S Uno de los propósitos de un sistem a operativo es ocultar al usuario las peculiaridades de los dis­ positivos hardware específicos. Por ejem plo, en UNIX, las peculiaridades de los dispositivos de E /S se ocultan a la m avor parte del propio sistema operativo m ediante el subsistem a de E/S. El sub­ sistema de E/ S consta de varios com ponentes: • Un com ponente de gestión de memoria que incluye alm acenam iento en búfer, gestión de caché y gestión de colas. • Una interfaz general para controladores de dispositivo.

24

Capítulo 1 Introducción

• Controladores para dispositivos hardware específicos. Sólo el controlador del dispositivo conoce las peculiaridades del dispositivo específico al que está asignado. En la Sección 1.2.3 se expone cómo se usan las rutinas de tratamiento de interrupciones y los controladores de dispositivo en la construcción de subsistem as de E /S eficientes. En el Capítulo 13 se aborda el modo-en q'ue el subsistema de E /S interactúa con los otros com ponentes del siste­ m a, gestiona los dispositivos, transfiere datos y detecta que las operaciones de E /S han concluido.

1.9

Protección y seguridad Si un sistem a inform ático tiene múltiples usuarios y perm ite la ejecución concurrente de múltiples procesos, entonces el acceso a los datos debe regularse. P ara dicho propósito, se em plean m eca­ nism os que aseguren que sólo puedan utilizar los recursos (archivos, segm entos de m em oria, CPU y otros) aquellos procesos que hayan obtenido la ap rop iad a autorización del sistem a operativo. P or ejem plo, el h ard w are de direccionam iento de m em oria asegura que un proceso sólo se pueda ejecutar dentro de su prop io espacio de m em oria; el tem porizador asegura que ningún proceso p u ed a obtener el control de la CPU sin después ceder el control; los usuarios no pueden acced er a los registros de control, p o r lo que la integridad de los diversos dispositivos periféricos está pro­ tegida, etc.

Por tanto, protección es cualquier m ecanism o que controle el acceso de procesos y usuarios a los recursos definidos por un sistema informático. Este m ecanism o debe proporcionar los medios para la especificación de los controles que hay que im poner y para la aplicación de dichos con­ troles. Los mecanism os de protección pueden m ejorar la fiabilidad, permitiendo detectar errores laten­ tes en las interfaces entre los subsistemas componentes. La detección temprana de los errores de interfaz a m enudo puede evitar la contaminación de un subsistema que funciona perfectamente por parte de otro subsistema que funcione mal. Un recurso desprotegido rio puede defenderse con­ tra el uso (o mal uso) de un usuario no autorizado o incompetente. Un sistema orientado a la pro­ tección proporciona un m edio para distinguir entre un uso autorizado y no autorizado, como se explica en el Capítulo 14. Un sistem a puede tener la protección adecuada pero estar expuesto a fallos y permitir accesos inapropiados. Considere un usuario al que le han robado su información de autenticación (los medios de identificarse ante el sistema); sus datos podrían ser copiados o borrados, incluso aun­ que esté funcionando la protección de archivos y de m emoria. Es responsabilidad de los m ecanis­ mos de seg u rid ad defender al sistema frente a ataques internos y externos. Tales ataques abarcan un enorm e rango, en el que se incluyen los virus y gusanos, los ataques de denegación de servi­ cio (que usan todos los recursos del sistem a y m antienen a los usuarios legítim os fuera del siste­ ma), el robo de identidad y el robo de servicio (el uso no autorizado de un sistem a). La prevención de algunos de estos ataques se considera una función del sistem a operativo en algunos sistemas, m ientras que en otros se deja a la política de prevención o a algún software adicional. Debido a la creciente alarm a en lo que se refiere a incidentes de seguridad, las características de seguridad del sistem a operativo constituyen un área de investigación e im plem entación en rápido crecimiento. Los temas relativos a la seguridad se estudian en el Capítulo 15. La protección y la seguridad requieren que el sistem a pueda distinguir a todos sus usuarios. La m ayoría de los sistem as operativos m antienen una lista con los nom bres de usuario y sus identificad o res de u su ario (ID) asociados. En la jerga de W indow s NT, esto se denomina ID de seg u ­ rid ad (SID, secu rity ID). Estos ID num éricos son unívocos, uno por usuario. Cuando un usuario inicia una sesión en el sistem a, la fase de autenticación determ ina el ID correspondiente a dicho usuario. Ese ID de usuario estará asociado con todos los procesos y hebras del usuario. Cuando un ID necesita poder ser leído por los usuarios, se utiliza la lista de nombres de usuario para tra­ ducir el ID al nom bre correspondiente. En algunas circunstancias, es deseable diferenciar entre conjuntos de usuarios en lugar d e entre usuarios individuales. Por ejemplo, el propietario de un archivo en un sistem a UXIX p u e d e ejecu­

1.10 Sistemas distribuidos

25

tar todas las operaciones sobre dicho archivo, m ientras que a un conjunto seleccionado de usua­ rios podría perm itírsele sólo leer el archivo. Para conseguir esto, es necesario definir un nombre de grupo y especificar los usuarios que pertenezcan a dicho grupo. La funcionalidad de grupo se puede im plem entar m anteniendo en el sistem a una lista de nom bres de grupo e id en tificad ores de g ru p o . U n usuario puede pertenecer a uno o m ás grupos, dependiendo de las decisiones de diseño del sistem a operativo. Los ID de grupo del usuario tam bién se incluyen en todos los-pro­ cesos y hebras asociados. D urante el uso norm al de un sistem a, el ID de usuario y el ID de grupo de un usuario son sufi­ cientes. Sin em bargo, en ocasiones, un usuario necesita escalar sus p rivilegios para obtener per­ m isos adicionales para una actividad. Por ejem plo, el usuario puede necesitar acceder a un dispositivo que está restringido. Los sistem as operativos proporcionan varios métodos para el escalado de privilegios. Por ejemplo, en UNIX, el atributo s e t u i d en un programa hace que dicho program a se ejecute con el ID de usuario del propietario del archivo, en lugar de con el ID del usuario actual. El proceso se ejecuta con este UID efectivo hasta que se desactivan los privilegios adicionales o se term ina el proceso. Veam os un ejem plo de cóm o se hace esto en Solaris 10: el usuario pbg podría tener un ID de usuario igual a 101 y un ID de grupo igual a 14, los cuales se asignarían m ediante / e t c / p a s s w d :p b g :x : 1 0 1 : 1 4 : : / e x p o rt/ h o m e / p b g : / u s r / b in / b a s h .

1.10 Sistemas distribuidos Un sistem a distribuido es una colección de com putadoras físicam ente separadas y posiblem ente heterogéneas que están conectadas en red para proporcionar a los usuarios acceso a los diversos recursos que el sistem a m antiene. Acceder a un recurso com partido increm enta la velocidad de cálculo, la funcionalidad, la disponibilidad de los datos y la fiabilidad. Algunos sistemas operati­ vos generalizan el acceso a red como una form a de acceso a archivo, m anteniendo los detalles de la conexión de red en el controlador de dispositivo de la interfaz de red. Otros sistemas operati­ vos invocan específicam ente una serie de funciones de red. Generalm ente, los sistemas contienen una m ezcla de los dos m odos, com o por ejem plo FTP y NFS. Los protocolos que forman un siste­ ma distribuido pueden afectar enorm em ente a la popularidad y utilidad de dicho sistema. En térm inos sencillos, una red es una vía de com unicación entre dos o más sistemas. La fun­ cionalidad de los sistem as distribuidos depende de la red. Las redes varían según el protocolo que usen, las distancias entre los nodos y el medio de transporte. TCP/IP es el protocolo de red más com ún, aunque el uso de ATM y otros protocolos está bastante extendido. Asimismo, los proto­ colos soportados varían de unos sistem as operativos a otros. La m ayoría de los sistemas operati­ vos soportan TCP/IP, incluidos los sistem as operativos W indow s y UNIX. Algunos sistemas soportan protocolos propietarios para ajustarse a sus necesidades. En un sistema operativo, un protocolo de red sim plem ente necesita un dispositivo de interfaz (por ejem plo, un adaptador de red), con un controlador de dispositivo que lo gestione y un softw are para tratar los datos. Estos conceptos se explican a lo largo del libro. Las redes se caracterizan en función de las distancias entre sus nodos. Una red de área local (LAN) conecta una serie de com putadoras que se encuentran en una misma habitación, planta o edificio. N orm alm ente, una red de área exten d id a (WAN) conecta varios edificios, ciudades o paí­ ses; una m ultinacional puede disponer de una red WAN para conectar sus oficinas en todo el m undo. Estas redes pueden ejecutar uno o varios protocolos y la continua aparición de nuevas tecnologías está dando lugar a nuevas formas de redes. Por ejem plo, una red de área m etrop oli­ tan a (MAN, m etropolitan-area network) puede conectar diversos edificios de una ciudad. Los dis­ positivos BlueTooth y 802.11 utilizan tecnología inalám brica para com unicarse a distancias de unos pocos m etros, creando en esencia lo que se denom ina una red de área peq u eñ a, como la que puede haber en cualquier hogar. Los soportes físicos o m edios que se utilizan para im plem entar las redes son igualmente varia­ dos. Entre ellos se incluyen el cobre, la fibra óptica y las transm isiones inalám bricas entre satéli­ tes, antenas de m icroondas y aparatos de radio. Cuando se conectan los dispositivos informáticos a, teléfonos móviles, se puede crear una red. Tam bién se puede em plear incluso com unicación por infrarrojos de corto alcance para establecer una red. A nivel rudim entario, siempre que las com ­

26

Capítulo 1 Introducción

putadoras se com uniquen, estarán usando o creando una red. Todas estas redes también varían en cuanto a su rendim iento y su fiabilidad. Algunos sistem as operativos han llevado el concepto de redes y sistem as distribuidos más allá de la noción de proporcionar conectividad de red. Un sistema operativo de red es un sistema ope­ rativo que proporciona funcionalidades com o la com partición de archivos a través de la red y que incluye un esquem a de com unicación que perm ite a diferentes procesos, en diferentes com puta­ doras, intercam biar m ensajes. Una com putadora que ejecuta un sistem a operativo de red actúa autónom am ente respecto de las restantes com putadoras de la red, aunque es consciente de la red y puede com unicarse con los dem ás equipos conectados en red. Un sistem a operativo distribuido proporciona un entorno m enos autónomo. Los diferentes sistem as operativos se comunican de modo que se crea la ilusión de que un único sistema operativo controla la red. En los Capítulos 16 a 18 verem os las redes de com putadoras y los sistem as distribuidos.

1.11 Sistemas de propósito general La exposición ha estado enfocada hasta ahora sobre los sistem as inform áticos de propósito gene­ ral con los que todos estam os fam iliarizados. Sin embargo, existen diferentes clases de sistemas inform áticos cuyas funciones son más limitadas y cuyo objetivo es tratar con dom inios de proce­ samiento limitados.

1.11.1 Sistemas em bebidos en tiempo real Las com putadoras em bebidas son las com putadoras predom inantes hoy en día. Estos dispositi­ vos se encuentran por todas partes, desde los m otores de autom óviles y los robots para fabrica­ ción, hasta los m agnetoscopios y los hornos de m icroondas. Estos sistem as suelen tener tareas m uy específicas. Los sistem as en los que operan usualm ente son prim itivos, por lo que los siste­ mas operativos proporcionan funcionalidades limitadas. U sualm ente, disponen de una interfaz de usuario m uy lim itada o no disponen de ella en absoluto, prefiriendo invertir su tiempo en m onitorizar y gestionar dispositivos hardware, como por ejem plo m otores de autom óvil y brazos robóticos. Estos sistem as em bebidos varían considerablem ente. Algunos son com putadoras de propósito general que ejecutan sistem as operativos estándar, como UNIX, con aplicaciones de propósito especial para im plementar la funcionalidad. Otros son sistem as hardw are con sistem as operativos em bebidos de propósito especial que sólo proporcionan la funcionalidad deseada. Otros son dis­ positivos hardw are con circuitos integrados específicos de la aplicación (ASIC, application speci. fie integrated circuit), que realizan sus tareas sin ningún sistem a operativo. El uso de sistem as em bebidos continúa expandiéndose. La potencia de estos dispositivos, tanto si trabajan com o unidades autónom as como si se conectan a redes o a la W eb, es seguro que tam ­ bién continuará increm entándose. Incluso ahora, pueden inform atizarse casas enteras, dé modo que una com putadora central (una com putadora de propósito general o un sistem a embebido) puede controlar la calefacción y la luz, los sistemas de alarm a e incluso la cafetera. El acceso web puede perm itir a alguien llam ar a su casa para poner a calentar el café antes de llegar. Algún día, la nevera llamará al superm ercado cuando falte leche. Los sistem as em bebidos casi siem pre ejecutan sistemas operativos en tiempo real. Un sistema en tiempo real se usa cuando se han establecido rígidos requisitos de tiem po en la operación de un procesador o del flujo de datos; por ello, este tipo de sistem a a m enudo se usa com o dispositi­ vo de control en una aplicación dedicada. Una serie de sensores proporcionan los datos a la com ­ putadora. La com putadora debe analizar los datos y, posiblem ente, ajustar los controles con el fin de m odificar los datos de entrada de los sensores. Los sistem as que controlan experimentos cien­ tíficos, los de imágenes m édicas, los de control industrial y ciertos sistem as de visualización son sistem as en tiempo real. Algunos sistemas de inyección de gasolina para motores de automóvil, algunas controladoras de electrodom ésticos y algunos sistem as de arm am ento son también siste­ mas en tiempo real.

1.11 Sistemas de propósito general

27

Un sistem a en tiempo real tiene restricciones fijas y bien definidas. El procesam iento tiene que hacerse dentro de las restricciones definidas o el sistem a fallará. Por ejem plo, no sirve de nada ins­ truir a un brazo de robot para que se pare después de haber golpeado el coche que estaba constru­ yendo. Un sistem a en tiem po real funciona correctam ente sólo si proporciona el resultado correcto dentro de sus restricciones de tiem po. Este tipo de sistem a contrasta con los sistemas de tiempo com partido, en los que es deseable (aunque no'obligatorio) que el sistem a responda rápidam en­ te, y tam bién contrasta con los sistem as de procesam iento por lotes, que no tienen ninguna restric­ ción de tiem po en absoluto. En el Capítulo 19, verem os los sistem as em bebidos en tiem po real con más detalle. En el Capítulo 5, presentarem os la facilidad de planificación necesaria para im plementar la funcionali­ dad de tiempo real en un sistem a operativo. En el Capítulo 9 se describe el diseño de la gestión de m em oria para sistem as en tiem po real. Por último, en el Capítulo 22, describiremos los com ponen­ tes de tiem po real del sistem a operativo W indows XP.

1.11.2 Sistemas m ultimedia La m ayor parte de los sistem as operativos están diseñados para gestionar datos convencionales, com o archivos de texto, program as, documentos de procesadores de textos y hojas de cálculo. Sin em bargo, una tendencia reciente en la tecnología inform ática es la incorporación de datos m ulti­ m edia en los sistem as. Los datos m ultim edia abarcan tanto archivos de audio y vídeo, como archi­ vos convencionales. Estos datos difieren de los convencionales en que los datos m ultim edia (como por ejem plo los fotogram as de una secuencia de vídeo) deben sum inistrarse cum pliendo ciertas restricciones de tiem po (por ejem plo, 30 imágenes por segundo). La palabra m ultim edia describe un amplio rango de aplicaciones que hoy en día son de uso popular. Incluye los archivos de audio (por ejem plo M P3), las películas de DVD, la videoconferen­ cia y las secuencias de vídeo con anuncios de películas o noticias que los usuarios descargan a tra­ vés de Internet. Las aplicaciones m ultim edia tam bién pueden incluir webcasts en directo (m ultidifusión a través de la W orld W ide W eb) de conferencias o eventos deportivos, e incluso cám aras web que perm iten a un observador que esté en M anhattan ver a los clientes de un café en París. Las aplicaciones m ultim edia no tienen por qué ser sólo audio o vídeo, sino que a m enu­ do son una com binación de am bos tipos de datos. Por ejemplo, una película puede tener pistas de audio y de vídeo separadas. Adem ás, las aplicaciones m ultim edia no están lim itadas a los PC de escritorio, ya que de m anera creciente se están dirigiendo a dispositivos más pequeños, como los PDA y teléfonos m óviles. Por ejem plo, un corredor de bolsa puede tener en su PDA en tiempo real y por vía inalám brica las cotizaciones de bolsa. En el Capítulo 20, exploram os la demanda de aplicaciones m ultim edia, analizando en qué difieren los datos m ultim edia de los datos convencionales y cóm o la naturaleza de estos datos afecta al diseño de los sistem as operativos que dan soporte a los requisitos de los sistem as m ul­ timedia.

1.11.3 Sistemas de mano Los sistem as de m ano incluyen los PDA (personal digital assistant, asistente digital personal), tales com o los Palm y Pocket-PC, y los teléfonos m óviles, muchos de los cuales usan sistem as operati­ vos em bebidos de propósito especial. Los desarrolladores de aplicaciones y sistem as de m ano se enfrentan a m uchos retos, la m ayoría de ellos debidos al tamaño limitado de dichos dispositivos. Por ejem plo, un PDA tiene una altura aproxim ada de 13 cm y un ancho de 8 cm, y pesa m enos de 200 gramos. Debido a su tam año, la m ayoría de los dispositivos de m ano tienen muy poca m em o­ ria, procesadores lentos y pantallas de visualización pequeñas. Veam os cada una de estas lim ita­ ciones. La cantidad de m em oria física en un sistem a de mano depende del dispositivo, pero norm al­ m ente se encuentra entre 512 KB y 128 MB (com pare estos núm eros con un típico PC o una esta­ ción de trabajo, que puede cener varios gigabytes de memoria). Como resultado, el sistema operativo y las aplicaciones deben gestionar la m em oria de form a muy eficiente. Esto incluye

28

Capítulo 1 Introducción

devolver toda la m em oria asignada al gestor de m em oria cuando ya no se esté usando. En el Capitulo 9 explorarem os la memoria virtual, que perm ite a los desarrolladores escribir programas que se com portan com o si el sistema tuviera más m em oria que la físicam ente disponible. Actualm ente, no m uchos dispositivos de mano usan las técnicas de m em oria virtual, por los que los desarrolladores de program as deben trabajar dentro de los confines de la limitada memoria física. Un segundo problem a que afecta a los desarrolladores de dispositivos de mano es la velocidad del procesador usado en los dispositivos. Los procesadores de la m ayor parte de los dispositivos de m ano funcionan a una fracción de la velocidad de un procesador típico para PC. Los procesa­ dores requieren mayor cantidad de energía cuanto más rápidos son. Para incluir un procesador más rápido en un dispositivo de mano sería necesaria una batería m ayor, que ocuparía más espa­ cio o tendría que ser reem plazada (o recargada) con m ayor frecuencia. La m ayoría de los disposi­ tivos de mano usan procesadores más pequeños y lentos, que consum en m enos energía. Por lauto, las aplicaciones y el sistem a operativo tienen que diseñarse para no im poner una excesiva caiga al procesador. El últim o problem a al que se enfrentan los diseñadores de program as para dispositivos de mano es la E/S. La falta de espacio físico limita los m étodos de entrada a pequeños teclados, sis­ temas de reconocim iento de escritura manual o pequeños teclados basados en pantalla. Las pequeñas pantallas de visualización limitan asimismo las opciones de salida. M ientras que un m onitor de un PC dom éstico puede medir hasta 30 pulgadas, la pantalla de un dispositivo de mano a menudo no es m ás que un cuadrado de 3 pulgadas. Tareas tan fam iliares com o leer un correo electrónico o navegar por diversas páginas w eb se tienen que condensar en pantallas muy pequeñas. Un m étodo para mostrar el contenido de una página w eb es el recorte web, que con­ siste en que sólo se sum inistra y se m uestra en el dispositivo de m ano un pequeño subconjunto de una página web. Algunos dispositivos de mano utilizan tecnología inalám brica, com o BlueTooth o 802.1 L per­ m itiendo el acceso rem oto al correo electrónico y la exploración web. Los teléfonos m óviles con conectividad a Internet caen dentro de esta categoría. Sin em bargo, para los PD A que no disponen de acceso inalám brico, descargar datos requiere norm alm ente que el usuario descargue primero los datos en un PC o en una estación de trabajo y luego transfiera los datos al PDA . A lgunos PDA perm iten que los datos se copien directamente de un dispositivo a otro usando un enlace de u ltr a ­ rrojos. Generalm ente, las lim itaciones en la funcionalidad de los PDA se equilibran con su p o rta b ih dad y su carácter práctico. Su uso continúa increm entándose, a m edida que hav disponibles mas conexiones de red y otras opciones, com o cám aras digitales y reproductores M P3, que increm en­ tan su utilidad.

1.12 Entornos informáticos Hasta ahora, hemos hecho una introducción a la organización de los sistem as inform áticos y ios principales com ponentes de los sistem as operativos. Vam os a concluir con una breve introducción sobre cóm o se usan los sistem as operativos en una variedad de entornos inform áticos.

1.12.1 Sistema informático tradicional A m edida que la inform ática m adura, las líneas que separan m uchos de los entorn os intovnuucos tradicionales se difum inan. C onsidere el “típico entorno de oficina”. H ace unos pocos anos este entorno consistía en equipos PC conectados m ediante una red, con serv id o res que propor­ cionaban servicios de archivos y de im presión. El acceso rem oto era difícil v la portabilidae. >e conseguía m ediante el uso de com putadoras portátiles. Tam bién los term in ales conectac.cs a m ainframes predom inaban en m uchas em presas, con algunas opciones de acceso rem oto \ porraV \¡11rl nVl. ri UlilUW La tendencia actualAe dirige a proporcionar más form as de acceso a estos entornos inlonnaneos. Las tecnologías web están extendiendo los límites de la inform ática traduc e na!. Las empresa.-

1.12 Entornos informáticos

29

establecen portales, que proporcionan acceso web a sus servidores internos. Las com putadoras de red son, esencialm ente, term inales que im plem entan la noción de informática basada en la Web. Las com putadoras de m ano pueden sincronizarse con los PC, para hacer un uso más portable de la inform ación de la em presa. Los PDA de m ano tam bién pueden conectarse a redes inalám bricas para usar eljaortal web de la em presa (así com o una m ultitud de otros recursos web). En los hogares, la m ayoría de los usuarios disponían de una sola com putadora con una lenta conexión por módem con la oficina, con Internet o con ambos. Actualmente, las velocidades de conexión de red que antes tenían un precio prohibitivo son ahora relativamente baratas y propor­ cionan a los usuarios dom ésticos un m ejor acceso a una m ayor cantidad de datos. Estas conexio­ nes de datos rápidas están perm itiendo a las com putadoras domésticas servir páginas web y funcionar en redes que incluyen im presoras, clientes tipo PC y servidores. En algunos hogares se dispone incluso de cortafuegos (o servidores de seguridad) para proteger sus redes frente a posi­ bles brechas de seguridad. Estos cortafuegos eran extrem adam ente caros hace unos años y hace una década ni siquiera existían. En la segunda mitad del siglo pasado, los recursos inform áticos eran escasos (¡y antes, inexis­ tentes!). Durante bastante tiempo, los sistem as estuvieron separados en dos categorías: de proce­ samiento por lotes e interactivos. Los sistem as de procesam iento por lotes procesaban trabajos m asivos, con una entrada predeterm inada (procedente de archivos u otros orígenes de datos). Los sistem as interactivos esperaban la introducción de datos por parte del usuario. Para optim izar el uso de los recursos inform áticos, varios usuarios com partían el tiempo en estos sistem as. Los sis­ temas de tiempo com partido em pleaban un tem porizador y algoritm os de planificación para eje­ cutar rápidam ente una serie de procesos por tum os en la CPU, proporcionando a cada usuario una parte de los recursos. Hoy en día, los sistem as tradicionales de tiempo com partido no son habituales. Las mismas técnicas de planificación se usan todavía en estaciones de trabajo y servidores, aunque frecuente­ mente los procesos son todos propiedad del mismo usuario (o del usuario y del sistem a operati­ vo). Los procesos de usuario y los procesos del sistema que proporcionan servicios al usuario son gestionados de manera que cada uno tenga derecho frecuentem ente a una parte del tiempo. Por ejem plo, considere las ventanas que se m uestran mientras un usuario está trabajando en un PC y el hecho de que puede realizar varias tareas al mismo tiempo.

1.12.2 Sistema cliente-servidor A m edida que los PC se han hecho más rápidos, potentes y baratos, los diseñadores han ido aban­ donando la arquitectura de sistemas centralizada. Los term inales conectados a sistem as centrali­ zados están siendo sustituidos por los PC. Igualmente, la funcionalidad de interfaz de usuario que antes era gestionada directamente por los sistem as centralizados ahora está siendo gestionada de forma cada vez más frecuente en los PC. Como resultado, m uchos sistemas actuales actúan com o sistem as servidor para satisfacer las solicitudes generadas por los sistem as cliente. Esta form a de sistem a distribuido especializado, denom inada sistema cliente-servidor, tiene la estructura gene­ ral descrita en la Figura 1.11. Los sistem as servidor pueden clasificarse de forma m uy general en senadores de cálculo y ser­ vidores de archivos. • El sistem a servidor de cálculo proporciona una interfaz a la que un cliente puede enviar una solicitud para realizar una acción, como por ejem plo leer datos; en res puesta, el servi-

Figura 1.11 Estructura general de un sistema cliente-servidcr.

Capítulo 1 Introducción

dor ejecuta la acción y devuelve los resultados al cliente. Un servidor que ejecuta una bas de datos y responde a las solicitudes de datos del cliente es un ejemplo de sistem a de est tipo. • El sistema servidor de archivos proporciona una interfaz de sistema de archivos mediant la que los clientes pueden crear, actualizar, leer y eliminar archivos. Un ejem plo de sistem así es un servidor web que sum inistra archivos a los clientes qüe ejecutan exploradores wel

1.12.3

Sistema entre iguales

O tra estructura de sistem a distribuido es el m odelo de sistema entre iguales (peer-to-peer > P2P). En este m odelo, los clientes y servidores no se diferencian entre sí; en su lugar, todos lo nodos del sistem a se consideran iguales y cada uno puede actuar com o cliente o com o servidor dependiendo de si solicita o proporciona un servicio. Los sistem as entre iguales ofrecen, un. ventaja sobre los sistem as cliente-servidor tradicionales. En un sistem a cliente-servidor, el ser vidor es un cuello de botella, pero en un sistem a entre iguales, varios nodos distribuidos a tra vés de la red p u eden proporcionar los servicios. Para participar en un sistem a entre iguales, un nodo debe en prim er lugar unirse a la red d iguales. Una vez que un nodo se ha unido a la red, puede comenzar a proporcionar servicios a y solicitar servicios de, otros nodos de la red. La determ inación de qué servicios hay disponible es algo que se puede llevar a cabo de una de dos form as generales: • Cuando un nodo se une a una red, registra su servicio ante un servicio de búsqueda centra­ lizado existente en la red. C ualquier nodo que desee un servicio concreto, contacta primer con ese servicio de búsqueda centralizado para determinar qué nodo sum inistra el servid deseado. El resto de la com unicación tiene lugar entre el cliente y el proveedor del servici¡ • U n nodo que actúe como cliente primero debe descubrir qué nodo proporciona el servid deseado, m ediante la m ultidifusión de una solicitud de servicio a todos los restantes nodc de la red. El nodo (o nodos) que proporcionen dicho servicio responden al nodo que efe*, túa la solicitud. Para soportar este método, debe proporcionarse un protocolo de descubrimiei to que perm ita a los nodos descubrir los servicios proporcionados por los demás nodos d la red. Las redes entre iguales han ganado popularidad al final de los años 90, con varios servicios d com partición de archivos como N apster y Gnutella, que permiten a una serie de nodos intercan biar archivos entre sí. El sistema N apster usa un m étodo similar al primer tipo descrito anterio mente: un servidor centralizado m antiene un índice de todos los archivos alm acenados en l< nodos de la red N apster y el intercam bio real de archivos tiene lugar entre esos nodos. El sisterr. Gnutella em plea una técnica sim ilar a la del segundo tipo: cada cliente difunde las solicitudes d archivos a los dem ás nodos del sistem a y los nodos que pueden servir la solicitud responde directam ente al cliente. El futuro del intercam bio de archivos permanece incierto, ya que much( de los archivos tienen derechos de propiedad intelectual (los archivos de música, por ejem plo) hay leyes que legislan la distribución de este tipo de material. En cualquier caso, la tecnolog: entre iguales desem peñará sin duda un papel en el futuro de muchos servicios, como los mee. nism os de búsqueda, el intercam bio de archivos y el correo electrónico.

1.12.4 Sistema basado en la W eb La W eb está em pezando a resultar om nipresente, proporcionando un mayor acceso m ediante ui más am plia variedad de dispositivos de lo que hubiéram os podido soñar hace unos pocos año Los PC todavía son los dispositivos de acceso predom inantes, aunque las estaciones de trabajo, 1< PDA de mano e incluso los teléfonos m óviles se em plean ahora también para proporcionar acce^ a Internet. La inform ática basada en la W eb ha increm entado el interés por los sistemas de interconexic por red. Dispositivos que anteriorm ente no estaban conectados en red ahora incluyen acceso pi

1.13 Resumen

31

cable o inalámbrico. Los dispositivos que sí estaban conectados en red ahora disponen de una conectividad de red más rápida, gracias a las mejoras en la tecnología de redes, a la optimización del código de implementación de red o a ambas cosas. La implementación de sistemas basados en la Web ha hecho surgir nuevas categorías de dis­ positivos, tales como los m ecan ism os de eq u ilib rad o de carg a, que distribuyen las conexiones de red entre una batería de servidores similares. Sistemas operativos como Windows 95, que actua­ ba como cliente web, han evolucionado a Linux o Windows XP, que pueden actuar como sena­ dores web y como clientes. En general, la Web ha incrementado la complejidad de muchos dispositivos, ya que los usuarios de los mismos exigen poder conectarlos a la Web.

1.13 Resumen Un sistema operativo es un software que gestiona el hardware de la computadora y proporciona un entorno para ejecutar los programas de aplicación. Quizá el aspecto más visible de un sistema operativo sea la interfaz que el sistema informático proporciona al usuario. Para que una computadora haga su trabajo de ejecutar programas, los programas deben encon­ trarse en la memoria principal. La memoria principal es la única área de almacenamiento de gran tamaño a la que el procesador puede acceder directamente. Es una matriz de palabras o bytes, con un tamaño que va de millones a miles de millones de posiciones distintas. Cada palabra de la memoria tiene su propia dirección. Normalmente, la memoria principal es un dispositivo de alma­ cenamiento volátil que pierde su contenido cuando se desconecta o desaparece la alimentación. La mayoría de los sistemas informáticos proporcionan un almacenamiento secundario como extensión de la memoria principal. El almacenamiento secundario proporciona una forma de almacenamiento no volátil, que es capaz de mantener enormes cantidades de datos de forma per­ manente. El dispositivo de almacenamiento secundario más común es el disco magnético, que proporciona un sistema de almacenamiento para programas y datos. La amplia variedad de sistemas de almacenamiento en un sistema informático puede organi­ zarse en una jerarquía, en función de su velocidad y su coste. Los niveles superiores son más caros, pero más rápidos. A medida que se desciende por la jerarquía, el coste por bit generalmen­ te disminuye, mientras que el tiempo de acceso por regla general aumenta. Existen varias estrategias diferentes para diseñar un sistema informático. Los sistemas monoprocesador sólo disponen de un procesador, mientras que los sistemas multiprocesador tienen dos o más procesadores que comparten la memoria física y los dispositivos periféricos. El diseño multiprocesador más común es el múítiprocesamiento simétrico (o SMP), donde todos los proce­ sadores se consideran iguales y operan independientemente unos de otros. Los sistemas conecta­ dos en cluster constituyen una forma especializada de sistema multiprocesador y constan de múltiples computadoras conectadas mediante una red de área local. Para un mejor uso de la CPU, los sistemas operativos modernos emplean multiprogramación, la cual permite tener en memoria a la vez varios trabajos, asegurando por tanto que la CPU tenga siempre un trabajo que ejecutar. Los sistemas de tiempo compartido son una extensión de la mul­ tiprogramación, en la que los algoritmos de planificación de la CPU conmutan rápidamente entre varios trabajos, proporcionando la ilusión de que cada trabajo está ejecutándose de forma concu­ rrente. El sistema operativo debe asegurar la correcta operación del sistema informático. Para impedir que los programas dé usuario interfieran con el apropiado funcionamiento del sistema, el hard­ ware soporta dos modos de trabajo: modo usuario y modo kernel. Diversas instrucciones, como las instrucciones de E/S y las instrucciones de espera, son instrucciones privilegiadas y sólo se pue­ den ejecutar en el modo kernel. La memoria en la que el sistema operativo reside debe protegerse frente a modificaciones por parte del usuario. Un temporizador impide los bucles infinitos. Estas características (modo dual, instrucciones privilegiadas, protección de memoria e interrupciones del temporizador) son los bloques básicos que emplea el sistema operativo para conseguir un correcto funcionamiento. Un proceso (o trabajo) es la unidad fundamcntarde trabajo en un sistema operativo. La gestión de procesos incluye la creación y borrado de procesos y proporciona mecanismos para que los

Capítulo 1 Introducción

procesos se com uniquen y sincronicen entre sí. Un sistem a operativo gestiona la memoria haden do un seguim iento de qué partes de la misma están siendo usadas y por quién. El sistem a opera tivo tam bién es responsable de la asignación dinámica y liberación del espacio de m em oria. E sistem a operativo tam bién gestiona el espacio de alm acenam iento, lo que incluye proporciona: sistem as de archivos para representar archivos y directorios y gestionar el espacio en los disposi­ tivos de alm acenam iento masivo. Los sistem as operativos también deben ocuparse de la protección y seguridad del propio sis­ tema operativo y de los usuarios. El concepto de protección incluye los mecanism os que contro­ lan el acceso de los procesos o usuarios a los recursos que el sistem a inform ático pone a so disposición. Las m edidas de seguridad son responsables de defender al sistem a inform ático de los ataques externos e internos. Los sistem as distribuidos perm iten a los usuarios com partir los recursos disponibles en una serie de hosts dispersos geográficam ente, conectados a través de una red de com putadoras. Los servicios pueden ser proporcionados según el modelo cliente-servidor o el modelo entre iguales. En un sistem a en cluster, las m últiples máquinas pueden realizar cálculos sobre los datos que resi­ den en sistem as de alm acenam iento com partidos y los cálculos pueden continuar incluso cuando algún subconjunto de los miembros del cluster falle. Las LAN y VVAN son los dos tipos básicos de redes. Las redes LAN perm iten que un conjunto de procesadores distribuidos en un área geográfica pequeña se com uniquen, mientras que las W A \ perm iten que se com uniquen diversos procesadores distribuidos en un área más grande. Las redes LAN son típicam ente más rápidas que las VVAN. Existen diversos tipos de sistem as inform áticos que sirven a propósitos específicos. Entre estos se incluyen los sistem as operativos en tiempo real diseñados para entornos embebidos, tales como los dispositivos de consum o, autom óviles y equipos robóticos. Los sistem as operativos en tiempo real tienen restricciones de tiempo fijas y bien definidas. El procesam iento tiene que realizarse den­ tro de las restricciones definidas, o el sistem a fallará. Los sistem as m ultim edia implican el sum i­ nistro de datos m ultim edia y, a menudo, tienen requisitos especiales para visualizar o reproducir audio, vídeo o flujos sincronizados de audio y vídeo. Recientem ente, la influencia de Internet y la World W ide W eb ha llevado al desarrollo de sis­ tem as operativos m odernos que integran exploradores w eb y software de red y com unicaciones.

Ejercicios 1.1

En un entorno de m ultiprogramación y tiempo com partido, varios usuarios com parten e! sistem a sim ultáneam ente. Esta situación puede dar lugar a varios problem as de seguridad. a. ¿Cuáles son dos de dichos problem as? b. ¿Podem os asegurar el m ismo grado de seguridad en un sistem a de tiempo com parti­ do que en un sistema dedicado? Explique su respuesta.

1.2

El problem a de la utilización de recursos se m anifiesta de diferentes m aneras en los diferen­ tes tipos de sistem a operativo. Enum ere qué recursos deben gestionarse de forma especial en las siguientes configuraciones: a. Sistem as mainframe y m inicomputadoras b. Estaciones de trabajo conectadas a servidores c. Com putadoras de mano

1.3

¿Bajo qué circunstancias sería m ejor para un usuario utilizar un sistem a de tiempo com par­ tido en lugar de un PC o una estación de trabajo monousuario?

1.4

¿A cuál de las funcionalidades que se enumeran a continuación tiene que dar soporte un sis­ tema operativo, en las dos configuraciones siguientes: (a) una com putadora de m ano y (b) un sistema en tiem po real? a. Program ación por lotes

Ejercicios

33

b. Memoria virtual c. Tiempo compartido 1.5

Describa las diferencias entre multiprocesamiento simétrico y asimétrico. Indique tres ven­ tajas y una desventaja de los sistemas con múltiples procesadores.

1.6

¿En qué se diferencian los sistemas en cluster de los sistemas multiprocesador? ¿Qué se requiere para que dos máquinas que pertenecen a un cluster cooperen para proporcionar un servicio de muy alta disponibilidad?

1.7

Indique las diferencias entre los sistemas distribuidos basados en los modelos cliente -ser­ vidor y entre iguales.

1.8

Considere un sistema en cluster que consta de dos nodos que ejecutan una base de datos. Describa dos formas en las que el software del cluster puede gestionar el acceso a los datos almacenados en el disco. Explique las ventajas y desventajas de cada forma.

1.9

¿En qué se diferencian las computadoras de red de las computadoras personales tradicio­ nales? Describa algunos escenarios de uso en los que sea ventajoso el uso de computadoras de red.

1.10

¿Cuál es el propósito de las interrupciones? ¿Cuáles son las diferencias entre una excepción y una interrupción? ¿Pueden generarse excepciones intencionadamente mediante un pro­ grama de usuario? En caso afirmativo, ¿con qué propósito?

1.11

El a cce so d ire cto a m e m o ria se u sa e n d isp o sitiv o s d e E / S d e alta v e lo cid a d p a ra e v ita r a u m e n ta r la c a r g a d e p ro ce sa m ie n to d e la CPU. a. ¿Cómo interactúa la CPU con el dispositivo para coordinar la transferencia? b. ¿Cómo sabe la CPU que las operaciones de memoria se han completado? c. La CPU puede ejecutar otros programas mientras la controladora de DMA está trans­ firiendo datos. ¿Interfiere este proceso con la ejecución de los programas de usuario? En caso afirmativo, describa las formas de interferencia que se puedan producir.

1.12

Algunos sistemas informáticos no proporcionan un modo privilegiado de operación en su hardware. ¿Es posible construir un sistema operativo seguro para estos sistemas informáti­ cos? Justifique su respuesta.

1.13

Proporcione dos razones por las que las cachés son útiles. ¿Qué problemas resuelven? ¿Qué problemas causan? Si una caché puede ser tan grande como el dispositivo para el que se uti­ liza (por ejemplo, una caché tan grande como un disco) ¿por qué no hacerla así de grande y eliminar el dispositivo?

1.14

Explique, con ejemplos, cómo se manifiesta el problema de mantener la coherencia de los datos en caché en los siguientes entornos de procesamiento: a. Sistemas de un solo procesador b. Sistemas multiprocesador c. Sistemas distribuidos

1.15

Describa un mecanismo de protección de memoria que evite que un programa modifique la memoria asociada con otros programas.

1.16

¿Qué configuración de red se adapta mejor a los entornos siguientes? a. Un piso en una ciudad dormitorio b. U'n campus universitario c. Una región d. Una nación

Capítulo 1 Introducción

1.17

Defina las propiedades esenciales de los siguientes tipos de sistemas operativos:

a. Procesamiento por lotes b. Interactivo c. Tiempo compartido d. Tiempo real e. Red f. Paralelo g- Distribuido h. En cluster i. De mano 1.18

¿Cuáles son las deficiencias inherentes de las computadoras de mano?

Notas bibliográficas Brookshear [2003] proporciona una introducción general a la Informática. Puede encontrar una introducción al sistema operativo Linux en Bovet y Cesa ti [2002], Solomon y Russinovich [2000] proporcionan una introducción a Microsoft Windows y considera­ bles detalles técnicos sobre los componentes e interioridades del sistema. Mauro y McDougall [2001] cubren el sistema operativo Solaris. Puede encontrar detalles sobre Mac OS X en

http://w unv.apple.com /m acosx.

Los sistemas entre iguales se cubren en Parameswaran et al. [2001], Gong [2002], Ripeanu et al. [2002], Agre[2003], Balakrishnan et al. [2003] y Loo [2003], Para ver detalles sobre los sistemas de compartición de archivos en las redes entre iguales, consulte Lee [2003]. En Buyya [1999] podrá encontrar una buena exposición sobre los sistemas en cluster. Los avances recientes sobre los sis­ temas en cluster se describen en Ahmed [2000], Un buen tratado sobre los problemas relaciona­ dos con el soporte de sistemas operativos para sistemas distribuidos es el que puede encontrarse en Tanenbaum y Van Renesse[1985]. Hay muchos libros de texto generales que cubren los sistemas operativos; incluyendo Stallings [2000b], Nutt [2004] y Tanenbaum [2001]. Hamacher [2002] describe la organización de las computadoras. Hennessy y Paterson [2002] cubren los sistemas de E/S y buses, y la arquitectura de sistemas en general. Las memorias caché, incluyendo las memorias asociativas, se describen y analizan en Smith [1982]. Dicho documento también incluye una extensa bibliografía sobre el tema. Podrá encontrar una exposición sobre la tecnología de discos magnéticos en Freedman [1983] y Harker et al. [1981]. Los discos ópticos se cubren en Kenville [1982], Fujitani [1984], O'Leary y Kitts [1985], Gait [1988] y Olsen y Kenley [1989]. Para ver información sobre disquetes, puede con­ sultar Pechura y Schoeffler [1983] y Sarisky [1983]. Chi [1982] y Hoagland [1985] ofrecen explica­ ciones generales sobre la tecnología de almacenamiento masivo. Kurose y Rose [2005], Tanenbaum[2003], Peterson y Davie [1996] y Halsall [1992] proporcionan una introducción general a las redes de computadoras. Fortier [1989] presenta una exposición detallada del hardware y software de red. Wolf[2003] expone los desarrollos recientes en el campo de los sistemas embebidos. Puede encontrar temas relacionados con los dispositivos de mano en Myers y Beig [2003] y Di Pietro v Mancini [2003],

Estructuras de sistemas operativos Un sistem a operativo proporciona el entorno en el que se ejecutan los programas. Internam ente, los sistem as operativos varían m ucho en su com posición, dado que su organización puede anali­ zarse aplicando m últiples criterios diferentes. El diseño de un nuevo sistem a operativo es una tarea de gran envergadura, siendo fundam ental que los objetivos del sistema estén bien definidos antes de com enzar el diseño. Estos objetivos establecen las bases para elegir entre diversos algo­ ritmos y estrategias. Podemos ver un sistem a operativo desde varios puntos de vista. Uno de ellos se centra en los servicios que el sistem a proporciona; otro, en la interfaz disponible para los usuarios y program adores; un tercero, en sus com ponentes y sus interconexiones. En este capítulo, explorarem os estos tres aspectos de los sistem as operativos, considerando los puntos de vista de los usuarios, progra­ madores y diseñadores de sistem as operativos. Tendrem os en cuenta qué servicios proporciona un sistem a operativo, cóm o los proporciona y las diferentes metodologías para diseñar tales sis­ temas. Por último, describirem os cóm o se crean los sistem as operativos y cómo puede una com ­ putadora iniciar su sistem a operativo.

OBJETIVOS DEL CAPÍTULO • Describir los servicios que un sistema operativo proporciona a los usuarios, a los procesos y a otros sistemas. • Exponer las diversas formas de estructurar un sistema operativo. • Explicar cómo se instalan, personalizan y arrancan los sistemas operativos.

2.1

Servicios del sistema operativo Un sistem a operativo proporciona un entorno para la ejecución de programas. El sistem a presta ciertos servicios a los program as y a los usuarios de dichos programas. Por supuesto, los servicios específicos que se sum inistran difieren de un sistem a operativo a otro, pero podemos identificar perfectam ente una serie de clases com unes. Estos servicios del sistema operativo se proporcionan para com odidad del program ador, con el fin de facilitar la tarea de desarrollo. Un cierto conjunto de servicios del sistem a operativo proporciona funciones que resultan úti­ les al usuario: • In terfaz de usuario. Casi todos los sistem as operativos disponen de una interfaz de usua­ rio (UI, user interface), que puede tomar diferentes formas. Uno de ios tipos existentes es la interfaz de lín ea de com andos (CLI, com m and-line interface), que usa com andos de textos y algún tipo de método para introducirlos, es decir, un programa que permite introducir y editar los com andos. Otro tipo destacabíe es la interfaz de proceso por lotes, en la qüe los

Capítulo 2 Estructuras de sistemas operativos

com andos y las directivas para controlar dichos com andos se introducen en archivos, \ luego dichos archivos se ejecutan. H abitualm ente, se utiliza una interfaz gráfica de usuario (GUI, graphical user interface); en este caso, la interfaz es un sistema de ventanas, con un dispositivo señalador para dirigir la E/S, para elegir opciones en los menús y para realizar otras selecciones, y con un teclado para introducir texto. Algunos sistem as proporcionan dos o tres de estas variantes.

• Ejecución de programas. El sistem a tiene que poder cargar un programa en m em oria y eje­ cutar dicho programa. Todo programa debe poder term inar su ejecución, de form a normal o anorm al (indicando un error).

• Operaciones de p/S. Un programa en ejecución puede necesitar llevar a cabo operaciones de E /S , dirigidas a un archivo o a un dispositivo de E /S . Para ciertos dispositivos específi­ cos, puede ser deseable disponer de funciones especiales, tales com o grabar en una unidad de CD o DVD o borrar una pantalla de TRC (tubo de rayos catódicos). Por cuestiones de efi­ ciencia y protección, los usuarios no pueden, norm alm ente, controlar de m odo directo los dispositivos de E /S ; por tanto, el sistema operativo debe proporcionar m edios para realizar la E /S .

• Manipulación del sistema de archivos. El sistem a de archivos tiene una im portancia espe­ cial. Obviam ente, los programas necesitan leer y escribir en archivos y directorios. También necesitan crearlos y borrarlos usando su nom bre, realizar búsquedas en un determ inado archivo o presentar la inform ación contenida en un archivo. Por último, algunos programas incluyen m ecanism os de gestión de perm isos para conceder o denegar el acceso a los archi­ vos o directorios basándose en quién sea el propietario del archivo.

• Comunicaciones. Hay m uchas circunstancias en las que un proceso necesita intercam biar inform ación con otro. Dicha com unicación puede tener lugar entre procesos que estén eje­ cutándose en la misma com putadora o entre procesos que se ejecuten en com putadoras diferentes conectadas a través de una red. Las com unicaciones se pueden im plem entar uti­ lizando memoria compartida o mediante paso de mensajes, procedim iento éste en el que el sis­ tema operativo transfiere paquetes de inform ación entre unos procesos y otros.

• Detección de errores. El sistema operativo necesita detectar constantem ente los posibles errores. Estos errores pueden producirse en el hardw are del procesador y de memoria (como, por ejem plo, un error de memoria o un fallo de la alimentación) en un dispositivo de E/S (como un error de paridad en una cinta, un fallo de conexión en una red o un pro­ blem a de falta papel en la impresora) o en los program as de usuario (como, por ejem plo, un desbordam iento aritmético, un intento de acceso a una posición de memoria ilegal o un uso excesivo del tiempo de GPU). Para cada tipo de error, el sistem a operativo debe llevar a cabo la acción apropiada para asegurar un funcionam iento correcto y coherente. Las facilidades de depuración pueden m ejorar en gran m edida la capacidad de los usuarios y programadores para utilizar el sistema de manera eficiente. Hay disponible otro conjunto de funciones del sistem a de operativo que no están pensadas para ayudar al usuario, sino para garantizar la eficiencia del propio sistema. Los sistem as con m últiples usuarios pueden ser más eficientes cuando se com parten los recursos del equipo entre los distintos usuarios:

• Asignación de recursos. Cuando hay varios usuarios, o hay varios trabajos ejecutándose al m ism o tiempo, deben asignarse a cada uno de ellos los recursos necesarios. El sistema operativo gestiona muchos tipos diferentes de recursos; algunos (como los ciclos de CPU, la memoria principal y el espacio de alm acenam iento de archivos) pueden disponer de códi­ go softw are especial que gestione su asignación, m ientras que otros (como los dispositivos de E/S) pueden tener código que gestione de form a m ucho más general su solicitud y libe­ ración. Por ejem plo, para poder determ inar cuál es el m ejor modo de usar la CPU, el siste­ ma operativo dispone de rutinas de planificación de la CPU que tienen en cuenta la veloci­ dad del procesador, los trabajos que tienen que ejecutarse, el núm ero de registros disponi-

2.2 Interfaz de usuario del sistema operativo

37

bles y otros factores. También puede haber rutinas para asignar impresoras, modems, uni­ dades de almacenamiento USB y otros dispositivos periféricos. Normalmente conviene hacer un seguimiento de qué usuarios emplean qué clase de recursos de la computadora y en qué cantidad. Este registro se puede usar para propósitos contables (con el fin de poder facturar el gasto correspondiente a los usuarios) o simplemente para acumular estadísticas de uso. Estas estadísticas pueden ser una herra­ mienta valiosa para aquellos investigadores que deseen reconfigurar el sistema con el fin de mejorar los servicios informáticos.

• R esp on sab ilid ad .

Los propietarios de la información almacenada en un sistema de computadoras en red o multiusuario necesitan a menudo poder controlar el uso de dicha información. Cuando se ejecutan de forma concurrente varios procesos distintos, no debe ser posible que un proceso interfiera con los demás procesos o con el propio sistema opera­ tivo. La protección implica asegurar que todos los accesos a los recursos del sistema estén controlados. También es importante garantizar la seguridad del sistema frente a posibles intrusos; dicha seguridad comienza por requerir que cada usuario se autentique ante el sis­ tema, usualmente mediante una contraseña, para obtener acceso a los recursos del mismo. Esto se extiende a la defensa de los dispositivos de E /S , entre los que se incluyen modems y adaptadores de red, frente a intentos de acceso ilegales y el registro de dichas conexiones con el fin de detectar intrusiones. Si hay que proteger y asegurar un sistema, las proteccio­ nes deben implementarse en todas partes del mismo: una cadena es tan fuerte como su esla­ bón más débil.

• P ro tecció n y segu rid ad .

2.2

Interfaz de usuario del sistema operativo Existen dos métodos fundamentales para que los usuarios interactúen con el sistema operativo. Una técnica consiste en proporcionar una interfaz de línea de comandos o in térp rete de co m an ­ dos, que permita a los usuarios introducir directamente comandos que el sistema operativo pueda ejecutar. El segundo método permite que el usuario interactúe con el sistema operativo a través de una interfaz gráfica de usuario o GUI.

2.2.1 Intérprete de comandos Algunos sistemas operativos incluyen el intérprete de comandos en el kernel. Otros, como Windows XP y UNIX, tratan al intérprete de comandos como un programa especial que se ejecuta cuando se inicia un trabajo o cuando un usuario inicia una sesión (en los sistemas interactivos). En los sistemas que disponen de varios intérpretes de comandos entre los que elegir, los intérpre­ tes se conocen como sh ells. Por ejemplo, en los sistemas UNIX y Linux, hay disponibles varias shells diferentes entre las que un usuario puede elegir, incluyendo la shell Bourne, la shell C, la shell B o im ie -A g a in , la shell K o rn , etc. La mayoría de las shells proporcionan funcionalidades similares, existiendo sólo algunas diferencias menores, casi todos los usuarios seleccionan una shell u otra basándose en sus preferencias personales. La función principal del intérprete de comandos es obtener y ejecutar el siguiente comando especificado por el usuario. Muchos de los comandos que se proporcionan en este nivel se utili­ zan para manipular archivos: creación, borrado, listado, impresión, copia, ejecución, etc.; las shells de MS-DOS y UNIX operan de esta forma. Estos comandos pueden implementarse de dos formas generales. Uno de los métodos consiste en que el propio intérprete de comandos contiene el código que el comando tiene que ejecutar. Por ejemplo, un comando para borrar un archivo puede hacer que el intérprete de comandos salte a una sección de su código que configura los parámetros nece­ sarios y realiza las apropiadas llamadas al sistema. En este caso, el número de comandos que puede proporcionarse determina el tamaño del intérprete de comandos, dado que cada comando requiere su propio código de implementación.

Capítulo 2 Estructuras de sistemas operativos

Un m étodo alternativo, utilizado por UNIX y otros sistem as operativos, im plem enta la m ayoría de los com andos a través de una serie de program as del sistem a. En este caso, el intérprete de com andos no “entiende” el comando, sino que sim plem ente lo usa para identificar el archivo que hay que cargar en m em oria y ejecutar. Por tanto, el com ando UNIX para borrar un archivo rm f i l e . t x t buscaría un archivo llam ado rm, cargaría el archivo en m em oria y lo ejecutaría, pasándole el pará­ m etro f i l e . t x t . La función asociada con el com ando rm queda definida com pletam ente m ediante el código contenido en el archivo rm. De esta form a, los programadores pueden añadir com andos al sistem a fácilm ente, creando nuevos archivos con los nom bres apropiados. El progra­ ma intérprete de com andos, que puede ser pequeño, no tiene que m odificarse en función de los nuevos com andos que se añadan.

2.2.2 Interfaces gráficas de usuario U na segunda estrategia para interactuar con el sistem a operativo es a través de una interfaz grá­ fica de usuario (GUI) suficientem ente amigable. En lugar de tener que introducir com andos direc­ tam ente a través de la línea de com andos, una GUI perm ite a los usuarios em plear un sistema de ventanas y menús controlable m ediante el ratón. U na GUI proporciona una especie de escritorio en el que el usuario m ueve el ratón para colocar su puntero sobre imágenes, o iconos, que se m uestran en la pantalla (el escritorio) y que representan programas, archivos, directorios y fun­ ciones del sistema. Dependiendo de la ubicación del puntero, pulsar el botón del ratón puede invocar un programa, seleccionar un archivo o directorio (conocido como carpeta) o desplegar un m enú que contenga com andos ejecutables. Las prim eras interfaces gráficas de usuario aparecieron debido, en parte, a las investigaciones realizadas en el departam ento de investigación de Xerox Pare a principios de los años 70. La pri­ m era GUI se incorporó en la com putadora Xerox Alto en 1973. Sin em bargo, las interfaces gráficas sólo se popularizaron con la introducción de las com putadoras Apple M acintosh en los años 80. La interfaz de usuario del sistema operativo de M acintosh (Mac OS) ha sufrido diversos cambios a lo largo de los años, siendo el más significativo la adopción de la interfaz Aqua en Mac OS X. La prim era versión de M icrosoft W indows (versión 1.0) estaba basada en una interfaz GUI que per­ m itía interactuar con el sistema operativo MS-DOS. Las distintas versiones de los sistemas W indows proceden de esa versión inicial, a la que se le han aplicado cambios cosméticos en cuan­ to su apariencia y diversas mejoras de funcionalidad, incluyendo el Explorador de Windows. Tradicionalm ente, en los sistemas UNIX han predom inado las interfaces de línea de comandos, aunque hay disponibles varias interfaces GUI, incluyendo el entorno de escritorio CDE (Common D esktop Environm ent) y los sistemas X-W indows, que son muy habituales en las versiones com erciales de UNIX, com o Solaris o el sistem a AIX de IBM. Sin embargo, también es necesario resaltar el desarrollo de diversas interfaces de tipo GUI en diferentes proyectos de cód igo fuente ab ierto, com o por ejem plo el entorno de escritorio KDE (K Desktop Environment) y el entorno GNOM E, que forma parte del proyecto GNU. Am bos entornos de escritorio, KDE y GNOM E, se ejecutan sobre Linux y otros varios sistem as UNIX, y están disponibles con licencias de código fuente abierto, lo que quiere decir que su código fuente es del dominio público. La decisión de usar una interfaz de línea de com andos o GUI es, principalm ente, una opción personal. Por regla general, muchos usuarios de UNIX prefieren una interfaz de línea de com an­ dos, ya que a menudo les proporciona interfaces de tipo shell más potentes. Por otro lado, la mayor parte de los usuarios de Windows se decantan por el uso del entorno GUI de W indows y casi nunca em plean la interfaz de tipo shell MS-DOS. Por el contrario, los diversos cambios experim en­ tados por los sistem as operativos de M acintosh proporcionan un interesante caso de estudio: his­ tóricam ente, Mac OS no proporcionaba una interfaz de línea de comandos, siendo obligatorio que los usuarios interactuaran con el sistema operativo a través de la interfaz GUI; sin em bargo, con el lanzam iento de Mac OS X (que está parcialm ente basado en un kernel UNIX), el sistema operativo proporciona ahora tanto la nueva interfaz Aqua, com o una interfaz de línea de comandos. La interfaz de usuario puede variar de un sistema a otro e incluso de un usuario a otro dentro de un sistem a; por esto, la interfaz de usuario se suele, norm alm ente, eliminar de la propia estruc­

2.3 Llamadas al sistema

39

tura del sistema. El diseño de una interfaz de usuario útil y amigable no es, por tanto, una función directa del sistema operativo. En este libro, vamos a concentrarnos en los problemas fundamen­ tales de proporcionar un servicio adecuado a los programas de usuario. Desde el punto de vista del sistema operativo, no diferenciaremos entre programas de usuario y programas del sistema.

Llam adas al sistema Las llam ad as al sistem a proporcionan una interfaz con la que poder invocar los servicios que el sistema operativo ofrece. Estas llamadas, generalmente, están disponibles como rutinas escritas en C y C++, aunque determinadas tareas de bajo nivel, como por ejemplo aquéllas en las que se tiene que acceder directamente al hardware, pueden necesitar escribirse con instrucciones de lenguaje ensamblador. Antes de ver cómo pone un sistema operativo a nuestra disposición las llamadas al sistema, vamos a ver un ejemplo para ilustrar cómo se usan esas llamadas: suponga que deseamos escri­ bir un programa sencillo para leer datos de un archivo y copiarlos en otro archivo. El primer dato de entrada que el programa va a necesitar son los nombres de los dos archivos, el de entrada y el de salida. Estos nombres pueden especificarse de muchas maneras, dependiendo del diseño del sistema operativo; un método consiste en que el programa pida al usuario que introduzca los nombres de los dos archivos. En un sistema interactivo, este método requerirá una secuencia de llamadas al sistema: primero hay que escribir un mensaje en el indicativo de comandos de la pan­ talla y luego leer del teclado los caracteres que especifican los dos archivos. En los sistemas basa­ dos en iconos y en el uso de un ratón, habitualmente se suele presentar un menú de nombres de archivo en una ventana. El usuario puede entonces usar el ratón para seleccionar el nombre del archivo de origen y puede abrirse otra ventana para especificar el nombre del archivo de des­ tino. Esta secuencia requiere realizar numerosas llamadas al sistema de E/S. Una vez que se han obtenido los nombres de los dos archivos, el programa debe abrir el archi­ vo de entrada y crear el archivo de salida. Cada una de estas operaciones requiere otra llamada al sistema. Asimismo, para cada operación, existen posibles condiciones de error. Cuando el progra­ ma intenta abrir el archivo de entrada, puede encontrarse con que no existe ningún archivo con ese nombre o que está protegido contra accesos. En estos casos, el programa debe escribir un men­ saje en la consola (otra secuencia de llamadas al sistema) y terminar de forma anormal (otra lla­ mada al sistema). Si el archivo de entrada existe, entonces se debe crear un nuevo archivo de salida. En este caso, podemos encontrarnos con que ya existe un archivo de salida con el mismo nombre; esta situación puede hacer que el programa termine (una llamada al sistema) o podemos borrar el archivo existente (otra llamada al sistema) y crear otro (otra llamada más). En un siste­ ma interactivo, otra posibilidad sería preguntar al usuario (a través de una secuencia de llamadas al sistema para mostrar mensajes en el indicativo de comandos y leer las respuestas desde el ter­ minal) si desea reemplazar el archivo existente o terminar el programa. Una vez que ambos archivos están definidos, hay que ejecutar un bucle que lea del archivo de entrada (una llamada al sistema; y escriba en ei archivo de salida (otra llamada al sistema). Cada lectura y escritura debe devolver información de estado relativa a las distintas condiciones posi­ bles de error. En la entrada, el programa puede encontrarse con que ha llegado al final del archi­ vo o con que se ha producido un fallo de hardware en la lectura (como por ejemplo, un error de paridad). En la operación de escritura pueden producirse varios errores, dependiendo del dispo­ sitivo de salida (espacio de disco insuficiente, la impresora no tiene papel, etc.) Finalmente, después de que se ha copiado el archivo completo, el programa cierra ambos archi­ vos (otra llamada al sistema), escribe un mensaje en la consola o ventana (más llamadas al siste­ ma) y, por último, termina normalmente (la última llamada al sistema). Como puede ver, incluso los programas más sencillos pueden hacer un uso intensivo del sistema operativo. Frecuentemen­ te, ¡os sistemas ejecutan miles d e Mamadas al sistema por segundo. Esta secuencia de llamadas al sistema se muestra en la Figura 2.1. Sin embargo, la mayoría de los programadores no ven este nivel de detalle. Normalmente, los desarroliadores de aplicaciones diseñan sus programas utilizando una API (application program-

Capítulo 2 Estructuras de sistemas operativos

archivo de destino —

e n o a d a llamada t

-

frentrada ^ * •i * * . * * * * '

file,

(HANDLE LPVOED

buffer,

DWORD

bytes

LPDWORD

b y t e s Read,

LPOVERLAPPED

ovl)

t? >■'

'

'

*

To Reac

parámetros

-

2 .2 ? * Á F ^ V r a función ReadfileO

J ^ o s ^ a r á m e t r o s de,R«

¿zZAülT-T

.V*wfW£c*J * i* TTMSrtí^Jlf * Í

tiitk*■

S^-c-jíe?* J H*t

«ÍL * */V*5

.t-

w .« >■»*•I,*»* _i I ii■mi ■IM |I , Ihuuji, ..... '**!■'£• erw b^eyrado^duranteJa ultim*w a lectura. * Í num V i A ' d& V **# com andos del disco; luego, el intérprete de com andos pone a disposición del usuario o del siguiente program a el código de error anterior. FreeBSD (derivado de Berkeley UNIX) es un ejem plo de sistem a multitarea. Cuando un usua­ rio inicia la sesión en el sistem a, se ejecuta la shell elegida por el usuario. Esta shell es sim ilar a la shell de MS-DOS, en cuanto que acepta com andos y ejecuta los programas que el usuario solicita. Sin em bargo, dado que FreeBSD es un sistem a m ultitarea, el intérprete de com andos puede seguir ejecutándose m ientras que se ejecuta otro program a (Figura 2.8). Para iniciar un nuevo proceso, la shell ejecuta la llam ada fork () al sistema. Luego, el program a seleccionado se carga en memoria m ediante una llam ada exec () al sistema y el program a se ejecuta. Dependiendo de la form a en que se haya ejecutado el com ando, la shell espera a que el proceso termine o ejecuta el proceso “en segundo plano”. En este últim o caso, la shell solicita inm ediatam ente otro com ando. Cuando un proceso se ejecuta en segundo plano, no puede recibir entradas directamente desde el teclado, ya que la shell está usando ese recurso. Por tanto, la E / S se hace a través de archivos o de una inter­ faz GUI. M ientras tanto, el usuario es libre de pedir a la shell que ejecute otros program as, que m onitorice el progreso del proceso en ejecución, que cam bie la prioridad de dicho program a, etc. Cuando el proceso concluye, ejecuta una llam ada exit () al sistem a para terminar, devolviendo al proceso que lo invocó un código de estado igual 0 (en caso de ejecución satisfactoria) o un códi­ go de error distinto de cero. Este código de estado o código de error queda entonces disponible para la shell o para otros programas. En el Capítulo 3 se explican los procesos, con un programa de ejem plo que usa las llam adas al sistem a fork () y exec ().

2.4.2 Administración de archivos En los Capítulos 10 y 11 analizarem os en detalle el sistema de archivos. De todos m odos, pode­ mos aquí identificar diversas llamadas com unes al sistema que están relacionadas con la gestión de archivos. En prim er lugar, necesitam os poder crear (create) y borrar (delere) archivos. Ambas llam a­ das al sistema requieren que se proporcione el nom bre del archivo y quizá algunos de los atribu­ tos del mismo. Una vez que el archivo se ha creado, necesitam os abrirlo (open) y utilizarlo. Tam bién tenemos que poder leerlo (read), escribir (v / rite) en él, o reposicionarnos (repos ition), es decir, volver a un punto anterior o saltar al final del archivo, por ejem plo. Por último, tenem os que poder cerrar ( c i ó s e ) el archivo, indicando que ya no deseamos usarlo.

proceso D memoria libre

proceso C

proceso B

kernel F ig u ra 2 .8

FreeBSD ejecutando múltiples programas.

2.4 Tipos de llamadas al sistema

FACILID AD;DE TRAZADO DINÁMICO DE SOLAfUSilO; ^

47

^

.*'. v . v • _ ;r ^

prender, dé depúrar y deopijmi- ' , , iP’lá^vés^aaórv^’imipléBaapfe-í^ ciórt* de'séfémas' opéráti^^T^r'ejemplo; Solaris lO^mtluye^a^fu^ trazado ' •dinámico dt race. Esta füpcidñalidad affádé'din3ini«ffnfenteitina serié ¿¿¿ “son ias”rais^toma que se esté ejecutando: dichas sondas pueden consultarse mediante el lenguaje’-de pro- • gramaaóh-D:y proporcionan;üiTáíásombrosa>ígantidad'de-.información. sobre ..eCterne/,. el estado-13él’‘sístema y laéáhtividadesde los procesos. Por .ejemplo, la Figura 2.9 .muestra las ^^chw^d^dé^há^áj5Ifc^dhícuáh'd‘oí>s^!'éjécat3:üna Uamada-ai sistema (i o ct l)j¿muestra a c é r ’q u íf jó s siste m a s^ o j^ era th . t ’1' . *' ¿ -i'f' 4

T S lillS lS l

■■>■

iX«»

S

¡ w / J n n f r r t / 4 ñ l T rn k i t/t/ n n r ‘l wn i n / » i < f ,a r 1 * l l a r T t l -

terínSM^OT-K” en modo kemd, > - * ■* ^: ■,

í,

^ • r» j * *1 > -*•*««V \

*uvi* »'■>«'. —

____ _____ti ‘IS W te á sssssM S W

# ./all.d 'pgrep xclock' XEventsQueued dtrace: script ',/all.d' matched 52377 prc CPU FUNCTION 0 -> XEventsQueued U > _XEventsQueued U -> _XllTransBytesReadable U _XllTransSocketBytesReadable U ioctl K -> ioctl K -> getf K -> set_accive_fd K clear_active_fd cv_brcadcast 0) {/* proceso padre */ wait(NULL); printf ("PARENT; valué = %d", valué); /* LÍNEA A */ exit(0) ; } }

Figura 3.24 Programa C A> - o

- ~

A, =i f i b n = f i b n- 1 + f i b tt- 2

Escriba un programa C, usando la llamada al sistema fork (), que genere la secuencia de Fibonacci en el proceso hijo. El límite de la secuencia se proporcionará a través de la línea de comandos. Por ejemplo, si se especifica 5, el proceso hijo proporcionará los primeros cinco números de la secuencia de Fibonacci como salida. Dado que los procesos padre e hijo disponen de sus propias copias de los datos, será necesario que el hijo presente la secuen­ cia de salida. El padre tendrá que invocar la función waic () para esperar a que el proceso hijo se complete antes de salir del programa. Realice las comprobaciones de errores necesa­ rias para asegurar que no se pase un número negativo a través de la línea de comandos. 3.7

Repita el ejercicio anterior, pero esta vez utilizando la función CreateProcess () de la API Win32. En este caso, tendrá que especificar un programa diferente para invocarlo con CreateProcess (). Dicho programa se ejecutará como proceso hijo y dará como salida la secuencia de Fibonacci. Realice las comprobaciones de errores necesarias para asegurar que no se pase un número negativo a través de la línea de comandos.

3.8

Modifique el servidor horario mostrado en la Figura 3.19 de modo que suministre mensa­ jes de la suerte aleatorios en lugar de la fecha actual. Debe permitir que esos mensajes de la suerte contengan múltiples líneas. Puede utilizarse el cliente horario mostrado en la Figura 3.20 para leer los mensajes multilínea devueltos por el servidor de la suerte.

3.9

Un servidor de eco es un servidor que devuelve el eco de todo lo que recibe de un cliente. Por ejemplo, si un cliente envía al servidor la cadena ; Hola!, el servidor responderá con los mismos datos que ha recibido del cliente, es decir, ; Hola ! Escriba un senador de eco usando la API de red Java descrita en la Sección 3.6.1. Este servi­ dor esperará a que un diente establezca una conexión, usando para ello el método accepo (). Cuando se reciba una conexión de cliente, el servidor entrará en un bucle, eje­ cutando los pasos siguientes:

106

Capítulo 3 Procesos

• Leer los datos del Socket y ponerlos en un búfer. .• Escribir de nuevo el contenido del búfer para devolverlo al cliente. El servidor saldrá del bucle sólo cuando haya determ inado que el cliente ha cerrado la coi xión. El servidor horario m ostrado en la Figura 3.19 usa la clase java.io.Buf fere Reader. La clase BufferedReader am plía la clase java. io.Reader, que se usa pp. leer flujos de caracteres. Sin em bargo, el servidor de eco no puede estar seguro de que que se reciba de los clientes sean caracteres; tam bién puede recibir datos binarios. La cía java.io.InputStream procesa datos en el nivel de byte en lugar de en el rm de carácter; por tanto, este servidor de eco debe usar un objeto que am plíe java.ir InputStream. El m étodo read () en la clase java.io .InputStream devuelve cuando el cliente ha cerrado su extrem o del socket. 3.10

En el Ejercicio 3.6, el proceso hijo proporcionaba com o salida la secuencia de Fibonac» dado que el padre y el hijo disponían de sus propias copias de los datos. Otro m étodo pa diseñar este program a consiste en establecer un segm ento de m em oria com partida entre lt procesos padre e hijo. Esta técnica perm ite al hijo escribir el contenido de la secuencia SEQUEN'CE. Estos elem entos se pueden representar en una estructura com o sigue:

#define MAX_SEQUENCE 10 typedef struct { long fib_sequence[MAX_SEQUENCE]; ir.r sequence_size; } shared_data; El proceso padre realizará los pasos siguientes: a. Aceptar el parámetro pasado a través de la línea de com andos y realizar la compro bación de errores que asegure que el parám etro es < MAX_SEQUENCE. b. Crear un segm ento de m em oria com partida de tamaño shared_data. c. Asociar el segmento de m em oria com partida a su espacio de direcciones. d. Asignar a secuence_size un valor igual al parám etro de la línea de comandos. e. Bifurcar el proceso hijo e invocar la llam ada al sistem a wait () para esperar a que e proceso hijo concluya. f. Llevar a la salida la secuencia de Fibonacci contenida en el segm ento de memoric com partida. g. Desasociar y eliminar el segm ento de m em oria com partida. Dado que el proceso hijo es una copia del padre, la región de m em oria com partida se aso­ ciará tam bién al espacio de direcciones del hijo. El hijo escribirá entonces la secuencia de Fibonacci en la memoria com partida y, finalm ente, desasociará el segm ento.

Ejercicios

107

Un problema que surge con los procesos cooperativos es el relativo a la sincronización. En este ejercicio, los procesos padre e hijo deben estar sincronizados, de modo que el. padre no lleve a la salida la secuencia de Fibonacci hasta que el proceso hijo haya terminado de gene­ rar la secuencia. Estos dos procesos se sincronizarán usando la llamada al sistema wait () ; ■el proceso padre invocará dicha llamada al sistema, la cual hará que quede en espera hasta que él proceso hijo termine. 3.11

La mayor parte de los sistemas UNIX y Linux proporcionan el comando ipes. Este coman­ do proporciona el estado de diversos mecanismos de comunicación interprocesos de POSIX, incluyendo los segmentos de memoria compartida. Gran parte de la información que pro­ porciona este comando procede de la estructura de datos struct shmid_ds, que está dis­ ponible en el archivo /usr/include/sys/shm. h. Algunos de los campos de esta estruc­ tura son: • int shm_segsz— tamaño del segmento de memoria compartida. • short shm_nattch— número de asociaciones al segmento de memoria compartida. • struct ipc_perm shm_perm— estructura de permisos del segmento de memoria compartida. La estructura de datos struct ipc_perm, disponible en el archivo /usr/include/sys i ipc .h, contiene los campos: • unsigned short uid — identificador del usuario del segmento de memoria compar­ tida. • unsigned short mode — modos de permisos. • Ley_t key (en sistemas Linux, key) — identificador clave especificado por el usua­ rio Los modos de permiso se establecen según se haya definido el segmento de memoria com­ partida en la llamada al sistema shmget (). Los permisos se identifican de acuerdo con la siguiente tabla:

modo 0400 0200 0040 0020 0004 0002

significado Permiso de lectura del propietario. Permiso de escritura del propietario. Permiso de lectura de grupo. Permiso de escritura de grupo. Permiso de lectura de todos. Permiso de escritura de todos

Se puede acceder a los permisos usando el operador AND bit a bit &. Por ejemplo, si la expresión mode & 0400 se evalúa como verdadera, se concede permiso de lectura al propie­ tario del segmento de memoria compartida. Los segmentos de memoria compartida pueden identificarse mediante una clave especifica­ da por el usuario o mediante un valor entero devuelto por la llamada al sistema shmget (), que representa el identificador entero del segmento de memoria compartida recién creado. La estructura shm_ds para un determinado identificador entero de segmento puede obte­ nerse mediante la siguiente llamada al sistema: /* identificador del segmento de memoria compartida */ int segment_id; shm_ds shmbuffer; shmctl(segment_id,

IPC_STAT,

&shmbuffer);

Capítulo 3 Procesos

Si se ejecuta con éxito, shmctl () devuelve 0; en caso contrario, devuelve -1. Escriba un program a C al que se le pase el identificador de un segm ento de m em oria com­ partida. Este program a invocará la función s h m c t l () para obtener su estructura shm__ds Luego proporcionará com o salida los siguientes valores del segm ento de m em oria compar­ tida especificado: ... • ID del segm en to

• Clave • Modo • UID del p rop ietario

• Tam año • Núm ero de asociaciones

Proyecto: Shell de UNIX y función historial Este proyecto consiste en m odificar un programa C utilizado como interfaz shell, que acepta com andos de usuario y luego ejecuta cada com ando com o un proceso diferente. Una interfaz shell proporciona al usuario un indicativo de comandos en el que el usuario puede introducir los com andos que desee ejecutar. El siguiente ejemplo m uestra el indicativo de com andos sh > , en el que se ha introducido el com ando de usuario cat prog.c. Este com ando m uestra el archivo prog.c en el term inal usando el com ando cat de UNIX.

sh> cat prog.c Una técnica para im plem entar una interfaz shell consiste en que prim ero el proceso padre lea lo que el usuario escribe en la línea de comandos (por ejemplo, cat p r o g . c), y luego cree un proceso hijo separado que ejecute el comando. A m enos que se indique lo contrario, el proceso padre espera a que el hijo term ine antes de continuar. Esto es similar en cuanto a funcionalidad al esquema m ostrado en la Figura 3.11. Sin embargo, norm alm ente, las shell de UNIX tam bién permi­ ten que el proceso hijo se ejecute en segundo plano o concurrentem ente, especificando el símbolo & al final del com ando. Reescribiendo el comando anterior como:

sh> cat crog.c & los procesos padre e hijo se ejecutarán de forma concurrente. El proceso hijo se crea usando la llamada al sistema fork () y el com ando de usuario se ejecu­ ta utilizando una de las llam adas al sistem a de la fam ilia exec (como se describe en la Sección 3.3.1). Shell sim p le

En la Figura 3.25 se incluye un program a en C que proporciona las operaciones básicas de una shell de línea de com andos. Este program a se com pone de dos funciones: m ain () y setup ( ) . La función setup f ) lee el siguiente com ando del usuario (que puede constar de hasta 80 caracteres), lo analiza sintácticam ente y lo descompone en identificadores separados que se usan para relle­ nar el vector de argum entos para el com ando que se va a ejecutar. (Si el com ando se va a ejecutar en segundo plano, term inará con y setup (} actualizará el parámetro background de modo que la función raain () pueda operar de acuerdo con ello. Este programa se termina cuando el usuario introduce < C o n t r o l x D > y setup í ) invoca, com o consecuencia, exit (). La función rr.ain () presenta el indicativo de com andos CCbü-lU:3-> y luego invoca setup (), que espera a que el usuario escriba un comando. Los contenidos dei com ando introducido por el usuario se cargan en la m atriz args. Por ejemplo, si el usuario escribe ls -1 en el indicativo COMMAND->, se asigna a args [01 la cadena ls y se asigna a aras 11 ] el valor -1. Por “cadena”, querem os decir una variable de cadena de caracteres de estilo C, con carácter de term inación nulo.

Ejercicios

109

#include #include #define MAX_LINE 80 /** setup() lee la siguiente línea de comandos, y la separa en distintos identificadores, usando los espacios en blanco como delimitado­ res, setup () modifica el parámetro args para que almacene punteros a las cadenas de caracteres con terminación nula que constituyen los identificadores de la línea de comandos de usuario más reciente, así como un puntero NULL que indica el final de la lista de argumentos; ese puntero nulo se incluye después de los punteros de cadena de caracteres asignados a args */ void setup(char inputBuffer[], char *args[], int *background) { /** el código fuente completo está disponible en línea */ } int main(void) { char inputBuf fer [MAX_LINE]

/* búfer para almacenar los comandos introducidos */ int background; ! * igual a 1 si el comando termina con */ char *argsfMAX_LINE/2 + 1]; /* argumentos de la línea de comandos */ while (1) { background = 0; printf(" COMMAND->"); /* setup() llama a exit() cuando se pulsa Control-D */ setup(inputBuffer, args, Lbackground); /** los pasos son; (1) bifurcan un proceso hijo usando fork() (2) el proceso hijo invocará execvp() (3) si background == 1, el padre esperará,en caso contrario, invocará de .nuevo la función setup() */ } }

Fjgura 3.25 Diseño de una Shell simple. Este proyecto está organizado en dos partes: (1) crear el proceso hijo y ejecutar el comando en este proceso y (2) modificar la shell para disponer de una función historial. Creación de un proceso hijo La primera parte de este proyecto consiste en modificar la función main () indicada en la Figura 3.25, de manera que al volver de la función setup (), se genere un proceso hijo y ejecute el comando especificado por el usuario. Como hemos dicho anteriormente, la función setup () carga los contenidos de ia matriz args con el comando especificado por el usuario. Esta matriz args se pasa a la función execvp (), que dispone de la siguiente interfaz:

110

Capítulo 3 Procesos

donde command representa el com ando que se va a ejecutar y p aram s almacena los parámetro del com ando. En este p roy ecto, la fu nción e x e c v p ( ) debe invocarse com o e x e c v ( a r g s [ 0 ] , a r g s ); hay que asegurarse de com probar el valor de b a c k g ro u n d para determine, si el proceso padre debe esperar a que term ine el proceso hijo o no. C reació n de u n a fu n ció n h isto rial

La siguiente tarea consiste en m odificar el program a de la Figura 3.25 para que proporcione ur función historial que perm ita al usuario acceder a los, como máximo, 10 últimos com andos qi: haya introducido. Estos com andos se num erarán com enzado por 1 y se increm entarán hast sobrepasar incluso 10; por ejem plo, si el usuario ha introducido 35 comandos, los 10 último com andos serán los num erados desde 26 hasta 35. Esta función historial se im plementará utiliza: do unas cuantas técnicas diferentes. En primer lugar, el usuario podrá obtener una lista de estos comandos cuando pul: , que es la señal SIGINT. Los sistem as UNIX em plean señales para notificar a i: proceso que se ha producido un determ inado suceso. Las señales pueden ser síncronas o asíncrc ñas, dependiendo del origen y de la razón por la que se haya señalado el suceso. Una vez que : ha generado una señal debido a que ha ocurrido un determ inado suceso (por ejem plo, una di\ sión por cero, un acceso a m em oria ilegal, una entrada del usuario, etc.), la señ se sum inistra a un proceso, donde será tratad a. El proceso que recibe una señal puede tratar m ediante una de las siguientes técnicas: • ignorar la señal, • usar la rutina de tratam iento de la señal predeterm inada, o • proporcionar una función específica de tratam iento de la señal. Las señales pueden tratarse configurando en prim er lugar determinados campos de la estru tura C s t r u c t s i g a c c i o n y pasando luego esa estructura a la función s i g a c t i o n ( ) . Las señ les se definen en el archivo / u s r / i n c l u d e / s y s / s i g n a l .h . Por ejemplo, la señal S IG II representa la señal para terminar un program a con la secuencia de control < C o n t r o l x C > . 1 rutina predeterm inada de tratam iento de señal para SIG IN T consiste en terminar el programa. A lternativam ente, un program a puede definir su propia función de tratamiento de la señ configurando el cam po sa_handler de struct sigaction con el nombre de la función q tratará la señal y luego invocando la función sigaction (), pasándola (1) la señal para la que está definiendo la rutina de tratam iento y (2) un puntero a struct sigan ion. En la Figura 3.26 m ostram os un programa en C que usa la función h =r.die_SIGINT () pa tratar la señal SIGINT. Esta función escribe el m ensaje “Capturado Cor.irol C” y luego invo la función exit () para term inar el programa. Debem os usar la función x r ice () para escribir salida en lugar de la más habitual pr int f ( ),ya que la primera es segura con resp ecto a las s e r les, lo que quiere decir que se la puede llam ar desde dentro de una función de tratam iento > señal; prir.cf () no ofrece dichas garantías. Este programa ejecutará el bucle while (1 ) ha: que el usuario introduzca la secuencia . Cuando esto ocurre, se invoca la fu n ci de tratamiento de señal handle_SIGlNT (). La función de tratamiento de señal se debe declarar antes de m ain i ; y, puesto que el cont¡ puede ser transferido a esta función en cualquier m om ento, no puede pasarse ningún parámei a esta función. Por tanto, cualquier dato del program a al que tenga que acceder deberá declar. se globalmente, es decir, al principio del archivo fuente, antes de la declaración de función Antes de volver de la función de tratam iento de señal, debe ejecutarse de nuevo el indicativo comandos. Si el usuario introduce < C o n t r o l x C > , la rutina de tratamiento de señal proporcionará coi salida una lista de los 10 últimos com andos. Con esta lista, el usuario puede ejecutar cualqu'n de los 10 com andos anteriores escribiendo r x donde ': #include #include #define BUFFER_SIZE 50 char buffer[BUFFER_SIZE]; /* función de tratamiento de señal */ void handle_SIGINT() { write(STDOUT_FILENO,buffer,strlen(buffer) ); exit(0); } int main(int argc, char *argv[]) { /* configura el descriptor de señal * ■ ' struct sigaction handler; handler.sa_handler = handle_SIGINT , sigaction(SIGINT, ¿handler, NULL) ,/* genera el mensaje de salida */ strcpy(buffer, "Captura Control C\n"); /* bucle hasta recibir */ while (1)

1;

return 0;

Figura 3.26 Programa de tratamiento de señal. asumir que la 'r estará separada de la primera letra por sólo un espacio y que la letra irá segui­ da de '\n\ Asimismo, si se desea ejecutar el comando más reciente, 'r' irá inmediatamente se­ guida del carácter \n. Cualquier comando que se ejecute de esta forma deberá enviarse como eco a la pantalla del usuario y el comando deberá incluirse en el búfer de historial como comando más reciente, (r x no se incluye en el historial; lo que se incluye es el comando al que realmente representa). Si el usuario intenta utilizar esta función historial para ejecutar un comando y se detecta que éste es erróneo, debe proporcionarse un mensaje de error al usuario y no añadirse el comando a la lista de historial, y no debe llamarse a la función execvp (). (Estaría bien poder detectar los comandos incorrectamente definidos que se entreguen a execvp i) , que parecen válidos y no lo son, y no incluirlos en el historial tampoco, pero esto queda fuera de las capacidades de este pro­ grama de shell simple). También debe modificarse setup () de modo que devuelva un entero que indique si se ha creado con éxito una lista args válida o no, y la función main () debe actualizar­ se de acuerdo con ello.

Notas bibliográficas La comunicación interprocesos en el sistema RC 4000 se explica en Brinch Hansen [1970]. Schlichting y Schneider [1982] abordan la primitivas de paso de mensajes asincronas. La funcioríalidad IPC implementada en el nivel de usuario se describe en Bershad et al [1990],

112

Capítulo 3 Ptocesos

Los detalles sobre la comunicación interprocesos en sistemas UNIX se exponen en Gray [199" Barrera [1991] y Vahalia [1996] describen la comunicación interprocesos en el sistema Mac Solomon y Russinovich [2000] y Stevens [1999] abordan la comunicación interprocesos Windows 2000 y UNIX, respectivamente. La implementación de llamadas RPC se explica en Birrell y Nelson [1984]. Un diseño de i mecanismo de llamadas RPC se describe en Shrivastava y Panzieri [1982], y Tay y Ananda [199 presentan una introducción a las llamadas RPC. Stankovic [1982] y Staunstrup [1982] presentan ] mecanismos de comunicación mediante llamadas a procedimientos y paso de mensajes. Gros [2002] trata en detalle la invocación de métodos remotos (RMI). Calvert [2001] cubre la prograrr ción de sockets en Java.

C A m m m LO

Hebras El modelo de proceso presentado en el Capítulo 3 suponía que un proceso era un programa en eje­ cución con una sola hebra de control. Ahora, la mayoría de los sistemas operativos modernos pro­ porcionan características que permiten que un proceso tenga múltiples hebras de control. Este capítulo presenta diversos conceptos asociados con los sistemas informáticos multihebra, inclu­ yendo una exposición sobre las API de las bibliotecas de hebras de Pthreads, Win32 y Java. Veremos muchos temas relacionados con la programación multihebra y veremos cómo afecta esta característica al diseño de sistemas operativos. Por último, estudiaremos cómo permiten los siste­ mas operativos Windows XP y Linux el uso de hebras en el nivel de kernel.

OBJETIVOS DEL CAPÍTULO • Presentar el concepto de hebra, una unidad fundamental de utilización de la CPU que conforma los fundamentos de los sistemas informáticos multihebra. • Explicar las API de las bibliotecas de hebras de Pthreads, Win32 y Java.

4.1

Introducción Una hebra es una unidad básica de utilización de la CPU; comprende un ID de hebra, un contador de programa, un conjunto de registros y una pila. Comparte con otras hebras que pertenecen al mismo proceso la sección de código, la sección de datos y otros recursos del sistema operativo, como los archivos abiertos y las señales. Un proceso tradicional (o proceso pesado) tiene una sola hebra de control. Si un proceso tiene, por el contrario, múltiples hebras de control, puede realizar más de una tarea a la vez. La Figura 4.1 ilustra la diferencia entre un proceso tradicional monohebra y un proceso multihebra.

4.1.1 Motivación Muchos paquetes de software que se ejecutan en los PC modernos de escritorio son multihebra. Normalmente, una aplicación se implementa como un proceso propio con varias hebras de con­ trol. Por ejemplo, un explorador web puede tener una hebra para mostrar imágenes o texto mien­ tras que otra hebra recupera datos de la red. Un procesador de textos puede tener una hebra para mostrar gráficos, otra hebra para responder a las pulsaciones de teclado del usuario y una terce­ ra hebra para el corrector ortográfico y gramatical que se ejecuta en segundo plano. En determinadas situaciones, una misma aplicación puede tener que realizar varias tareas similares. Por ejemplo, un senador web acepta solicitudes de los clientes que piden páginas web, imágenes, sonido, etc. Un servidor web sometido a una gran carga puede tener varios (quizá, miles) de dientes accediendo de forma concurrente a él. Si el servidor web funcionara como un proceso tradicional de una sola hebra, sólo podría dar servicio a un cliente cada vez y la cantidad

114

Capítulo 4 Hebras

código

datos

archivos

código

datos

archivos

pila

registros

registros

registros

pila

pila

pila

*

*

registros

hebra

proceso de una sola hebra F ig u ra

proceso multihebra

4.1 Procesos monohebra y multihebra.

de tiempo que un cliente podría tener que esperar para que su solicitud fuera servida podría ser enorm e. Una solución es que el servidor funcione com o un solo proceso de aceptación de solicitudes. Cuando el servidor recibe una solicitud, crea otro proceso para dar servicio a dicha solicitud. De hecho, este m étodo de creación de procesos era habitual antes de que las hebras se popularizaran. Com o hem os visto en el capítulo anterior, la creación de procesos lleva tiem po y hace un uso intensivo de los recursos. Si el nuevo proceso va a realizar las m ism as tareas que los procesos exis­ tentes, ¿por qué realizar todo ese trabajo adicional? Generalm ente, es más eficiente usar un pro­ ceso que contenga m últiples hebras. Según este método, lo que se hace es dividir en múltiples hebras el proceso servidor web. El servidor crea una hebra específica para escuchar las solicitudes de cliente y cuando llega una solicitud, en lugar de crear otro proceso, el servidor crea otra hebra para dar servicio a la solicitud. Las hebras tam bién juegan un papel importante en los sistem as de llamada a procedimientos remotos (RPC). Recuerde del Capítulo 3 que las RPC perm iten la com unicación entre procesos pro­ porcionando un m ecanism o de com unicación sim ilar a las llam adas a funciones o procedimientos ordinarias. N orm alm ente, los servidores RPC son multihebra. Cuando un servidor recibe un m en­ saje, sirve el m ensaje usando una hebra específica. Esto perm ite al servidor dar servicio a varias solicitudes concurrentes. Los sistem as RMI de Java trabajan de form a similar. Por último, ahora m uchos kem el de sistem as operativos son m ultihebra; hay varias hebras ope­ rando en el kem el y cada hebra realiza una tarea específica, tal com o gestionar dispositivos o tra­ tar interrupciones. Por ejem plo, Solaris crea un conjunto de hebras en el kem el específicam ente para el tratamiento de interrupciones; Linux utiliza una hebra del kem el para gestionar la canti­ dad de memoria libre en el sistema.

4.1.2 Ventajas Las ventajas de la program ación m ultihebra pueden dividirse en cuatro categorías principales: 1.

C apacidad de respuesta. El uso de múltiples hebras en una aplicación interactiva permite que un programa continúe ejecutándose incluso aunque parte de él esté bloqueado o reali­ zando una operación muy larga, lo que incrementa la capacidad de respuesta al usuario. Por ejem plo, un explorador web m ultihebra permite la interacción del usuario a través de una hebra m ientras que en otra hebra se está cargando una imagen.

2.

C om partición de recursos. Por omisión, las hebras com parten la memoria y los recursos del proceso al que pertenecen. La ventaja de compartir el código y los datos es que perm ite que

4.2 Modelos multihebra

115

una aplicación tenga varias hebras de actividad diferentes dentro del mismo espacio de direcciones. 3.

Econom ía. La asignación de memoria y recursos para la creación de procesos es costosa.

Dado que las hebras comparten recursos del proceso al que pertenecen, es más económico crear y realizar cambios de contexto entre unas y otras hebras. Puede ser difícil determinar empíricamente la diferencia en la carga de adicional de trabajo administrativo pero, en gene­ ral, se consume mucho más tiempo en crear y gestionar los procesos que las hebras. Por ejem­ plo, en Solaris, crear un proceso es treinta veces lento que crear una hebra, y el cambio de contexto es aproximadamente cinco veces más lento. 4.

U tilización sobre arquitecturas multiprocesador. Las ventajas de usar configuraciones

multihebra pueden verse incrementadas significativamente en una arquitectura multiproce­ sador, donde las hebras pueden ejecutarse en paralelo en los diferentes procesadores. Un proceso monohebra sólo se puede ejecutar en una CPU, independientemente de cuántas haya disponibles. Los mecanismos multihebra en una máquina con varias CPU incrementan el grado de concurrencia.

Modelos multihebra Hasta ahora, nuestra exposición se ha ocupado de las hebras en sentido genérico. Sin embargo, desde el punto de vista práctico, el soporte para hebras puede proporcionarse en el nivel de usua­ rio (para las hebras de usuario) o por parte del kernel (para las hebras del kemel). El soporte para las hebras de usuario se proporciona por encima del kemel y las hebras se gestionan sin soporte del mismo, mientras que el sistema operativo soporta y gestiona directamente las hebras del ker­ nel. Casi todos los sistemas operativos actuales, incluyendo Windows XP, Linux, Mac OS X, Solaris y Tru64 UNIX (antes Digital UNIX) soportan las hebras de kernel. En último término, debe existir una relación entras las hebras de usuario y las del kemel; en esta sección, vamos a ver tres formas de establecer esta relación.

4.2.1 Modelo m uchos-a-uno El modelo muchos-a-uno (Figura 4.2) asigna múltiples hebras del nivel de usuario a una hebra del kemel. La gestión de hebras se hace mediante la biblioteca de hebras en el espacio de usuario, por lo que resulta eficiente, pero el proceso completo se bloquea si una hebra realiza una llamada blo­ queante al sistema. También, dado que sólo una hebra puede acceder al kernel cada vez, no podrán

116

Capítulo 4 Hebras

■hebra de usuario

■hebra del kernel

Figura 4.3 Modelo uno-a-uno. ejecutarse varias hebras en paralelo sobre múltiples procesadores. El sistema de hebras Green, una biblioteca de hebras disponible en Solaris, usa este modelo, asi como GNU Portable Threads.

4.2.2 Modelo uno-a-uno El modelo uno-a-uno (Figura 4.3) asigna cada hebra de usuario a una hebra del kernel. Proporciona una mayor concurrencia que el modelo muchos-a-uno, permitiendo que se ejecute otra hebra mientras una hebra hace una llamada bloqueante al sistema; también permite que se ejecuten múl­ tiples hebras en paralelo sobre varios procesadores. El único inconveniente de este modelo es que crear una hebra de usuario requiere crear la correspondiente hebra del kernel. Dado que la carga de trabajo administrativa para la creación de hebras del kernel puede repercutir en el rendimiento de una aplicación, la mayoría de las implementaciones de este modelo restringen el número de hebras soportadas por el sistema. Linux, junto con la familia de sistemas operativos Windows (incluyendo Windows 95, 98, NT, 200 y XP), implementan el modelo uno-a-uno.

4.2.3 Modelo m uchos-a-m uchos El modelo muchos-a-muchos (Figura 4.4) multiplexa muchas hebras de usuario sobre un número menor o igual de hebras del kernel. El número de hebras del kernel puede ser específico de una determinada aplicación o de una determinada máquina (pueden asignarse más hebras del kernel a una aplicación en un sistema multiprocesador que en uno de un solo procesador). Mientras que el modelo muchos-a-uno permite al desarrollador crear tantas hebras de usuario como desee, no se consigue una concurrencia real, ya que el kernel sólo puede planificar la ejecución de una hebra cada vez. El modelo uno-a-uno permite una mayor concurrencia, pero el desarrollador debe tener

Figura 4.4 Modelo muchos-a-muchos.

4.3 Bibliotecas de hebras

117

■hebra de usuario

■hebra del kernel

Figura 4.5 Modelo de dos niveles. cuidado de no crear demasiadas hebras dentro de una aplicación (y, en algunos casos, el número de hebras que pueda crear estará limitado). El modelo muchos-a-muchos no sufre ninguno de estos inconvenientes. Los desarrolladores pueden crear tantas hebras de usuario como sean nece­ sarias y las correspondientes hebras del kernel pueden ejecutarse en paralelo en un multiprocesador. Asimismo, cuando una hebra realiza una llamada bloqueante al sistema, el kernel puede planificar otra hebra para su ejecución. Una popular variación del modelo muchos-a-muchos multiplexa muchas hebras del nivel de usuario sobre un número menor o igual de hebras del kernel, pero también permite acoplar una hebra de usuario a una hebra del kernel. Algunos sistemas operativos como IRIX, HP-UX y Tru64 UNIX emplean esta variante, que algunas veces se denomina modelo de dos niveles (Figura 4.5). El sistema operativo Solaris permitía el uso del modelo de dos niveles en las versiones anteriores a Solaris 9. Sin embargo, a partir de Solaris 9, este sistema emplea el modelo uno-a-uno.

Bibliotecas de hebras Una biblioteca de hebras proporciona al programador una API para crear y gestionar hebras. Existen dos formas principales de implementar una biblioteca de hebras. El primer método con­ siste en proporcionar una biblioteca enteramente en el espacio de usuario, sin ningún soporte del kernel. Tocias las estructuras de datos y el código de la biblioteca se encuentran en el espacio de usuario. Esto significa que invocar a una función de la biblioteca es como realizar una llamada a una función local en el espacio de usuario y no una llamada al sistema. El segundo método consiste en implementar una biblioteca en el nivel del kernel, soportada directamente por el sistema operativo. En este caso, el código y las estructuras de datos de la biblioteca se encuentran en el espacio del kem el. Invocar una función en la API de la biblioteca nor­ malmente da lugar a que se produzca una llamada al sistema dirigida al kernel. Las tres principales bibliotecas de hebras actualmente en uso son: (1) POSIX Pthreads, (2) Win32 y (3) Java. Pthreads, la extensión de hebras del estándar POSIX, puede proporcionarse como biblio­ teca del nivel de usuario o del nivel de kernel. La biblioteca de hebras de Win32 es una biblioteca del nivel de kernel disponible en los sistemas Windows. La API de hebras Java permite crear y ges­ tionar directamente hebras en los programas Java. Sin embargo, puesto que en la mayoría de los casos la JVM se ejecuta por encima del sistema operativo del host, la API de hebras Java se implementa habitualmente usando una biblioteca de hebras disponible en el sistema hest. Esto signifi­ ca que, normalmente, en los sistemas Windows, las hebras Java se implementan usando la API de Win32, mientras que en los sistemas Linux se suelen implementar empleando Pthreads.

Capítulo 4 Hebras

En el resto de esta sección, vamos a describir la creación de hebras usando estas tres bibliot^H cas. Mediante un ejemplo ilustrativo, vamos a diseñar un programa multihebra que calcule e fB sumatorio de un entero no negativo en una hebra específica empleando la muy conocida función»! sumatorio: ** ,Y ' ‘ 1=0

Por ejemplo, si N fuera igual a 5, esta función representaría el sumatorio desde 0 hasta 5, que¿§¡ es 15. Cada uno de los tres programas se ejecutará especificando el límite superior del sum a través de la línea de comandos; por tanto, si el usuario escribe 8, a la salida se obtendrá la de los valores enteros comprendidos entre 0 y 8.

4.3.1 Pthreads Pthreads se basa en el estándar POSIX (IEEE 1003.1c) que define una API para la creación y sincro- ¡ nización de hebras. Se trata de una especificación para el comportamiento de las hebras, no de una' implementación. Los diseñadores de sistemas operativos pueden Ímplementar la especificación de la forma que deseen. Hay muchos sistemas que implementan la especificación Pthreads, incluyen­ do Solaris, Linux; Mac OS X v Tru64 UNIX. También hay disponibles implementaciones de libre distribución para diversos sistemas operativos Windows. El programa C mostrado en la Figura 4.6 ilustra la API básica de Pthreads mediante un ejem­ plo de creación de un programa multihebra que calcula el sumatorio de un entero no negativo en una hebra específica. En un programa Pthreads, las diferentes hebras inician su ejecución en una función específica. En la Figura 4.6, se trata de la función ru n n er (). Cuando este programa se ini­ cia, da comienzo una sola hebra de control en main (). Después de algunas inicializaciones, raain () crea una segunda hebra que comienza en la función runner (). Ambas hebras compar­ ten la variable global sum. Analicemos más despacio este programa. Todos los programas Pthreads deben incluir el archi­ vo de cabecera p t h r e a d . h. La instrucción p th re a d _ t t i d declara el identificador de la hebra que se va a crear. Cada hebra tiene un conjunto de atributos, que incluye el tamaño de la pila y la información de planificación. La declaración p t h r e a d _ a t t r _ t a t t r representa los atributos de la hebra; establecemos los atributos en la llamada a la función p t h r e a d _ a t t r _ i n i t ( & a t t r ) . Dado que no definimos explícitamente ningún atributo, se usan los atributos predeterminados. En el Capítulo 5, veremos algunos de los atributos de planificación proporcionados por la API de Pthreads. Para crear otra hebra se usa la llamada a la función p t h r e a d _ c r e a t e (). Además de pasar el identificador de la hebra y los atributos de la misma, también pasamos el nombre de la función en la que la nueva hebra comenzará la ejecución, que en este caso es la función runner (). Por último, pasamos el parámetro entero que se proporcionó en la línea de comandos, arg v [1]. En este punto, el programa tiene dos hebras: la hebra inicial (o padre) en main () y la hebra del sumatorio (o hijo) que realiza la operación de suma en la función runner (). Después de crear la hebra sumatorio, la hebra padre esperará a que se complete llamando a la función p th re a d _ j oin. La hebra sumatorio se completará cuando llame a la función p t h r e a a _ e x i t {). Una vez que la hebra sumatorio ha vuelto, la hebra padre presenta a la salida el valor de la varia­ ble compartida sum.

4.3.2 Hebras de Win32 La técnica de creación de hebras usando la biblioteca de hebras de Win32 es similar en varios aspectos a la técnica empleada en Pthreads. Vamos a ilustrar la API para hebras Win32 mediante el programa C de la Figura 4.7. Observe que tenemos que incluir el archivo de cabecera W i n ­ dows . h cuando se usa la API de Win32. Al igual que la versión de Pthreads de la Figura 4.6, los datos compartidos por las diferentes hebras, en este caso, sum, de declaran globalmente (el tipo de datos DWORD es un entero de 32 bits

4.3 Bibliotecas de hebras

119

#include #include int sum /*las hebras comparten esta variable*/ void *runner(void *param); /* la hebra */ int mainfint argc, char *argv[]) { pthread_t tid; /* el identificador de la hebra */ pthread_attr_t attr; /* conjunto de atributos de la hebra */ if (argc != 2) { fprintf (stderr, "uso: a.out \n"); return -1; } if (atoi(argv[1]) < 0) { fprintf (stderr, "%d debe ser >= 0\n", atoi(argv[l] )) ; return -1;

/* obtener los atributos predeterminados */ pthread_attr_init(&attr); /* crear la hebra */ pthread_create(&tid, &attr, runner, argvfl]); /* esperar a que la hebra termine */ pthread_join(tid,NULL); printf("sum = %d\n", sum) } /* La hebra inicia su ejecución en esta función */ void *runner(void *param) { int i, upper = attoi(param); sum = 0; for (i = 1; i = 0."); else { // crea el objeto que hay que compartir Sum sumObject = new Sumí); int upper = Integer.parselnt(args[0] ) ; Thread thrd = new Thread(new Summation(upper, sumObject)); thrd.start(); try { thrd.join() ; -System.out.println ("La suma de "+upper+" es "+sumObject.getSum()); } catch (InterruptedException ie) { } } }

else System, err.println ("Uso: Summation cvalor entero") ; } \

i

Figura 4.8 Programa Java para el sumatorio de un entero no negativo.

4.4 Consideraciones sobre las hebras

'V ..

,

123

.. _

__

iiinptemerite^ . ijjqc^erente que permijrt^uná' JVM. lá & p e c É K

¿téáno^in'dica cómo asigoqclas hebras Java al iisTSna operativo ^subyacente, iíaxfmsiHna la'inipTmvcní^^r^íó^^^^^^^lí^Pbr ejemplo, el sistema ' v - y-iT-' í ' v ,' TÍi¿~ ' * « ■ » , i - e * rf j w - t.v ix frv -tí .#?*! i ^ j i a r f W f c A É ^ , ~ T ¿ „ % ^wu-Us^usí

rQj/vmdowsXE usa-eLmodelo unofa-imo; por iantcr/'csraahebra Java de una m aq u is * ^ i ^ ^ ^ q é ^ ^ p ^ 'U n ’a stC T ^ ^ ^ ^ m apea^obre^toia^^gaH éi ferrad. Eni.lóS.sís1 ÜJ” divos q u eu sáh el m cK ÍeIo.m um os-áTm ucím ¿fíaLoqm aJi^CyíáíX)/ cada hebra' acuerdo Con el modelqfflCnlicdios-ctmuenp^S^ar^gmpieínentíM uyLCT^» -mferkaona^iaBB — ^ d °d e T . ; Java y la bibliohsar§ a ABl,de W in32 a|^

Consideraciones sobre las hebras En esta sección vamos a ver algunas de las cuestiones que hay que tener en cuenta en los progra­ mas m ultihebra.

4.4.1 Las llamadas al sistema fo rk () y execí) En el Capítulo 3 hemos descrito cómo se usa la llamada al sistema f o r k () para crear un proceso duplicado e independiente. La semántica de las llamadas al sistema f o r k () y e x e c . cam bia en los program as multihebra. Si una hebra de un programa llama a f o r k ( ) , ¿duplica todas las hebras el nuevo proceso o es un proceso de una sola hebra? Algunos sistem as UNIX han decidido disponer de d o s versiones de f o r k ( ) , una que duplica todas las hebras y otra que sólo duplica la hebra que invocó la llamada al sistem a f o r k (). La llam ada al sistema e x e c í ), típicamente, funciona de la misma form a que se ha descrito en el Capítulo3. Es decir, si una hebra invoca la llam ada al sistem a e x e c (), el programa especifica­ do en el parám etro de e x e c (} reem plazará al proceso com pleto, incluyendo todas las hebras. Cuál de las dos versiones de f o r k () se use depende de la aplicación. Si se llama a e x e c () inm ediatam ente después de f o r k (), entonces resulta innecesario duplicar todas las hebras, ya que el program a especificado en los parám etros de e x e c () reemplazará al proceso existente. En este caso, lo apropiado es duplicar sólo la hebra que hace la llamada. Sin em bargo, si el nuevo pro­ ceso no llama a e x e c () después de f o r k (), el nuevo proceso deberá duplicar todas las hebras.

4.4.2 Cancelación La can celación de una hebra es la acción de terminar una hebra antes de que se hava com pleta­ do. Por ejem plo, si '. arias hebras están realizando una búsqueda de forma concurrente en una base de datos y una hebra devuelve el resultado, las restantes hebras deben ser canceladas. Puede pro­ ducirse otra situación de este tipo cuando un usuario pulsa un botón en un explorador web que detiene la descarga de una página web. A menudo, las páginas web se cargan usando varias

124

Capítulo 4 Hebras

hebras, cargándose cada im agen en una hebra diferente. Cuando un usuario pulsa el botón sft del navegador, todas las hebras de carga de la página se cancelan. U na hebra que vaya a ser cancelada se denom ina a m enudo h ebra objetivo. La cancelación c una hebra objetivo puede ocurrir en dos escenarios diferentes: 1. C ancelación asincrona. Una determ inada hebra hace que termine-inmediatamente la hebr objetivo. 2. C ancelación d iferida. La hebra objetivo com prueba periódicam ente si debe terminar, lo qo la proporciona una oportunidad de term inar por sí m ism a de una forma ordenada. La dificultad de la cancelación se produce en aquellas situaciones en las que se han asignad recursos a una hebra cancelada o cuando una hebra se cancela en mitad de una actualización de datos que tuviera com partidos con otras hebras. Estos problem as son especialmente graves cuan do se utiliza el m ecanism o de cancelación asincrona. A m enudo, el sistema operativo reclamare los recursos asignados a una hebra cancelada, pero no reclam ará todos los recursos. Por tantc cancelar una hebra de form a asincrona puede hacer que no se libere urt recurso del sistema qut sea necesario para otras cosas. Por el contrario, con la cancelación diferida, una hebra indica que otra hebra objetivo va a ser cancelada, pero la cancelación sólo se produce después de que la hebra objetivo haya comproba do el valor de un indicador para determ inar si debe cancelarse o no. Esto perm ite que esa com probación de si debe cancelarse sea realizada por la hebra objetivo en algún punto en que la cancelación se pueda hacer de forma segura. Pthreads denom ina a dichos m om entos puntos de cancelación.

4.4.3 Tratamiento de señales U na señ al se usa en los sistem as UNIX para notificar a un proceso que se ha producido un deter­ m inado suceso. Una señal puede recibirse síncrona o asincronam ente, dependiendo del origen y de la razón por la que el suceso deba ser señalizado. Todas las señales, sean síncronas o asincro­ nas, siguen el m ism o patrón: 1. U na señal se genera debido a que se produce un determ inado suceso. 2. La seña] generada se sum inistra a un proceso. 3. U na vez sum inistrada, la señal debe ser tratada. Com o ejem plos de señales síncronas podem os citar los accesos ilegales a memoria y la división por 0. Si un program a en ejecución realiza una de estas acciones, se genera una señal. Las señales síncronas se proporcionan al m ismo proceso que realizó la operación que causó la señal (ésa es la razón por la que se consideran síncronas). Cuando una señal se genera por un suceso externo a un proceso en ejecución, dicho proceso recibe la señal en m odo asincrono. Como ejem plos de tales señales podemos citar la terminación de un proceso m ediante la pulsación de teclas específicas, com o « c o n tr o l> < C > , y el fin de cuen­ ta de un tem porizador. N orm alm ente, las señales asincronas se envían a otro proceso. Cada señal puede ser tratada por una de dos posibles rutinas de tratamiento: 1. Una rutina de tratam iento de señal predeterm inada. 2. Una rutina de tratam iento de señal definida por el usuario. Cada señal tiene una ru tina de tratam iento de señal predeterm inada que el kem el ejecuta cuando trata dicha señal. Esta acción predeterm inada puede ser sustituida por una ru tina de tra­ tam iento de señal d efin id a por el usuario a la que se llama para tratar la señal. Las señales pue­ den tratarse de diferentes formas: algunas señales (tales como la de cambio en eltamaño de una ventana) sim plem ente pueden ignorarse; otras (como un acceso ilegal a memoria) pueden tratar­ se m ediante la term inación del programa.

4.4 Consideraciones sobre las hebras

125

El tratam iento de señales en programas de una sola hebra resulta sencillo; las señales siempre se sum inistran a un proceso. Sin embargo, sum inistrar las señales en los programas m ultihebra es más com plicado, ya que un proceso puede tener varias hebras. ¿A quién, entonces, debe sum inis­ trarse la señal? En general, hay disponibles las siguientes opciones; 1. Sum inistrar la señal a la hebra a la que sea aplicable la señal. 2. Sum inistrar la señal a todas las hebras del proceso. 3. Sum inistrar la señal a determ inadas hebras del proceso. 4. A signar una hebra específica para recibir todas las señales del proceso. El m étodo para sum inistrar una señal depende del tipo de señal generada. Por ejem plo, las señales síncronas tienen que sum inistrarse a la hebra que causó la señal y no a las restantes hebras del proceso. Sin em bargo, la situación con las señales asincronas no es tan clara. Algunas señales asincronas, com o una señal de term inación de un proceso (por ejem plo, < c o n tr o l> < C > ) deberí­ an enviarse a todas las hebras. La m ayoría de las versiones multihebra de UNIX perm iten que las hebras especifiquen qué señales aceptarán y cuáles bloquearán. Por tanto, en algunos casos, una señal asincrona puede sum inistrarse sólo a aquellas hebras que no la estén bloqueando. Sin em bargo, dado que las seña­ les necesitan ser tratadas sólo una vez, cada señal se sum inistra norm alm ente sólo a la primera hebra que no la esté bloqueando. La función estándar UNIX para sum inistrar una señal es k i l l ( a i d _ t a i d , i n t s i g n a l ) ; aquí, especificam os el proceso a i d al que se va a sum inis­ trar una señal determ inada. Sin em bargo, Pthreads de POSIX tam bién proporciona la función p t h r e a d _ k i l l ( p t h r e a d _ t t i d , i n t s i g n a l }, que perm ite que una señal sea §uministrada a una hebra especificada ( t i d ) . Aunque W indows no proporciona explícitam ente soporte para señales, puede em ularse usan­ do las lla m a d a s a s in c r o n a s a p ro c e d im ie n to s (APC, asynchronous procedure cali). La facilidad A PC perm ite a una hebra de usuario especificar una función que será llamada cuando la hebra de usuario reciba una notificación de un suceso particular. Como indica su nombre, una llamada APC es el equivalente de una señal asincrona en UNIX. Sin em bargo, mientras que UNIX tiene que enfrentarse con cómo tratar las señales en un entorno m ultihebra, la facilidad APC es más sencilla, ya que cada APC se sum inistra a una hebra concreta en lugar de a un proceso.

4.4.4 Conjuntos com partidos de hebras En la Sección 4.1 hem os m encionado la funcionalidad m ultihebra de un servidor web. En esta situación, cuando el servidor recibe una solicitud, crea una hebra nueva para dar servicio a la soli­ citud. Aunque crear una nueva hebra es, indudablem ente, m ucho m enos costoso que crear un proceso nuevo, los servidores multihebra no están exentos de problem as potenciales. El primero concierne a la cantidad de tiempo necesario para crear la hebra antes de dar servicio a la solicitud, junto con el hecho de que esta hebra se descartará una vez que haya completado su trabajo. El segundo tema es m ás problem ático: si perm itim os que todas las solicitudes concurrentes sean ser­ vidas m ediante una nueva hebra, no ponemos lím ite al núm ero de hebras activas de form a con­ currente en el sistem a. U n número ilimitado de hebras podría agotar determinados recursos del sistema, como el tiem po de CPU o la-memoria. Una solución para este problem a consiste en usar lo que se denom ina un c o n ju n to c o m p a rtid o d e h e b ra s. La idea general subyacente a los conjuntos de hebras es la de crear una serie de hebras al prin­ cipio del proceso y colocarlas en un conjunto compartido, donde las hebras quedan a la espera de que se les asigne un trabajo. Cuando un servidor recibe una solicitud, despierta a una hebra del conjunto, si hay una disponible, v le pasa la solicitud para que la hebra se encargue de darla ser­ vicio. Una vez que la hebra completa su tarea, vueive ai conjunto com partido y espera hasta que haya m ás trabajo. Si el conjunto no tiene ninguna hebra disponible, el servidor espera hasta que quede una libre. Los conjuntos com partidos de hebras ofrecen l a s siguientes ventajas;

126

Capítulo 4 Hebras

1. Dar servicio a una solicitud con una hebra existente norm alm ente es más rápido que esperar; a crear una hebra. 2. Un conjunto de hebras limita el número de hebras existentes en cualquier instante dado. Esto es particularm ente im portante en aquellos sistem as que no puedan soportar un gran núme­ ro de hebras concurrentes. ■ El núm ero de hebras del conjunto puede definirse heurísticam ente basándose en factores como el núm ero de procesadores del sistema, la cantidad de m em oria física y el núm ero esperado de solicitudes concurrentes de los clientes. Las arquitecturas de conjuntos de hebras más complejas pueden ajustar dinám icam ente el número de hebras del conjunto de acuerdo con los patrones de uso. Tales arquitecturas proporcionan la im portante ventaja de tener un conjunto com partido más pequeño, que consum e menos memoria, cuando la carga del sistem a es baja. La API de W in32 proporciona varias funciones relacionadas con los conjuntos de hebras. El uso de la API del conjunto com partido de hebras es sim ilar a la creación de una hebra con la función T h r e a d C r e a t e (), com o se describe en la Sección 4.3.2. El código m ostrado a continuación defi­ ne una función que hay que ejecutar como una hebra independiente:

DWORD WINAPI PoolFunction(AVOID Param) { ! ★★

/* esta función se ejecuta como una hebra independiente. ★★j

} Se p a sa u n p u n tero a P o o l F u n c t i o n () a u n a d e las fu n cio n e s d e la API del co n ju n to d e hebras, y u n a h eb ra del co n ju n to se e n ca rg a d e ejecu tar e sta fu n ció n . U n a d e e sa s fu n cio n es d e la API del co n ju n to d e h eb ras es Q u e u e U s e r W o r k lt e m ( ) , a la q u e se p a s a n tres p a rá m e tro s :

• LPTHREAD_START_ROUTINE Function— un puntero a la función que se va a ejecutar como una hebra independiente.

• PVOID Param— el parámetro pasado a Function • ULONG Flags— una serie de indicadores que regulan cóm o debe el conjunto de hebras crear la hebra y gestionar su ejecución. Un ejem plo de invocación sería:

QueueUserWorkltem(&PoolFunction, NULL, 0); Esto hace que una hebra del conjunto de hebras invoque PoolFunction () por cuenta nuestra; en este caso, no pasamos ningún parámetro a PoolFunction (). Dado que especificam os 0 como indicador, no proporcionam os al conjunto de hebras ninguna instrucción especial para la creación de la hebra. Otras funciones de la API del conjunto de hebras de W in32 son las utilidades que invocan fun­ ciones a intervalos periódicos o cuando se com pleta una solicitud de E/S asincrona. El paquete a v a . ú t i l . c o n c u r r e n t de Java proporciona tam bién una funcionalidad de conjunto com­ partido de hebras.

j

1.5

4.4.5 Datos específicos de una hebra Las hebras que pertenecen a un mismo proceso com parten los datos del proceso. Realmente, esta com partición de datos constituye una de las ventajas de la program ación multihebra. Sin embar­ go, en algunas circunstancias, cada hebra puede necesitar su propia copia de ciertos datos. Llam arem os a dichos datos, datos específicos de la hebra. Por ejem plo, en un sistema de proce­ sam iento de transacciones, podemos dar servicio a cada transacción m ediante una hebra distinta. Adem ás, puede asignarse a cada transacción un identificador unívoco. Para asociar cada hebra con su identificador unívoco, podemos emplear los datos específicos de la hebra. La mayor parte de las bibliotecas de hebras, incluyendo VVin32 y Pthreads, proporcionan ciertos m ecanism o- ole

4.4 Consideraciones sobre las hebras

127

soporte para los datos específicos de las hebras. Java tam bién proporciona soporte para este tipo de datos.

4.4.6 Activaciones del planificador Una últim a cuestión que hay que considerar en los program as m ultihebra concierne a los m eca­ nismos de com unicación entre el kernel y la biblioteca de hebras, que pueden ser necesarios para los modelos m uchos-a-m uchos y de dos niveles vistos en la Sección 4.2.3. Tal coordinación perm i­ te que el núm ero de hebras del kernel se ajuste de form a dinám ica, con el fin de obtener el mejor rendim iento posible. M uchos sistem as que im plem entan el m odelo m uchos-a-m uchos o el m odelo de dos niveles colocan una estructura de datos interm edia entre las hebras de usuario y del kernel. Esta estructu­ ra de datos, conocida norm alm ente como el nom bre de proceso ligero o LWP (lightw eight process) se m uestra en la Figura 4.9. A la biblioteca de hebras de usuario, el proceso ligero le parece un pro­ cesador virtual en el que la aplicación puede hacer que se ejecute una hebra de usuario. Cada LWP se asocia a una hebra del kernel, y es esta hebra del kernel la que el sistem a operativo ejecuta en los procesadores físicos. Si una hebra del kernel se bloquea (por ejem plo, m ientras espera a que se complete una operación de E/ S), el proceso ligero LWP se bloquea tam bién. Por últim o, la hebra de usuario asociada al LWP tam bién se bloquea. Una aplicación puede requerir un núm ero cualquiera de procesos ligeros para ejecutarse de forma eficiente. Considere una aplicación lim itada por CPU que se ejecute en un solo procesador. En este escenario, sólo una hebra puede ejecutarse cada vez, por lo que un proceso ligero es sufi­ ciente. Sin em bargo, una aplicación que haga un uso intensivo de las operaciones de E/S puede requerir ejecutar múltiples procesos LWP. N orm alm ente, se necesita un proceso ligero por cada llamada concurrente al sistem a que sea de tipo bloqueante. Por ejem plo, suponga que se produ­ cen sim ultáneam ente cinco lecturas de archivo diferentes; se necesitarán cinco procesos ligeros, ya que todos podrían tener que esperar a que se com plete una operación de E/S en el kernel. Si un proceso tiene sólo cuatro LWP, entonces la quinta solicitud tendrá que esperar a que uno de los procesos LWP vuelva del kernel. Un posible esquema de com unicación entre la biblioteca de hebras de usuario y el kernel es el que se conoce con el nom bre de activación del p lan ificad or, que funciona como sigue: el kernel proporciona a la aplicación un conjunto de procesadores virtuales (LWP) y la aplicación puede pla­ nificar la ejecución de las hebras de usuario en uno de los procesadores virtuales disponibles. Además, el kem el debe inform ar a la aplicación sobre determ inados sucesos; este procedim iento se conoce com o el nombre de suprallam ada (upcall) Las suprallam adas son tratadas por la biblio­ teca de hebras mediante una ru tina de tratam iento de suprallam ada, y estas rutinas deben ejecu­ tarse sobre un procesador virtual. Uno de los sucesos que disparan una suprallam ada se produce cuando una hebra de la aplicación esté a punto de bloquearse. En este escenario, el kernel realiza una suprallam ada a la aplicación para informarla de que una hebra se va a bloquear y para iden­ tificar la hebra concreta de que se trata. El kernel asigna entonces un procesador virtual nuevo a la hebra de usuario

LWP

proceso ligero

Figura 4.9 Proceso ligero (LWP).

Capítulo 4 Hebras

128

aplicación. La aplicación ejecuta la rutina de tratam iento de la suprallamada sobre el nuevo pr cesador virtual, que guarda el estado de la hebra bloqueante, y libera el procesador virtual en que se está ejecutando dicha hebra. La rutina de tratam iento de la suprallamada planifica ento ces la ejecución de otra hebra que reúna los requisitos para ejecutarse en el nuevo procesador vi tual. Cuando se produce el suceso que la hebra bloqueante estaba esperando, el kernel hace ot suprallam ada a la biblioteca de hebras para inform ar de que la hebra anteriormente bloqueac ahora puede ejecutarse. La rutina de tratam iento de la suprallamada correspondiente a este suc so tam bién necesita un procesador virtual, y el k em el puede asignar un nuevo procesador o su pender tem poralm ente una de las hebras de usuario y ejecutar la rutina de tratam iento de suprallam ada en su procesador virtual. D espués de marcar la hebra desbloqueada com o dispon ble para ejecutarse, la aplicación elige una de las hebras que esté preparada para ejecutarse y 1 ejecuta en un procesador virtual disponible.

4.5

Ejemplos de sistemas operativos En esta sección explorarem os cóm o se im plem entan las hebras en los sistemas W indow s XP Linux.

4.5.1 Hebras de W indows XP W indows XP im plem enta la API Win32. Esta API es la principal interfaz de programación de api caciones de la fam ilia de sistem as operativos M icrosoft (Windows 95, 98, NT, 2000 y XP Ciertam ente, gran parte de lo que se ha explicado'en esta sección se aplica a esta fam ilia de sisL mas operativos. Una aplicación de W indow s XP se ejecuta com o un proceso independiente, y cada proces puede contener una o más hebras. La API de W in32 para la creación de hebras se explica en ’ Sección 4.3.2. W indow s X P utiliza el m odelo uno-a-uno descrito en la Sección 4.2.2, donde cae hebra de nivel de usuario se asigna a una hebra del kem el. Sin embargo, W indows XP tam bién prc porciona soporte para una biblioteca de fib ras, que proporciona la funcionalidad del model m uchos-a-m uchos (Sección 4.2.3). Con la biblioteca de hebras, cualquier hebra perteneciente a u proceso puede acceder al espacio de direcciones de dicho proceso. Los com ponentes generales de una hebra son: • Un identifícador de hebra que identifique de forma unívoca la hebra. • Un conjunto de registros que represente el estado del procesador. •

Una pila de usuario, em pleada cuando la hebra está ejecutándose en modo usuario, y un pila del kernel, em pleada cuando la hebra se esté ejecutando en modo kem el.

• U n área de alm acenam iento privada usada por las distintas bibliotecas de tiempo de ejeci ción y b ib lio te c a s d e enlace dinám ico (DLL). El conjunto de registros, las pilas y el área de alm acenam iento privado constituyen el conte> to de la hebra. Las principales estructuras de datos de una hebra son: •

ETHREAD— bloque de hebra ejecutiva

• KTHREAD— bloque de hebra del kernel • TEB— bloque de entorno de la hebra Los com ponentes clave de ETHREAD incluyen un puntero al proceso al que pertenece la hebr y la dirección de la rutina en la que la hebra inicia su ejecución. ETHREAD también contiene u: puntero al correspondiente bloque KTHREAD. KTHREAD incluye inform ación de planificación y sincronización de la hebra. A dem ás, KTHR1 AD incluye la pila del kernel (utilizada cu and o la hebra se está ejecutando en m odo kem el) -'y u puntero al bloque TEB.

4.5 Ejemplos de sistemas operativos

129

ETHREAD dirección de inicio de la hebra puntero al proceso padre

KTHREAD información de planificación

y sincronización

pila del kemel

TEB identificador de la hebra pila de usuario almacenamiento local de la hebra

espacio del kernel

Figura 4 .1 0

espacio de usuario

Estructuras de datos d e una hebra de W indows XP.

ETHREAD y KTHREAD están com pletam ente incluidos en el espacio del kem el; esto significa que sólo el kernel puede acceder a ellos. El bloque TEB es una estructura de datos del espacio de usua­ rio a la que se accede cuando la hebra está ejecutándose en modo usuario. Entre otros cam pos, TEB contiene el identificador de la hebra, una pila del modo usuario y una m atriz para los datos espe­ cíficos de la hebra (lo que en la term inología de W indow s XP se denomina alm acen am ien to local de la h eb ra). La estructura de una hebra de W indow s XP se ilustra en la Figura 4.10.

4.5.2 Hebras de Linux Linux proporciona la llam ada al sistem a f o r k () con la funcionalidad tradicional de duplicar un proceso, com o se ha descrito en el Capítulo 3. Linux tam bién proporciona la capacidad de crear hebras usando la llamada al sistema c l o n e (). Sin em bargo, Linux no diferencia entre procesos y hebras. De hecho, generalm ente, Linux utiliza el térm ino tarea en lugar de proceso o hebra, para hacer referencia a un flujo de control dentro de un program a. Cuando se invoca c l o n e (), se pasa un conjunto de indicadores, que determ ina el nivel de com partición entre las tareas padre e hijo. Algunos de estos indicadores son los siguientes:

indicador CLONE_FS CLONE_VM CLONE_SIGHAND CLONE_FILES

significado Se comparte información del sistema de archivos. Se comparte el mismo espacio de memoria. Se comparten los descriptores de señal. Se comparte el conjunto de archivos abiertos.

Capítulo 4 Hebras

130

Por ejemplo, si se pasan a c l o n e () los indicadores CLONE_FS, CLONE_VM, CLONE_SIGHAtr y CLONE_FIL.e s , las tareas padre e hijo com partirán la m ism a inform ación del sistem a de archi­ vos (como por ejem plo, el directorio actual de trabajo), el m ism o espacio de m emoria, las misma. rutinas de tratam iento de señal y el m ism o conjunto de archivos abiertos. Usar c l o n e () de esu modo es equivalente a crear una hebra com o se ha descrito en este capítulo, dado que la tare: padre com parte la mayor parte de sus recursos con sus tareas hijo. Sin embargo, si no se defin. ninguno de estos indicadores al invocar c l o n e (), no habrá com partición, teniendo entonces un¿ funcionalidad sim ilar a la proporcionada por la llam ada al sistema f o r k (). El nivel variable de com partición es posible por la form a en que se representa una tarea en e kernel de Linux. Existe una estructura de datos del kem el específica (concretam ente, s truco t a s k _ s t r u c t ) para cada tarea del sistema. Esta estructura, en lugar de alm acenar datos para L tarea, contiene punteros a otras estructuras en las que se alm acenan dichos datos, com o por ejem­ plo estructuras de datos que representan la lista de archivos abiertos, inform ación sobre el trata­ miento de señales y la memoria virtual. Cuando se invoca f o r k (), se crea una nueva tarea junte con una copia de todas las estructuras de datos asociadas del proceso padre. Tam bién se crea una tarea nueva cuando se realiza la llam ada al sistem a c l o n e (); sin em bargo, en lugar de copia' todas las estructuras de datos, la nueva tarea apunta a las estructuras de datos de la tarea padre en función del conjunto de indicadores pasados a c l o n e ().

4.6

Resumen Una hebra es un flujo de control dentro de un proceso. U n proceso m ultihebra contiene varios flu­ jos de control diferentes dentro del m ism o espacio de direcciones. Las ventajas de los mecanismo, m ultihebra son que proporcionan una m ayor capacidad de respuesta al usuario, la comparticiór de recursos dentro del proceso, una m ayor econom ía y la capacidad de aprovechar las ventajas el­ las arquitecturas m ultiprocesador. Las hebras de nivel de usuario son hebras visibles para el program ador y desconocidas para e kernel. El kernel del sistema operativo soporta y gestiona las hebras del nivel de kernel. En genera las hebras de usuario se crean y gestionan más rápidam ente que las del kernel, ya que no es nece saria la intervención del kem el. Existen tres m odelos diferentes que perm iten relacionar las hebra de usuario y las hebras del kem el. el m odelo m uchos-a-uno asigna m uchas hebras de usuario a un sola hebra del kernel; el modelo uno-a-uno asigna a cada hebra de usuario la correspondient hebra del kernel; el modelo m uchos-a-m uchos m ultiplexa muchas hebras de usuario sobre u número m enor o igual de hebras del kernel. La mayoría de los sistemas operativos m odernos proporcionan soporte para hebras en el kenel; entre ellos se encuentran W indows 98, NT, 2000 y XP, así como Solaris y Linux. Las bibliotecas de hebras proporcionan al program ador de la aplicación una API para crear gestionar hebras. Las tres bibliotecas de hebras principales de uso com ún son: Pthreads de POSl> las hebras de W in32 para los sistem as W indow s y las hebras de Java. Los programas m ultihebra plantean m uchos retos a los program adores, entre los que se inclu ye la semántica de las llamadas al sistem a f o r k () y e x e c (). Otras cuestiones relevantes son 1 cancelación de hebras, el tratamiento de señales y los datos específicos de las hebras.

Ejercicios 4.1

Proporcione dos ejemplos de program ación en los que los m ecanism os m ultihebra no prc porcionen un mejor rendim iento que una solución m onohebra.

4.2

Describa las acciones que toma una biblioteca de hebras para cam biar el contexto entr hebras de nivel de usuario.

4.3

^Rcijo tjü.c circunstancias una solución m ultihebra que usa m últiples hebras del kernel prt porciona un mejor rendimiento que una solución de una sola hebra sobre un sistem a monc

procesador?

Ejercicios

4.4

131

¿Cuáles de los siguientes com ponentes del estado de un program a se com parten entre las hebras de un proceso m ultihebra? a. Valores de los registros b. C úm ulo de m em oria c. Variables globales d. M em oria de pila

4.5

¿Puede una solución m ultihebra que utilice múltiples hebras de usuario conseguir un mejor rendim iento en un sistem a m ultiprocesador que en un sistem a de un solo procesador?

4.6

Com o se ha descrito en la Sección 4.5.2, Linux no diferencia entre procesos y hebras. En su lugar, Linux trata del m ism o modo a ambos, perm itiendo que una tarea se asem eje más a un proceso o a una hebra, en función del conjunto de indicadores que se pasen a la llam a­ da al sistem a c l o n e (}. Sin embargo, m uchos sistem as operativos, com o W indows XP y Solaris, tratan las hebras y los procesos de form a diferente. N orm alm ente, dichos sistemas usan una notación en la que la estructura de datos para un proceso contiene punteros a las distintas hebras pertenecientes al proceso. Com pare estos dos m étodos para el m odelado de procesos y hebras dentro del kernel.

4.7

El program a mostrado en la Figura 4.11 usa la API de Pthreads. ¿Cuál sería la salida del pro­ gram a en la LÍNEA C y en la LÍNEA P?

#include #include int valué =0; void *runner(void ‘parara); /* la hebra */ int mainíint argc, char *argv[]) {

int pid; pthread_t tid; pthread_attr_t attr; pid = fork() ;. if (pid == 0) { /* proceso hijo */ pthread_attr_init(&attr); pthread_create(&tia, &attr, runner, NULL); pthread_join (tid, NtTLL) ; printf ("HIJO: valer = %d", valué); /* LÍNEA C * / return -1; }

else if (pid > 0) {/* proceso padre */ wait'NULL); printf ("PADRE: valor = %d", valué); /* LÍNEA P*/ } }

void ‘runnerívoid ‘parara;< valué = 5 pthread_exit(0); }

Figura 4.11 Programa en C para el Ejercicio 4.7.

"'

132

Capítulo 4 Hebras

4.8

Considere un sistem a m ultiprocesador y un programa m ultihebra escrito usando el lo m uchos-a-m uchos. Suponga que el núm ero de hebras de usuario en el programa e f m ayor que el núm ero de procesadores del sistema. Explique el impacto sobre el rendimieip to en los siguientes escenarios: * a. El núm ero de hebras del kernel asignadas al programa es menor que el n ú m e ro ^ procesadores. b. El núm ero de hebras del kernel asignadas al programa es igual que el núm ero de pro. cesadores. c. El núm ero de hebras del kernel asignadas al programa es mayor que el número de procesadores, pero m enor que el núm ero de hebras de usuario. .

4.9

Escriba un program a m ultihebra Java, Pthreads o W in32 que genere como salida los sucesi­ vos núm eros primos. Este program a debe funcionar como sigue: el usuario ejecutará el pro­ grama e introducirá un núm ero en la línea de comandos. Entonces, el program a creará una hebra nueva que dará com o salida todos los números primos menores o iguales que el núm ero especificado por el usuario.

4.10

M odifique el servidor horario basado en sockets (Figura 3.19) del Capítulo 3, de modo que el servidor dé servicio a cada solicitud de un cliente a través de una hebra distinta.

4 .1 1

La secuencia de Fibonacci es la serie de núm eros 0 , 1 ,1 , 2, 3, 5, 8,... Form alm ente se expresa como sigue: -

fih v 0 f i bi = l f i bn

+ f i bn-2

Escriba un program a m ultihebra que genere la serie de Fibonacci usando la biblioteca de hebras Java, Pthreads o W in32. Este program a funcionará del siguiente modo: el usuario especificará en la línea de com andos la cantidad de números de la secuencia de Fibonacci que el program a debe generar. El program a entonces creará una nueva hebra que generará los núm eros de Fibonacci, colocando la secuencia en variables com partidas por todas las hebras (probablem ente, una m atriz será la estructura de datos más adecuada). Cuando la hebra term ine de ejecutarse, la hebra padre proporcionará a la salida la secuencia generada por la hebra hijo. Dado que la hebra padre no puede com enzar a facilitar com o salida la secuencia de Fibonacci hasta que la hebra hijo termine, hará falta que la hebra padre espe­ re a que la hebra hijo concluya, m ediante las técnicas descritas en la Sección 4.3. 4 .1 2

El Ejercicio 3 .9 del Capítulo 3 especifica el diseño de un servidor de eco usando la API de hebras Java. Sin em bargo, este servidor es de una sola hebra, lo que significa que no puede responder a clientes de eco concurrentes hasta que el cliente actual concluya. M odifique la solución del ejercicio 3 .9 de m odo que el servidor de eco dé servicio a cada cliente m edian­ te una hebra distinta.

Proyecto: multiplicación de matrices Dadas dos m atrices, A y 6, donde A es una m atriz con M filas y K colum nas y la m atriz B es una matriz con K filas y N colum nas, la m atriz producto de A por B es C, la cual tiene M filas y .V columnas. La entrada de la m atriz C en la fila i, colum na j (C ,.) es la sum a de los productos de los elementos de la fila i de la m atriz A y la colum na j de la matriz B. Es decir, C . - y A ... X B

Proyecto: multiplicación de matrices

133

Por ejem plo, si A fuera una m atriz de 3 por 2 y B fuera una matriz de 2 por 3, el elem ento C31 sería la sum a de A3 x B-¡ ^y A3 ^ x B j 3 En este proyecto querem os calcular cada elemento C1; m ediante una hebra de trabajo diferente. Esto im plica crear M X N hebras de trabajo. La hebra principal, o padre, inicializará las m atrices A y B y asignará m em oria suficiente para la matriz C, la cual alm acenará el producto de las m atri­ ces A y B. Estas m atrices se declararán com o datos globales, con el fin de que cada hebra de tra­ bajo tenga acceso a A, B y C. Las m atrices A y B pueden inicializarse de forma estática del siguiente modo:

#define M 3 #define K 2 #define N 3 int A [M] [K] = { {1-4}, {2,5}, {3,6} int B [K] [N] = { {8,7,6} , {5,4,3} }; int C [M] INI ; A lternativam ente, pueden rellenarse leyendo los valores de un archivo. Paso de parám etros a cada hebra La hebra padre creará M x N hebras de trabajo, pasando a cada hebra los valores de la fila i y la colum na j que se van a usar para calcular la matriz producto. Esto requiere pasar dos parám etros a cada hebra. La form a m ás sencilla con Pthreads y W in32 es crear una estructura de datos usan­ do s t r u c t . Los m iem bros de esta estructura son i y j, y la estructura es:

/* .estructura para pasar datos a las hebras */ struct v {

int i; /* fila */ int j ; /* columna */ }; Los program as de Pthreads y W in32 crearán las hebras de trabajo usando una estrategia sim i­ lar a la que se muestra a continuación:

/* Tenemos que crear M * N hebras de trabajo -*/ for (i = 0; i < M, i++ ) for (j = 0; j < N; j++ ) { struct v *data = (struct v *) malloc (sizeof (struct v) ) ,data->i = i; data->j = j ; /* Ahora creamos la hebra pasándola data como parámetro */ } } El puntero data se pasará a la función de Pthreads pthread_create O o a la función de W in32 CreateThread (), que a su vez lo pasará como parám etro a la función que se va a ejecutar como una hebra independiente. La com partición de datos entre hebras Java es diferente de la com partición entre hebras de Pthreads o W in32. Un m étodo consiste en que la hebra principal cree e inicíalice las m atrices A, B y C. Esta hebra principal creará a continuación las hebras de trabajo, pasando las tres m atrices, junto con la fila i y la co lu m n a;, al constructor de cada hebra de trabajo. Por tanto, el esquem a de una hebra de trabajo será com o sigue:

public class WorkerThread implements Runnable

134

Capítulo 4 Hebras

private private private private private

int row, int col ; int [] [1 A; int [] [] B; int [] [] CN-

public WorkerThread(int row, int col, int[][] A, int [] [] B, int [] [] C) { tliis .row = this .col = this .A = A; this .B = B; this .C = C; }

public void run() { /* calcular la matriz producto en C[row]

[col] */

} }

Esperar a que se completen las hebras Una vez que todas las hebras de trabajo se han com pletado, la hebra principal proporcionará! com o salida el producto contenido en la m atriz C. Esto requiere que la hebra principal espere al que todas las hebras de trabajo term inen antes de poder poner en la salida el valor de la m atriz1 producto. Se pueden utilizar varias estrategias para hacer que una hebra espere a que las demás i terminen. La Sección 4.3 describe cóm o esperar a que una hebra hijo se com plete usando las b ib lio te c a s de h e b ra s de P th re a d s , W in 3 2 y Ja v a . W in 3 2 p r o p o r c io n a la fu n c ió n WaitForSingleObj ect (), mientras que Pthreads y Java usan, respectivamente, pthread_ join () y jo i n (). Sin embargo, en los ejemplos de program ación de esa sección, la hebra padre espera a que una sola hebra hijo termine; com pletar el presente ejercicio requiere, por el contrario, esperar a que concluyan múltiples hebras. En la Sección 4.3.2 hem os descrito la función WaitForSingleObj ect (), que se em plea para esperar a que una sola hebra termine. Sin embargo, la API de W in32 tam bién proporciona la fun­ ción WaitForMultipleObjects (), que se usa para esperar a que se com pleten múltiples hebras. A WaitForMultipleObj ects () hay que pasarle cuatro parámetros: 1. El núm ero de objetos por los que hay que esperar

2. U n puntero a la m atriz de objetos. 3. U n indicador que m uestre si todos los objetos han sido señalizados. 4. Tiem po de espera (o INFINITE). Por ejem plo, si THandles es una m atriz de objetos HANDLE (descriptores) de hebra de tam a­ ño N, la hebra padre puede esperar a que todas las hebras hijo se com pleten con la siguiente ins­ trucción:

WaitForMultipleObjects (N, THandles, TRUE, INFINITE); Una estrategia sencilla para esperar a que varias hebras terminen usando la función p t h r e -

ad_j o i n () de Pthreads o join () de Java consiste en incluir la operación en un bucle fo r . Por ejem plo, podríamos esperar a que se com pletaran diez hebras usando el código de Pthreads de la Figura 4.12. El código equivalente usando Java se m uestra en la Figura 4.13.

Notas bibliográficas

135

#define NUM_THREADS 10 /* una matriz de hebras que se van a esperar */ pthread_t workers[NUM_THREADS] ; for (int i = 0; i < NUM_THREADS; i++ ) pthread_join(workers[i], NULL);

Figura 4.12 Código Pthread para esperar diez hebras. final static int NUM_THREADS 10; /* una matriz de hebras que se van a esperar */ Thread[] workers = new Thread[NUM_THREADS]; for (int i = 0; i < NUM_THREADS; i++) { try { workers[i].join(); }catch (InterruptedException ie) {} }

Figura 4.13 Código Java para esperar diez hebras.

Notas bibliográficas Las cuestiones sobre el rendim iento de las hebras se estudian en A nderson et al. [1989], quien con­ tinuó su trabajo en Anderson et al. [1991] evaluando el rendim iento de las hebras de nivel de usuario con soporte del kernel. Bershad et al. [1990] describe la com binación de los m ecanism os de hebras con las llamadas RPC. Engelschall [2000] expone una técnica para dar soporte a las hebras de nivel de usuario. Un análisis sobre el tam año óptim o de los conjuntos com partidos de hebras es el que puede encontrarse en Ling et al. [2000]. Las activaciones del planificador se presentaron por prim era ver en Anderson et al. [1991] y W illiam s [2002] aborda las activaciones del planifica­ dor en el sistem a NetBSD. Otros mecanismos m ediante los que la biblioteca de hebras de usuario y el kernel pueden cooperar entre sí se tratan en M arsh et al. [1991], G ovindan y Anderson [1991], Draves et al. [1991] y Black [1990]. Zabatta y Young [1998] com paran las hebras de W indows \'T y Solaris en un m ultiprocesador simétrico. Pinilla y G ilí [2003] com paran el rendim iento de las hebras Java en los sistem as Linux, W indows y Solaris. Vahaba [1996] cubre el tema de las hebras en varias versiones de UNIX. M auro y M cDougall [2001] describen desarrollos recientes en el uso de hebras del kernel de Solaris. Solom on y Russinovich [2000] abordan el uso de hebras en W indow s 2000. Bovet y Cesati [2002] explican cóm o gestiona Linux el m ecanism o de hebras. En Lew is y Berg [1998] y Butenhof [1997] se proporciona inform ación sobre program ación con Pthreads. La inform ación sobre programación de hebras en Solaris puede encontrarse en Sun M icrosystem s [1995], Oaks y Wong [1999], Lewis y Berg [2000] y H olub [2000] abordan las solu­ ciones m ultihebra en Java. Beveridge y W iener [1997] y Cohén y W oodring [1997] describen las soluciones m ultihebra usando WTin32.

c A

g r y Lq

panificación ^ ia CPU Los mecanism os de planificación de la CPU son la base de los sistem as operativos m ultiprogram ados. M ediante la conm utación de la CPU entre distintos procesos, el sistem a operativo puede hacer que la com putadora sea m ás productiva. En este capítulo, vamos a presentar los conceptos bási­ cos sobre la planificación de la CPU y varios de los algoritm os utilizados para este fin. Tam bién consideraremos el problem a de seleccionar el m ejor algoritm o para un sistem a particular. En el Capítulo 4, hem os presentado el concepto de hebras en el m odelo de procesos. En los sis­ temas operativos que las soportan, son las hebras del nivel del kernel, y no los procesos, las que de hecho son planificadas por el sistem a operativo. Sin embargo, los términos p lan ificació n de pro­ cesos y p lan ificació n de h eb ras se usan indistintamente. En este capítulo, utilizarem os el térmi. no planificación de procesos cuando hablem os de los conceptos generales sobre planificación y planificación de hebras cuando hagam os referencia a conceptos específicos de las hebras.

OBJETIVOS DEL CAPÍTULO • Presentar los mecanismos de planificación de la CPU, que constituyen los cimientos de los siste­ mas operativos multiprogramados. • Describir los distintos algoritmos para la planificación de la CPU. • Exponer los criterios de evaluación utilizados para seleccionar un algoritmo de planificación de la CPU para un determinado sistema.

5.1

Conceptos básicos En un sistem a de un único procesador, sólo puede ejecutarse un proceso cada vez; cualquier otro proceso tendrá que esperar hasta que la CPU quede libre y pueda volver a planificarse. El objeti­ vo de la m ultiprogram ación es tener continuam ente varios procesos en ejecución, con el fin de m axim izar el uso de la CPU. La idea es bastante simple: un proceso se ejecuta hasta que tenga que esperar, norm alm ente porque es necesario com pletar alguna solicitud de E/S. En un sistem a infor­ mático sim ple, la CPU perm anece entonces inactiva y todo el tiempo de espera se desperdicia; no se realiza ningún trabajo útil. Con la m ultiprogram ación, se intenta usar ese tiempo de form a pro­ ductiva. En este caso, se m antienen varios procesos en m em oria a la vez. Cuando un proceso tiene que esperar, el sistem a operativo retira el uso de la CPU a ese proceso y se lo cede a otro proceso. Este patrón se repite continuam ente y cada vez que un proceso tiene que esperar, otro proceso puede hacer uso de la CPU. Este tipo de planificación es una función fundamental del sistema operativo; casi todos los recursos de la com putadora se planifican antes de usarlos. Por supuesto, la CPU es uno de los prin­ cipales recursos de la com putadora, así que su correcta planificación resulta crucial en el diseño del sistem a operativo.

138

Capítulo 5 Planificación de la CPU

5.1.1 Ciclo de ráfagas de CPU y de E/S La adecuada planificación de la CPU depende de una propiedad observada de los procesos: la e j e j cución de un proceso consta de un ciclo de ejecución en la CPU, seguido de una espera de E /S; lo5B procesos alternan entre estos dos estados. La ejecución del proceso com ienza con una ráfag a d ea CPU. Ésta va seguida de una ráfag a de t/S , a la cual sigue otra ráfaga de CPU, luego otra ráfaga dea F/S, etc. Finalmente, la ráfaga final de CPU concluye con una solicitud al sistem a para terminar laji ejecución (Figura 5.1). |j| La duración de las ráfagas de CPU se ha m edido exhaustivam ente en la práctica. A unque varí-1 an enorm em ente de un proceso a otro y de una com putadora a otra, tienden a presentar una cu rv a l de frecuencia similar a la m ostrada en la Figura 5.2. Generalm ente, la curva es de tipo exponen-1 cial o hiperexponencial, con un gran núm ero de ráfagas de CPU cortas y un núm ero m enor de rá fa jl gas de CPU largas. N orm alm ente, un program a lim itado por E /S presenta m uchas ráfagas de CPu| cortas. Esta distribución puede ser im portante en la selección de un algoritm o apropiado para la 3 planificación de la CPU. |

4

-.3

5.1.2 Planificador de la CPU

|

Cuando la CPU queda inactiva, el sistem a operativo debe seleccionar uno de los procesos que se i encuentran en la cola de procesos preparados para ejecución. El p lan ificad o r a corto p lazo (o pla­ nificador de la CPU) lleva a cabo esa selección del proceso. El planificador elige uno de los proce­ sos que están en memoria preparados para ejecutarse y asigna la CPU a dicho proceso. O bserve que la cola de procesos preparados no necesariam ente tiene que ser una cola FIFO (first-in, first-out). Como verem os al considerar los distintos algoritm os de planificación, una cola de procesos preparados puede im plem entarse com o una cola FIFO, una cola prioritaria, un árbol o sim plem ente una lista enlazada no ordenada. Sin em bargo, conceptualm ente, todos los proce-

load store add store read

dearchivo

esp erar E/S store increment index write

enarchivo

esp erar E/S

load store add store read

dearchivo

esp era r E/S

*

ráfagadeCPU ráfagadeE/S ráfagadeCPU ráfagadeE/S ráfagadeCPU ráfagadeE/S

Figura 5.1 Secuencia alternante de ráfagas de CPU y d e E/S.

5.1 Conceptos básicos

139

duración de la ráfaga (milisegundos)

Figura 5.2 Histograma de duración de las ráfagas de CPU. sos que se encuentran en la cola de procesos preparados se ponen en fila esperando la oportuni­ dad de ejecutarse en la CPU. Los registros que se alm acenan en las colas son, generalm ente, blo­ ques de control de proceso (PCB) que describen los procesos en cuestión.

5.1.3 Planificación apropiativa Puede ser necesario tomar decisiones sobre planificación de la CPU en las siguientes cuatro cir­ cunstancias: 1. Cuando un proceso cam bia del estado de ejecución al estado de espera (por ejemplo, como resultado de una solicitud de E/S o de una invocación de wait para esperar a que termine uno de los procesos hijo). 2. Cuando un proceso cam bia del estado de ejecución al estado preparado (por ejem plo, cuan­ do se produce una interrupción). 3. Cuando un proceso cam bia del estado de espera al estado preparado (por ejem plo, al com ­ pletarse una operación de E/S).

4.

Cuando un proceso termina.

En las situaciones 1 y 4, no hay más que una opción en términos de planificación: debe seleccio­ narse un nuevo proceso para su ejecución (si hay algún proceso en la cola de procesos preparados). Sin embargo, en las situaciones 2 y 3 sí que existe la opción de planificar un nuevo proceso o no. Cuando las decisiones de planificación sólo tienen lugar en las circunstancias 1 y 4, decimos que el esquem a de planificación es sin d esalojo o co o p erativ o ; en caso contrario, se trata de un esquema ap rop iativ o. En la planificación sin desalojo, una vez que se ha asignado la CPU a un pro­ ceso, el proceso se m antiene en la CPU hasta que ésta es liberada bien por la term inación del pro­ ceso o bien por la conm utación al estado de espera. Este m étodo de planificación era el utilizado por M icrosoft W indows 3.x; W indow s 95 introdujo la planificación apropiativa y todas las versio­ nes siguientes de los sistem as operativos W indows han usado dicho tipo de planificación. El sis­ tema operativo Mac OS X para M acintosh utiliza la planificación apropiativa; las versiones anteriores del sistema operativo de M acintosh se basaban en la planificación cooperativa. La pla­ nificación cooperativa es el único m étodo que se puede em plear en determ inadas plataformas

Capítulo 5 Planificación de la CPU

140

hardware, dado que no requiere el hardware especial (por ejem plo, un tem porizador) necesario^ para la planificación apropiativa. *g Lam entablem ente, la planificación apropiativa tiene un coste asociado con el acceso a los datos! com partidos. Considere el caso de dos procesos que com partan datos y suponga que, m ientras* que uno está actualizando los datos, resulta desalojado con el fin de que el segundo proceso p.ueda| ejecutarse. El segundo proceso podría intentar entonces leer los datos, que se encuentran en u n í estado incoherente. En tales situaciones, son necesarios nuevos m ecanism os para coordinar e lj acceso a los datos com partidos; verem os este tem a en el Capítulo 6. | La técnica de desalojo tam bién afecta al diseño del kem el del sistem a operativo. Durante el p ro-j cesam iento de una llam ada al sistem a, el kernel puede estar ocupado realizando una actividad enf nom bre de un proceso. Tales actividades pueden im plicar cam bios im portantes en los datos del'j¡ kernel (por ejem plo, en las colas de E /S ) . ¿Qué ocurre si el proceso se desaloja en m itad de estos® cam bios y el kem el (o el controlador del dispositivo) necesita leer o m odificar la m ism a estructu- = ra? El resultado será un auténtico caos. Ciertos sistem as operativos, incluyendo la m ayor parte del las versiones de UNIX, resuelven este problem a esperando a que se com plete la llam ada al siste-: ma o a que se transfiera un bloque de E / S antes de hacer un cam bio de contexto. Esta solución p e r-; mite obtener una estructura del kem el sim ple, ya que el kernel no desalojará ningún proceso, m ientras que las estructuras de datos del kem el se encuentren en un estado incoherente. Lam entablem ente, este m odelo de ejecución del kernel no resulta adecuado para perm itir la reali­ zación de cálculos en tiem po real y el m ultiprocesamiento. Estos problem as y sus soluciones se describen en las Secciones 5.4 y 19.5. Dado que, por definición, las interrupciones pueden producirse en cualquier m om ento, y pues­ to que no siem pre pueden ser ignoradas por el kernel, las secciones de código afectadas por las interrupciones deben ser resguardadas de un posible uso sim ultáneo. Sin em bargo, el sistema operativo tiene que aceptar interrupciones casi continuam ente, ya que de otra m anera podrían perderse valores de entrada o sobreescribirse los valores de salida; por esto, para que no puedan acceder de form a concurrente varios procesos a estas secciones de código, lo que se hace es des­ activar las interrupciones al principio de cada sección y volver a activarlas al final. Es importante observar que no son m uy num erosas las secciones de código que desactivan las interrupciones y que, norm alm ente, esas secciones contienen pocas instrucciones.

5.1.4 Despachador Otro com ponente im plicado en la función de planificación de la CPU es el despachador. El despa­ chador es el módulo que proporciona el control de la CPU a los procesos seleccionados por el pla­ nificador a corto plazo. Esta función implica lo siguiente: • Cambio de contexto. • Cambio al modo usuario. • Salto a la posición correcta dentro del program a de usuario para reiniciar dicho programa. El despachador debe ser lo m ás rápido posible, ya que se invoca en cada conm utación de pro­ ceso. El tiempo que tarda el despachador en detener un proceso e iniciar la ejecución de otro se conoce com o laten cia de despacho.

5.2

Criterios de planificación Los diferentes algoritm os de planificación de la CPU tienen distintas propiedades, y la elección de un algoritm o en particular puede favorecer una clase de procesos sobre otros. A la hora de deci­ dir qué algoritm o utilizar en una situación particular, debemos considerar las propiedades de los diversos algoritmos. Se han sugerido m uchos criterios para com parar los distintos algoritm os de planificación. Las carácterísticas que se usen para realizar la com paración pueden afectar enorm em ente a la deter­ m inación de cuál es el m ejor algoritm o. Los criterios son los siguientes:

5.2 Criterios de planificación

141

• U tilización de la CPU. D eseam os m antener la CPU tan ocupada com o sea posible. Conceptualm ente, la utilización de la CPU se define en el rango com prendido entre el 0 y el 100 por cien. En un sistem a real, debe variar entre el 40 por ciento (para un sistem a ligera­ m ente cargado) y el 90 por ciento (para un sistem a intensam ente utilizado). • T asa de procesam iento. Si la CPU está ocupada ejecutando procesos, entonces se estará lle­ vando a cabo algún tipo de trabajo. Una m edida de esa cantidad de trabajo es el núm ero de procesos que se com pletan por unidad de tiempo, y dicha medida se denom ina tasa de pro­ cesamiento. Para procesos de larga duración, este valor puede ser de un proceso por hora; para transacciones cortas, puede ser de 10 procesos por segundo. • Tiem po de ejecución. Desde el punto de vista de un proceso individual, el criterio im por­ tante es cuánto tarda en ejecutarse dicho proceso. El intervalo que va desde el instante en qu e se ordena la ejecución de un proceso hasta el instante en que se com pleta es el tiempo de ejecución. Ese tiempo de ejecución es la suma de los períodos que el proceso invierte en espe­ rar para cargarse en memoria, esperar en la cola de procesos preparados, ejecutarse en la CPU y realizar las operaciones de E/S. • Tiem po de espera. E l a lg o ritm o d e p la n ifica ció n d e la CPU n o a fe c ta a la c a n tid a d d e tie m p o d u ra n te la q u e u n p ro c e s o se e jecu ta o h a c e u n a o p e ra ció n d e E /S ; a fe c ta só lo al p e río d o d e tie m p o q u e u n p ro c e s o in v ie rte en e s p e ra r e n la co la d e p ro c e s o s p re p a ra d o s . E l tiem po de espera es la su m a d e los p e río d o s in v e rtid o s e n e sp e ra r e n la co la d e p ro c e s o s p re p a ra d o s .

• Tiem po de respuesta. En un sistem a interactivo, el tiempo de ejecución puede no ser el m ejor criterio. A m enudo, un proceso puede generar parte de la salida con relativa rapidez y puede continuar calculando nuevos resultados m ientras que los resultados previos se envían a la salida para ponerlos a disposición del usuario. Por tanto, otra m edida es el tiem ­ po transcurrido desde que se envía una solicitud hasta que se produce la prim era respues­ ta. Esta medida, denom inada tiempo de respuesta, es el tiempo que el proceso tarda en em pezar a responder, no el tiempo que tarda en enviar a la salida toda la inform ación de respuesta. Generalm ente, el tiem po de respuesta está lim itado por la velocidad del disposi­ tivo de salida. El objetivo consiste en m axim izar la utilización de la CPU y la tasa de procesam iento, y m ini­ mizar el tiem po de ejecución, el tiempo de espera y el tiem po de respuesta. En la m ayoría de los casos, lo que se hace es optim izar algún tipo de valor prom edio. Sin em bargo, en determ inadas circunstancias, resulta deseable optim izar los valores m áxim o y mínimo en lugar del prom edio. Por ejem plo, para garantizar que todos los usuarios tengan un buen servicio, podem os tratar de m inim izar el tiempo de respuesta máximo. D iversos investigadores han sugerido que, para los sistem as interactivos (com o, por ejem ­ plo, los sistem as de tiem po com partido), es más im portante m inim izar la varianza del tiem po de respuesta que m inim izar el tiem po m edio de respuesta. Un sistem a con un tiem po de res­ puesta razonable y predecible puede considerarse m ás deseable que un sistem a que sea más rápido por térm ino m edio, pero que resulte altam ente variable. Sin em bargo, no se han llevado a cabo m uchas investigaciones sobre algoritm os de planificación de la CPU que m inim icen la varianza. A m edida que estudiem os en la sección siguiente los diversos algoritm os de planificación de la CPU, tratarem os de ilustrar su funcionam iento. Para poder ilustrar ese funcionam iento de form a precisa, sería necesario utilizar muchos procesos, com puesto cada uno de una secuencia de varios cientos de ráfagas de CPU y de E/S. No obstante, con el fin de simplificar, en nuestros ejem plos sólo vam os a considerar una ráfaga de CPU (en m ilisegundos) por cada proceso. La m edida de com paración que hemos em pleado es el tiempo medio de espera. En la Sección 5.7 se presenta un m ecanism o de evaluación más elaborado.

142

Capítulo 5 Planificación de la CPU

5.3 Algoritmos de planificación La cuestión de la planificación de la CPU aborda el problem a de decidir a qué proceso de la co de procesos preparados debe asignársele la CPU. Existen muchos algoritm os de planificación j la CPU; en esta sección, describiremos algunos de ellos.

5.3.1 Planificación FCFS El algoritm o más sim ple de planificación de la CPU es, con mucho, el algoritm o FCFS (first-coc first-served; primero en llegar, prim ero en ser servido). Con este esquem a, se asigna primero ] CPU al proceso que prim ero la solicite. La im plem entación de la política FCFS se gestiona fácilme te con una cola FIFO. Cuando un proceso entra en la cola de procesos preparados, su PCB se colo ca al final de la cola. Cuando la CPU queda libre, se asigna al proceso que esté al principio de) cola y ese proceso que pasa a ejecutarse se elimina de la cola. El código del algoritmo de pía cación FCFS es sim ple de escribir y fácil de com prender. Sin em bargo, el tiem po medio de espera con el algoritm o FCFS es a m enudo bastante largq Suponga que el siguiente conjunto de procesos llega en el instante 0, estando la duración de i ráfaga de CPU especificada en m ilisegundos: Proceso

Tiempo de ráfaga

24

Pi Pi P3

3 3

Si los procesos llegan en el orden P lr P2, P y y se sirven según el orden FCFS, obtendremos i resultado m ostrado en el siguiente diagram a de G antt:

P1 24

27

30

El tiem po de espera es de 10 m ilisegundos para el proceso Pv de 24 milisegundos para el proce­ so P2 y de 27 m ilisegundos para el proceso P3. Por tanto, el tiempo m edio de espera es de (0 + 24 +27)/3 = 17 m ilisegundos. Sin em bargo, si los procesos llegan en el orden P 2, Py Pp los resultados serán los mostrados en el siguiente diagram a de Gantt:

P2

30 A hora el tiempo de espera es de (6 + 0 + 3)/3 = 3 m ilisegundos. Esta reducción es sustancial. Por tanto, el tiempo m edio de espera con una política FCFS no es, generalmente, mínimo y puede variar significativam ente si la duración de las ráfagas de CPU de los procesos es muy variable. Adem ás, considere el com portam iento del algoritm o de planificación FCFS en un caso dinámi­ co. Suponga que tenem os un proceso lim itado por CPU y muchos procesos limitados por E/S. A m edida que los procesos fluyen por el sistema, puede llegarse al siguiente escenario: el proceso lim itado por CPU obtendrá y mantendrá la CPU; durante ese tiempo, los demás procesos termina­ rán sus operaciones de E/S y pasarán a la cola de procesos preparados, esperando a acceder a la CPU. M ientras que los procesos esperan en la cola de procesos preparados, los dispositivos de E/S están inactivos. Finalm ente, el proceso lim itado por CPU termina su ráfaga de CPU y pasa a espe­ rar por un dispositivo de E/S. Todos los procesos lim itados por E/S, que tienen ráfagas de CPU cortas, se ejecutan rápidam ente y vuelven a las colas de E/S. En este punto, la CPU permanecerá inactiva. El proceso limitado por CPU volverá en algún mom ento a la cola de procesos preparados

5.3 Algoritmos de planificación

143

y se le asignará la CPU. De nuevo, todos los procesos lim itados por E/S term inarán esperando en la cola de procesos preparados hasta que el proceso lim itado por CPU haya terminado. Se produ­ ce lo que se denom ina un efecto co n v o y a m edida que todos los procesos restantes esperan a que ese único proceso de larga duración deje de usar la CPU. Este efecto da lugar a una utilización de la CPU y de los dispositivos m enor que la que se conseguiría si se perm itiera a los procesos más cortos ejecutarse primero. El algoritm o de planificación FCFS es cooperativo. U na vez que la CPU ha sido asignada a un proceso, dicho proceso conserva la CPU hasta que la libera, bien porque termina su ejecución o porque realiza una solicitud de E/S. El algoritm o FCFS resulta, por tanto, especialm ente proble­ mático en los sistem as de tiempo com partido, donde es im portante que cada usuario obtenga una cuota de la CPU a intervalos regulares. Sería desastroso perm itir que un proceso mantuviera la CPU durante un largo período de tiempo.

5.3.2 Planificación SJF Otro m étodo de planificación de la CPU es el algoritm o de planificación con selección del trabajo más corto (SJF,shortest-job-first). Este algoritm o asocia con cada proceso la duración de la siguien­ te ráfaga de CPU del proceso. Cuando la CPU está disponible, se asigna al proceso que tiene la siguiente ráfaga de CPU m ás corta. Si las siguientes ráfagas de CPU de dos procesos son iguales, se usa la planificación FCFS para rom per el em pate. O bserve que un térm ino más apropiado para este m étodo de planificación sería el de algoritm o de la siguiente ráfaga de CPU más corta, ya que la plani­ ficación depende de la duración de la siguiente ráfaga de CPU de un proceso, en lugar de depen­ der de su duración total. Usam os el térm ino SJF porque casi todo el mundo y gran parte de los libros de texto em plean este término para referirse a este tipo de planificación. Com o ejem plo de planificación SJF, considere el siguiente conjunto de procesos, estando espe­ cificada la duración de la ráfaga de CPU en m ilisegundos: Proceso

Tiem po de ráfaga

P, P2 h P4

6 8 7 3

Usando la planificación SJF, planificaríam os estos procesos de acuerdo con el sig u ien te d ia g ra ­ ma de Gantt:

p4 0

p^ 3

Pz

p3 9

16

24

El tiem po de espera es de 3 m ilisegundos para el proceso P-¡, de 16 milisegundos p a ra el pro­ ceso P2, de 9 m ilisegundos para P3 y de 0 m ilisegundos para P4. Por tanto, el tiempo medio de espera es de (3 + 16 + 9 + 0)/4 = 7 m ilisegundos. Por com paración, si estuviéram os usando el esquem a de planificación FCFS, el tiem po m edio de espera sería de 10,25 milisegundos. El algoritm o de planificación SJF es probablem ente óptimo, en el sentido de que proporciona el tiempo m edio de espera m ínim o para un conjunto de procesos dado. Anteponer un proceso corto a uno largo dism inuye el tiempo de espera del proceso corto en m ayor m edida de lo que incre­ m enta el tiempo de espera del proceso largo. C onsecuentem ente, el tiempo medio de espera dism i­ nuye. L a d ificu ltad real del a lg o ritm o SJF es c o n o c e r la d u ra c ió n d e la sig u ien te so licitu d d e CPU. E n u n a p lan ificació n a la rg o p lazo d e trab ajos e n u n sis te m a d e p ro ce sa m ie n to p o r lotes, p o d e m o s u sa r c o m o d u ra ció n el lím ite d e tiem p o del p ro c e s o q u e el u su a rio esp ecifiq u e en el m o m e n to d e en v ia r el trab ajo. C on este m e ca n ism o , los u su a rio s e stá n m o tiv a d o s p a ra e stim a r el lím ite d e tie m ­ p o del p ro ce so d e fo rm a p recisa, d a d o q u e u n v a lo r m e n o r p u e d e sig n ificar u n a re sp u e sta m á s

144

Capítulo 5 Planificación de la CPU

rápida. (Un valor dem asiado bajo producirá un error de límite de tiempo excedido y será necesa­ rio reenviar el proceso.) La planificación SJF se usa frecuentem ente com o mecanismo de planificas ción a largo plazo. ál A unque el algoritm o SJF es óptim o, no se p uede im plem entar en el nivel de la planificación dg? la CPU a corto plazo, y a que no hay form a de conocer la d uración de la siguiente ráfaga de CPUjj¡ U n m étod o consiste en intentar ap roxim ar la planificación SJF: podem os no conocer la duración cíl? la siguiente ráfaga de CPU, pero p odem os predecir su valor, p or el procedim iento de confiar en qnf| la siguiente ráfaga de CPU será sim ilar en duración a las anteriores. De este m odo, calculando unaf aproxim ación de la d u ración de la siguiente ráfaga de CPU, podem os tom ar el proceso que teng^ la ráfaga de CPU pred ich a m ás corta. G eneralm ente, la siguiente ráfaga de CPU se predice com o la m edia exponencial de las dura? d o n e s m edidas de las anteriores ráfagas de CPU. Sea tn la duración de la n-ésima ráfaga de CPU yi sea x„+1 el valor predicho para la siguiente ráfaga de CPU. Entonces, para a , 0 < a < 1, se define x„n = a tn + (1 - a ) xn

Esta fórm ula define un prom edio exponencial. El valor de tn contiene la información m ás recien- , te; xn alm acena el historial pasado. El parám etro a controla el peso relativo del historial reciente y pasado de nuestra predicción. Si a = 0, entonces xn+l = xn, y el historial reciente no tiene ningún efecto (se supone que las condiciones actuales van a ser transitorias); si a = 1, entonces xr¡+1 = tn, y sólo la ráfaga de CPU m ás reciente im porta (se supone que el historial es obsoleto y, por tanto, irrelevante). Frecuentem ente, a = V2, en cuyo caso, el historial reciente y pasado tienen el mismo peso. El valor inicial x0 puede definirse com o una constante o com o un promedio global para todo el sistema. La Figura 5 .3 m uestra un prom edio exponencial con a = V2 y x0 = 10. Para com prender el com portam iento del prom edio' exponencial, podemos desarrollar la fór­ m ula para xn+1 sustituyendo el valor de x„ y de los térm inos sucesivos, obteniendo Un =

a t n

+ (1 - a )a í „-i + • ■■+ (1 - Co' a

tn_ f

+ ■• • + (1 - a ) " * 1x0

D ado que tanto a com o 1 —a son m enores o iguales a 1, cad a térm ino sucesivo tiene m enor peso que su predecesor.

El algoritmo SJF puede ser cooperativo o apropiativo. La necesidad de elegir surge cuando un proceso llega a la cola de procesos preparados m ientras que un proceso anterior está todavía en

tiempo

ráfaga de CPU "invitado" (x,)

(Q

10

6

4

6

8

6

6

4 5

13

13

13

9

11

12

Figura 5.3 Predicción de la duración de ia siguiente ráfaga de CPU.

5.3 Algoritmos de planificación

145

ejecución. La siguiente ráfaga de CPU del proceso que acaba de llegar puede ser más corta que lo que quede del proceso actualm ente en ejecución. U n algoritm o SJF apropiativo detendrá el proce­ so actualm ente en ejecución, m ientras que un algoritm o sin desalojo perm itirá que dicho proceso term ine su ráfaga de CPU. La planificación SJF apropiativa a veces se denom ina p lan ificación con selecció n del p roceso co n tiem p o restan te m ás corto. C o m o ejem p lo , co n sid e re lo s c u a tro p ro ce so s sig u ien tes, e sta n d o e sp e cifica d a la d u ra ció n d e la rá fag a d e CPU e n m iliseg u n d o s:

Proceso

Tiem po de llegada

Pj P2 P3 P4

Tiem po de ráfaga

0 1 2 3

8 4 9 5

Si los procesos llegan a la cola de procesos preparados en los instantes que se muestran y necesi­ tan los tiem pos de ráfaga indicados, entonces la planificación SJF apropiativa es la que se muestra en el siguiente diagram a de Gantt:

0

1

5

10

17

26

El proceso Px se inicia en el instante 0, dado que es el único proceso que hay en la cola. El proce­ so P2 llega en el instante 1. El tiem po que-le queda al proceso P2 (7 milisegundos) es m ayor que el tiem po requerido por el proceso P2 (4 m ilisegundos), por lo que el proceso Pl se desaloja y se pla­ nifica el proceso P2. El tiem po m edio de espera en este ejem plo es de ((10 - 1) + ( 1 - 1) + (17 2) + (5 — 3) )/4 = 26/4 = 6,5 m ilisegundos. La planificación SJF cooperativa proporcionaría un tiem po m edio de espera de 7,75 milisegundos.

5.3.3 Planificación por prioridades El algoritm o SJF es un caso especial del algoritm o de p lan ificació n por p rioridades general. A cada proceso se le asocia una prioridad y la CPU se asigna al proceso que tenga la prioridad más alta. Los procesos con la m isma prioridad se planifican en orden FCFS. Un algoritmo SJF es sim ple­ m ente un algoritm o por prioridades donde la prioridad (p) es el inverso de la siguiente ráfaga de CPU (predicha). Cuanto más larga sea la ráfaga de CPU, m enor será la prioridad y viceversa. Observe que al hablar de planificación pensam os en térm inos de alta prioridad y baja priori­ dad. G eneralm ente, las prioridades se indican m ediante un rango de números fijo, com o por ejem ­ plo de 0 a 7, o de 0 a 4095. Sin embargo, no existe un acuerdo general sobre si 0 es la prioridad más alta o la m ás baja. Algunos sistem as usan los núm eros bajos para representar una prioridad baja; otros, em plean núm eros bajos para especificar una prioridad alta; esta diferencia puede lle­ var a confusión. En este texto, vam os a asum ir que los núm eros bajos representan una alta priori­ dad. Por ejem plo, considere el siguiente conjunto de procesos y suponga que llegan en el instante 0 en este orden: Plr P2, . . . , P5, estando la duración de las ráfagas de CPU especificada en m ilisegun­ dos: Proceso P2 P2 P, P4 P5

Tiempo de ráfaga

Prioridad

10 1 2 1 5

3 1 4 5 2

146

Capítulo 5 Planificación de la CPU

Usando la planificación por prioridades, vamos a planificar estos procesos de acuerdo cotí siguiente diagram a de Gantt:

16

18

19

El tiem po m edio de espera es de 8,2 milisegundos. Las prioridades pueden definirse interna o externam ente. Las prioridades definidas inter m ente utilizan algún valor m ensurable para calcular la prioridad de un proceso. Por ejemplo, pa calcular las prioridades se han usado en diversos sistem as m agnitudes tales com o los límites j tiempo, los requisitos de m emoria, el núm ero de archivos abiertos y la relación entre la ráfaga < E/S prom edio y la ráfaga de CPU promedio. Las prioridades definidas externam ente se establecéS en función de criterios externos al sistem a operativo, com o por ejem plo la im portancia del procép so, el coste m onetario de uso de la com putadora, el departam ento que patrocina el trabajo y otrojl factores, a m enudo de carácter político. 3 La planificación por prioridades puede ser apropiativa o cooperativa. Cuando un proceso Ilegal a la cola de procesos preparados, su prioridad se com para con la prioridad del proceso actualm enl te en ejecución. Un algoritm o de planificación por prioridades apropiativo, expulsará de la CPU a i proceso actual si la prioridad del proceso que acaba de llegar es mayor. U n algoritm o de plarúfig cación por prioridades cooperativo sim plem ente pondrá el nuevo proceso al principio de la cola de procesos preparados. j Un problem a im portante de los algoritm os de planificación por„ prioridades es el bloqueog in d efin id o o la m uerte por in anición . Un proceso que está preparado para ejecutarse pero está esperando a acceder a la CPU puede considerarse bloqueado; un algoritm o de planificación pop prioridades puede dejar a algunos procesos de baja prioridad esperando indefinidam ente. En uir sistem a inform ático con una carga de trabajo grande, un flujo estable de procesos de alta priori­ dad puede im pedir que un proceso de baja prioridad llegue a la CPU. G eneralm ente, ocurrirá una de dos cosas: o bien el proceso se ejecutará finalm ente (a las 2 de la m adrugada del domingo, cuando el sistem a finalm ente tenga una m enor carga de trabajo) o bien el sistem a inform ático ter­ minará fallando y se perderán todos los procesos con baja prioridad no term inados. Se rumorea que, en 1973, en el MIT, cuando apagaron el IBM 7094, encontraron un proceso de baja prioridad que había sido enviado en 1967 y todavía no había sido ejecutado. Una solución al problem a del bloqueo indefinido de los procesos de baja prioridad consiste en aplicar m ecanism os de en vejecim ien to. Esta técnica consiste en aum entar gradualm ente la prio­ ridad de los procesos que estén esperando en el sistema durante mucho tiem po. Por ejemplo, si el rango de prioridades va desde 127 (baja) a 0 (alta), podríam os restar 1 a la prioridad de un proce­ so en espera cada 15 m inutos. Finalm ente, incluso un proceso con una prioridad inicial de 127 lle­ garía a tener la prioridad más alta del sistema y podría ejecutarse. De hecho, un proceso con prioridad 127 no tardaría más de 32 horas en convertirse en un proceso con prioridad 0.

5.3.4 Planificación por turnos El algoritm o de planificación por tum os (RR, round robin) está diseñado especialm ente para los sistem as de tiem po com partido. Es sim ilar a la planificación FCFS, pero se añade la técnica de des­ alojo para conm utar entre procesos. En este tipo de sistem a se define una pequeña unidad de tiempo, denom inada cuanto de tiem po, o franja temporal. Generalm ente, el cuanto de tiempo se encuentra en el rango com prendido entre 10 y 100 m ilisegundos. La cola de procesos preparados se trata com o una cola circular. El planificador de la CPU recorre la cola de procesos preparados, asignando la CPU a cada proceso durante un intervalo de tiem po de hasta 1 cuanto de tiempo. Para im plem entar la planificación por tumos, m antenem os la cola de procesos preparados como una cola FIFO de procesos. Los procesos nuevos se añaden al final de la cola de procesos pre­ parados. El planificador de la CPU toma el primer proceso de la cola de procesos preparados, con­ figura un tem porizador para que interrumpa pasado 1 cuanto de tiempo y despacha el proceso.

5.3 Algoritmos de planificación

147

Puede ocurrir una de dos cosas. El proceso puede tener una ráfaga de CPU cuya duración sea m enor que 1 cuanto de tiem po; en este caso, el propio proceso liberará voluntariam ente la CPU. El planificador continuará entonces con el siguiente proceso de la cola de procesos preparados. En caso contrario, si la ráfaga de CPU del proceso actualm ente en ejecución tiene una duración mayor que 1 cuanto de tiem po, se producirá un fin de cuenta del tem porizador y éste enviará una inte­ rrupción al sistem a operativo;.entonces se ejecutará un cam bio de contexto y el proceso se coloca­ rá al final de la cola de procesos preparados. El planificador de la CPU seleccionará a continuación el siguiente proceso de la cola de procesos preparados. El tiempo m edio de espera en los sistem as por tum os es, con frecuencia, largo. Considere el siguiente conjunto de procesos que llegan en el instante 0, estando especificada la duración de las ráfagas de CPU en m ilisegundos: Proceso

Tiempo de ráfaga

Px P2

24 3

P3

3

Si usam os un cuanto de tiempo de 4 m ilisegundos, entonces el proceso Pl obtiene los 4 prime­ ros m ilisegundos. Dado que necesita otros 20 m ilisegundos, es desalojado después del primer cuanto de tiempo, y la CPU se concede al siguiente proceso de la cola, el proceso P2. Puesto que el proceso P2 no necesita 4 m ilisegundos, termina antes de que caduque su cuanto de tiempo. Entonces la CPU se proporciona al siguiente proceso, el proceso P3. Una vez que cada proceso ha recibido 1 cuanto de tiem po, la CPU es devuelta al proceso P1 para un cuanto de tiem po adicional. La planificación por tum os resultante es:

Pl 0

p3

p2 4

7

Pi

Pl 10

14

Pl

Pl 18

22

Pl 26

30

El tiem po m edio de espera es de 17/3 = 5,66 milisegundos. En el algoritm o de planificación por turnos, a ningún proceso se le asigna la CPU por más de 1 cuanto de tiempo en cada tum o (a m enos que sea el único proceso ejecutable). Si una ráfaga de CPU de un proceso excede 1 cuanto de tiempo, dicho proceso se desaloja y se coloca de nuevo en la cola de procesos preparados. El algoritm o de planificación por turnos incluye, por tanto, un m ecanism o de desalojo. Si hay n procesos en la cola de procesos preparados y el cuanto de tiempo es q, cada proceso obtiene 1 / n del tiempo de CPU en partes de como m áxim o q unidades de tiempo. Cada proce­ so no tiene que esperar m ás de (n - 1) X q unidades de tiempo hasta obtener su siguiente cuanto de tiempo. Por ejem plo, con cinco procesos y un cuanto de tiempo de 20 m ilisegundos, cada pro­ ceso obtendrá 20 m ilisegundos cada 100 milisegundos. El rendim iento del algoritm o de planificación por turnos depende enorm em ente del tamaño del cuanto de tiempo. Por un lado, si el cuanto de tiempo es extrem adam ente largo, la planifica­ ción por turnos es igual que la FCFS. Si el cuanto de tiempo es muy pequeño (por ejem plo, 1 milisegundo), el m étodo por turnos se denom ina com partición del procesador y (en teoría) crea la apariencia de que cada uno de los n procesos tiene su propio procesador ejecutándose a 1 /n de la velocidad del procesador real. Este m étodo se usaba en las m áquinas de Control Data Corporation (CDC) para im plem entar diez procesadores periféricos con sólo un conjunto de hardw are y diez conjuntos de registros. El hardware ejecuta una instrucción para un conjunto de registros y luego pasa al siguiente; este ciclo se repite, dando lugar en la práctica a diez procesadores lentos, en lugar de uno rápido. Realm ente, dado que el procesador era m ucho m ás rápido que la memoria y cada instrucción hacía referencia a memoria, los procesadores no eran m ucho más lentos que lo que hubieran sido diez procesadores reales. En softw are, tam bién necesitam os considerar el efecto del cambio de contexto en el rendim ien­ to de la planificación por turnos. Suponga que sólo tenemos un proceso de 10 unidades de tiem-

Capítulo 5 Planificación de la CPU

tiempo?!

po. Si el cuanto tiene 12 unidades de tiem po, el proceso termina en m enos de 1 cuanto de sin requerir ninguna carga de trabajo adicional de cam bio de contexto. Sin em bargo, si el cuanto"! de tiempo dura 6 unidades, el proceso requerirá 2 cuantos, requiriendo un cam bio de contexto. el cuanto de tiem po es de 1 unidad, entonces se producirán nueve cam bios de contexto, ralentb * f zando correspondientem ente la ejecución del proceso (Figura 5.4). ?| Por tanto, conviene que el cuanto de tiempo sea grande con respecto al tiempo requerido por • un cam bio de contexto. Si el tiem po de cam bio de contexto es, aproxim adam ente, el 10 por ciento * del cuanto de tiem po, entonces un 10 por ciento del tiempo de CPU se invertirá en cam bios de con­ texto. En la práctica, los sistem as m ás m odernos em plean cuantos de tiempo en el rango de 10 a 100 m ilisegundos y el tiempo requerido para un cam bio de contexto es, norm alm ente, m enor que 10 m icrosegundos; por tanto, el tiem po de cam bio de contexto es una fracción pequeña del cuanto de tiempo. El tiempo de ejecución tam bién depende del valor del cuanto de tiempo. Como podem os ver en la Figura 5.5, el tiem po medio de ejecución de un conjunto de procesos no necesariamente m ejora cuando se increm enta el cuanto de tiempo. En general, el tiem po m edio de ejecución puede m ejorarse si la m ayor parte de los procesos term ina su siguiente ráfaga de CPU en un solo cuanto de tiempo. Por ejemplo, dados tres procesos con una duración, cada uno de ellos, de 10 unidades de tiem po y un cuanto igual a 1 unidad de tiempo, el tiempo medio de ejecución será de 29 unidades. Sin em bargo, si el cuanto de tiempo es 10, el tiempo m edio de ejecución cae a 20. Si se añade el tiempo de cam bio de contexto, el tiempo m edio de ejecución aumenta al dism inuir el cuanto de tiempo, dado que serán necesarios más cam bios de contexto. Aunque el cuanto de tiempo debe ser grande com parado con el tiempo de cam bio de contex­ to, no debe ser dem asiado grande. Si el cuanto de tiempo es demasiado largo, la planificación por turnos degenera en el método FCFS. U na regla práctica es que el 80 por ciento de las ráfagas de CPU deben ser m ás cortas que el cuanto de tiempo.

5.3.5 Planificación mediante colas multinivel Otra clase de algoritm os de planificación es la que se ha desarrollado para aquellas situaciones en las que los procesos pueden clasificarse fácilmente en grupos diferentes. Por ejemplo, una clasifi­ cación habitual consiste en diferenciar entre procesos de prim er plano (interactivos) y procesos de segundo plano (por lotes). Estos dos tipos de procesos tienen requisitos diferentes de tiempo de respuesta y, por tanto, pueden tener distintas necesidades de planificación. Además, los procesos de primer plano pueden tener prioridad (definida externamente) sobre los procesos de segundo plano. Un algoritm o de p lan ificació n m ediante colas m ultinivel divide la cola de procesos prepara­ dos en varias colas distintas (Figura 5.6). Los procesos se asignan perm anentem ente a una cola, generalm ente en función de alguna propiedad del proceso, como por ejemplo el tamaño de memoria, la prioridad del proceso o el tipo de proceso. Cada cola tiene su propio algoritm o de pla­ nificación. Por ejem plo, pueden em plearse colas distintas para los procesos de prim er plano y de tiempo de proceso = 10 —— -----------------------------------------------------

0 1

2

.3

4

5

6

7

8

9

cuanto

cambios de

12

0

10

Figura 5.4 Uklwwra en que un cuanto de tiempo muy pequeño incrementa los cambios de contexto.

5.3 Algoritmos de planificación

proceso P2 P3 P4

149

tiempo 6 3 1 7

cuanto de tiempo

Figura 5.5

La form a en que varía el tiempo de ejecución con el cuanto de tiempo.

prioridad más alta

prioridad más baja

Figura 5.6

Planificación de colas multinivel.

segundo plano. La cola de primer plano puede planificarse m ediante un algoritmo por tumos, mientras que para la cola de segundo plano puede emplearse un algoritm o FCFS. A dem ás, debe definirse una planificación entre las colas, la cual suele im plem entarse como una planificación apropiativa y prioridad fija. Por ejemplo, la cola de procesos de primer plano puede tener prioridad absoluta sobre la cola de procesos de segundo plano. Veam os un ejem plo de algoritm o de planificación mediante colas m ultinivel con las cinco colas que se enum eran a continuación, según su orden de prioridad: 1. Procesos del sistema. 2. Procesos interactivos.

150

Capitulo 5 Planificación de la CPU

3. Procesos de edición interactivos. 4. Procesos por lotes. 5. Procesos de estudiantes. Cada cola tiene prioridad absoluta sobre las colas de prioridad más baja. Por ejemplo, ningún proceso de la cola por lotes podrá ejecutarse hasta que se hayan vaciado com pletam ente las colas de los procesos del sistem a, los procesos interactivos y los procesos de edición interactivos. Si un proceso de edición interactivo llega a la cola de procesos preparados m ientras se está ejecutando un proceso por lotes, el proceso por lotes será desalojado. Otra posibilidad consiste en repartir el tiem po entre las colas. En este caso, cada cola obtiene una cierta porción del tiem po de CPU, con la que puede entonces planificar sus distintos procesos. Por ejem plo, en el caso de la colas de procesos de prim er plano y segundo plano, la cola de pri­ mer plano puede disponer del 80 por ciento del tiempo de CPU para planificar por tum os sus pro­ cesos, m ientras que la cola de procesos de segundo plano recibe el 20 por ciento del tiempo de CPU para gestionar sus procesos mediante el m étodo FCFS.

5.3.6 Planificación mediante colas multinivel realimentadas N orm alm ente, cuando se usa el algoritm o de planificación m ediante colas m ultinivel, los proce­ sos se asignan de form a perm anente a una cola cuando entran en el sistem a. Por ejemplo, si hay colas diferentes para los procesos de prim er y segundo plano, los procesos no se m ueven de una cola a otra, dado que no pueden cam biar su naturaleza de proceso de prim er o segundo plano. Esta configuración presenta la ventaja de una baja carga de trabajo de planificación, pero resulta poco flexible. Por el contrario, el algoritm o de p lan ificació n m ediante colas m u ltin iv el realim entadas per­ m ite m over un proceso de una cola a otra. La idea es separar los procesos en función de las carac­ terísticas de sus ráfagas de CPU. Si un proceso utiliza dem asiado tiem po de CPU, se pasa a una cola de prioridad más baja. Este esquema deja los procesos lim itados por E/S y los procesos interacti­ vos en las colas de prioridad más alta. Adem ás, un proceso que esté esperando dem asiado tiem­ po en una cola de baja prioridad puede pasarse a una cola de prioridad m ás alta. Este mecanismo de envejecim iento evita el bloqueo indefinido. Por ejem plo, considere un planificador de colas m ultinivel realim entadas con tres colas, nume­ radas de 0 a 2 (Figura 5.7). En primer lugar, el planificador ejecuta todos los procesos de la cola 0. Sólo cuando la cola 0 esté vacía ejecutará procesos de la cola 1. De form a sim ilar, los procesos de la cola 2 solo se ejecutarán si las colas 0 y 1 están vacías. U n proceso que llegue a la cola 1 desalo­ jará a un proceso de la cola 2 y ese proceso de la cola 1 será, a su vez, desalojado por un proceso que llegue a la cola 0. Un proceso que entre en la cola de procesos preparados se coloca en la cola 0 y a cada uno de los procesos de esa cola se le proporciona un cuanto de tiempo de 8 m ilisegundos. Si el proceso no termina en ese tiem po, se pasa al final de la cola 1. Si la cola 0 está vacía, al proceso que se encuentra al principio de la cola 1 se le asigna un cuanto de 16 m ilisegundos. Si no se com pleta en ese tiem po, se lo desaloja y se lo incluye en la cola 2. Los procesos de la cola 2 se ejecutan basán­ dose en una planificación FCFS, pero sólo cuando las colas 0 y 1 están vacías. Este algoritm o de planificación proporciona la prioridad más alta a todo proceso que tenga una ráfaga de CPU de 8 m ilisegundos o m enos. Tales procesos acceden rápidam ente a la CPU, conclu­ yen su ráfaga de CPU y pasan a su siguiente ráfaga de E/S. Los procesos que necesitan m ás de 8 m ilisegundos y m enos de 24 m ilisegundos tam bién son servidor rápidam ente, aunque con una prioridad m ás baja que los procesos m ás cortos. Los procesos largos term inan yendo autom ática­ m ente a la cola 2 y se sirven, siguiendo el orden FCFS, con los ciclos de CPU no utilizados por las colas 0 y 1. En general, un planificador m ediante colas m ultinivel realim entadas se define m ediante los parám etros siguientes: • El núm ero de colas.

5.4 Planificación de sistemas multiprocesador

Figura 5.7

151

Colas multinivel realim entadas.

• El algoritm o de planificación de cada cola. • El m étodo usado para determ inar cuándo pasar un proceso a una cola de prioridad más alta. • El m étodo usado para determ inar cuándo pasar un proceso a una cola de prioridad más baja. • El m étodo usado para determ inar en qué cola se introducirá un proceso cuando haya que darle servicio. La definición del planificador m ediante colas m ultinivel realim entadas le convierte en el algo­ ritmo de planificación de la CPU más general. Puede configurarse este algoritm o para adaptarlo a cualquier sistem a específico que se quiera diseñar. Lam entablem ente, tam bién es el algoritm o más com plejo, puesto que definir el m ejor planificador requiere disponer de algún m ecanismo para seleccionar los valores de todos los parámetros.

Planificación de sistemas multiprocesador Hasta el momento, nuestra exposición se ha centrado en los problemas de planificación de la CPU en un sistema con un solo procesador. Si hay disponibles m últiples CPU, se puede com partir la carga; sin em bargo, el problem a de la planificación se hace más com plejo. Se han probado muchas posibilidades; y como ya hem os visto para el caso de la planificación de la CPU con un único pro­ cesador, no existe una solución única. Aquí vam os a presentar diversas cuestiones acerca de la planificación m ultiprocesador. Vam os a concentrarnos en los sistem as en los que los procesado­ res son idénticos, h o m o g é n e o s en cuanto a su funcionalidad; en este tipo de sistemas, podemos usar cualquiera de los procesadores disponibles para ejecutar cualquier proceso de la cola. (Sin embargo, observe que incluso con múltiples procesadores hom ogéneos, en ocasiones hay lim ita­ ciones que afectan a la planificación; considere un sistem a con un dispositivo de E/S conectado a un bus privado de un procesador. Los procesos que deseen em plear ese dispositivo deberán pla­ nificarse para ser ejecutados en dicho procesador.)

5.4.1 Métodos de planificación en los sistemas multiprocesador Un m étodo para planificar las CPU en un sistema m ultiprocesador consiste en que todas las deci­ siones sobre la planificación, el procesam iento de E /S y otras actividades del sistema sean gestio­ nadas por un mismo procesador, el servidor m aestro. Los demás procesadores sólo ejecutan código de usuario. Este m u ltip ro c e s a m ie n to a s im é tric o resulta simple, porque sólo hav un pro­ cesador que accede a las estructuras de datos de! sistem a, reduciendo la necesidad de com partir datos. Un segundo m étodo utiliza el m u ltip ro c e s a m ie n to s im é tric o (SMP), en el que cada uno de ios procesadores se auto-planifica. Todos los procesos pueden estar en una cola común de procesos

152

Capítulo 5 Planificación de la CPU

preparados, o cada procesador puede tener su propia cola privada de procesos preparado, In d epend ientem en te de esto, la planificación se lleva a cabo haciendo que el planificador de cad p rocesador exam ine la cola de procesos preparados y seleccione un proceso para ejecutarlo. Con verem os en el Capítulo 6, si tenemos varios procesadores intentando acceder a una estructura» datos co m ú n para actualizarla, el planificador tiene que program arse cuidadosam ente: tener que asegu rar que dos procesadores no elegirán el m ismo proceso y que no se perderán proce de la co la. Prácticam ente todos los sistem as operativos m odernos soportan el multiprocesamie to sim étrico, incluyendo W indows XP, W indows 2000, Solaris, Linux y Mac OS X. En el resto de esta sección, analizarem os diversas cuestiones relacion ad as con los sistem as SN

5.4.2 Afinidad al procesador C o n sid ere lo que o cu rre con la m em oria caché cu an d o un proceso se ha estado ejecutando en i p ro ce sa d o r específico: los datos a los que el proceso ha accedido m ás recientem ente se alm acer en la ca ch é del p ro ce sa d o r y, com o resultado, los sucesivos accesos a m em oria por parte del prql ceso su elen satisfacerse sin m ás que consultar la m em oria caché. A h o ra considere lo que ocurres el p ro ceso m igra a otro p rocesad or: los contenidos de la m em oria cach é del p rocesador de orige deben in valid arse y la cach é del p rocesad or de destino debe ser rellenada. Debido al alto coste deS in valid ar y rellenar las m em orias caché, la m ayoría de los sistem as SMP intentan evitar la m igralS ción d e p rocesos de un p ro cesad o r a otro, y en su lugar intentan m an ten er en ejecución cada pro-jj ceso en el m ism o p rocesad or. Esto se conoce con el nom bre de afin id ad al p rocesad or, lo qué¡| significa que un p roceso tiene una afinidad hacia el p rocesad or en que está ejecutándose a c tu a ljl m ente. .¡a La afinidad al procesador toma varias formas. Cuando un sistem a operativo tiene la política d é £ intentar m antener un proceso en ejecución en el m ism o procesador, pero no está garantizado quell lo haga, nos encontram os ante una situación conocida com o afin id ad su ave. En este caso, es posi-11

ble que un proceso m igre entre procesadores. Algunos sistem as, com o Linux, tam bién proporcio-1 nan llam adas al sistem a que soportan la afin id ad dura, la cual perm ite a un proceso especificar!! que no debe m igrar a otros procesadores. I

5.4.3 Equilibrado de carga

1

E n los sistem as SM P, es im portante m antener la carga de trabajo equilibrada entre todos los pro­ c e s a d o r e s , para aprovechar por com pleto las ventajas de disponer de m ás de un procesador. Si no

se hiciera así, podría darse el caso de que uno o más procesadores perm anecieran inactivos mien­ tras o t i o s procesadores tuvieran cargas de trabajo altas y una lista de procesos esperando a acce­ der a la CPU. Los m ecanism os de eq u ilib rad o de carga intentan distribuir equitativam ente la carga de trabajo entre todos los procesadores del sistem a SMP. Es im portante observar que el equi­ librado de carga, norm alm ente, sólo es necesario en aquellos sistem as en los que cada procesador tiene su propia cola privada de procesos preparados para ejecutarse. En los sistem as con una cola d e ejecución com ún, el equilibrado de carga es a m enudo innecesario, ya que una vez que un pro­ cesador pasa a estar inactivo, inm ediatam ente extrae un proceso ejecutable de la cola de ejecución común. No obstante, tam bién es im portante destacar que en la m ayoría de los sistem as operativos a c tu a le s que soportan SM P. cada procesador tiene una cola privada de procesos preparados. Existen dos m éto d o s gen erales p ara equilibrar la carga: m ig ració n co m an d ad a (push m igration) y m igració n so licita d a (pulí m igration). C on la m igración co m an d ad a, una tarea específica com prueba p erió d icam en te la carg a en cad a p rocesad or y, si en cu en tra un desequilibrio, distribuve equitativam ente la c a rg a m oviendo (o cargan d o) procesos de los p rocesad ores sobrecargados en los m enos o cu p ad o s o inactivos. L a m igración solicitada se p ro d u ce cuando un procesador inactivo extrae de un p ro ce sa d o r o cu p ad o alguna tarea que esté en espera. Las m igraciones c o m a n d a d a s y solicitadas no tienen por qué ser m u tu am en te exclu yen tes y, de hecho, a menudo se im p le m e n ta n en p aralelo en los sistem as de equilibrado de carga. P o r ejemplo, el planificador de Linux (descrito en la Sección 5.6.3) y el planificador ULE disponible en los sistem as FreeBSD ¡m p lo m e n ta n am bas técn icas. Linux ejecuta sus algoritm os de equilibrado de carga cad a 200 mili-

5.5 Planificación de hebras

153

segundos (m igración com andada) o cuando la cola de ejecución de un procesador está vacía (m igración solicitada). Es interesante com entar que el equilibrado de carga a m enudo contrarresta los beneficios de la afinidad al procesador, vista en la Sección 5.4.2. Es decir, la ventaja de m antener un proceso eje­ cutánd ose en el m ism o procesador es que el proceso se aprovecha de que sus datos se encuentran en la m em oria caché de dicho procesador. Al m igrar procesos de un procesador a otro, anulam os esta ventaja. C om o se habitual en la ingeniería de sistem as, no existe una regla absoluta para determ inar cuál es la m ejor política; por tanto, en algunos sistem as, un procesador inactivo siem ­ pre extrae un proceso de un procesador que no esté inactivo m ientras que, en otros sistem as, los procesos m igran sólo si el desequilibrio excede determ inado umbral.

5.4.4 M ecanism os multihebra simétricos Los sistem as SMP perm iten que varias hebras se ejecuten de form a concurrente, ya que proporcio­ nan varios procesadores físicos. U na estrategia alternativa consiste en proporcionar varios proce­ sadores lógicos, en lugar de físicos. Esta estrategia se conoce con el nom bre de m ecanism o m ultihebra sim étrico (SMT, sym m etric m ultithreading), aunque tam bién se denom ina te c n o lo g ía h ip e r h e b r a (hyperthreading) en los procesadores Intel. L a idea que subyace al m ecanism o SMT es la de crear varios procesadores lógicos sobre un m ism o procesador físico, presentando una vista de varios procesadores lógicos al sistem a opera­ tivo, incluso en los sistem as con un solo procesador físico. Cada procesador lógico tiene su propio e s ta d o d e la a rq u ite c tu ra , que incluye los registros de propósito general y los registros de estado de la m áquina. Adem ás, cada procesador lógico es responsable de su propio tratam iento de inte­ rrupciones, lo que significa que las interrupciones son proporcionadas, y gestionadas, por los pro­ cesadores lógicos en lugar de por los físicos. Por lo demás, cada procesador lógico com parte los recursos de su procesador físico, com o la memoria caché y los buses. La Figura 5.8 ilustra una arquitectura SMT típica con dos procesadores físicos, albergando cada uno dos procesadores lógi­ cos. Desde la perspectiva del sistem a operativo, en este sistem a hay disponibles cuatro procesa­ dores para realizar el trabajo. Es importante recalcar que SMT es una funcionalidad proporcionada por hardw are y no por software. Es decir, el hardware tiene que proporcionar la representación del estado de la arquitec­ tura de cada procesador lógico, así com o el tratamiento de interrupciones. Los sistem as operati­ vos no tienen necesariam ente que diseñarse de forma diferente para ejecutarse en un sistem a SMT; sin embargo, se pueden obtener ciertas ventajas si el sistem a operativo es consciente de que se está ' ejecutando en un sistema de este tipo. Por ejemplo, considere un sistema con dos procesadores físicos, ambos en estado de inactividad. En primer lugar, el planificador debe intentar planificar hebras distintas en cada procesador físico en lugar de en procesadores lógicos distintos del mismo procesador tísico; en caso contrario, am bos procesadores lógicos de un procesador físico podrían estar ocupados mientras que el otro procesador físico perm anecería inactivo.

Planificación de hebras En el Capitulo 4, hemos presentado el papel de las hebras en el modelo de procesos, diferencian­ do entre hebras de nivel de usuario y de nivel de kernel. En los sistem as operativos que perm iten su

CPU

CPU

CPU

lógica

lógica

lógica

CPU

CPU

lógica

CPU física

física bus del sistema

Figura 5.8 Una arquitectura

SMT típica.

154

Capítulo 5 Planificación de la CPU

uso, el sistem a operativo planifica hebras del nivel del kernel, no procesos. Las hebras del nivel d jl usuario son gestionadas por una biblioteca de hebras, y el kernel no es consciente de ellas. Paraeje|¡ cutarse en una CPU, las hebras de usuario deben ser asignadas a una hebra de nivel de kem el aso-f ciada, aunque esta asignación puede ser indirecta y puede em plear un proceso ligero (LWP). {r¿|| esta sección, vamos a explorar las cuestiones de planificación relativas a las hebras de nivel dej usuario y de nivel del k em el y ofrecerem os ejemplos concretos de planificación en Pthreads. %

5.5.1 Ámbito de contienda

-.H

1

Una de las diferencias entre las hebras de nivel de usuario y de nivel del kernel radica en la forma" en que se planifican unas y otras. En los sistem as que im plem entan los modelos muchos-a-uno? (Sección 4.2.1) y m uchos-a-m uchos (Sección 4.2.3), la biblioteca de hebras planifica las hebras de) nivel de usuario para que se ejecuten sobre un proceso LW P disponible, lo cual es un esquema' conocido con el nom bre de ám bito de co n tien d a del p ro ceso (PCS, process-contention scope), dado que la com petición por la CPU tiene lugar entre hebras que pertenecen al mismo proceso. • Cuando decimos que la biblioteca de hebras planifica las hebras de usuario sobre los procesos lige­ ros disponibles, no querem os decir que la hebra se ejecute realm ente en una CPU; esto requeriría que el sistem a operativo planificara la hebra del kem el en una CPU física. Para decidir qué hebra del kem el planificar en una CPU, el kem el usa el ám bito de con tien d a del sistem a (SCS); la compe­ tición por la CPU con la planificación SCS tiene lugar entre todas las hebras del sistema. Los siste­ mas que usan el modelo uno-a-uno (tal com o W indows XP, Solaris 9 y Linux) planifican las hebras sólo con SCS. N orm alm ente, la planificación PCS se lleva a cabo de acuerdo con la prioridad: el planificador selecciona para su ejecución la hebra ejecutable con la prioridad más alta. Las prioridades de las hebras de nivel de usuario son establecidas por el program ador y no se ajustan mediante la biblio­ teca de hebras, aunque algunas bibliotecas de hebras perm iten que el programador cambie la prio­ ridad de una hebra. Es im portante destacar que PCS norm alm ente desalojará la hebra actualmente en ejecución en favor de una hebra de prioridad más alta; sin embargo, no se garantiza un repar­ to equitativo de cuantos de tiempo (Sección 5.3.4) entre las hebras de igual prioridad.

5.5.2 Planificación en Pthread En la Sección 4.3.1 se ha proporcionando un programa de ejem plo de Libread en POSIX, junto con una introducción a la creación de hebras con Pthread. Ahora, vamos a analizar la API de Pthread de POSIX que permite especificar el ám bito de contienda del proceso (PCA o el ámbito de contien­ da del sistema (SCS) durante la creación de hebras. Pthreads utiliza ios siguientes valores para definir el ámbito de contienda: •

PTHREAD_SCOPE_PROCESS planifica las hebras usando la planificación PCS.

•

PTHREAD_SCOPE_SYSTEM planifica las hebras usando la planificación SCS.

En los sistemas que im plem entan el m odelo muchos-a-muchos (Sección 4.2.3), la política PTHREAD_SCOPE_PROCESS planifica las hebras de nivel usuario s o b re ios procesos ligeros dispo­

nibles. El número de procesos LWP se m antiene m ediante la biblioteca d e hebras, quizá utilizan­ do activaciones del planificador (Sección 4.4.6). La política de p la n ifica ció n PTHREAD_SCOPE_ SYSTEM creará y asociará un proceso L W P a cada hebra de nivel de u s u a rio en los sistemas muchosa-muchos, lo que equivale en la práctica a asignar las hebras usando el m o d e lo uno-a-uno (Sección 4.2.2). La API de Pthread proporciona las dos funciones siguientes para c o n su lta r, y definir, la políti­ ca de ám bito de contienda:

• pthread_attr_setscope(pthread_attr_t *attr, int scope • pthread_attr_getscope(pthread_attr_t *attr, int *ocepe El prim er parám etro para a m b a s funciones contiene un puntero al c c iv a n ío de a tr ib u to s de la hebra. En el segundo parám etro de p t h r e a d _ a t t r s e t s c o p e ' se naso, e ! v a lo r PTHREAD_ S

5.5 Planificación de hebras

155

SCOPE_SYSTEM o PTHREAD_SCOPE_PROCESS, lo que indica cómo se define el ámbito de contienda. En el caso de p t h r e a d _ _ a t t r _ g e t s c o p e ( ) , este segundo parám etro contiene un puntero a un valor entero ( i n t ) al que se asignará el valor actual del ámbito de la contienda. Si se produce un error, cada una de estas funciones devuelve valores distintos de cero. En la Figura 5.9 se presenta un program a Pthread que primero determina el ám bito de contien­ da existente y luego lo define com o PTHREAD_SCPPE_PROCESS. A continuación crea cinco hebras independientes que se ejecutarán usando la política de planificación SCS. Observe que algunos sis­ tem as sólo perm iten determ inados valores para el ámbito de contienda. Por ejem plo, los sistem as Linux y Mac OS X sólo perm iten PTHREAD_SCOPE_SYSTEM.

#include #include #define NUMJTHREADS 5 int main(int argc, char *argv[]) {

int i, scope pthread_t tid[NUMJTHREADS]; pthread_attr_t attr; /* obtener los atributos predeterminados */ pthread_attr_init(&attr); /* primero consultar el ámbito actual */ if (pthread_attr_getscope(&attr, &scope) !=0) fprintf(stderr, "Imposible obtener ámbito de planificación\n"); else { if (scioe == PTHREAD_SCOPE_PROCESS) printf("PTHREAD_SCOPE_PROCESS"); else if (scope == PTHREAD_SCOPE_SYSTEM) printf("PTHREAD_SCOPE_SYSTEM"); else fprintf(stderr, "Valor de ámbito ilegal.\n"); }

/* definir el algoritmo de planificación como PCS o SCS */ pthread.attr.setscope(&attr, PTHREAD_SCOPE_SYSTEM); /* crear las hebras */ for (i = 0; i < NUMJTHREADS; i++) pthread_create(&tid[i], &attr,runner,NULL); /* ahora esperar a que termine cada hebra */ for (i = 0; i < NUM_THREADS; i++) pthread_join(tid[i] , NULL); }

/* Cada hebra iniciará su ejecución en esta función */ void *runner(void *param) {

/* realizar alguna tarea ... */ pthread.exit(0 i; }

Figura 5.9 api de planificación de Pthread.

Capítulo 5 Planificación de la CPU

Ejemplos de sistemas operativos A continuación vamos a describir las políticas de planificación de los sistemas operativos Sol: Windows XP y Linux. Es im portante recordar que lo que vam os a describir en el caso de Solaris Linux es la planificación de las hebras del kem el. Recuerde que Linux no diferencia entre procea y hebras; por tanto, utilizam os el término tarea al hablar del planificador de Linux.

5.6.1 Ejemplo: planificación en Solaris

m Solaris usa una planificación de hebras basada en prioridades, definiendo cuatro clases para p la li nificación. Estas clases son, por orden de prioridad: S 1.

Tiempo real

1|

2.

Sistema

2

3.

Tiempo compartido

-d

4.

Interactiva

|

Dentro de cada clase hay diferentes prioridades y diferentes algoritmos de planificación. Los mecanismos de planificación en Solaris se ilustran en la Figura 5.10. % La clase de planificación predeterm inada para un proceso es la de tiempo compartido. La poli- _ tica de planificación para tiempo com partido m odifica dinám icam ente las prioridades y asigna cuantos de tiempo de diferente duración usando colas m ultinivel realimentadas. De m anera predeterminada, existe una relación inversa entre las prioridades y los cuantos de tiempo. Cuanto más alta sea la prioridad, más pequeño será el cuanto de tiem po; y cuanto m enor sea la prioridad,

prioridad global

orden de planificación

prioridades específicas de la clase

más alta

primero

tiempo real

clases de planificador

k.

sistema

interactivo & tiempo compartido

más baja

últim o

Figura 5.10 Planificación en Solaris.

cola de ejecución

5.6 Ejemplos de sistemas operativos

157

más larga será la franja. Los procesos interactivos suelen tener la prioridad más alta; los procesos limitados por la CPU tienen la prioridad más baja. Esta política de planificación proporciona un buen tiempo de respuesta para los procesos interactivos y una buena tasa de procesam iento para los procesos limitados por la CPU. La clase interactiva usa la misma política de planificación que la clase de tiem po com partido, pero proporciona a las aplicaciones con interfaz de ventanas una prioridad más alta, para aum entar el rendim iento. La Figura 5.11 m uestra la tabla de despacho para la planificación de hebras interactivas y de tiempo com partido. Estas dos clases de planificación incluyen 60 niveles de prioridad pero, para abreviar, solo se m uestran unos cuantos. La tabla de despacho m ostrada en la Figura 5.11 contie­ ne los siguientes campos: .

Prioridad. La prioridad, dependiente de la clase, para las clases de tiempo com partido e interactiva. Un núm ero alto indica una m ayor prioridad.

• C uanto de tiem po. El cuanto de tiempo para la prioridad asociada. Ilustra la relación inversa entre prioridades y cuantos de tiempo: la prioridad más baja (prioridad 0) tiene el cuanto de tiempo m ás largo (200 m ilisegundos), m ientras que la prioridad más alta (priori­ dad 59) tiene el cuanto de tiem po más bajo (20 milisegundos). • C aducidad del cuanto de tiem po. La nueva prioridad que se asignará a una hebra que haya consumido su cuanto de tiem po com pleto sin bloquearse. Tales hebras se considera que hacen un uso intensivo de la CPU. Como se m uestra en la tabla, la prioridad de estas hebras se reduce. • R eto m o del estado dorm ido. La prioridad que se asigna a una hebra cuando sale del esta­ do dorm ido (como, por ejem plo, cuando la hebra estaba esperando para realizar una ope­ ración de E/S). Como ilustra la tabla, cuando el dispositivo de E/S está disponible para una hebra en espera, la prioridad de ésta se aumenta a entre 50 y 59, con el fin de soportar la política de planificación consistente en proporcionar un buen tiempo de respuesta para los procesos interactivos. Solaris 9 introduce dos nuevas clases de planificación: de prioridad fija y de cuota equitativa. Las hebras de prioridad fija tienen el m ismo rango de prioridades que las de tiempo com partido;

prioridad

cuanto de tiempo

cuanto de tiempo caducado

0

200

0

50

5

200

0

50

10

160

0

51

15

160

5

51

20

120

10

52

25

120

15

52

30

80

20

53

35

80

25

54

40

40

30

55

45

40

35

56

50

40

40

58

55

40

45

58

59

20

49

59

retorno del estado durmiente

i | ¡ ¡

Figura 5.11 Tabla de despacho de Solaris para hebras interactivas y de tiempo compartido.

158

Capítulo 5 Planificación de la CPU

sin em bargo, sus prioridades no se ajustan dinámicamente. La clase de cuota equitativa usa c j< f 9 tas de CPU en lugar de prioridades a la hora de tomar decisiones de planificación. Las cuotas i H CPU indican el derecho a utilizar los recursos de CPU disponibles y se asignan a un co n ju n to '^ H procesos (a cada uno de esos conjuntos se le denomina proyecto). Solaris usa la clase sistem a para ejecutar procesos del kernel, como el planificador y el d em o n fH de paginación. Una vez establecida, la prioridad de un proceso del sistema no cambia. La clase s i s » tema se reserva para uso del kernel (los procesos de usuario que se ejecutan en modo kernel no J H incluyen en la clase sistema). I M A las hebras pertenecientes a la clase de tiempo real se les asigna la prioridad más alta. FctaÉ asignación perm ite que un proceso en tiempo real tenga una respuesta asegurada del sistema deiSB tro de un período limitado de tiempo. U n proceso en tiempo real se ejecutará antes que los p r o c e S sos de cualquier otra clase. Sin em bargo, en general, son pocos los procesos pertenecientes a ]|K clase de tiem po real. -Jp Cada clase de planificación incluye un conjunto de prioridades. Sin em bargo, el planificado® convierte las prioridades específicas de una clase en prioridades globales y selecciona la hebra q u e * tenga la prioridad global más alta para ejecutarla. La hebra seleccionada se ejecuta en la CPU hasta® que (1) se bloquea, (2) consum e su cuanto de tiempo o (3) es desalojada por una hebra de p r io r i* dad m ás alta. Si existen m últiples hebras con la misma prioridad, el planificador usa una cola ylg selecciona las hebras por tum os. Como ya hemos dicho anteriormente, Solaris ha usado tradicio-nalm ente el m odelo m uchos-a-m uchos (Sección 4.2.3), pero con Solaris 9 se cam bió al modelo uno-» a-uno (Sección 4.2.2). -

5.6.2 Ejemplo: planificación en W indows XP W indow s XP planifica las hebras utilizando un algoritm o de planificación apropiativo basado en prioridades. El planificador de W indow s XP asegura que siempre se ejecute la hebra de prioridad m ás alta. La parte del kernel de W indow s XP que gestiona la planificación se denomina despacha­ dor. U na hebra seleccionada para ejecutarse por el despachador se ejecutará hasta que sea desalo­ jada por una hebra de prioridad m ás alta, hasta que termine, hasta que su cuanto de tiempo concluya o hasta que invoque una llam ada bloqueante al sistema, como por ejemplo para una ope­ ración de E/S. Si una hebra en tiem po real de prioridad más alta pasa al estado preparado mien­ tras se está ejecutando una hebra de prioridad más baja, esta última será desalojada. Este desalojo proporciona a la hebra de tiem po real un acceso preferencial a la CPU en el momento en que la hebra necesite dicho acceso. El despachador usa un esquem a de prioridades de 32 niveles para determ inar el orden de eje­ cución de las hebras. Las prioridades se dividen en dos clases: la clase variable contiene hebras cuyas prioridades van de 1 a 15, m ientras que la clase de tiem po real contiene hebras con priori­ dades com prendidas en el rango de 16 a 31. Existe tam bién una hebra que se ejecuta con priori­ dad 0 y que se em plea para la gestión de memoria. El despachador usa una cola distinta para cada prioridad de planificación y recorre el conjunto de colas desde la más alta a la más baja, hasta que encuentra una hebra que esté preparada para ejecutarse. Si no encuentra una hebra preparada, el despachador ejecuta una hebra especial denom inada h ebra inactiva. Existe una relación entre las prioridades num éricas del kernel de W indow s XP y la API Win32. La API W in32 identifica varias clases de prioridades a las que un proceso puede pertenecer. Entre ellas se incluyen:

. REALTIME_PRIORITY_CLASS • HIGH_PRIORITY_CLASS . ABOVE_NORMAL_PRIORITY_CLASS . NORMAL_PRIORITY_CLASS . BELOW_NORMAL_PRIORITY_CLASS • IDLE_PRIORlTY_CLASS

5.6 Ejemplos de sistemas operativos

159

Las priorid ad es de todas las clases, excepto REALTIME_PRIORITY_CLASS, son del tipo variable, lo que significa que la prioridad de una hebra que p erten ezca a una de esas clases puede cam biar.

Dentro de cada clase de prioridad hay una prioridad relativa. Los valores para la prioridad relativa son: .

TIME_CRITICAL

.

HIGHEST

.

ABOVE_NORMAL

• NORMAL .

BELOW_NORMAL

.

LOWEST

•

(DLE

La prioridad de cada hebra se basa en la clase de prioridad a la que pertenece y en su priori­ dad relativa dentro de dicha clase. Esta relación se m uestra en la Figura 5.12. Los valores de las clases de prioridad se m uestran en la fila superior; la colum na de la izquierda contiene los valo­ res de las prioridades relativas. Por ejemplo, si la prioridad relativa de una hebra de la clase ABOVE_NORMAL_PRIORITY_CLASS es NORMAL, la prioridad num érica de dicha hebra será 10. Adem ás, cada hebra tiene una prioridad base que representa un valor dentro del rango de prio­ ridades de la clase a la que pertenece la hebra. De m anera predeterm inada, la prioridad base es el valor de la prioridad relativa NORMAL para la clase especificada. Las prioridades base para cada clase de prioridad son: •

REALTIME_PRIORITY_CLASS-24

.

HIGH_PRIORITY_CLASS—13

.

ABOVE_NORM AL_PRIORITY_CLASS - 1 0

.

NORMAL_PRIORITY_CLASS-8

.

BELOW_NORMAL_PRIORITY_CLASS-6

.

IDLE_PRIORITY_CLASS—4

N orm alm ente, ios procesos son miem bros de la clase NORMAL_PRIORITY_CLASS. Un proceso pertenecerá a esta clase a menos que el padre del proceso pertenezca a la clase !DLE_PRlORITY_ CLASS o que se haya especificado otra clase en el m om ento de crear el proceso. La prioridad ini­ cial de una hebra es norm alm ente la prioridad base del proceso al que pertenece la hebra. Cuando se excede el cuanto de tiempo de una hebra, dicha hebra se interrum pe; si la hebra per­ tenece a la clase de prioridad variable, se reduce su prioridad. N o obstante, la prioridad nunca dis-

time-critical highest above normal normal below normal lowest idle

realtime 31 26 25 24 23 22 16

high 15 15 14 13 12 11 1

above normal 15 12 11 10 9 8 1

normal 15 10 9 8 7 6 1

Figura 5.12 Prioridades en Windows XP.

below normal 15 8 7 6 5 4 1

idle priority 15 6 5 4 3 2 1

Capítulo 5 Planificación de la CPU

m inuye por debajo de la prioridad base. Dism inuir la prioridad de la hebra tiende a limitar el con sum o de CPU por parte de las hebras que realicen cálculos intensivos. Cuando una hebra de prio­ ridad variable sale de un estado de espera, el despachador incrementa su prioridad. Dicho?! increm ento dependerá de lo que la hebra estuviera esperando; por ejemplo, la prioridad de una hebra que estuviera esperando por una operación de E/S de teclado se aumentará de forma signrll ficativa, m ientras que la de una hebra que estuviera esperando por una operación de disco se a increm entará de form a moderada. Esta estrategia suele proporcionar buenos tiempos de respues^S ta a las hebras interactivas que utilicen el ratón y una interfaz de ventanas. Tam bién permite a las " hebras lim itadas por E/S m antener ocupados a los dispositivos de E/S, al mismo tiempo que lass hebras que realizan cálculos intensivos em plean en segundo plano los ciclos de CPU libres. Esta • estrategia se usa en varios sistemas operativos de tiem po com partido, incluyendo UNIX. Además,^ se aum enta la prioridad de la ventana con la que esté interactuando actualm ente el usuario, p aráí m ejorar el tiem po de respuesta. ’ Cuando un usuario está ejecutando un programa interactivo, el sistema necesita proporcionar un rendim iento especialm ente bueno a dicho proceso. Por esta razón, W indows XP tiene una regla ^ de planificación especial para los procesos de la clase NORMAL_PRIORITY_CLASS. W indows XP , diferencia entre el proceso de prim er plano que está actualm ente seleccionado en la pantalla y los pro cesos de segundo plano que no están actualm ente seleccionados. Cuando un proceso pasa a primer , plano, W indow s XP m ultiplica el cuanto de planificación por un cierto factor, normalmente igual a 3. Este increm ento proporciona al proceso en prim er plano tres veces más tiempo para ejecutarse, antes de que se produzca un desalojo debido a la com partición de tiempo.

5.6.3 Ejemplo: planificación en Linux Antes de la versión 2.5, el kem el de Linux ejecutaba una variante del algoritmo tradicional de p a ­ nificación de UNIX. Los dos problemas que tiene el planificador tradicional de UNIX son, por un; lado, que no proporciona el adecuado soporte para sistem as SMP y por otro que no puede escalar­ se bien al aum entar el núm ero de tareas en el sistema. Con la versión 2.5, se optimizó el planifica­ dor y ahora el kernel proporciona un algoritmo de planificación que se ejecuta a velocidad constante [con tasa de proporcionalidad 0 (1 )], independientem ente del núm ero de tareas del sis­ tema. El nuevo planificador tam bién proporciona un m ejor soporte para sistem as SMP, incluyen­ do m ecanism os de afinidad al procesador y equilibrado de carga, así com o un reparto equitativo de recursos y soporte para tareas interactivas. El planificador de Linux es un algoritm o basado en prioridades y apropiativo, con dos rangos distintos de prioridades: un rango de tiem po real de O a 99 y un valor norm al (nfce) en el rango com prendido entre 100 y 140. Estos dos rangos se asignan a un esquema de prioridades global, en el que los valores num éricam ente más bajos indican las prioridades más altas. A diferencia de otros muchos sistem as, incluyendo Solaris (Sección 5.6.1) y W indows XP (Sección 5.6.2), Linux asigna a las tareas de prioridad m ás alta cuantos de tiempo más largos y a las tareas de prioridad más baja cuantos de tiempo más cortos. La relación entre la prioridad y la duración del cuanto de tiempo se m uestra en la Figura 5.13. Una tarea ejecutable se considera elegible para ejecutarse en la CPU cuando todavía le quede tiempo de su cuanto de tiempo. Cuando una tarea ha agotado su cuanto de tiempo, se considera caducada y no puede volver a ejecutarse hasta que las otras tareas hayan agotado sus respectivos cuantos de tiempo. El kernel m antiene una lista de todas las tareas ejecutables en una estructura de datos denom inada cola de ejecu ció n (runqueue ). Debido al soporte para sistemas SMP, cada procesador m antiene su propia cola de ejecución y la planifica de forma independiente, Cada cola de ejecución contiene dos matrices de prioridades, denom inadas matrices activa v caducada. La m atriz activa contiene todas las tareas que todavía disponen de tiempo en su cuanto de tiempo, m ientras que la matriz caducada contiene todas las tareas caducadas. Cada una cié estas matrices de prioridades contiene una lista de tareas indexada en función de la prioridad (Figur•a 5.14) El planificador elige la tarea de la m atriz activa con la prioridad más alta para su ejecución en la CPU. En las máquinas m ultiprocesador, esto significa que cada procesador selecciona la tarea de prio­ ridad más alta de su propia cola de ejecución. Cuando todas las tareas han agotado sus cuantos"

5.7 Evaluación de algoritmos

prioridad numérica

prioridad relativa

0

más alta

161

cuanto de tiempo 200 ms tareas en tiempo real

99

100 otras tareas 140

10 ms

más baja

Figura 5.13 Relación entre la prioridad y la duración del cuanto de tiempo. matriz caducada

matriz activa prioridad

[0] '

listas de tareas

0 —0

[ 1]

[140]

O

prioridad

[ 0] [1]

[140]

listas de tareas

O

0 —0

Figura 5.14 Lista de tareas indexadas en función de la prioridad. de tiem po (es decir, cuando la m atriz activa está vacía), las dos m atrices de prioridades se inter­ cam bian: la m atriz caducada pasa a ser la m atriz activa, y viceversa. Linux im plem enta la planificación en tiempo real tal com o se define en POSIX.lb, lo cual se corresponde con el m ecanism o descrito en ia Sección 5.5.2. A las tareas en tiempo real se les asig­ nan prioridades estáticas; las restantes tareas tienen prioridades dinám icas que se basan en sus valores nice, m ás o menos 5. La interactividad de una tarea determ ina si el valor 5 tiene que sum ar­ se o restarse del valor nice. El grado de interactividad de una tarea se determina por el tiempo que ha estado durm iendo m ientras esperaba para realizar una operación de E/S. Las tareas más inter­ activas suelen perm anecer m ás tiempo en el estado dormido y, por tanto, lo más probable es que usen ajustes próxim os a —5, ya que el planificador favorece las tareas interactivas. Inversamente, las tareas que pasan m enos tiempo en estado durmiente suelen estar limitadas por la CPU y, por tanto, se les asignará una prioridad menor. El recálculo de la prioridad dinám ica de una tarea se produce cuando la tarea ha agotado su cuanto de tiem po y se pasa a la m atriz de caducadas. Por tanto, cuando se intercambian las dos matrices, a todas las tareas que hay en la nueva matriz activa se les habrán asignado nuevas prio­ ridades y los correspondientes cuantos de tiempo.

Evaluación de algoritmos ¿Cómo seleccionar un algoritm o de planificación de la CPU para un sistem a en particular? Como hemos visto en la Sección 5.3, existen m uchos algoritmos de planificación distintos, cada uno con sus propios parám etros; por tanto, seleccionar un algoritmo puede resultar complicado. El primer problem a consiste en definir los criterios que se van a em plear para seleccionar un algoritmo. Com o hemos visto en la Sección 5.2, los criterios se definen a menudo en términos de utilización de la CPU, del tiempo de respuesta o de la tasa de procesam iento; para seleccionar un algoritmo, prim ero tenemos que definir la importancia relativa de estas medidas. Nuestros crite­ rios pueden incluir varias m edidas distintas, como por ejemplo:

162

Capítulo 5 Planificación de la CPU

• •

M axim izar la utilización de la CPU bajo la restricción de que eltiem po m áxim o de r e s p is -a ta sea igual a 1 segundo. jl M axim izar la tasa de procesam iento de modo que el tiem po de ejecución sea (como prom ág dio) linealm ente proporcional al tiempo total de ejecución. ^

Una vez definidos los criterios de selección, podem os evaluar los algoritm os que estem os con-1 siderando. A continuación se describen los distintos m étodos de evaluación que podem os utilizar i

!i

5.7.1 Modelado determinista

:!

Un m étodo im portante de evaluación es la evaluación analítica. Este tipo de evaluación utiliza ell algoritm o especificado y la carga de trabajo del sistema para generar una fórm ula o núm ero qu¿| evalúe el rendim iento del algoritmo para dicha carga de trabajo. | Uno de los tipos de evaluación analítica es el m odelado determ inista. Este m étodo tom a una a carga de trabajo predeterm inada concreta y define el rendim iento de cada algoritm o para dicha carga de trabajo. Por ejem plo, suponga que tenemos la carga de trabajo m ostrada a continuación, i Los cinco procesos llegan en el instante 0 en el orden indicado, con la duración de las ráfagas de ' CPU especificada en milisegundos: Proceso

Tiempo de ráfaga

10

Pi P, P,

29 3 7

12

Considere los algoritm os de planificación FCFS, SJF y por turnos (cuanto = 10 m ilisegundos) para este conjunto de procesos. ¿Qué algoritm o proporcionará el tiempo medio de espera m ínimo? Para el algoritm o FCFS, ejecutaríamos los procesos del siguiente modo:

Pl

P

P3

9

?• i

Pí

i

El tiempo de espera es de 0 milisegundos para P,, 10 m ilisegundos para P2, 39 m ilisegundos para P3, 42 milisegundos para P4 y.49 milisegundos para el proceso P^. Por tanto, el tiempo m edio de espera es de (0 + 10 + 39 -s 42 + 49)/5 = 28 milisegundos. Con la planificación SJF cooperativa, ejecutamos ios procesos del modo siguiente:

P4

P3 0 3

■

P5 1C

20

32

61

El tiempo de espera es de 10 m ilisegundos para el proceso P: , 32 m ilisegundos para el proceso P2, 0 m ilisegundos para el proceso P3, 3 m ilisegundos para el proceso P4 y 20 m ilisegundos para el proceso P5. Por tanto, el tiempo m edio de espera es de (10 + 32 - 0 + 3 + 20)/5 = 13 milisegundos Con el algoritm o de planificación por turnos, ejecutam os los procesos com o sigue:

P-

D j, -

*-H

P'J

i i-

A

1

■ ~!

5.7 Evaluación de algoritmos

163

El tiem po de espera es de 0 m ilisegundos para el proceso Py 32 m ilisegundos para el proceso P2, 20 m ilisegundos para el proceso P3, 23 m ilisegundos para el proceso P4 y 40 m ilisegundos para el proceso P5. Por tanto, el tiempo m edio de espera es de (0 + 32 + 20 + 23 + 40)/5 = 23 m ilise­ gundos Vem os que, en este caso, el tiempo m edio de espera obtenido con el algoritm o SJF es m enos que la mitad del obtenido con el algoritm o de'planificación FCFS; el algoritm o de planificación por tur­ nos nos proporciona un valor interm edio. El m odelado determ inista es sim ple y rápido. N os proporciona núm eros exactos, perm itiendo así com parar los algoritm os. Sin em bargo, requiere que se proporcionen núm eros exactos como entrada y sus respuestas sólo se aplican a dichos casos. El modelado determ inista se utiliza prin­ cipalm ente para la descripción de los algoritm os de planificación y para proporcionar los corres­ pondientes ejem plos. En los casos en que estemos ejecutando el m ism o program a una y otra vez y podam os m edir los requisitos de procesam iento de form a exacta, podem os usar el m odelado determ inista para seleccionar un algoritm o de planificación. Además, utilizando un conjunto de ejem plos, el m odelado determ inista puede indicar una serie de tendencias, que pueden ser anali­ zadas y dem ostradas por separado. Por ejem plo, podem os dem ostrar que, para el entorno descri­ to (en el que todos los procesos y sus tiempos están disponibles en el instante 0), la política SF] siempre dará com o resultado el tiempo de espera m ínim o.

5.7.2 Modelos de colas En m uchos sistem as, los procesos que se ejecutan varían de un día a otro, por lo que no existe nin­ gún conjunto estático de procesos (o tiem pos) que se pueda emplear en el m odelado determ inis­ ta. Sin em bargo, lo que sí es posible determ inar es la distribución de las ráfagas de CPU y de E/S. Estas distribuciones pueden m edirse y luego aproxim arse, o sim plem ente estimarse. El resultado es una fórm ula m atem ática que describe la probabilidad de aparición de una ráfaga de CPU con­ creta. Habitual mente, esta distribución es exponencial y se describe m ediante su media. De forma similar, podem os describir la distribución de los tiem pos de llegada de los procesos al sistem a. A partir de estas dos distribuciones, resulta posible calcular la tasa m edia de procesam iento, la uti­ lización m edia, el tiem po medio de espera, etc. para la m ayoría de los algoritmos. El sistem a inform ático se describe, dentro de este m odelo, como una red de servidores. Cada servidor dispone de una cola de procesos en espera. La CPU es un servidor con su cola de proce­ sos preparados, al igual que el sistem a de E/S con sus colas de dispositivos. Conociendo las tasas de llegada y el tiempo de servicio, podem os calcular la utilización, la longitud media de las colas, el tiempo m edio de espera, etc. Este área de investigación se denomina an álisis de redes de colas. Por ejem plo, sea n la longitud m edia de la cola (excluyendo el proceso al que se está prestan­ do servicio en ese m om ento), sea W el tiem po m edió de espera en la cola y sea X la tasa m edia de llegada de nuevos procesos a la cola (por ejemplo, tres procesos por segundo). Podem os estim ar que, durante el tiempo W en que está esperando un proceso, llegarán a la cola X x W nuevos pro­ cesos. Si el sistem a está operando en régim en perm anente, entonces el núm ero de procesos que abandonan la cola debe ser igual al núm ero de procesos que llegan. Por tanto: n = Xx W Esta ecuación, conocida com o fórm ula de Little, resulta especialm ente útil, ya que es válida para cualquier algoritm o de planificación y para cualquier distribución de las llegadas. Podem os em plear la fórm ula de Little para calcular una de las tres variables si conocem os dos de ellas. Por ejemplo, si sabemos que llegan 7 procesos por segundo (valor medio) y que norm al­ mente hay 14 procesos en la cola, entonces podem os calcular el tiempo medio de espera por pro­ ceso, obteniendo que es de 2 segundos. El análisis de colas puede resultar útil para com parar los distintos algoritm os de planificación, aunque también tiene sus limitaciones. Por el m om ento, las clases de algoritm os y de distribucio­ nes que pueden incluirse en el análisis son bastante limitadas. Los análisis m atemáticos necesarios para las distribuciones y algoritm os com plejos pueden resultar enorm em ente difíciles. Por ello, las distribuciones de llegada y de servicio se suelen definir de forma m atem áticam ente tratable, pero

Capítulo 5 Planificación de la CPU

poco realista. G eneralm ente, tam bién es necesario hacer una serie de suposiciones independí^, tes, que pueden no ser excesivam ente precisas. Debido a estas dificultades, a m enudo los mode­ los de colas sólo representan una aproxim ación a los sistemas reales, y la precisión de |qj resultados obtenidos puede ser cuestionable.

5.7.3 Simulaciones Para obtener una evaluación m ás precisa de los algoritm os de planificación, podemos usar simu­ laciones. Ejecutar las sim ulaciones requiere program ar un modelo del sistema informático. Lo; com ponentes principales del sistem a se representan m ediante estructuras de datos software. El sim ulador tiene una variable que representa una señal de reloj y, cuando el valor de esta variable se incrementa, el sim ulador m odifica el estado del sistem a para reflejar las actividades de los dis­ positivos, de los procesos y del planificador. A m edida que se ejecuta la simulación, las estadísti­ cas que indican el rendim iento del algoritm o se recopilan y se presentan en la salida. Los datos para controlar la sim ulación pueden generarse de varias formas. El m étodo más com ún utiliza un generador de núm eros aleatorios, que se programa para generar procesos, tiem­ pos de ráfaga de CPU, llegadas, salidas, etc., de acuerdo con una serie de distribuciones de proba­ bilidad. Las distribuciones pueden definirse m atem áticam ente (uniforme, exponencial, de Poisson) o em píricam ente. Si hay que definir em píricam ente una distribución, se toman medida^ del sistem a real que se esté estudiando. Los resultados de las medidas definen la distribución de probabilidad de los sucesos en el sistem a real; esta distribución puede entonces utilizarse para controlar la sim ulación. Sin embargo, una sim ulación controlada m ediante una distribución de probabilidad puede ser im precisa, debido a las relaciones entre sucesos sucesivos dentro del sistema real. La distribución de frecuencias sólo indica cuántas veces se produce cada suceso; no indica nada acerca del order en que los sucesos tienen lugar. Para corregir este problem a, podemos usar lo que se denominar cintas de traza. Para crear una cinta de traza se m onitoriza el sistema real y se registra una secuen cia de sucesos reales (Figura 5.15). Luego, esta secuencia se emplea para controlar la simulación Las cintas de traza proporcionan una form a excelente de comparar dos algoritmos cuando st em plea exactam ente el m ism o conjunto de entradas reales. Este método perm ite obtener resulta­ dos precisos para los datos de entrada considerados. Las sim ulaciones pueden resultar caras, ya que requieren muchas horas de tiempo de compu tadora. Una sim ulación más detallada proporciona resultados más precisos, pero también requie

estadísticas = ¡ > de rendimiento para FCFS

• • •

ejecución del proceso real

CPU 10 l/O 213 CPU 12 l/O 112 CPU 2 l/O 147 CPU 173 •••

estadísticas de rendimiento para SJF

cinta de traza estadísticas de rendimiento para RR ( q = 14)

Figura 5.15 Evaluación de planificadores de CPU mediante simulación.

5.8 Resumen

165

re más tiempo de cálculo. Adem ás, las cintas de traza pueden requerir una gran cantidad de espa­ cio de alm acenam iento. Por último, el diseño, codificación y depuración del sim ulador pueden ser tareas de gran com plejidad.

5.7.4’ Implementación Incluso las sim ulaciones tienen una precisión limitada. La única forma com pletam ente precisa de evaluar un algoritm o de planificación es codificándolo, incluyéndolo en el sistema operativo y viendo cóm o funciona. Este m étodo introduce el algoritm o real en el sistema para su evaluación bajo condiciones de operación reales. La principal dificultad de este m étodo es su alto coste. No sólo se incurre en los costes de codi­ ficar el algoritm o y m odificar el sistem a para que lo soporte (junto con sus estructuras de datos requeridas) sino que tam bién hay que tener en cuenta la reacción de los usuarios a los cam bios constantes en el sistem a operativo. La m ayoría de los usuarios no están interesados en crear un sistema operativo m ejor; sim plem ente desean ejecutar sus procesos y utilizar los resultados obte­ nidos. Los cam bios continuos en el sistem a operativo no ayudan a los usuarios a realizar su tra­ bajo. Otra dificultad es que el entorno en el que se use el algoritm o está sujeto a cambios. El entor­ no cam biará no sólo de la form a usual, a m edida que se escriban nuevos programas y los tipos de problem as cam bien, sino tam bién com o consecuencia del propio rendimiento del planificador. Si se da prioridad a los procesos cortos, entonces los usuarios pueden dividir los procesos largos en conjuntos de procesos m ás cortos. Si se asigna una m ayor prioridad a los procesos interactivos que a los no interactivos, entonces los usuarios pueden decidir utilizar procesos interactivos. Por ejem plo, un grupo de investigadores diseñó un sistem a que clasificaba los procesos inter­ activos y no interactivos de form a autom ática, según la cantidad de operaciones de E/S realizadas a través del term inal. Si un proceso no leía ninguna entrada ni escribía ninguna salida en el termir nal en un intervalo de 1 segundo, el proceso se clasificaba com o no interactivo y se pasaba a la cola de prioridad m ás baja. En respuesta a esta política, un program ador modificó sus programas para escribir un carácter arbitrario en el term inal a intervalos regulares de menos de 1 segundo. El sis­ tema concedía a esos program as una prioridad alta, incluso aunque la salida presentada a través del term inal no tenía ningún sentido. Los algoritm os de planificación más flexibles son aquéllos que pueden ser modificados por los adm inistradores del sistem a o por los usuarios, de m odo que puedan ser ajustados para una apli­ cación específica o para un determ inado conjunto de aplicaciones. Por ejemplo, una estación de trabajo que ejecute aplicaciones gráficas de gama alta puede tener necesidades de planificación diferentes que un servidor web o un servidor de archivos. Algunos sistemas operativos, en parti­ cular distintas versiones de UNIX, perm iten que el adm inistrador del sistema ajuste los parám e­ tros de planificación para cada configuración concreta del sistema. Por ejem plo, Solaris proporciona el com ando d is p a d m in para que el adm inistrador del sistema m odifique los pará­ metros de las clases de planificación descritas en la Sección 5.6.1. Otro m étodo consiste en em plear interfaces de program ación de aplicaciones que perm itan m odificar la prioridad de un proceso o de una hebra; las API de Java, POSIX y W indows propor­ cionan dichas funciones. La desventaja de este m étodo es que, a menudo, ajustar el rendim iento de un sistem a o aplicación concretos no permite m ejorar el rendimiento en otras situaciones más generales.

5 .8

Resumen La planificación de la CPU es la tarea de seleccionar un proceso en espera de la cola de procesos preparados y asignarle la CPU. El despachador asigna la CPU al proceso seleccionado. L a p lan ificació n FCFS (first-co m e, first-se rv e d ; p rim e ro en llegar, p rim e ro en ser se rv id o ) es el a lg o ritm o d e p lan ificació n m ás sen cillo, p e ro p u e d e d a r lu g a r a q u e los p ro ce so s d e c o rta d u ra ­ ció n ten g an q u e e s p e ra r a q u e se ejecu ten o tro s p ro ce so s d e d u ra ció n m u ch o m á s g ra n d e . “••. a > 0? b. ¿Cuál es el algoritm o que resulta de a < (3 < 0?

5.10

Explique las diferencias con respecto al grado en que los siguientes algoritm os de planifica­ ción favorecen a los procesos más cortos: a. FCFS b. planificación por tumos c. planificación m ediante colas multinivel realimentadas

5.11

Usando el algoritm o de planificación de W indows XP, ¿cuál es la prioridad num érica de una hebra en los casos siguientes? a. Una hebra de la clase REALTIME_PRIORITY_CLASS con una prioridad relativa HIGHEST. b. Una hebra de la clase NORMAL_PRIORITY_CLASS con una prioridad relativa NORMAL. c. Una hebra de la clase HIGH_PRIORITY_CLASS con una prioridad relativa ABOVEJMOR-

MAL. 5.12

Considere el algoritm o de planificación del sistem a operativo Solaris para las hebras de tiempo com partido. a. ¿Cuál es el cuanto de tiem po (en milisegundos) para una hebra con prioridad 10? b. Suponga que una hebra con una prioridad de 35 ha utilizado su cuanto de tiempo com pleto sin bloquearse. ¿Qué nueva prioridad asignará el planificador a esta hebra? c. Suponga que una hebra con una prioridad de 35 se bloquea en espera de una opera­ ción de E/S antes de consum ir su cuanto de tiempo. ¿Qué nueva prioridad asignará el planificador a esta hebra?

5.13

El planificador tradicional de UNIX fuerza una relación inversa entre los núm eros de priori­ dad y las prioridades: cuanto m ayor es el número, menor es la prioridad. El planificador recalcula las prioridades de los procesos una vez por segundo usando la siguiente función: Prioridad = (uso reciente de la CPU / 2) + prioridad base d o n d e p rio rid a d b a se = 60 y u so rec ien te d e la CPU h a ce re fe re n cia a u n v a lo r q u e in d ica con q u é frecu en cia h a e m p le a d o u n p ro ce so la CPU d e sd e q u e se ca lc u la ro n las p rio rid a d e s p or ú ltim a v ez.

Suponga que el uso reciente de la CPU para el proceso Px es de 40, para el proceso P-, de 18 y para el proceso P3 de 10. ¿Cuáles serán las nuevas prioridades para estos tres procesos

Notas bibliográficas

169

cuando éstas se vuelvan a calcular? Teniendo esto en cuenta, ¿increm entará o dism inuirá el planificador tradicional de UNIX la prioridad relativa de un proceso lim itado por la CPU?

Notas bibliográficas Las colas realim entadas se im plem entaron originalm ente en el sistema CTSS descrito en Corbato et al. [1962], Este sistem a de planificación mediante colas realim entadas se analiza en Schrage [1967]. El algoritm o de planificación m ediante prioridades y apropiativo del Ejercicio 5.9 fue suge­ rido por K leinrock [1975]. Anderson et al. [1989], Lew is y Berg [1998] y Philbin et al. [1996] se ocupan de la planificación de hebras. La planificación para sistem as m ultiprocesador se aborda en Tucker y Gupta [1989], Zahorjan y M cCann [1990], Feitelson y Rudolph [1990], Leutenegger y Vernon [1990], Blumofe y Leiserson [1994], Polychronopoulos y Kuck [1987] y Lucco [1992], Las técnicas de planificación que tienen en cuenta la inform ación relativa a los tiem pos de ejecución anteriores de los procesos fueron descritas en Fisher [1981], Hall et al. [1996] y Lowney et al. [1993]. Las técnicas de planificación para sistem as en tiempo real se estudian en Liu y Layland [1973], Abbot [1984], Jensen et al. [1985], Hong et al. [1989] y Khanna et al. [1992], Zhao [1989] compiló una edición especial de O perating System Revieiv dedicada los sistemas operativos en tiempo real. Los planificadores de cuota equitativa se cubren en Henry [1984], W oodside [1986] y Kay y Lauder [1988], Las políticas de planificación utilizadas en el sistem a operativo UNIX V se describen en Bach [1987]; las correspondientes políticas para UNIX BSD 4.4 se presentan en M ckusick et al. [1996]; y para el sistem a operativo M ach se describen en Black [1990], Bovet y Cesati [2002] analizan el tema de la planificación en Linux. La planificación en Solaris se describe en M auro y M cDougall [2001], Solom on [1998] y Solom on y Russinovich [2000] abordan la planificación en W indows NT y W indows 2000, respectivam ente. Butenhof [1997] y Lew is y Berg [1998] describen ¡a planificación en los sistem as Pthreads.

c

/w

i

U

j l o

Sincronización deprocesos Un proceso cooperativo es aquel que puede afectar o verse afectado por otros procesos que estén ejecutándose en el sistema. Los procesos cooperativos pueden com partir directamente un espacio de direcciones lógico (es decir, tanto código com o datos) o com partir los datos sólo a través de archivos o m ensajes. El prim er caso se consigue m ediante el uso de procesos ligeros o hebras, los cuales se han estudiado en el Capítulo 4. El acceso concurrente a datos com partidos puede dar lugar a incoherencia de los datos y en este capítulo vam os a ver varios m ecanism os para asegurar la ejecución ordenada de procesos cooperativos que com partan un espacio de direcciones lógico, de m odo que se m antenga la coherencia de los datos.

OBJETIVOS DEL CAPÍTULO • Presentar el problema de las secciones críticas, cuyas soluciones pueden utilizarse para asegu­ rar la coherencia de los datos compartidos. • Presentar soluciones tanto software como hardware para el problema de las secciones críticas. • Presentar el concepto de transacción atómica y describir los mecanismos para garantizar la ato­ micidad.

6.1

Fundamentos En el Capítulo 3 hemos desarrollado un m odelo de sistema formado por procesos o hebras secuenciales cooperativas, los cuales se ejecutan de m anera asincrona y posiblem ente com partien­ do datos. Ilustramos este m odelo con el problem a del productor-consumidor, que es representa­ tivo de los sistem as operativos. Específicam ente, en la Sección 3.4.1 hemos descrito cómo podría utilizarse un búfer limitado para perm itir a los procesos compartir la memoria. Considerem os de nuevo el búfer limitado. Com o ya apuntamos, nuestra solución permite que haya como m áxim o BUFFER_SIZE -1 elem entos en el búfer al mismo tiempo. Suponga que desea­ mos m odificar el algoritm o para rem ediar esta deficiencia. Una posibilidad consiste en añadir una variable entera counter, inicializada con el valor 0. counter se increm enta cada vez que se añade un nuevo elem ento al búfer y se decrem enta cada vez que se elimina un elem ento del búfer. El código para el proceso productor se puede m odificar del siguiente modo:

whiie (true) {

/* produce un elemento en nextProduced V vr.ile (counter == BUr rr.?._SiZE) ; /* no hacer nada bufferíin] = nextProdm = ( m -r 1) % BUFF ^

171

172

Capítulo 6 Sincronización de procesos

counter-n- ; } El código para el proceso consum idor se puede m odificar del modo siguiente

while (true) {

while (counter == 0) ; /* no hacer nada */ nextConsumed = bufferfout]; out = {Out + 1) % BUFFER_SIZE; counter--; /* consume el elemento que hay en nextConsumed */ } A unque las rutinas del productor y del consum idor son correctas por separado, no pueden funcionar correctam ente cuando se ejecutan de form a concurrente. Por ejemplo, suponga que el valor de la variable counter es actualm ente 5 y que los procesos productor y consumidor ejecu-' tan las instrucciones “counter ++” y “counter--” de form a concurrente. Después de la ejecu­ ción de estas dos instrucciones, el valor de la variable counter puede ser 4, 5 o 6. El único resultado correcto es, no obstante, counter == 5, valor que se genera correctam ente si los pro­ cesos consum idor y productor se ejecutan por separado. Podem os dem ostrar que el valor de counter puede ser incorrecto del modo siguiente. Observe que la instrucción “counter++” se puede im plem entar en lenguaje m áquina, en un procesador típi­ co, com o sigue: registroa - counter regis trox - registro1 + 1 counter = registrot donde registroa es un registro local de la CPU. De form a sim ilar, la instrucción “counter--” se im plem enta como sigue: registro2 = counter registro2 ~ registro2 + 1 counter = registro2 donde, de nuevo, registro2 es un registro local de la CPU. Incluso aunque registro1 y registro2 pue­ dan ser el m ism o registro físico (por ejem plo, un acum ulador), recuerde que los contenidos de este registro serán guardados y restaurados por la rutina de tratam iento de interrupciones (Sección 1.2.3). La ejecución concurrente de “counter++” y “counter--” es equivalente a una ejecución secuencial donde las instrucciones de m enor nivel indicadas anteriorm ente se intercalan en un cierto orden arbitrario (pero el orden dentro de cada instrucción de alto nivel se conserva). Una intercalación de este tipo sería: T0

productor

Ti

productor

t2

consumidor.

t3

consumidor

t4

productor productor

t5

exscute execute execute execute execute execute

registro1 = counter

[registrol = 5]

registroa = registroa + 1

[registro! = 6]

registro2 = counter

[regis tro2 = 5]

regis tro2 = regis tro2 + 1

[registro2 — 6]

counter = registro1 counter = registro2

[counter = 6] [counter = 4]

O bserve que hemos llegado al estado incorrecto “counter = = 4 ”, lo que indica que cuatro posi­ ciones del búfeif están llenas, cuando, de hecho, son cinco las posiciones llenas. Si invirtiéram os el orden de las instrucciones T. y T-, llegaríam os al estado incorrecto “counter = = 6".

6.2 El problema de la sección crítica

173

Llegaríam os a este estado incorrecto porque hemos perm itido que ambos procesos m anipulen la variable c o u n t e r de form a concurrente. Una situación com o ésta, donde varios procesos m ani­ pulan y acceden a los m ism os datos concurrentem ente y el resultado de la ejecución depende del orden concreto en que se produzcan los accesos, se conoce com o condición de carrera. Para pro­ tegerse frente a este tipo de condiciones, necesitamos garantizar que sólo un proceso cada vez pueda m anipular la variable c o u n t e r . Para conseguir tal garantía, tenemos que sincronizar de alguna m anera los procesos. Las situaciones com o la que acabam os de describir se producen frecuentem ente en los sistemas operativos, cuando las diferentes partes del sistema m anipulan los recursos. Claram ente, necesi­ tamos que los cam bios resultantes no interfieran entre sí. Debido a la im portancia de este proble­ ma, gran parte de este capítulo se dedica a la sincronización y coordinación de procesos.

El problem a de la sección crítica Considere un sistem a que consta de n procesos {Pq, Pv ..., Cada proceso tiene un segm ento de código, llam ado sección crítica, en el que el proceso puede m odificar variables com unes, actua­ lizar una tabla, escribir en un archivo, etc. La característica im portante del sistem a es que, cuando un proceso está ejecutando su sección crítica, ningún otro proceso puede ejecutar su correspon­ diente sección crítica. Es decir, dos procesos no pueden ejecutar su sección crítica al m ism o tiem ­ po. El problem a de la sección crítica consiste en diseñar un protocolo que los procesos puedan usar para cooperar de esta forma. Cada proceso debe solicitar perm iso para entrar en su sección críti­ ca; la sección de código que im plem enta esta solicitud es la sección de entrada. La sección crítica puede ir seguida de una sección de salida. El código restante se encuentra en la sección restante. La estructura general de un proceso típico JP^es la que se m uestra en la Figura 6.1. La sección de entrada y la sección de salida se han indicado en recuadros para resaltar estos im portantes seg­ mentos de código. Cualquier solución al problema de la sección crítica deberá satisfacer los tres requisitos siguientes: 1. Exclusión m utua. Si el proceso P, está ejecutándose en su sección crítica, los demás procesos no pueden estar ejecutando sus secciones críticas. 2. Progreso. Si ningún proceso está ejecutando su sección crítica y algunos procesos desean entrar en sus correspondientes secciones críticas, sólo aquellos procesos que no estén ejecu­ tando sus secciones restantes pueden participar en la decisión de cuál será el siguiente que entre en su sección crítica, y esta selección no se puede posponer indefinidam ente. 3. Espera lim itada. Existe un límite en el número de veces que se perm ite que otros procesos entren en sús secciones críticas después de que un proceso haya hecho una solicitud para entrar en su sección crítica y antes de que la misma haya sido concedida. Estamos suponiendo que cada proceso se ejecuta a una velocidad distinta de cero. Sin embargo, no podem os hacer ninguna suposición sobre la velocidad relativa de los n procesos. En un instante de tiem po determ inado, pueden estar activos m uchos procesos en modo kernel en el sistem a operativo. Com o resultado, el código que im plem enta el sistema operativo (el códido { sección de entrada sección crítica sección de salida se cció n re sta n te

Figura 6.1 Estructura general de un proceso típico Pr

Capítulo 6 Sincronización de procesos

174

go del kernel) está sujeto a varias posibles condiciones de carrera. Considere por ejemplo estructura de datos del kernel que m antenga una lista de todos los archivos abiertos en el sisterrtaíj Esta lista debe m odificarse cuando se abre un nuevo archivo o se cierra un archivo abierto (af¡2j¡i diendo el archivo a la lista o elim inándolo de la m ism a). Si dos procesos abrieran archivos simulJl táneamente, las actualizaciones de la lista podrían llevar a una condición de carrera. Otraj| estructuras de datos del kernel propensas a posibles condiciones de carrera son aquéllas em plead das para controlar la asignación de m emoria, las listas de procesos y para gestionar las interrupa¡¡ ciones. Es responsabilidad de los desabolladores del kernel asegurar que el sistem a operativo estéi libre de tales condiciones de carrera. z Se usan dos m étodos generales para gestionar las secciones críticas en los sistemas operativos^ (1) los kern els apropiativos y (2) los k e m e ls no apropiativos. Un kernel apropiativo perm ite que unlj proceso sea desalojado m ientras se está ejecutando en modo kernel. Un kernel no apropiativo no** permite que un proceso que se esté ejecutando en m odo kernel sea desalojado; el proceso en modo:kernel se ejecutará hasta que salga de dicho modo, hasta que se bloquee o hasta que ceda volunta- 1 riam ente el control de la CPU. Obviam ente, un kernel no apropiativo está esencialm ente libre deP condiciones de carrera en lo que respecta a las estructuras de datos del kernel, ya que sólo hay uiyt¡ proceso activo en el kernel en cada momento. No podem os decir lo mismo acerca de los kernel¿3 apropiativos, por lo que deben ser diseñados cuidadosam ente para asegurar que los datos com-t , partidos del kernel no se vean afectados por posibles condiciones de carrera. Los kernel apropiad-"** vos son especialm ente difíciles de diseñar en arquitecturas SMP, dado que en estos entornos es posible que dos procesos se ejecuten sim ultáneam ente en modo kernel en procesadores diferentes. ¿Por qué entonces sería preferible un kernel apropiativo a uno no apropiativo? Un kernel a propiativo es m ás adecuado para la program ación en tiempo real, ya que permite a un proceso en tiempo real desalojar a un proceso que se esté ejecutando actualm ente en el kernel. Además, un kernel apropiativo puede tener una m ejor capacidad de respuesta, ya que existe menos riesgo de que un proceso en m odo kernel se ejecute durante un período de tiempo arbitrariam ente largo antes de ceder el procesador a los procesos que estén a la espera. Por supuesto, este efecto puede m inim izarse diseñando código de kernel que no presente este tipo de comportamiento. W indow s XP y W indow s 2000 son kem els no apropiativos, al igual que el kernel tradicional de UNIX. Antes de Linux 2.6, el kernel de Linux tam bién era no apropiativo. Sin embargo, con la ver­ sión del kernel 2.6, Linux cam bió al modelo apropiativo. Varias versiones com erciales de UNIX usan un kernel apropiativo, incluyendo Solaris e IRIX.

6.3

Solución de Peterson A continuación presentam os una solución clásica basada en softw are al problema de la sección crítica, conocida con el nom bre de solución de Peterson. Debido a la forma en que las arquitectu­ ras inform áticas m odernas ejecutan las instrucciones básicas en lenguaje m áquina, como lo a d y s t o r e , no hay garantías de que la solución de Peterson funcione correctam ente en tales arquitec­ turas. Sin em bargo, presentam os esta solución porque proporciona una buena descripción algo­ rítm ica de la resolución del problem a de la sección crítica e ilustra algunas de las complejidades asociadas al diseño de softw are que satisfaga los requisitos de exclusión mutua, progreso y tiem­ po de espera limitado. La solución de Peterson se restringe a dos procesos que van alternando la ejecución de sus sec­ ciones críticas y de sus secciones restantes. Los procesos se numeran como P0 y Pv Por convenien­ cia, cuando hablem os de P,, usaremos P, para referim os al otro proceso; es decir, j es igual a

1 — i. La solución de Peterson requiere que los dos procesos compartan dos elementos de datos:

boolear. íLag[2V La variable turn indica qué proceso va a entrar en su sección crítica. Es decir, si cura == i , entonces el proceso P ( puede ejecutar su sección crítica. La matriz fl a a se usa para indicar si un proceso está preparado para entrar en su sección crítica. Por ejemplo, si f 1 a ? [ i j es verdadera, este

6.4 Hardware de sincronización

175

valor indica que P¿ está preparado para entrar en su sección crítica. H abiendo explicado estas estructuras de datos, ya estam os preparados para describir el algoritm o m ostrado en la Figura 6.2. Para entrar en la sección crítica, el proceso P¡ primero asigna el valor verdadero a flag fi ] y luego asigna a turn el valor j, confirm ando así que, si el otro proceso desea entrar en la sección crítica, puede hacerlo. Si am bos procesos intentan entrar al m ism o tiempo, a la variable turn se le asignarán los valores tanto i com o j aproxim adam ente al m ismo tiempo. Sólo una de estas asignaciones perm anecerá; la otra tendrá lugar, pero será sobreescrita inm ediatam ente. El valor que adopte turn decidirá cuál de los dos procesos podrá entrar primero en su sección crítica. Ahora vam os a dem ostrar que esta solución es correcta. Necesitam os dem ostrar que: 1. La exclusión m utua se conserva. 2. El requisito de progreso se satisface. 3. El requisito de espera lim itada se cum ple. Para probar la prim era propiedad, observam os que P, entra en su sección crítica sólo si

flag [ j ] == falseo turn == i. O bserve tam bién que, si am bos procesos pudieran estar eje­ cutando sus secciones críticas al m ism o tiem po, entonces flag [ 0 ] == flag [1 ] == true. Estas dos observaciones im plican que P0 y P1 no podrían haber term inado de ejecutar sus instrucciones v;hile aproxim adam ente al m ism o tiempo, dado que el valor de turn puede ser 0 o 1, pero no ambos. Por tanto, uno de los procesos, por ejem plo Py, debe haber term inado de ejecutar la ins­ trucción whi le, m ientras que P¡ tendrá que ejecutar al m enos una instrucción adicional “turn = = j’\ Sin em bargo, dado que, en dicho instante, flag [j ] == true y turn == j, y está condi­ ción se cum plirá m ientras que j se encuentre en su sección crítica, el resultado es que la exclusión m utua se conserva. Para probar la segunda y tercera propiedades, observam os que sólo se puede im pedir que un proceso P, entre en la sección crítica si el proceso se atasca en el bucle whi le con la condición ¿lag [j ]== true y turn= = j; este bucle es el único posible. Si P¡ no está preparado para entrar en la sección crítica, entonces flag [j ] == fal se, y P¡ puede entrar en su sección crítica. Si Pha definido flag [ j ] com o true y tam bién está ejecutando su instrucción whi le, entonces turn = = i o turn == j.Siturn== i, entonces P¡ entrará en la sección crítica. Si turn == j , enton­ ces Py entrará en la sección crítica. Sin em bargo, una vez que Py salga de su sección crítica, asigna­ rá de nuevo a flac ' i ] el valor false, perm itiendo que P¡ entre en su sección crítica. Si Py asigna de nuevo a flag [ j ' el valor true, tam bién debe asignar el valor i a curn. Por tanto, dado que P, no cam bia el valor de la variable turn m ientras está ejecutando la instrucción whi le, P ¿ entra­ rá en la sección crítica (progreso) después de como m áxim o una entrada de P¡ (espera limitada).

6.4

Hardware de sincronización Acabamos de describir una solución softw are al problema de la sección crítica. En general, pode­ mos afirm ar que cualquier solución al problem a de la sección crítica requiere una herramienta do

{

flag[i] = -3Ü E ; turn = j ; whil e (flagijj && turn == j) sección crítica

flag[i] = r h lS u ; sección restante

Figura 6.2 La estructura del proceso P, en la solución de Peterson.

176

Capítulo 6 Sincronización de procesos

do

{ adquirir cerrojo sección crítica liberar cerrojo sección restante

} while

(TRUE);

Figura 6.3 Solución al problema de la sección crítica usando cerrojos. muy sim ple, un cerrojo. Las condiciones de carrera se evitan requiriendo que las regiones críticas! se protejan mediante cerrojos. Es decir, un proceso debe adquirir un cerrojo antes de entrar en unas sección crítica y liberarlo cuando salga de la misma. Esto se ilustra en la Figura 6.3. || A continuación, vam os a explorar varias soluciones m ás al problem a de la sección crítica, usaivl do técnicas que van desde el soporte hardw are a las A PI softw are que los program adores de aplilf caciones tienen a su disposición. Todas estas soluciones se basan en la prem isa del bloqueo; sinj em bargo, com o verem os, el diseño de tales bloqueos (cerrojos) puede ser bastante complejo. El soporte hardware puede facilitar cualquier tarea de program ación y m ejorar la eficiencia dek sistema. En esta sección, vam os a presentar algunas instrucciones hardware sencillas que están* disponibles en m uchos sistem as y m ostrarem os cómo se pueden usar de form a efectiva en la reso-~ lución del problema de la sección crítica. ~ ... El problem a de la sección crítica podría resolverse de form a simple en un entorno de un soI cm procesador si pudiéram os impedir que se produjeran interrupciones mientras se está modifican-^ do una variable com partida. De este m odo, podríamos asegurar que la secuencia actual de ins­ trucciones se ejecute por orden, sin posibilidad de desalojo. N inguna otra instrucción se ejecutará, por lo que no se producirán m odificaciones inesperadas de la variable com partida. Este es el m étodo que em plean los kernels no apropiativos. Lam entablem ente, esta solución no resulta tan adecuada en un entorno multiprocesador. D esactivar las interrupciones en un sistem a m ultiprocesador puede consumir m ucho tiempo, ya que hay que pasar el m ensaje a todos los procesadores. Este paso de mensajes retarda la entrada en cada sección crítica y la eficiencia del sistem a dism inuye. Tam bién hay que tener en cuenta el efecto del reloj del sistem a, en el caso de que el reloj se actualice mediante interrupciones. Por tanto, muchos sistem as inform áticos m odernos proporcionan instrucciones hardware especiales que nos perm iten consultar y m odificar el contenido de una palabra o intercam biar los contenidos de dos palabras atóm icam ente, es decir, com o una unidad de trabajo ininterrumpible. Podemos usar estas instrucciones especiales para resolver el problem a de la sección crítica de una form a relativamente sim ple. En lugar de estudiar una instrucción específica de una determinada m áquina, vam os a abstraer los principales conceptos que subyacen a este tipo de instrucciones. La instrucción TestAndSet para leer y m odificar atóm icam ente una variable puede definirse com o se m uestra en la Figura 6.4. La característica im portante es que esta instrucción se ejecuta atómicam ente. Por tanto, si dos instrucciones TestAndSet se ejecutan sim ultáneam ente (cada una en una CPU diferente), se ejecutarán secuencialm ente en un orden arbitrario. Si la máquina soporta la instrucción TestAndSet, entonces podemos Ím plem entar la exclusión mutua decla­ rando una variable booleana lock inicializada con el valor false. En la Figura 6.5 se'm uestra la estructura del proceso P¡. boolear. TestAndSet (boolean *target) bealean rv = *target; *aarget = TRUE; }

Figura 6.4 Definición de la instrucción TestAndSet.

•'

6.4 Hardware de sincronización

do { while

177

(TestAndSetLock (&lock)) / / no hacer nada

// sección crítica lock = FALSE; // sección restante } whíle (TRUE);

Figura 6.5 Implementación de la exclusión mutua con TestAndSet(). La instrucción Swap () para intercam biar el valor de dos variables, a diferencia de la instruc­ ción TestAndSet () opera sobre los contenidos de dos palabras; se define como se m uestra en la Figura 6.6. Com o la instrucción TestAndSet (), se ejecuta atóm icam ente. Si la máquina soporta la instrucción Swap () , entonces la exclusión m utua se proporciona como sigue: se declara una variable global booleana l o c k y se inicializa com o f a l s e . Adem ás, cada proceso tiene una varia­ ble local booleana key. La estructura del proceso P¡ se m uestra en la Figura 6.7. Aunque estos algoritm os satisfacen el requisito de exclusión m utua, no satisfacen el requisito de espera lim itada. En la Figura 6.8 presentam os otro algoritm o usando la instrucción TestAndSet() que satisface todos los requisitos del problem a de la sección crítica. Las estructuras de datos com unes son boolean waiting[n]; boolean lock; Estas estructuras de datos se inicializan con el valor false. Para probar que el requisito de exclusión m utua se cumple, observam os que el proceso P, puede entrar en su sección crítica sólo siwaiting[i] == false o key == false. El valor de key puede ser false sólo si se eje­ cuta TestAndSet ( ) ; el primer proceso que ejecute TestAndSet () com probará que key = = false y todos los demás tendrán que esperar. La variable waiting [i] puede tomar el valor false sólo si otro proceso sale de su sección crítica; sólo se asigna el valor false a una única variable waiting [ i ], m anteniendo el requisito de exclusión mutua. Para probar que se cum ple el requisito de progreso, observam os que los argumentos relativos a la exclusión mutua también se aplican aquí, dado que un proceso que sale de la sección crítica configura lock com o false o waitinglj] com o false. En ambos casos, se permite que un proceso en espera entre en su sección crítica para continuar. Para probar que se cum ple el requisito de tiem po de espera limitado, observamos que, cuando un proceso deja su sección crítica, explora la m atriz waiting en el orden cíclico (i + 1, i + 2, ..., n — 1, 0 ,.. ., ; — 1) y selecciona el prim er proceso (según este orden) que se encuentre en la sección de entrada (waiting [ j ] == true) com o siguiente proceso que debe entrar en la sección críti­ ca. Cualquier proceso que quiera entrar en su sección crítica podrá hacerlo en, como máximo, n 1 turnos. Lam entablem ente para los diseñadores de hardw are, la im plem entación de instrucciones TestAndSet en los sistem as m ultiprocesador no es una tarea trivial. Tales im plementaciones se tratan en los libros dedicados a arquitecturas inform áticas. void Swap (boolean *a, boolear. *b) boolean temo = *a; *a = * D ; * b = oemp;

Figura 6.6 La definición de la instrucción Swap().

{

Capítulo 6 Sincronización de procesos

do { key = TRUE; while (key == TRUE) Swapí&lock, Sckey) ; // sección crítica lock = FALSE; // sección restante }while (TRUE);

Figura 6.7

Im plem entación de la exclusión m utua con la instrucción Swap í).

do { wa it ing[i] = T RUE; key = TRUE; while (waiting [i] && key) key = TestAndSet(&lock); waiting[i] = FALSE; // sección crítica j = (i + 1) % n ; while (íj != i) && !waiting[j]) j = (j + 1 ) % n; ii

( j == x) lock = FALSE; else waitir.g[j] = FALSE; // sección restante }while (TRUE);

Figura 6.8

Exclusión mutua con tiempo de espera limitada, utilizando la instrucción T e s c A r.d S e t ().

Semáforos Las diversas soluciones hardware al problem a de la sección crítica, basadas en las instrucciones TestAndSet () y Swap () y presentadas en la Sección 6.4, son com plicadas de utilizar por los program adores de aplicaciones. Para superar esta dificultad, podemos usar una herram ienta de sincronización denom inada sem áforo. Un sem áforo S es una variable entera a la que, dejando aparte la inicialización, sólo se accede m ediante dos operaciones atómicas estándar: w a i t () y s i g n a l ( ) . Originalmente, la operación w a i t () se denom inaba P (del término holandés proberen, probar); mientras que s i g n a l () se denom inaba originalm ente V (verhogen, increm entar). La definición de w a i t ; es la que sigue: w a S I { ■.-.'hile 3 es:

■ to-op

6.5 Semáforos

s i g n a l (S )

S + +;

179

{

Todas las m odificaciones del valor entero del sem áforo en las operaciones w a i t () y s i g ­ n a l () deben ejecutarse de forma indivisible. Es decir, cuando un proceso m odifica el valor del sem áforo, ningún otro proceso puede m odificar sim ultáneam ente el valor de dicho semáforo. A dem ás, en el caso de wa i t ( ) , la prueba del valor entero de S ( S ^ 0), y su posible m odifica­ ción (S — ) también se deben ejecutar sin interrupción. Verem os cómo pueden im plem entarse estas operaciones en la Sección 6.5.2, pero antes, vam os a ver cómo pueden utilizarse los sem á­ foros.

6.5.1 Utilización Los sistem as operativos diferencian a m enudo entre sem áforos contadores y semáforos binarios. El valor de un sem áforo contador puede variar en un dom inio no restringido, m ientras que el valor de un sem áforo binario sólo puede ser 0 o 1. En algunos sistemas, los semáforos binarios se conocen com o cerrojos mútex, ya que son cerrojos que proporcionan exclusión mutua. Podem os usar sem áforos binarios para abordar el problem a de la sección crítica en el caso de m últiples procesos. Los n procesos com parten un sem áforo, m u tex, inicializado con el valor 1. Cada proceso P¡ se organiza como se m uestra en la Figura 6.9. Los sem áforos contadores se pueden usar para controlar el acceso a un determ inado recurso form ado por un núm ero finito de instancias. El semáforo se inicializa con el número de recursos disponibles. Cada proceso que desee usar un recurso ejecuta una operación w a i t () en el sem á­ foro (decrem entando la cuenta). Cuando- un proceso libera un recurso, ejecuta una operación s i g n a l () (increm entando la cuenta). Cuando la cuenta del semáforo llega a 0, todos los recur­ sos estarán en uso. Después, los procesos que deseen usar un recurso se bloquearán hasta que la cuenta sea m ayor que 0. Tam bién podem os usar los semáforos para resolver diversos problemas de sincronización. Por ejem plo, considere dos procesos que se estén ejecutando de form a concurrente: Pl con una instruc­ ción S j y P2 con una instrucción S2. Suponga que necesitam os que S2 se ejecute sólo después de que St se haya com pletado. Podemos im plementar este esquema dejando que P1 y P2 com partan un sem áforo com ún synch, inicializado con el valor 0, e insertando las instrucciones:

SL; signal(synch); en el proceso Pv y las instrucciones w a i t (s y n c h );

S2;

en el proceso P 2. Dado que s y r.ch se inicializa con el valor 0, P2 ejecutará S2 sólo después de que Pa haya invocado s i g n a l ( s y n c h ) , instrucción que sigue a la ejecución de S - .

waiting(mutex); // sección crítica signal(mu te:*:i; / / SeCcior.

'•v / n i l e

rGSCdr.Cc

( 7 RUE) ;

Figura 6.9 Implementación de ia exclusión mutua con semáforos.

180

Capítulo 6 Sincronización de procesos

6.5.2 Implementación La principal desventaja de la definición de sem áforo dada aquí es que requiere una espera activa^ M ientras un proceso está en su sección crítica, cualquier otro proceso que intente entrar en su secj¡ ción crítica debe ejecutar continuam ente un bucle en el código de entrada. Este bucle con tinu é plantea claram ente un problem a en un sistem a real de m ultiprogram ación, donde una sola CPU sel com parte entre muchos procesos. La espera activa desperdicia ciclos de CPU que algunos otro!» procesos podrían usar de form a productiva. Este tipo de sem áforo tam bién se denom ina cerrojo" mediante bucle sin fin (spinlock), ya que el proceso “perm anece en un bucle sin fin” en espera del adquirir el cerrojo. (Los cerrojos m ediante bucle sin fin tienen una ventaja y es que no requieren^ ningún cam bio de contexto cuando un proceso tiene que esperar para adquirir un cerrojo. Los? cambios de contexto pueden llevar un tiempo considerable. Por tanto, cuando se espera que losi cerrojos se m antengan durante un período de tiempo corto, los cerrojos m ediante bucle sin fin" pueden resultar útiles; por eso se em plean a m enudo en los sistem as m ultiprocesador, donde una hebra puede “ejecutar un bucle" sobre un procesador m ientras otra hebra ejecuta su sección críti-¿ ca en otro procesador). u Para salvar la necesidad de la espera activa, podem os m odificar la definición de las operacio­ nes de sem áforo w a i t () y s i g n a l () . Cuando un proceso ejecuta la operación w a i t () y determina que el valor del sem áforo no es positivo, tiene que esperar. Sin em bargo, en lugar de entrar en una espera activa, el proceso puede bloquearse a sí m ismo. La operación de bloqueo coloca al proceso en una cola de espera asociada con el sem áforo y el estado del proceso pasa al estado de espera. A continuación, el control se transfiere al planificador de la CPU, que selecciona otro pro­ ceso para su ejecución. Un proceso bloqueado, que está esperando en un sem áforo S, debe reiniciarse cuando algún otro proceso ejecuta una operación signal (). El proceso se reinicia m ediante una operación wakeup () , que cambia al proceso del estado de espera al estado de preparado. El proceso se coloca en la cola de procesos preparados. (La CPU puede o no conm utar del proceso en ejecución al proceso que se acaba de pasar al estado de preparado, dependiendo del algoritm o de planifica­ ción de la CPU.) Para im plementar sem áforos usando esta definición, definimos un sem áforo como una estruc­ tura “C”: typedef struct { int valué; struct process *list; }semaphore; Cada sem áforo tiene un valor (v a lu é ) entero y una lista de procesos l i s t . Cuando un proce­ so tiene que esperar en un semáforo, se añade a la lista de procesos. Una operación s i g n a l () eli­ mina un proceso de la lista de procesos en espera y lo despierta. La operación de sem áforo w a i t () ahora se puede definir del siguiente modo; waitísemaphore *S) { S->value--; if (S->value < 0) { añadir este proceso a S->list; bl ock(); 1 La operación de sem áforo s i g n a l í ) ahora puede definirse así: signal (serr.aphore *S)

{

3 - > v a l ú e t i-; } '*

if

'3->value 1 isr;

6.5 Semáforos

181

wakeup r .; } La operación b l o c k () suspende al proceso que la ha invocado. La operación w akeup () rea­ nuda la ejecución de un proceso bloqueado P. Estas dos operaciones las proporciona el sistema operativo com o llam adas al sistem a básicas. Observe que, aunque bajo la definición clásica de sem áforos con espera activa, el valor del semáforo nunca es negativo, esta im plem entación sí que puede tener valores negativos de sem á­ foro. Si el valor del sem áforo es negativo, su módulo es el núm ero de procesos en espera en dicho semáforo. Este hecho resulta de conm utar el orden de las operaciones de decrem ento y de prue­ ba en la im plem entación de la operación w a i t (} . La lista de procesos en espera puede im plementarse fácilm ente mediante un cam po de enlace en cada bloque de control de proceso (PCB). Cada semáforo contiene un valor entero y un punte­ ro a la lista de bloques PCB. Una forma de añadir y eliminar procesos de la lista de m anera que se garantice un tiempo de espera lim itado consiste en usar una cola FIFO, donde el sem áforo conten­ ga punteros a ambos extrem os de la cola. Sin embargo, en general, la lista puede utilizar cualquier estrategia de gestión de la cola. El uso correcto de los sem áforos no depende de la estrategia con­ creta de gestión de la cola que se em plee para las listas de los semáforos. El aspecto crítico de los sem áforos es que se deben ejecutar atómicam ente: tenemos que garan­ tizar que dos procesos no puedan ejecutar al mismo tiempo sendas operaciones w a i t () y s i g ­ n a ! () sobre el mismo sem áforo. Se trata de un problema de sección crítica. En un entorno de un solo procesador (es decir, en el que sólo exista una CPU), podem os solucionar el problem a de forma sencilla inhibiendo las interrupciones durante el tiem po en que se ejecutan las operaciones w a i t () y s i g n a l ( ) . Este esquem a funciona adecuadam ente en un entorno de un solo procesa­ dor porque, una vez que se inhiben las interrupciones, las instrucciones de los diferentes procesos no pueden intercalarse: sólo se ejecuta el proceso actual hasta que se reactivan las interrupciones y el planificador puede tom ar de nuevo el control. En un entorno m ultiprocesador, hay que deshabilitar las interrupciones en cada procesador; si no se hace así, las instrucciones de los diferentes procesos (que estén ejecutándose sobre diferen­ tes procesadores) pueden intercalarse de form a arbitraria. D eshabilitar las interrupciones en todos los procesadores puede ser una tarea com pleja y, además, puede disminuir seriam ente el rendi­ miento. Por tanto, los sistem as SMP deben proporcionar técnicas alternativas de bloqueo, como por ejem plo cerrojos m ediante bucle sin fin, para asegurar que las operaciones wait () y sig­ na i ( ) se ejecuten atóm icam ente. Es im portante recalcar que no hem os elim inado por com pleto la espera activa con esta defini­ ción de las operaciones wait () y signal ( ) ; en lugar de ello, hemos eliminado la espera activa de la sección de entrada y la hem os llevado a las secciones críticas de los programas de aplicación. Además, hem os limitado la espera activa a las secciones críticas de las operaciones wait () y s ignal ( ) , y estas secciones son cortas (si se codifican apropiadam ente, no deberían tener más de unas diez instrucciones). Por tanto, la sección crítica casi nunca está ocupada y raras veces se pro­ duce este tipo de espera; y, si se produce, sólo dura un tiempo corto. En los program as de aplica­ ción, la situación es com pletam ente diferente, porque sus secciones críticas pueden ser largas (minutos o incluso horas) o pueden estar casi siempre ocupadas. En tales casos, la espera activa resulta extrem adam ente ineficiente.

6.5.3 Interbloqueos e inanición La im plem entación de un sem áforo con una cola de espera puede dar lugar a una situación en la que dos o más procesos estén esperando indefinidam ente a que se produzca un suceso que sólo puede producirse como consecuencia de las operaciones efectuadas por otro de los procesos en espera. El suceso en cuestión es la ejecución de una operación sigr.e _ . Cuando se llega a un estado así, se dice que estos procesos se han interbloqueado. Para ilustrar el concepto, considerem os un sistema que consta de dos procesos, P0 y P l, con acceso cada uno de ellos a dos semáforos, S y Q, configurados con el valor 1:

-íirulo 6 Sincronización de procesos

Po

Pi

wait(S) wait(Q)

wait(Q); wait(S);

signal(S) signal(Q)

signal(Q); signal(S);

Suponga que P0 ejecuta wait (S) y luego P1 ejecuta wait (Q). Cuando P0 ejecuta wait (Q 'ate esperar hasta que ejecute signal (Q). De forma similar, cuando P1 ejecuta wait (s tere que esperar hasta que P0 ejecute signal (S). Dado que estas operaciones signal () r : ,eden ejecutarse, P0 y P-¡ se interbloquean. Decimos que un conjunto de procesos está en un estado de interbloqueo cuando todos los pr< tesos del conjunto están esperando un suceso que sólo puede producirse como consecuencia c es acciones de otro proceso del conjunto. Los sucesos que más nos interesan aquí son los de adqi, //.en v liberación de recursos, pero tam bién hay otros tipos de sucesos que pueden dar lugar a inte ' '.cueos, como verem os en el Capítulo 7. En ese capítulo describiremos varios m ecanism os pa: "atar los problemas de interbloqueo. Ciro problema relacionado con los interbloqueos es el del bloqu eo in d efin id o o muerte pi -.'¿nidón, una situación en la que algunos procesos esperan de form a indefinida dentro del serrt 'tro. El bloqueo indefinido puede producirse si añadim os y eliminamos los procesos a la lista asi t:¿'Ja con el semáforo utilizando un esquema LIFO (last-in, first-out).

Problemas clásicos de sincronización Er esta sección, vam os a presentar una serie de problemas de sincronización com o ejem plos i era amplia clase de problem as de control de concurrencia. Estos problemas se utilizan para pr< car casi todos los nuevos esquem as de sincronización propuestos. En nuestras soluciones a k problemas, emplearemos sem áforos para la sincronización.

t 6.1 Problema del búfer limitado ó. problema del buffer limitado se ha presentado en la Sección 6.1; habitualm ente se utiliza pa: v ir a r la potencia de las prim itivas de sincronización. Vamos a presentar una estructura gener este esquema, sin com prom eternos con ninguna implementación particular; en los ejercicios . úr¿i del capitulo se proporciona un proyecto de programación relacionado con este problema. Suponga que la cola consta de n búferes, siendo cada uno capaz de alm acenar un elemento. I semáforo rrurex proporciona exclusión mutua para los accesos al conjunto de búferes y se inicie

do { // produce un elenier.ro en nextp wait(empty); wait (rrutex) ; // añadir nextp al iúisr signal ¡rn.utex) ; signal(full); }while (TRUE) ;

Figura 6.10 Estructura de! proceso productor.

6.6 Problemas clásicos de sincronización

183

do { wait(fuli); wait(mucex); // eliminar un elemento del búfer a nextc signal(mutex); signal(empty); // consume el elemento en nextc }while (TRUE); Figura 6.11

Estructura del proceso consumidor.

liza con el v a lo r 1. L os sem áforos empty y full cu en tan el n ú m ero de b ú feres v acíos y llenos. El sem áforo empty se inicializa con el v alor n; el sem áfo ro full se in icializa con el v alor 0. El código p ara el p roceso p ro d u ctor se m u estra en la F ig u ra 6.10; el cód ig o p ara el p ro ceso co n ­ sum idor se p resen ta en la Fig u ra 6.11. O bserve la sim etría en tre el p ro d u cto r y el con su m id or: podem os in terp retar este cód ig o co m o u n p ro d u ctor q u e gen era los b ú feres llen os p ara el co n su ­ m idor o com o u n co n su m id o r que g en era b ú feres v acío s p ara el p rod u ctor.

6.6.2 El problema de los lectores-escritores Im agine u na b a se de d atos que d eb e ser com p artid a p or v arios p rocesos con cu rren tes. A lg u n os de estos p ro cesos p u ed en sim p lem en te qu erer leer la b ase de datos, m ientras que otros p u ed en desear actu alizarla (es decir, leer y escribir). D iferen ciam os en tre estos dos tip o s de p ro ceso s d en o ­ m inando a los prim eros lectores y a los otros escritores. O bv iam en te, si dos lectores acced en sim ultán eam en te a los d atos com p artid o s, esto n o d ará lu g ar a n in gú n p ro blem a. Sin em b argo, si un escritor y algú n otro proceso (sea lecto r o escritor) acced en sim u ltán eam en te a la b ase de datos, el caos está asegurad o. Para aseg u rar que estos p ro blem as no afloren, req u erim o s qu e los p rocesos escrito res tengan acceso exclu sivo a la base de datos com p artid a. E ste p ro b lem a de sin cro n izació n se d en om in a p ro­ blema de los lectores y escritores. D esd e que-se lo estab leció o rigin alm en te, este p ro blem a se ha u ti­ lizado para p ro b a r casi todas las n u ev as p rim itiv as de sin cro n ización . El p ro blem a de los lectores y escritores p resen ta diversas v arian tes, todas las cu ales u tilizan p riorid ad es. La m ás sencilla, conocida com o p rim er p roblem a d e los lectores-escritores, req u iere que n in g ú n lector se m an ten ­ ga en esp era a m en os que un escrito r haya ob ten id o ya p erm iso para u tilizar el ob jeto co m p arti­ do. En otras p alabras, n in gú n lector debe esp erar a q u e otros lectores term in en sim p lem en te porque un p ro ceso escritor esté esp eran d o. El segu n do p ro blem a de los lectores-escritores req u ie­ re por el co n trario que, una vez que un escritor está p rep arad o, d icho escritor realice la escritu ra tan pronto com o sea posible. Es d ecir, si un escritor está esp eran d o para acced er al objeto, n in gú n proceso lector n u ev o pu ed e in iciar la lectura. U na so lu ción a cu alqu iera de estos problem as p u ed e dar com o resu ltad o u n pro blem a de inanición. En el primer- c-aso, los escritores p u ed en b lo q u earse in d efin id am en te; en el segun d o caso, son los lectores los que p u ed en m o rir de in an ición . P or esta razón, se han p ro p u esto otras variantes d el p ro blem a. En esta secció n , vam os a p resen tar una so lu ción sin b loq u eos in d efinid os para el p rim er problem a de los lectores-escritores; co n su lte las notas b ib lio g ráficas in clu id as al final del ca p ítu lo para ver referen cias que d escriben so lu cion es sin bloq u eos in d efin id os para el segundo p ro blem a de los lectores-escritores. En la so lu ció n del prim er p ro blem a de los lecto res-escrito res, los p ro cesos lectores com p arten las sigu ien tes estru ctu ras de datos:

184

Capítulo 6 Sincronización de procesos

L os sem áfo ros mutex y wrt se in icializan con el v alo r 1, m ien tras que readcount se inicialpH za con el v alor 0. El sem áforo wrc es co m ú n a los p rocesos lecto res y escritores. El sem áforo mute'JS se usa para asegu rar la ex clu sió n m u tu a m ientras se actu aliza la v ariab le readcount. La variabl e ! readcounc alm acen a el n ú m ero de p rocesos qu e están ley en d o actu alm en te el objeto. El semáfo|8 ro wrt fu n cion a com o un sem áfo ro de exclu sión m u tu a p ara los escritores. T am b ién lo utilizan 4 a p rim er o el últim o lector que en tran o salen de la sección crítica. Los lectores q u e en tren o salg an * m ien tras otros p rocesos lectores estén en su s seccion es críticas n o lo utilizan. J| El cód ig o para un p roceso escritor se m uestra en la F ig u ra 6.12; el código para u n proceso lec| j tor se m u estra en la Fig u ra 6.13. O b serv e que, si un escrito r está en la sección crítica y n le cto re sj están esp eran d o, en ton ces un proceso lector estará en la cola de wrt y n - 1 lectores estarán en laH cola d e mutex. O bserve tam bién que, cu an d o u n escritor eje cu ta signal (wrt ) , p od em os reanu-í| d ar la ejecu ció n de tod os los p rocesos lectores en esp era o d e u n ú n ico proceso escritor en espera; j ¡ la d ecisió n le corresp on d erá al p lan ificad or. i E n algu n os sistem as, el p roblem a de los p ro cesos lecto res y escritores y sus so lu cion es se han # g en eralizad o para p ro p orcio n ar b loq u eos lector-escritor. A d q u irir un b loq u eo lector-escritor req u iere esp ecificar el m od o del bloqu eo: acceso de lectura o de escritura. C u an d o u n proceso sólo d esee leer los datos com p artid o s, solicitará un cerro jo lecto r-escrito r en m od o lectu ra. U n proceso J qu e d esee m od ificar los d atos com p artid o s d eb erá so licitar el cerro jo en m odo escritu ra. Se perm i-? te q u e m ú ltip les procesos ad q u ieran de form a co n cu rren te u n cerro jo lector-escritor en m odo lec­ tura, p ero sólo un proceso pu ed e ad q u irir el cerro jo en m od o escritu ra, ya qu e se req u iere acceso ex clu siv o por parte de los p rocesos escritores. L os cerro jos lector-escritor resu ltan esp ecialm en te ú tiles en las situ acion es siguien tes: •

E n aquellas ap licacion es en las qu e sea fácil id en tificar q u é procesos sólo desean leer los d atos com p artid o s y qué h ebras sólo q u ieren escrib ir en lo s datos com p artid os.

do { wait(wrt); // se realiza la escritura

signal(wrt); (TRUE);

}w hile Figura 6.12

Estructura de un proceso escritor.

do { wait(mutex); readcount++; if (readcount == 1) wait(wrt); signal(mutex); // se realiza la lectura wait(mutex); readcount--; if (readcount == 0) signal(wrt); signal(mutex);

■while (TRUE);

Figura 6.13 Estructura de un proceso lector.

6.6 Problemas clásicos de sincronización

185

• E n aq u ellas ap licacion es q u e tengan m ás p ro cesos lecto res que escritores. Esto se d ebe a que, gen eralm en te, esta b lece r los b loq u eos lecto r-escrito r requiere m ás carca de trabajo que los b lo q u eo s de ex clu sió n m utu a o los sem áfo ros, y la carga de trabajo de con figu rar u n cerro jo lecto r-escrito r se co m p en sa m ed ian te el in crem en to en el grado de concurrencia que se ob tien e al p erm itir el acceso p or p arte de m ú ltip les lectores.

6.6.3 Problema de la cena de los filósofos C on sid ere cin co filóso fo s qu e g astan sus v id as en p en sar y com er. Los rilósofos com parten u na m esa red o n d a con cin co sillas, u n a para cada filó so fo . En el cen tro de la m esa hay una fuente de arroz y la m esa se ha p u esto co n sólo cinco p alillo s (Figura 6.14). C uando un filósofo piensa, no se relacion a con su s colegas. D e vez en cuan d o, u n filóso fo sien te ham bre v trata de tom ar los p ali­ llos m ás p ró xim o s a él (los p alillos que se en cu e n tra n en tre él y sus vecinos de la izquierda y la d erecha). U n filóso fo sólo p u ed e co g er un p alillo ca d a vez. O bviam en te, no puede coger un p ali­ llo q u e h aya cog id o antes u n v ecin o de m esa. C u an d o un filó so fo ham briento ha conseguido dos palillos, com e sin soltar su s p alillos. C uand o term in a de com er, los coloca de nuevo sobre la m esa y v u elv e a pensar. El p roblem a d e la cena d e los filó so fo s se co n sid era u n p ro b lem a clásico de sincronización, no por su im p o rtan cia p ráctica ni p orq u e los in fo rm ático s tengan av ersió n a los filósofos, sino porque es un ejem p lo de u na am p lia cla se de p roblem as d e co n tro l de concurrencia. Es una rep resen tación sen cilla de la n ecesid ad de rep a rtir varios recu rso s en tre v ario s procesos de una form a que no se p ro d u zcan in terb lo q u eo s ni b lo q u eo s indefinid os. U na so lu ció n sen cilla co n siste en rep resen tar ca d a p alillo m ed ian te un sem áforo. U n filósofo in ten ta h acerse con un p alillo ejecu tan d o u na o p eració n wa i t () en dicho sem áforo y libera sus p alillo s ejecu tan d o la o p eració n s i g n a l () en lo s sem áfo ro s adecu ados. Por tanto, los datos co m ­ p artid o s son

semaphore palillo[5]; d on d e tod os los elem en to s de p a l i 1 l o se in icializan con el v a lo r 1. La estructura del filósofo i se m u estra en la Fig u ra 6.15. A u n q u e esta solu ción g aran tiza que dos v ecin o s de m esa no com an nunca sim ultáneam ente, d ebe rech azarse, porqu e p u ed e crear in terb loq u eos. S u p o n g am o s que ¡os cin co filósofos sienten h am bre a la vez y cad a u no tom a el palillo situ ad o a su izq u ierd a. Ahora, todos ios elem entos de p a l i l l o ten d rán el valor 0. C u an d o los filó so fo s in ten ten co g er el palillo de la derecha, tendrán qu e esp erar etern am en te. A co n tin u ació n se en u m eran v arias p osib les so lu cion es p ara este problem a de m terbloqueo. En la Secció n 6.7 p resen tarem os u na solu ción p ara el p ro b lem a d e la cena de los filósofos que garan ­ tiza que no ex ista n in terb loq u eos. • P erm itir qu e com o m áx im o h aya cu atro filó so fo s sen tad os a la m esa sim ultáneam ente.

Figura 6.14 La cena de los filósofos.

Capítulo 6 Sincronización de procesos

186

do { wait(palillofi]); wait(palillo [ (i + 1)% 51); /'/ comer sigr.al (palillo [i] ) ; signal(palillo [(i+l)% 5]); // pensar

}while (TRUE)i Figura 6.15

Estructura del filósofo /.

«

P erm itir a cad a filó so fo coger su s p alillos sólo si am bos palillos están d isp on ibles (para ellóf| d eb erá co g er lo s p alillos d en tro de una sección crítica). uj

•

U tilizar u na so lu ció n asim étrica, es decir, un filóso fo im p ar coge p rim ero el palillo de suf izq u ierd a y lu eg o el que está a su d erecha, m ientras qu e un filósofo p a r coge prim ero el pali-^ lio de su d erech a y luego el de la izqu ierda. Jj

Por ú ltim o, tod a so lu ció n satisfactoria al problem a de la cen a de los filó so fo s debe proteger del la p osib ilid ad de q u e u no de los filósofos m uera por inanición. U na so lu ció n libre de interblo-j q u eos no n ecesa ria m en te elim in a la posibilidad de m u erte por inanición. 1

6.7

Monitores A u n q u e los sem áfo ro s p ro p orcio n an u n m ecanism o ad ecu ado y efectivo p ara el proceso de sin­ cron ización , u n u so in correcto de los m ism os puede dar lu gar a errores de tem p orización que son difíciles de d etectar, d ad o que estos errores sólo ocurren si tien en lu gar alg u n as secu en cias de eje­ cu ció n con cretas y estas secu en cias n o siem pre se producen. H em os v isto u n ejem p lo de dichos errores en el uso de con tad ores en la so lu ción del problem a p ro d u cto r-co n su m id o r (Sección 6.1). En ese ejem plo, el p roblem a de tem p o rizació n se producía raras v eces, e in clu so en ton ces el v alor del contador parecía ser razon able: lo que pasaba es que d ifería en 1 d el v alor correcto. Pero au nqu e el valor pareciera correcto, no era aceptable y es por esta razó n q u e se in tro d u jero n los sem áforos. L am en tab lem en te, esto s errores de tem p orización p u ed en p ro d u cirse tam bién cu an d o se em p lean sem áfo ros. P ara ilu strar cóm o, revisem os la solu ción con sem áfo ros para el p roblem a de la sección crítica. T o d o s los procesos com p arten una v ariab le de sem áforo m u te x , que se inicializa co n el v alor 1. C ad a p ro ceso debe ejecu tar u na op eración w a i t ( m u t e x ) antes de entrar en la sección crítica y u na o p eració n s i g n a l ( mu t e x ) después de la m ism a. Si esta secu en cia no se lleva a cabo, dos p ro ceso s p od rían estar dentro de sus seccion es críticas al m ism o tiem po. E xam in em os los p ro b lem as a los que esto da lugar. O bserve que estos p ro b lem as su rgirán in clu ­ so au n q u e só lo sea u n ú n ico proceso el que no se com porte de la form a ad ecu ad a; dicha situación p u ed e d eb erse a u n erro r de p ro gram ación no in ten cion ado o a que u n cierto p ro gram ad or no tenga m u ch as gan as d e coop erar. • Su p on g a q u e u n p roceso in tercam b ia el orden en el que se ejecu tan las op eracion es v/ai t () y s i g n a l { ) , d an d o lugar a la sigu ien te secuencia de ejecución: S1C

sección crítica

6.7 Monitores

187

E n esta situ ación , v a rio s p ro cesos p u ed en estar ejecu tand o sus seccion es críticas sim u ltán e­ am en te, v iolan d o el req u isito de exclu sión m utu a. O bserve q u e este erro r sólo p u ed e d es­ cu b rirse si v arios p ro ceso s están activ o s sim u ltán eam en te en su s seccion es críticas y que esta situ ación n o siem p re se prod uce. • Su p o n g a que un p ro ceso reem p laza s i g n a l ( m u t e x ) por w a .it ( m u t e x ) . Es decir, ejecu ta wait(mutex); sección

crítica

wait(mutex); E n este caso, se p ro d u cirá u n interbloqu eo. • S u p o n g a q u e u n p ro ceso om ite la op eració n w a i t ( m u t e x ) , la op eración s i g n a l ( m u t e x ) , o am bas. E n este caso, se v iolará la exclu sión m u tu a o se p rod u cirá un in terb lo ­ queo. E stos ejem p los ilu stra n los d istintos tipos de error qu e se pu ed en gen erar fácilm ente cu an d o los p ro g ram ad o res em p lea n in correctam en te los sem áfo ros para so lu cion ar el problem a de la se c ­ ción crítica. P u ed en su rg ir p roblem as sim ilares en los otros m od elos de sin cro n ización qu e h em os p resen tad o en la S e cció n 6.6. P ara ab o rd a r tales erro res, los in v estig ad ores han d esarrollad o estru ctu ras de lengu aje d e alto n ivel. E n esta sección , v am os a d escribir una estru ctu ra fu n d am en tal de sin cro n ización de alto n iv el, el tipo m on itor.

6.7.1 Utilización U n tipo, o u n tipo ab stra cto de d atos, agru p a una serie de datos p rivad os con un con ju n to de m étod os p ú blicos qu e se u tilizan para o p erar sobre dich os datos. U n tipo m on itor tiene u n co n ­ ju n to de op eracion es d efin id a s p or el p ro g ram ad o r que gozan de la característica de exclu sión m u tu a d en tro del m on itor. El tipo m on itor tam bién con tien e la d eclaración de una serie de v aria­ bles cu y o s v alores d efin en el estado de u na instancia d e dicho tipo, ju n to con los cuerpos d e los p ro ced im ien tos o fu n cio n es que op eran so bre d ich as variables. En la Fig u ra 6.16 se m u estra la sin ­ taxis de un m onitor. La rep resen tació n de un tipo m on itor no puede ser u tilizad a d irectam en te por los d iv ersos p rocesos. A sí, u n pro ced im ien to defin id o den tro de un m on itor sólo pu ed e a cced er a las v ariab les d eclarad as lo calm en te den tro d el m on itor y a sus p arám etros form ales. D e form a sim ilar, a las variables lo cales de un m on itor sólo p u ed en acced er los pro ced im ien tos locales. La estru ctu ra del m o n ito r asegu ra qu e sólo un p roceso esté activo cad a vez dentro del m o n i­ tor. E n co n secu en cia, el p ro g ram ad o r no tiene que co d ificar exp lícitam en te esta restricción de sin ­ cro n iz a ció n (Fig ura 6.17). Sin em bargo, la estru ctu ra de m on itor, com o se ha d efin ido hasta ahora, no es lo su ficien tem en te p oten te com o p ara m od elar algu n os esqu em as de sincronización . P ara ello, n ecesitam o s d efin ir m ecan ism o s de sin cro n ización adicion ales. Estos m ecan ism os los p ro p o r­ cio n a la estru ctu ra c o n d i t i o n . U n p ro g ram ad or que n ecesite escribir u n esqu em a de sin cro n iza­ ción a m ed id a pu ed e d efin ir una o m ás v ariab les de tipo condition:

condición x, y; Las ú nicas op eracio n es que se p u ed en in v ocar en u na variable de con d ición son w a i t () y s i g n a l ( ). La op eración x .w a it(); ind ica q u e el proceso q u e in v oca esta op eración queda su sp end id o hasta qu e otro pro ceso in v o ­ que la op eración x .s i g n a l (); La o p eració n x . s i g n a 1 ( ; hace qu e se rean u d e exactam en te uno de los procesos su sp en d id os. Si no había nin gú n p ro ceso su spend id o, en ton ces la op eración s i g n a l ( i no tiene efecto, es decir,

188

Capítulo 6 Sincronización de procesos

monitor

n o m b re del m o n itor

{ /'/ declaraciones de variables compartidas procedimiento Pl ( . . . ) {

} procedimiento P2

( . . . )

{

( . . . )

{

}

procedimiento Pn

} código de inicialización

( . . . )

\ Figura 6.16

Sintaxis de un monitor.

el estad o de x será el m ism o que si la o p eració n n u n ca se h u b iera ejecu tad o (Figura 6.18). Com pare esta op eración con la op eración s i g n a l () asociad a con los sem áfo ros, q u e siem p re afectaba al estad o del sem áforo. Su p on g a ahora que, cu an d o un p ro ceso invoca la o p eració n x . s i g n a l ( ) , h ay un proceso Q en estad o su sp end id o aso ciad o con la co n d ició n x. E v id en tem en te, si se p erm ite al proceso sus­ p en d id o Q rean u d ar su ejecu ción, el p ro ceso P qu e ha efectu ad o la señ alizació n deberá esperar; en caso con trario, P y Q se activ arían sim u ltán eam en te d en tro d el m on itor. Sin em bargo, observe que co n cep tu alm en te am bos p rocesos p u ed en co n tin u ar con su ejecu ció n. E xisten dos posibilidades: 1.

S e ñ a liz a r y esp erar. con d ición .

P esp era h asta qu e Q salg a del m o n ito r o espere a q u e se produzca otra

Figura 6.17 Vista esquemática de un monitor.

6.7 Monitores

189

cola cia onf /iX-*ü*£MEk cosnadsicoio nedsasx,cy

Figura 6 .18

Monitor con variables de condición.

2. Señalizar y continuar. Q espera hasta que P salga del monitor o espere a que se produzca otra condición. Hay argumentos razonables en favor de adoptar cualquiera de estas opciones. Por un lado, puesto que P ya estaba ejecutándose en el monitor, el método de señalizar y continuar parece el más razonable. Por otro lado, si permitimos que la hebra P continúe, para cuando se reanude la ejecu­ ción de Q, es posible que ya no se cumpla la condición lógica por la que Q estaba esperando. En el lenguaje Pascal Concurrente se adoptó un compromiso entre estas dos opciones: cuando la hebra P ejecuta la operación signal, sale inmediatamente del monitor. Por tanto, la ejecución de Q se reanuda de forma inmediata.

6.7.2 Solución al problema de la cena de los filósofos usando monitores Vamos a ilustrar ahora el concepto de monitor presentando una solución libre de interbloqueos al problema de la cena de los filósofos. Esta solución impone la restricción de que un filósofo puede coger sus palillos sólo si ambos están disponibles. Para codificar esta solución, necesitamos dife­ renciar entre tres estados en los que puede hallarse un filósofo. Con este objetivo, introducimos la siguiente estructura de datos: enum {pen sar, hambre, comer) s t a t e [ 5 ] ; El filósofo i puede configurar la variable s t a t e [ i ] = comer sólo si sus dos vecinos de mesa no están comiendo: : s t a t e [ ( i + 4 ) % 5] i - comer) y (s t a t e [( i +1 ) % 5) ! = comer) . También tenemos que declarar condit ion s e l f [ 5 ] ; donde el filósofo i tiene que esperar cuando tiene hambre pero no puede conseguir los palillos que necesita. Ahora estamos en condiciones de describir nuestra solución al problema de la cena de los filó­ sofos. La distribución de los palillos se controla mediante el monitor dp, cuya definición se mues­ tra en la Figura 6.19. Cada filósofo, antes de empezar a comer, debe invocar la operación níckup ( ). Ésta puede dar lugar a la suspensión del proceso filósofo. Después de completar con éxito esta operación, el filósofo puede comer. A continuación, el filósofo invoca la operación

190

Capítulo 6 Sincronización de procesos

putdown ( ) . Por tanto, el filósofo i tiene que invocar las operaciones pickup () y putdown la siguiente secuencia: dp. p i c k u p (i );

comer dp.putdown(i );

Es fácil demostrar que esta solución asegura que nunca dos vecinos de mesa estarán co do simultáneamente y que no se producirán interbloqueos. Observe, sin embargo, que es que un filósofo se muera de hambre. No vamos a proporcionar aquí una solución para este blema; lo dejamos como ejercicio para el lector.

6.7.3 Implementación de un monitor utilizando semáforos Consideremos ahora una posible implementación del mecanismo de monitor utilizando senj ros. Para cada monitor se proporciona un semáforo mutex inicializado con el valor 1. Un pr so debe ejecutar la operación w a it (mutex ) antes de entrar en el monitor y tiene que ejecutar operación s i g n a l (mutex) después de salir del monitor. monitor dp

{ enum {PENSAR, HAMBRE, condition sel'f[5]';‘

COMER}State[5] ;

void pickup(int i) { State[i] = HAMBRE; test (i ) ,if (state[i] != COMER) self[i].wait();

void putdown(int i) { State[i] = PENSAR; test((i + 4) % 5) ; test((i + 1) % 5) ;

v o i d test ( i n t i ) if

{

((s t a t e [ (i + 4 )

% 5] != COMER) && = = HAMBRE) && (state[(i + 1 ) % 5] != COMER)) { S t a t e [i] = COMER; self [i] .signal() ; ( S t a t e [i]

}

initialization c ode() { for (int 1 = 0 ; i < 5; istate[i] = PENSAR;

}

Figura 6.19 Solución empleando monitores para el problema de la cena de los filósofos.

6.7 Monitores

191

Dado que un proceso que efectúe una operación de señalización debe esperar hasta que el pro­ ceso reanudado salga del monitor o quede en espera, se introduce un semáforo adicional, next, inicializado a 0, en el que los procesos que efectúen una señalización pueden quedarse suspendi­ dos. También se proporciona una variable entera n ext_coun c para contar el número de proce­ sos suspendidos en n e x t. Así, cada procedimiento externo ? se reemplaza por wai t ( mut e x ) ; cuerpo de F if

(next_count > 0 ) s i g n a l ( n e x t ); else s i g n a l ( mu t e x ) ; La exclusión mutua dentro del monitor está asegurada. Ahora podemos ver cómo se implementan las variables de condición. Para cada condición x, introducimos un semáforo x_sem y una variable entera x_cou n t, ambos inicializados a 0. La operación x . wai t () se puede implementar ahora como sigue x_count++; i í (next_count > 0 ) s i g n a l ( n e x t ); el s e s i g n a l ( mu t e x ) ; wa i t ( x_ s e m) ; x_ c o u n t - - ; La operación x . s i g n a l () se puede implementar de la siguiente manera if

(x_count > 0 ) { nexc_count++; s i g n a l ( x _ s e m) ; w a i t ( n e x t ); nexc_count--;

Esta implementación es aplicable a las definiciones de monitor dadas por Hoare y por BrinchHansen. Sin embargo, en algunos casos, la generalidad de la implementación es innecesaria y puede conseguirse mejorar significativamente la eficiencia. Dejamos este problema para el lector como Ejercicio 6.17.

6.7.4 Reanudación de procesos dentro de un monitor Volvamos ahora al tema del orden de reanudación de los procesos dentro de un monitor. Si hay varios procesos suspendidos en la condición x y algún proceso ejecuta una operación x . s i g n a l (), ¿cómo determinamos cuál de los procesos en estado suspendido será el siguiente en reanudarse? Una solución sencilla consiste en usar el orden FCFS, de modo que el proceso que lleve más tiempo en espera se reanude en primer lugar. Sin.embargo, en muchas circunstancias, un esquema de planificación tan simple no resulta adecuado. Puede utilizarse en este caso la estructura de espera condicional, que tiene la siguiente forma x.waiz(c); donde c es una expresión entera que se evalúa cuando se ejecuta la operación wait (). El valor de c, que se denomina número de prioridad, se almacena entonces junto con el nombre del proceso suspendido. Cuando se ejecuta x . s i g n a l (), se reanuda el proceso que tenga asociado el núme­ ro de prioridad más bajo.

192

Capítulo 6 Sincronización de procesos

Para ilustrar este nuevo mecanismo, considere el monitor ResourceAllocator mostra< la Figura 6.20, que controla la asignación de un recurso entre varios procesos competidores, proceso, al solicitar una asignación de este recurso, especifica el tiempo máximo durante el pretende usar dicho recurso. El monitor asigna el recurso al proceso cuya solicitud especifiqu; tiempo más corto. Un proceso que necesite acceder al recurso en cuestión deberá seguir secuencia: R .acquire(t); acceso al recurso; R .release(); donde R es una instancia del tipo ResourceAllocator. Lamentablemente, el concepto de monitor no puede garantizar que la secuencia de acceso anb rior sea respetada. En concreto, pueden producirse los siguientes problemas: • Un proceso podría acceder a un recurso sin haber obtenido primero el permiso de accesos recurso. ¿ 3?-'

• Un proceso podría no liberar nunca un recurso una vez que le hubiese sidoconcedido el¿ acceso al recurso. # • Un proceso podría intentar liberar un recurso que nunca solicitó.

®

• Un proceso podría solicitar el mismo recurso dos veces (sin liberar primero elrecurso).

5

Estos mismos problemas existían con el uso de semáforos y son de naturaleza similar a los que nos animaron a desarrollar las estructuras de monitor. Anteriormente, teníamos que preocupar­ nos por el correcto uso de los semáforos; ahora, debemos preocuparnos por el correcto uso de las operaciones de alto nivel definidas por el programador, para las que no podemos esperar ningu­ na ayuda por parte del compilador. monitor ResourceAllocator { boolean busy; condition x; void acquire(int tome. if (busy) x.wait (time) busy = TRUE; }

{

void release() { busy = FALSE; x .signal(); } initialization code(i { busy = FALSE;

Figura 6.20 Un monitor para asignar un único recurso.

6.7 Monitores

193

Una posible solución a este problema consiste en incluir las operaciones de acceso al recurso dentro del monitor ResourceAllocator. Sin embargo, el uso de esta solución significará que la planificación se realice de acuerdo con el algoritmo de planificación del monitor, en lugar de con el algoritmo que hayamos codificado. Para asegurar que los procesos respeten las secuencias apropiadas, debemos inspeccionar todos los programas que usen el monitor ResourceAllocator y el recurso gestionado. Tenemos que comprobar dos condiciones para poder establecer la corrección de este sistema. En primer lugar, los procesos de usuario siempre deben realizar sus llamadas en el monitor en la secuencia correcta. En segundo lugar, tenemos que asegurarnos de que no haya ningún proceso no cooperativo que ignore simplemente el mecanismo de exclusión mutua proporcionado por el monitor e intente acceder directamente al recurso compartido sin utilizar los protocolos de acce­ so. Sólo si estas dos condiciones se cumplen, podemos garantizar que no se produzcan errores dependientes de la temporización y que el algoritmo de planificación no falle. Aunque este tipo de inspección resulta posible en un sistema pequeño y estático, no es razona­ ble para un sistema grande o dinámico. Este problema de control de acceso sólo puede resolver­ se mediante mecanismos adicionales que describiremos en el Capítulo 14. Muchos lenguajes de programación han incorporado la idea de monitor descrita en esta sec­ ción, incluyendo Pascal Concurrente, Mesa, C# y Java. Otros lenguajes, como Erlang, proporcio­ nan un cierto soporte de concurrencia usando un mecanismo similar.

1 .4 * *

... ►

-V* &

■" • . btizj ' -

Java proporciona un mecanismo,decpr^uCTenda.d^tipq.anqjnitor parala.sincronizadón de hebrasr-Todo objeto de Java tiene asociado: im ú r a ta cerroiS' Cuando seí declara'rm m étodo c o m o .s y n c h r o h iz e d , la llam ad a .a l 'm éto d aT eq u ierejad q ú irir ehbloqueo sob re el cerrojo. D eclaram os un m éto d o co m o syn ch rón d JzéffX sih cro ru zád p J'in clu yen d o -d a’ p alab ra clav e * syn ch ron ized en la d e fín id ó rrd e l m étod q rP p rfejem p lo yél có d ig o siguienteydéfine el m éto - , d ó^ s'af e M e th o d 'fi cóm o i

public- class :SimpleClass{

■ .

'■V C > - ..7My \\ “ '

•;

public synchronized"voíd saf eMethod*f) {’ /* Imp 1emehtácí'ón 'Me5'saf'eMethadJj^' */

“* ~ -y~ ~ -

' ■>ÁiCC

'M

'

- v - r ^•''^lSpT^crrdst„

. ..................' .

. ....

.l "

^

,,,

.

"

Invocar el método" s e . safeM ethod() .requiere adquirir.el cerrojo.sobreda instancia sel Si -elcerrojo ya lo-

•- •• -

-- ~

194

Capítulo 6 Sincronización de procesos

6.8 Ejemplos de sincronización A continuación se describen los mecanismos de sincronización proporcionados por los sistpnv|B I operativos Solaris, Windows XP y Linux, así como por la API Pthreads. Hemos elegido estos tre ¿ ' sistemas porque proporcionan buenos ejemplos de los diferentes métodos de sincronización djff ? "kernel y hemos incluido la API de Pthreads porque su uso está muy extendido entre los desarrolla^ dores de UNIX y Linux para la creación y sincronización de hebras. Como veremos en esta secáóilf los métodos de sincronización disponibles en estos diferentes sistemas varían de forma sutil y sigTl nificativa. |¡|.

6.8.1 Sincronización en Solaris

*É .

"1| -

-# Para controlar el acceso a las secciones críticas, Solaris proporciona mútex adaptativos, variabiesj de condición, semáforos, bloqueos o cerrojos lector-escritor y colas de bloqueos (turnstiles). Solaris! implementa los semáforos y las variables de condición como se ha explicado en las Secciones 65* y 6.7. En esta sección, vamos a describir los mútex adaptativos, los bloqueos lector-escritor y la#§ colas de bloqueos. i? Un m ú tex ad ap tativ o protege el acceso a todos los elementos de datos críticos. En un sistema^ multiprocesador, un mútex adaptativo se inicia como un semáforo estándar, implementado como, un cerrojo de bucle sin fin (spinlock). Si los datos están bloqueados, lo que quiere decir que ya están* en uso, el mútex adaptativo hace una de dos cosas: si el cerrojo es mantenido por una hebra quej se está ejecutando concurrentemente en otra CPU, la hebra actual ejecuta un bucle sin fin mientras^1 ' espera a que el bloqueo esté disponible, dado que la hebra que mantiene el cerrojo probablemen-; te vaya a terminar pronto; si la hebra que mantiene él cerrojo no está actualmente en estado de ejeC cución, la hebra actual se bloquea, pasando a estado durmiente hasta que la liberación del cerrojo la despierta. Se la pone en estado durmiente para que no ejecute un bucle sin fin mientras espera, ’ dado que el cerrojo probablemente no se libere pronto. Los cerrojos mantenidos por hebras dur­ mientes caen, probablemente, dentro de esta categoría. En un sistema monoprocesador, la hebra que mantiene el cerrojo nunca estará ejecutándose cuando otra hebra compruebe el cerrojo, ya que sólo puede haber una hebra ejecutándose cada vez. Por tanto, en este tipo de sistema, las hebras siempre pasan a estado durmiente, en lugar de entrar en un bucle sin fin, cuando encuentran un cerrojo. Solaris utiliza el método del mútex adaptativo sólo para proteger aquellos datos a los que se accede mediante segmentos de código cortos. Es decir, se usa un mútex sólo si se va a mantener el bloqueo durante un máximo de unos cientos de instrucciones. Si el segmento de código es más largo, la solución basada en bucle sin fin será extremadamente ineficiente. Para estos segmentos de código largos, se usan las variables de condición y los semáforos. Si el cerrojo deseado ya está en uso, la hebra ejecuta una operación de espera y pasa al estado durmiente. Cuando otra hebra libere el cerrojo, ejecutará una operación s i g n a l dirigida a la siguiente hebra durmiente de la cola. El coste adicional de poner una hebra en estado durmiente y despertarla y de los cambios de contexto asociados es menor que el coste de malgastar varios cientos de instrucciones esperando en un bucle sin fin. Los bloqueos lector-escritor se usan para proteger aquellos datos a los que se accede frecuen­ temente, pero que habitualmente se usan en modo de sólo lectura. En estas circunstancias, los blo­ queos lector-escritor son más eficientes que los semáforos, dado que múltiples hebras pueden leer los datos de forma concurrente, mientras que los semáforos siempre serializan el acceso a los datos. Los bloqueos lector-escritor son relativamente caros de implementar, por lo que se usan sólo en secciones de código largas. Solaris utiliza colas de bloqueos para ordenar la lista de hebras en espera de adquirir un mútex adaptativo o un cerrojo lector-escritor. Una cola de b lo q u eo s (tumstile) es una estructura de cola que contiene las hebras que están a la espera de adquirir un cierto cerrojo. Por ejemplo, si una hebra posee actualmente el cerrojo para un objeto sincronizado, todas las restantes hebras que intenten adquirir el cerrojo se bloquearán y entrarán en la cola de dicho cerrojo. Cuando el cerro­ jo se libera, el kernel selecciona una hebra de la cola de bloqueo como nueva propietaria del cerro-

6.8 Ejemplos de sincronización

195

■ Cada objeto sincronizado que tenga al menos una hebra esperando a adquirir el cerrojo del ^b'eto requiere una cola de bloqueo propia. Sin embargo, en lugar de asociar una cola de bloqueo con cada objeto sincronizado, Solaris proporciona a cada hebra de kernel su propia cola de blo05

D ad o q u e u n a h e b ra só lo p u e d e e s ta r b lo q u e a d a e n u n objeto c a d a v e z , e sta s o lu c ió n es

m ás eficiente q u e ten er u n a co la d e b lo q u e o p a ra c a d a objeto.

‘

La cola de bloqueo correspondiente a la primera hebra que quede bloqueada por un objeto sinronizado se convierte en la cola de bloqueo del propio objeto. Las hebras subsiguientes se añadi­ rán a esta cola de bloqueo. Cuando la hebra inicial libere finalmente el cerrojo, obtendrá una nueva cola de bloqueo de una lista de colas de bloqueo libres que mantiene el kemel. Para impe­ dir una in v e rs ió n d e p r io r id a d , las colas de bloqueo se organizan de acuerdo con un p ro to c o lo de h e r e n c ia d e p r io rid a d (Sección 19.5). Esto significa que, si una hebra de baja prioridad mantie­ ne un cerrojo que una hebra de prioridad más alta necesita, la hebra con la prioridad más baja heredará temporalmente la prioridad de la hebra con prioridad más alta. Después de liberar el cerrojo, la hebra volverá a su prioridad original. Observe que los mecanismos de bloqueo utilizados por el kemel se implementan también para las hebras de nivel de usuario, de modo que los mismos tipos de cerrojo están disponibles fuera y dentro del kemel. Una diferencia de implementación fundamental es el protocolo de herencia de prioridad. Las rutinas de bloqueo del kernel se ajustan a los métodos de herencia de prioridades del kernel utilizados por el planificador, como se describe en la Sección 19.5; los mecanismos de bloqueo de hebras de nivel de usuario no proporcionan esta funcionalidad. Para optimizar el rendimiento de Solaris, los desarrolladores han depurado y ajustado los métodos de bloqueo. Puesto que los cerrojos se usan frecuentemente, y como generalmente se emplean para funciones cruciales del kernel, optimizar su implementación y uso permite obtener importantes mejoras de rendimiento.

6.8.2 Sincronización en W indows XP El sistema operativo Windows XP es un kemel multihebra que proporciona soporte para aplicacio­ nes en tiempo real y múltiples procesadores. Cuando el kernel de Windows XP accede a un recur­ so global en un sistema monoprocesador, enmascara temporalmente las interrupciones de todas las rutinas de tratamiento de interrupción que puedan también acceder al recurso global. En un sistema multiprocesador, Windows XP protege el acceso a los recursos globales utilizando blo­ queos basados en bucles sin fin. Al igual que en Solaris, el kernel usa los bucles sin fin sólo para proteger segmentos de código cortos. Además, por razones de eficiencia, el kernel asegura que una hebra nunca será desalojada mientras mantenga un cerrojo basado en bucle sin fin. Para la sincronización de hebras fuera del kernel, Windows XP proporciona o b je to s d e s p a c h a ­ d o res. Utilizando un objeto despachador, las hebras se sincronizan empleando diferentes meca­ nismos, incluyendo m ú te x , semáforos, sucesos y temporizadores. El sistema protege los datos compartidos requiriendo que una hebra adquiera la propiedad de un mútex para acceder a los datos y libere dicha propiedad cuando termine. Los semáforos se comportan como se ha descrito en la Sección 6.5. Los s u c e s o s son similares a las variables de condición; es decir, pueden notificar a una hebra en espera que una condición deseada se ha producido. Por último, los temporizadores se emplean para notificar a una (o más de una) hebra que ha transcurrido un determinado período de tiempo. Los objetos despachadores pueden estar en estado señalizado o en estado no señalizado. Un e sta d o s e ñ a liz a d o indica que el objeto está disponible y que una hebra no se bloqueará cuando adquiera el objeto. Un e s ta d o n o s e ñ a liz a d o indica que el objeto no está disponible y que una hebra se bloqueará cuando intente adquirir el objeto. En la Figura 6.21 se ilustran las transiciones entre estados de un objeto despachador para un cerrojo mútex. Existe una relación entre el estado de un objeto despachador y el estado de una hebra. Cuando una hebra se bloquea en un objeto despachador no señalizado, su estado cambia de preparado a en espera, y la hebra se pone en la cola de espera de dicho objeto. Cuando el estado del objeto des­ pachador pasa a señalizado, el kernel comprueba si hay hebras en espera para ese objeto. En caso afirmativo, el kernel pasa una hebra, o posiblemente más de una hebra, del estado de espera al

Capítulo 6 Sincronización de procesos

la hebra propietaria libera el cerrojo mútex.

Figura 6.21 Objeto despachador para un mútex. estado preparado, en el que pueden reanudar su ejecución. La cantidad de hebras que selección^ el kem el en la cola de espera dependerá del tipo de objeto despachador. El kernel sólo selecciona# rá una hebra de la cola de espera de un mútex, ya que un objeto mútex sólo puede ser poseído pop una hebra. Con un objeto suceso, el kernel seleccionará todas las hebras que estén esperando a qu| se produzca dicho suceso. C Podemos usar un cerrojo mútex como ilustración de los estados de los objetos despachadores y las hebras. Si una hebra intenta adquirir un objeto despachador mútex que se encuentre en estado no señalizado, dicha hebra se pondrá en estado suspendido y se colocará en la cola de espe­ ra del objeto mútex. Cuando el mútex pase al estado señalizado (porque otra hebra haya liberado el bloqueo sobre el mútex), la hebra en espera al principio de la cola pasará del estado de espera al de preparado y adquirirá el cerrojo mútex. Al final del capítulo se proporciona un proyecto de programación que utiliza bloqueos mútex y semáforos con la API Win32.

6.8.3 Sincronización en Linux Anteriormente a la versión 2.6, Linux era un kernel no apropiativo, lo que significa que un proce­ so que se ejecutase en modo kernel no podía ser desalojado, incluso aunque un proceso de mayor prioridad pasara a estar disponible para ejecución. Sin embargo, ahora el kernel de Linux es com­ pletamente un kernel apropiativo, de modo que una tarea puede ser desalojada aún cuando esté ejecutándose en el kem el. El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos (asi como versio­ nes lector-escritor de estos dos bloqueos) para establecer bloqueos en el kernel. En una máquina SMP, el mecanismo fundamental de bloqueo es el que se basa en el uso de bucles sin fin, y el ker­ nel se diseña de modo que dicho tipo de bloqueo se mantenga sólo durante períodos de tiempo cortos. En-las máquinas con un solo procesador, los bloqueos mediante bucle sin fin no resultan apropiados y se reemplazan por un mecanismo de activación y desactivación de la función de apropiación en el kernel. Es decir, en las máquinas monoprocesador, en lugar de mantener un blo­ queo mediante un bucle sin fin, el kernel desactiva el mecanismo de apropiación, y el proceso de liberación del bloqueo se sustituye por una reactivación del mecanismo de apropiación. Esto se resume del siguiente modo: un solo procesador

múltiples procesadores

Desactivar kemel apropiativo.

Adquirir bloqueo mediante bucle sin fin.

Activar kemel apropiativo.

Liberar bloqueo mediante buclersin fin.

Linux utiliza un método interesante para activar y desactivar los mecanismos de desalojo del y preempc_enable (), para desactivar v activar los mecanismos de apropiación. Además, el kernel no es desalojable si hay una tarea en modo kernel que esté manteniendo un bloqueo. Para imponer esta característica, cada tarea del sistema tiene una estructura t h r e a d - m í o que contiene un contador, ereempt .ecu r.:, para indicar el número de bloqueos que dicha tarea está manteniendo. Cuando se adquiere un cerrojo, pveempt_count se incrementa, y se decrementa cuando el bloqueado es

kernel: proporciona dos llamadas al sistema, preempt_di sable()

6.9 Transacciones atómicas

197

liberado. Si el valor de preempt_count para la tarea que está actualmente en ejecución es mayor que cero, no resultará seguro desalojar el kernel, ya que esa tarea mantiene un cerrojo. Si el conta­ dor es cero, el kernel puede ser interrumpido de forma segura (suponiendo que no haya llamadas pendientes a preempt_dísable ()). Los bloqueos mediante bucle sin fin (así como el mecanismo de activación y desactivación del desalojo del kernel) se usan en el kernel sólo cuando el bloqueo (o la desactivación del desalojo) se mantiene durante un período de tiempo corto. Cuando sea necesario mantener un bloqueo duran­ te un período de tiempo largo, resulta más apropiado utilizar semáforos.

6.8.4 Sincronización en Pthreads La API de Pthreads proporciona cerrojos mútex, variables de condición y cerrojos de lectura-escri­ tura para la sincronización de hebras. Esta API está disponible para los programadores y no forma parte de ningún kernel. Los cerrojos mútex representan la técnica fundamental de sincronización utilizada en Pthreads. Un cerrojo mútex se usa para proteger las secciones críticas de código, es decir, una hebra adquiere el cerrojo antes de entrar en una sección crítica y lo libera al salir de la misma. Las variables de condición en Pthreads se comportan como se ha descrito en la Sección 6.7. Los cerrojos de lectura-escritura se comportan de forma similar al mecanismo de bloqueo descri­ to en la Sección 6.6.2. Muchos sistemas que implementan Pthreads también proporcionan semá­ foros, aunque no forman parte del estándar Pthreads, sino que pertenecen a la extensión SEM de POSIX. Otras extensiones de la API de Pthreads incluyen cerrojos mediante bucle sin fin, aunque no todas las extensiones pueden portarse de una implementación a otra. Al final del capítulo se proporciona un proyecto de programación que usa cerrojos mútex y semáforos de Pthreads.

Transacciones atómicas La exclusión mutua de sección críticas asegura que éstas se ejecuten atómicamente. Es decir, si dos secciones críticas se ejecutan de forma concurrente, el resultado es equivalente a su ejecución secuencial en algún orden desconocido. Aunque esta propiedad resulta útil en numerosos domi­ nios de aplicación, en muchos casos desearíamos asegurarnos de que una sección crítica forme una sola unidad lógica de trabajo, que se ejecute por completo o que no se ejecute en absoluto. Un ejemplo sería una transferencia de fondos, en la que en una cuenta bancaria se anota un adeudo y en otra un abono. Evidentemente, es esencial para la coherencia de los datos que el adeudo y el abono se realicen ambos, o no se realice ninguno. El problema de la coherencia de los datos, junto con el del almacenamiento y la recuperación de los mismos, tiene una gran-importancia en los sistemas de bases de datos. Recientemente, ha resurgido el interés por el uso de las técnicas de los sistemas de bases de datos en los sistemas ope­ rativos. Los sistemas operativos pueden verse como manipuladores de datos; por tanto, pueden beneficiarse de las técnicas y modelos avanzados disponibles en las investigaciones sobre bases de datos. Por ejemplo, muchas de las técnicas ad hoc utilizadas en los sistemas operativos para ges­ tionar los archivos podrían ser más flexibles y potentes si en su lugar se emplearan métodos más formales extraídos del campo de las bases de datos. En las Secciones 6.9.2 a 6.9.4 describimos algu­ nas de estas técnicas de bases de datos y explicamos cómo pueden utilizarse en los sistemas ope­ rativos. No obstante, en primer lugar, vamos a ocuparnos del tema general de la atomicidad de transacciones. En esta propiedad se basan las técnicas utilizadas en las bases de datos.

6.9.1 Modelo del sistema Una colección de instrucciones (u operaciones) que realiza una sola función lógica se denomina transacción. Una cuestión importante en el procesamiento de transacciones es la conservación de la atomicidad, incluso en el caso de que se produzcan fallos dentro del sistema informático. Podemos pensar en una transacción como en una unidad de programa que accede a (y quizá actualiza) elementos de datos que residen en un disco, dentro de algunos determinados archivos. Desde nuestro punto de vista, una transacción es simplemente una secuencia de oper¿iCiOiiGS CiG

198

Capítulo 6 Sincronización de procesos

lectura (read) y escritura (write) que se termina bien con una operación de confirmación (co®| mit) o una operación de cancelación (ab o rt). Una operación corrcn.it significa que la transaccifi ha terminado su ejecución con éxito, mientras que una operación a b o rt indica que la transacció no ha podido terminar su ejecución de la forma normal, porque se ha producido un error lógic o un fallo del sistema. Si una transacción terminada ha completado su ejecución con éxito, se co firma; en caso contrario, se aborta. Dado que una transacción abortada puede haber modificado los datos a los que ha accedido! el estado de estos datos puede no ser el mismo que el que habrían tenido si la transacción se hubie-jf ra ejecutado atómicamente. Para poder garantizar la atomicidad, las transacciones abortadas rnP deben tener ningún efecto sobre el estado de los datos que ya haya modificádo. Por tanto, el estafí do de los datos a los que haya accedido una transacción abortada deben restaurarse al estado < que estaban antes de que la transacción comenzara a ejecutarse. Decimos entonces que tal trans-| acción ha sido anulada. Es responsabilidad del sistema garantizar esta propiedad. -i¡J < Para determinar cómo debe el sistema asegurar la atomicidad, necesitamos identificar en pri-:l? mer lugar las propiedades de los dispositivos utilizados para almacenar los datos a los que las j transacciones acceden. Podemos clasificar los diversos tipos de medios de almacenamiento aten-.1* diendo a su velocidad, su capacidad y su resistencia a los fallos. f • Almacenamiento volátil. La información que reside en los dispositivos de almacenamien- ‘ to volátiles normalmente no sobrevive a los fallos catastróficos del sistema. Como ejemplos i de este tipo de medios de almacenamiento podemos citar la memoria principal y la memo- I ria caché. El acceso a medios volátiles es extremadamente rápido, debido a la velocidad de acceso de la propia memoria y porque se puede acceder directamente a cualquier elemento de datos que se encuentre almacenado en dicho medio. Almacenamiento no volátil. La información que reside en los medios de almacenamiento no volátiles normalmente sobrevive a los fallos catastróficos del sistema. Como ejemplos de estos medios de almacenamiento podemos citar los discos y las cintas magnéticas. Los dis­ cos son más fiables que la memoria principal, pero menos que las cintas magnéticas. Sin embargo, tanto los discos como las cintas están sujetos a fallos, que pueden dar lugar a pér­ didas de información. Actualmente, el almacenamiento no volátil es más lento que el volá­ til en varios órdenes de magnitud, porque los dispositivos de disco y de cinta son electro­ mecánicos y requieren un movimiento físico para acceder a los datos. • Almacenamiento estable. La información que reside en los medios de almacenamiento estables minea se pierde (minea no debe tomarse en sentido absoluto, ya que en teoría esos absolutos no pueden garantizarse). Para tratar de aproximarnos a las características de este tipo de almacenamiento, necesitamos replicar la información en varias cachés de almacena­ miento no volátiles (normalmente, discos) con modos de fallo independientes y actualizar la información de una forma controlada (Sección 12.8). Aquí sólo vamos a ocupamos de asegurar la atomicidad de las transacciones en un entorno en el que los fallos provoquen una pérdida de la información contenida en los medios de almacena­ miento volátil.

6.9.2 Recuperación basada en registro Una forma de asegurar la atomicidad consiste en grabar en un dispositivo de almacenamiento estable la información que describa todas las modificaciones realizadas por la transacción en los distintos datos a los que haya accedido. El método más extendido para conseguir esta forma de protección es el registro de escritura anticipada (ivrite-ahead logging). En este caso, el sistema man­ tiene en un medio de almacenamiento estable una estructura de datos denominada registro. Cada entrada del registro describe una única operación de escritura de la transacción y consta de los campos siguientes: • Nombre de la transacción. El nombre unívoco de la transacción que realizó la operación de escritura (write).

6.9 Transacciones atómicas

•

199

N om b re del elem en to de datos. El nombre unívoco del elemento de datos escrito.

• V alo r an tigu o. El valor del elemento de datos antes de ejecutarse la operación de escritura. • N u evo valor.

El valor que el elemento de datos tendrá después de la operación de escri­

tura. Existen otras entradas de registro especiales que permiten registrar los sucesos significativos producidos durante el procesamiento de la transacción, como por ejemplo el inicio de una trans­ acción y la confirmación o cancelación de una transacción. Antes de que una transacción i inicie su ejecución, se escribe la entrada < T, s t a r t s > en el registro. Durante su ejecución, cualquier operación wr i ce de T¡ va precedida por la escritura de la correspondiente entrada nueva en el registro. Cuando T¡ se confirma, se escribe la entrada < T¡ commits> en el registro. Dado que la información contenida en el registro se utiliza para restaurar el estado de los ele­ mentos de datos a los que las distintas transacciones hayan accedido, no podemos permitir que la actualización de un elemento de datos tenga lugar antes de que se escriba la correspondiente entrada del registro en un medio de almacenamiento estable. Por tanto, es necesario que, antes de ejecutar una operación w r i t e ( X ) , las entradas del registro correspondientes a X se escriban en un medio de almacenamiento estable. Observe el impacto sobre el rendimiento que este sistema tiene: son necesarias dos escrituras físicas por cada escritura lógica solicitada. También se necesita más almacenamiento, para los pro­ pios datos y para guardar los cambios en el registro. Pero en aquellos casos en los que los datos sean extremadamente importantes y sea necesario disponer de mecanismos rápidos de recupera­ ción de fallos, la funcionalidad adicional que se obtiene bien merece el precio que hay que pagar por ella. Usando el registro, el sistema puede corregir cualquier fallo que no dé lugar a perdida de infor­ mación en un medio de almacenamiento no volátil. Él algoritmo de recuperación utiliza dos pro­ cedimientos: • undo(T,-), que restaura el valor de todos los datos actualizados por la transacción T¡ a sus antiguos valores. • redo(Tj), que asigna los nuevos valores a todos los datos actualizados por la transacción T,. En el registro pueden consultarse el conjunto de datos actualizados por T¡ y sus respectivos valores antiguos y nuevos. Las operaciones undo y redo deben ser idempotentes (es decir, múltiples ejecuciones deben dar el mismo resultado que una sola ejecución), para garantizar un comportamiento correcto incluso aunque se produzca un fallo durante el proceso de recuperación. Si una transacción T, se aborta, podemos restaurar el estado de los datos que se hayan actuali­ zado simplemente ejecutando undo(T,). Si se produce un fallo del sistema, restauraremos el esta­ do de todos los datos actualizados consultando el registro para determinar qué transacciones tienen que ser rehechas y cuáles deben deshacerse. Esta clasificación de las transacciones se hace del siguiente modo: • La transacción T¡ tiene que deshacerse si el registro contiene la entrada < T, s t a r t s > pero no contiene la entrada < T¡ coirur>ics>. • La transacción T¡ tiene que rehacerse si el registro contiene tanto la entrada < T¡ s t a r t s > como la entrada .

6.9.3 Puntos de comprobación Cuando se produce un fallo del sistema, debemos consultar el registro para determinar aquellas transacciones que necesitan ser rehechas y aquellas que tienen que deshacerse. En principio, nece­ sitamos revisar el registro completo para identificar todas las transacciones. Este método tiene, fundamentalmente, dos inconvenientes: -

200

Capítulo 6 Sincronización de procesos

1. El proceso de búsqueda consume mucho tiempo. 2. La mayor parte de las transacciones que, de acuerdo con nuestro algoritmo, va a haberSL rehacer ya habrán actualizado los datos que el registro indica que hay que modificar. Auiv? rehacer las modificaciones de los datos no causará ningún daño (gracias a la característica^ idempotencia), sí que hará que el proceso de recuperación tarde más tiempo. yj Para reducir esta carga de trabajo, introducimos el concepto de puntos de comprobad^ Durante la ejecución, el sistema se encarga de mantener el registro de escritura anticipa^ Además, el sistema realiza periódicamente puntos de comprobación, lo que requiere la siguient secuencia de acciones: 1. Enviar todas las entradas del registro que actualmente se encuentren en un medio de almj. cenamiento volátil (normalmente en la memoria principal) a un medio de almacenamiettl estable. 2. Enviar todos los datos modificados que residan en el medio de almacenamiento volátil a medio de almacenamiento estable. 3. Enviar una entrada de registro al almacenamiento estable. La presencia de una entrada en el registro permite al sistema simplificar s procedimiento de recuperación. Considere una transacción T¡ que se haya confirmado antes d punto de comprobación. La entrada < T, commits> aparecerá en el registro antes que la entrad . Cualquier modificación realizada por T¡ deberá haberse escrito en un medio d almacenamiento estable antes del punto de comprobación o como parte del propio punto de corr probación. Por tanto, en el momento de la recuperación, no hay necesidad de ejecutar una opera ción de rehacer (redo) sobre T¿. Esta observación nos permite mejorar nuestro anterior algoritmo de recuperación. Después c producirse un fallo, la rutina de recuperación examina el registro para determinar la transaccic T, más reciente que haya iniciado su ejecución antes de que tuviera lugar el punto de comprob: ción. Dicha transacción se localiza buscando hacia atrás en el registro la primera entrada , y localizando a continuación la siguiente entrada < T¡ start>. Una vez que se ha identificado la transacción T¡, las operaciones redo y undo se aplican sól a la transacción T¡ y a todas las transacciones T- que hayan comenzado a ejecutarse después de 7 Denominaremos a este conjunto de transacciones T. Podemos ignorar el resto del registro. L¿ operaciones de recuperación necesarias se llevan a cabo del siguiente modo: • Para todas las transacciones Tk de T en las que aparezca la entrada en registro, ejecutar redo(T¿.). • Para todas las transacciones Tk de T que no tengan la entrada en el registr ejecutar undo(T¿.).

6.9.4 Transacciones atómicas concurrentes Hemos estado considerando un entorno en el que sólo puede ejecutarse una transacción cada ve Ahora vamos a ver el caso en el haya activas simultáneamente varias transacciones. Dado qr cada transacción es atómica, la ejecución concurrente de transacciones debe ser equivalente al cas en que las transacciones se ejecuten en serie siguiendo un orden arbitrario. Esta propiedad, den minada señalización, se puede mantener simplemente ejecutando cada transacción dentro de ui sección crítica. Es decir, todas las transacciones comparten un semáforo miítex común, inicializ do con el valor 1. Cuando una transacción empieza a ejecutarse, su primera acción consiste en ej cutar la operación wait (mutex) . Aunque este esquema asegura la atomicidad de todas las transacciones que se estén ejecuta: do de forma concurrente, es bastante restrictivo. Como veremos, en muchos casos podemos pe mitir que las transacciones solapen sus operaciones, siempre que se mantenga la señalizado Para garantizar la señalización se utilizan distintos algoritmos de control de concurrencia, los cu. les'se describen a continuación.

6.9 Transacciones atómicas

6.9.4.1

201

S e ñ a liz a c ió n

Considere un sistema con dos elementos de datos, A y B, que dos transacciones T0 y Tj leen y escri­ ben. Suponga que estas dos transacciones se ejecutan atómicamente, primero T0 seguida de T¡. En la Figura 6.22 se representa esta secuencia de ejecución, la cual se denomina planificación. En la planificación 1 de la figura, la secuencia de instrucciones sigue un orden cronológico de arriba a abajo, estando las instrucciones de T0 en la columna izquierda y las de 7\ en la columna de la dere­ cha. Una planificación en la que cada transacción se ejecuta atómicamente se denomina planifica­ ción serie. Una planificación serie consta de una secuencia de instrucciones correspondientes a varias transacciones, apareciendo juntas todas las instrucciones que pertenecen a una determina­ da transacción. Por tanto, para un conjunto de n transacciones, existen ni planificaciones serie váli­ das diferentes. Cada planificación serie es correcta, ya que es equivalente a la ejecución atómica de las distintas transacciones participantes en un orden arbitrario. Si permitimos que las dos transacciones solapen su ejecución, entonces la planificación resul­ tante ya no será serie. Una planificación no serie no necesariamente implica una ejecución inco­ rrecta, es decir, una ejecución que no sea equivalente a otra representada por una planificación serie. Para ver que esto es así, necesitamos definir el concepto de operaciones conflictivas. Considere una planificación S en la que hay dos operaciones consecutivas O, y 0 ; de las trans­ acciones T¡ y Tj, respectivamente. Decimos que O, y Oj son conflictivas si acceden al mismo elemen­ to de datos y al menos una de ellas es una operación de escritura. Para ilustrar el concepto de operaciones conflictivas, consideremos la planificación no serie 2 mostrada en la Figura 6.23. La operación write(A) de T0 está en conflicto con la operación read(A) de T\. Sin embargo, la ope­ ración write(A) de no está en conflicto con la operación r ead(B) de T0, dado que cada operación accede a un elemento de datos diferente. Sean 0¡ y O, operaciones consecutivas de una planificación S. Si O, y O. son operaciones de transacciones diferentes y no están en conflicto, entonces podemos intercambiar el orden de O, y T0

Ti

read(A) write(AJ read(B) write(B) read(A) write(A) read(B) write(B)

Figura 6.22

Planificación

1: una planificación serie en la que T0 va seguida de T,. T0 read(A) write(A)

Ti

read(A) write(A) read(B) write(B) read(B) write(B)

Figura 6.23

Planificación 2: planificación serializable concurrente.

202

Capítulo 6 Sincronización de procesos

Oj para generar una nueva planificación S '. Cabe esperar que S y S ' sean equivalentes, ya1 todas las operaciones aparecen en el mismo orden en ambas planificaciones, excepto 0 ¿y Oorden no importa. ¡g Podemos ilustrar la idea del intercambio considerando de nuevo la planificación 2 mostrad la Figura 6.23. Como la operación wri te(A) de no entra en conflicto con la operación reacj de T0, podemos intercambiar estas operaciones para generar una planificación equivalí Independientemente del estado inicial del sistema, ambas planificaciones dan lugar al estado final. Continuando con este procedimiento de intercambio de operaciones no conflicto tenemos: • Intercambio de la operación read ( B ) de T0 con la operación read ( A t de Tv • Intercambio de la operación write (B) de T0 con la operación write (AS de T1. • Intercambio de la operación write (J3) de T0 con la operación read (A de Tv El resultado final de estos intercambios es la planificación 1 de la Figura 6.22, que es una pl¡ nificación serie. Por tanto, hemos demostrado que la planificación 2 es equivalente a una pía cación serie. Este resultado implica que, independientemente del estado inicial del sistema,! planificación 2 producirá el mismo estado final que una planificación serie. Si una planificación S se puede transformar en una planificación serie S' mediante un conjurff to de intercambios de operaciones no conflictivas, decimos que la planificación S es serializabl¿ con respecto a los conflictos. Por tanto, la planificación 2 es serializable con respecto a los confli W-timestamp() entonces la operación reaá se ejecuta y a R-timestamp(Q) sejH asigna el máximo de R-timestamp(Q) y TS(T¿).

• Suponga que la transacción T¡ ejecuta la instrucción vvrics(Q): o Si TS(7j) < R-timestamp(), entonces el valor de Q que T¡ está generando era necesaiwB anteriormente y T¡ supuso que este valor nunca se generaría. Por tanto, la operaciájB de escritura se rechaza y la transacción T¡ se anula. ,^ 3 o Si TS(T,) < W-timestamp(), entonces T¡ está intentando escribir un valor obsoleto de Q¡3

Por tanto, la operación de escritura se rechaza y T¡ se anula. o

En cualquier otro caso, se ejecuta la operación de escritura write.

A unatransacción T¡ que se anula como resultado de la ejecución de una operación de lectura® o deescritura se le asigna una nueva marca temporal y se reinicia. j| Para ilustrar este protocolo, considere la planificación 3 mostrada en la Figura 6.24, que indu|| ye las transacciones T2 y T3. Suponemos que a cada transacción se le asigna una marca témpora^ inmediatamente antes de su primera instrucción. Por tanto, en la planificación 3, TS(T2) < TS(T3)^ y la planificación es posible usando el protocolo de marcas temporales. -d Esta ejecución también puede generarse utilizando el protocolo de bloqueo en dos fases. Six^i embargo, algunas planificaciones son posibles con el protocolo de bloqueo en dos fases pero nó con el protocolo de marcas temporales, y viceversa. El protocolo de marcas temporales asegura la serialización con respecto a los conflictos. Esta característica se sigue del hecho de que las operaciones conflictivas se procesan siguiendo el orden de las marcas temporales. El protocolo también asegura que no se produzcan interbloqueos, dado que ninguna transacción tiene nunca que esperar.

6.10 Resumen Dada una colección de procesos secuenciales cooperativos que compartan datos, es necesario pro­ porcionar mecanismos de exclusión mutua. Una solución consiste en garantizar que una sección crítica de código sólo sea utilizada por un proceso o hebra cada vez. Existen diferentes algoritmos para resolver el problema de la sección crítica, suponiendo que sólo haya disponibles bloqueos del almacenamiento. La principal desventaja de estas soluciones codificadas por el programador es que todas ellas requieren una espera activa. Los semáforos permiten resolver este problema. Los semáforos se pueden emplear para solucionar varios problemas de sincronización y se pueden implementar de forma eficiente, especialmente si se dispone de soporte hardware para ejecutar las operaciones atómicamente. Clásicamente, se han definido diversos problemas de sincronización (como el problema del búfer limitado, el problema de losprocesos lectores-escritores, v el problema de la cena de los filó­ sofos) que son importantes principalmente como ejemplos de una amplia dase de problemas de control de concurrencia. Estos problemas clásicos se utilizan para probar casi todos los nuevos esquemas de sincronización propuestos.

Ejercicios

205

El sistema operativo debe proporcionar los medios de protección frente a los errores de temporización. Se han propuesto diversas estructuras para afrontar estos problemas. Los monitores proporcionan mecanismos de sincronización para compartir tipos abstractos de datos. Las varia­ bles de condición proporcionan un método mediante el que un procedimiento de un monitor puede bloquear su ejecución hasta recibir la señal de que puede continuar. Los sistemas operativos también proporcionan soporte para la sincronización. Por ejemplo, Solaris, Windows XP y Linux proporcionan mecanismos como semáforos, mútex, bloqueos mediante bucles sin fin y variables de condición para controlar el acceso a datos compartidos. La API de Pthreads proporciona soporte para bloqueos mútex y variables de condición. Una transacción es una unidad de programa que se debe ejecutar atómicamente; es decir, todas las operaciones asociadas con ella se ejecutan hasta completarse, o no se ejecuta ninguna de las operaciones. Para asegurar la atomicidad a pesar de los fallos del sistema, podemos usar un regis­ tro de escritura anticipada. Todas las actualizaciones se escriben en el registro, que se almacena en un medio de almacenamiento estable. Si se produce un fallo catastrófico del sistema, la informa­ ción contenida en el registro se usa para restaurar el estado de los elementos de datos actualiza­ dos, lo que se consigue a través de las operaciones de deshacer (undo) y rehacer (redo). Para disminuir el trabajo de buscar en el registro después de haberse producido un fallo del sistema, podemos usar un mecanismo de puntos de comprobación. Para asegurar la señalización cuando se solapa la ejecución de varias transacciones, debemos emplear un esquema de control de concurrencia. Hay diversos esquemas de control de concurren­ cia que aseguran la señalización retardando una operación o cancelando la transacción que ejecu­ tó la operación. Los métodos más habitualmente utilizados son los protocolos de bloqueo y los esquemas de ordenación mediante marcas temporales.

Ejercicios 6.1

Dekker desarrolló la primera solución software correcta para el problema de la sección crí­ tica para dos procesos. Los dos procesos, P0 y Pv comparten las variables siguientes: boolean flag[2]; /* inicialmente falso */ int turn; La estructura del proceso P, (i == 0 o 1) se muestra en la Figura 6.25; el otro proceso es Py (j== 1 o 0). Demostrar que el algoritmo satisface los tres requisitos del problema de la sec­ ción crítica. do { flag[i] = IRUS; while (flag[j]) { if (turn == j) { flagfi] = false; while (turn == j) ; // no hacer nada flagfij = TRUE; } } // sección crítica turn = j ; flag[i] = FALSE; //' sección rascante }while (TRUE);

Figura

6.25

Estructura del proceso P, en el algoritm o de Dekker.

206

Capítulo 6 Sincronización de procesos

6.2

Eisenberg y McGuire presentaron la primera solución software correcta para el problema!®* la sección crítica para n procesos, con un límite máximo de espera de n - 1 tumos. Los cesos comparten las siguientes variables: ¿A gg

enum pstate {idle, wanc_in, in_cs}; pstate flag [n] ; f int turn;

n#Todos los elementos de flag tienen inicialmente el valor idle; el valor inicial de turneé irrelevante (entre 0 y n-1 ). La estructura del proceso P, se muestra en la Figura 6.26.-* Demostrar que el algoritmo satisface los tres requisitos del problema de la sección crítica. 6.3

¿Cuál es el significado del término espera activa? ¿Qué otros tipos de esperas existen en m sistema operativo? ¿Puede evitarse de alguna manera la espera activa? Explique su respues- s % ta.

6.4

Explique por qué los bloqueos mediante bucle sin fin no son apropiados para sistemas ! monoprocesador, aunque se usen con frecuencia en los sistemas multiprocesador. g do { while (TRUE) { flagfi] = want in; j = turn; while (j != i) { if (fiag[j] != idle) j = turn; else j = (j + 1) % n; }

{

flag[i] = in es; j = C; while ! (j < n) && (j == i i' flagfj]

if ( G >= n) break;

(turn == i ■■

!= in es) )

flagfturn] == idle) )

} // sección crítica j = (turn - 1) % n; while (ílag[j] == idle) j = íj - 1 ’ % n; turn = j; flag[i] = idle; // sección restante ;w m l e

{11^-z. ■;

Figura 6.26 Estructura del proceso P, en el algoritmo de Eisenberg y McGuire.

Ejercicios

207

6.5

Explique por qué la implementación de primitivas de sincronización desactivando las inte­ rrupciones no resulta apropiada en un sistema monoprocesador si hay que usar las primi­ tivas de sincronización en programas de nivel de usuario.

6.6

Explique por qué las interrupciones no son apropiadas para ímplementar primitivas de sin­ cronización en los sistemas multiprocesador.

6.7

Describa cómo se puede utilizar la instrucción swap () para proporcionar un mecanismo de exclusión mutua que satisfaga el requisito de espera limitada.

6.8

Los servidores pueden diseñarse de modo que limiten el número de conexiones abiertas. Por ejemplo, un servidor puede autorizar sólo N conexiones simultáneas de tipo socket. En cuanto se establezcan las N conexiones, el servidor ya no aceptará otra conexión entrante hasta que una conexión existente se libere. Explique cómo puede utilizar un servidor los semáforos para limitar el número de conexiones concurrentes.

6.9

Demuestre que si las operaciones wait que ejecuta la instrucción espere hasta que B tome el valor t r u e . a. Escriba un monitor utilizando este esquema para implementar el problema de los procesos lectores-escritores. b. Explique por qué esta estructura no puede, en general, implementarse de manera eficiente. c. ¿Qué restricciones hay que incluir en la instrucción await para poder implementarla de forma eficiente? (Consejo: restrinja la generalidad de B; consulte Kessels [1997])

6.22

Escriba un monitor que implemente un reloj alarma que permita al programa llamante retar­ darse un número específico de unidades de tiempo (ticks). Puede suponer que existe un reloj hardware real que invoca un procedimiento tick del monitor a intervalos regulares.

6.23

¿Por qué Solaris, Linux y Windows 2000 utilizan bloqueos mediante bucle sin fin como mecanismo de sincronización sólo en los sistemas multiprocesador y no en los sistemas de un solo procesador?

6.24

En los sistemas basados en registro que proporcionan soporte para transacciones, la actua­ lización de elementos de datos no se puede realizar antes de que las entradas correspon­ dientes se hayan registrado. ¿Por qué es necesaria esta restricción?

6.25

Demuestre que son posibles algunas planificaciones con el protocolo de bloqueo en dos fases pero no con el protocolo de ordenación mediante marcas temporales, y viceversa.

6.26

¿Cuáles son las implicaciones de asignar una nueva marca temporal a una transacción que se ha anulado? ¿Cómo procesa el sistema las transacciones que se han ejecutado después de una transacción anulada pero que tienen marcas temporales más pequeñas que la nueva marca temporal de la transacción anulada?

6.27

Suponga que existe un número finito de recursos de un mismo tipo que hay que gestionar. Los procesos pueden pedir una cantidad de estos recursos y, una vez que terminen con ellos, devolverlos. Por ejemplo, muchos paquetes comerciales de software operan usando un número fijo de licencias, que especifica el número de aplicaciones que se pueden ejecu­ tar de forma concurrente. Cuando se inicia la aplicación, el contador de licencias se decrementa. Si todas las licencias están en uso, las solicitudes para iniciar la aplicación se denie­ gan. Tales solicitudes sólo serán concedidas cuando el usuario de una de las licencias termi­ ne la aplicación y devuelva la licencia. El siguiente segmento de programa se usa para gestionar un número finito de instancias de un recurso disponible. El número máximo de recursos y el número de recursos disponibles se declaran como sigue: Sdefine MAX_RESOURCES 5 int recursos_disponib!es = MAX_RESOURCES;

Cuando un proceso desea obtener una serie de recursos, invoca la función decrease_ count(): /* decrementa recursos_disponibles en count recursos */ /* devuelve 0 si hay suficientes recursos disponibles, */ /* en caso contrario, devuelve -1 */ int decrease_count (ir.t count) { i f (recursos_disponibles < count)

Ejercicios

209

return -i; else { recursos_disponibles -= count; return 0; } } Cuando un proceso desea devolver una serie de recursos, llama a la función increase_ count(): /* incrementa recursos_disponibles en count */ ■int increase_count(int count) { recursos_disponibles i-= count; return 0; } El segmento de programa anterior da lugar a una condición de carrera. Haga lo siguien­ te: a. Identifique los datos implicados en la condición de carrera. b. Identifique la ubicación (o ubicaciones) en el código donde se produce la condición de carrera. c. Utilice un semáforo para resolver la condición de carrera. 6.28

La función d e cre a se _ co u n t () del ejercicio anterior actualmente devuelve 0 si hay sufi­ cientes recursos disponibles y -1 en caso contrario. Esto lleva a un estilo de programación complicado para un proceso que desee obtener una serie de recursos: while (decrease_count(count) == -1) Reescriba el segmento de código del gestor de recursos usando un monitor y variables de condición, de modo que la función aecrease_count () suspenda el proceso hasta que haya disponibles suficientes recursos. Esto permitirá a un proceso invocar la función decrease_count () así: decrease_cour.t (count) ; El proceso sólo volverá de esta llamada a función cuando haya suficientes recursos dispo­ nibles.

Proyecto: problem a del productor-consum idor En la Sección 6.6.1 hemos presentado una solución basada en semáforos para el problema de los procesos productor-consumidor usando un búfer limitado. Este proyecto va a diseñar una solu­ ción software para el problema del búfer limitado usando los procesos productor-consumidor mostrados en las figuras 6.10 y 6.11. La solución presentada en la Sección 6.6.1 utiliza tres semá­ foros: empty y full, que contabilizan el número de posiciones vacías y llenas en el búfer , v mutex, que es un semáforo binario (o de exclusión mutua) que protege la propia inserción o eli­ minación de elementos en el búfer. En este proyecto, se utilizarán para empty y full semáforos contadores estándar y, en lugar de un semáforo binario, se empleará un cerrojo mútex para repre­ sentar a mutex. El productor y el consumidor, que se ejecutan como hebras diferentes, introduci­ rán y eliminarán elementos en un búfer que se sincroniza mediante estas estructuras empty, full y mutex. Puede resolver este problema usando la API Pthreads o Win32.

210

Capítulo 6 Sincronización de procesos

E l b ú fe r

Internamente, el búfer consta de un array de tamaño fijo de tipo buf fer_item (que se definí usando typefdef). El array de buf fer_item objetos se manipulará como una cola circular, definición de buf fer_item, junto con el tamaño del búfer, puede almacenarse en el archivo cabecera como sigue: /* buffer.h */ typedef int buffer_item; #define 3UFFER_SZZZ 5 El búfer se manipulará mediante dos funciones, insert_item () y remove_item (), a las quellaman los procesos productor y consumidor, respectivamente. Un esqueleto de estas funciones eí el siguiente: #include /* el búfer */ buf fer__item buf fer [3UFFER_SIZE] ; int insert_item(buffer_item item) { /* insertar el elemento en el búfer devuelve 0 si se ejecuta con éxito, en caso contrario devuelve -1 indicando una condición de error */' } int remove_itemíbuífer_item *item) { /* eliminar un objeto del búfer colocándolo en la variable item devuelve 0 si se ejecuta con éxito, en caso contrario devuelve -1 indicando una condición de error */ } Las funciones insert_icem {) y remove_item () sincronizarán al productor y al consumi­ dor usando los algoritmos descritos en las Figuras 6.10 y 6.11. El búfer también requerirá una fun­ ción de inicialización que inicialice el objeto de exclusión mutua mutex junto con los semáforos emptyyfull. La función main () inicializará el búfer y creará las hebras consumidora y productora. Una vez creadas las hebras consumidora y productora, la función main () dormirá durante un período de tiempo y, al despertar, terminará la aplicación. A la función main () se le pasan tres parámetros a través de la línea de comandos: 1. Cuánto tiempo dormirá antes de terminar. 2. El número de hebras productoras. 3. El número de hebras consumidoras. Un esqueleto para esta función sería #include int mair.íint "arce, char *argvíjJ í /* 1 . /* /* 2 . /* 3 . /' * 4

Obtener argumentos de la linea de comandos argv[l], argv'2A argv[2; '' Inicialrzar búfer *■ Crear hebra(s) productora */' crear .ierra ís ) consumidora */

Ejercicios

211

/* b . Dormir */ /* 6. Salir */ } Hebras productora y consum idora

La hebra productora alternará entre dormir durante un período de tiempo aleatorio e insertar un entero aleatorio en el búfer. Los números aleatorios se generarán usando la función rand (), que genera enteros aleatorios ente 0 y RAND_MAX. El consumidor también dormirá durante un perío­ do de tiempo aleatorio y, al despertar, intentará eliminar un elemento del búfer. Un esquema de las hebras consumidora y productora sería el siguiente: #include /* requerido para rand() */ #include void *producer(void *param) { buffer_item rand; while (TRUE) { /* dormir durante un período de tiempo aleatorio */ sleep(...); /* generar un número aleatorio */ rand = rand(); printf ("productor ha producido %f\n",rand) if (insert_item(rand)) fprintf("informar de condición de error"); } void ‘consumer(void *param) ~ buffer_icem rand;

{

while (TRUE) { /* dormir durante un período de tiempo aleatorio */ sleep(...); if {remove_.item (&rand) ) iprintf("informar de condición de error " ; else printf("consumidor ha consumido %f\n",ratá!; -- } En las siguientes secciones vamos a ver detalles específicos de las implementaciones Pthreads y Win32. Creación de hebras en Pthreads

En el Capítulo 4 se cubren los detalles sobre la creación de hebras usando la API de Pthreads. Consulte dicho capítulo para ver las instrucciones específicas para crear el productor y el consu­ midor usando Pthreads. Bloqueos mútex de Pthreads

El siguiente ejemplo de código ilustra cómo se pueden usar en la API de Pthreads los bloqueos mútex para proteger una sección crítica: #include pt.hread_iT.ucex_t mutex;

212

Capítulo 6 Sincronización de procesos

/* crear el cerrojo mútex */ pthread_mutex_init (¿mutex,NULL) ; /* adquirir el cerrojo mútex */ pthread_mutex_lock(¿mutex); /*** sección crítica ***/ /* liberar el cerrojo mútex */ pthread_mutex_unlock(¿mutex) ;

i Pthreads utiliza el tipo de datos pthread_mutex_t para los bloqueos mútex. Un mútex sel crea con la función pthread_mutex_init (¿mutex,NULL), siendo el primer parámetro uní puntero al mútex. Pasando NULL como segundo parámetro, inicializamos el mútex con sus atri­ butos predeterminados. El mútex se adquiere y libera con las funciones pthread_mutex__ lock () y pthread_mutex_unlock (). Si el cerrojo mútex no está disponible cuando se invoca pchread_mutex_lock ( ) , la hebra llamante se bloquea hasta que el propietario invoca la fun­ ción pthread_mutex_unlock í). Todas las funciones mútex devuelven el valor 0 si se ejecutan correctamente; si se produce un error, estas funciones devuelven un código de error distinto de 0. Semáforos de Pthreads Pthreads proporciona dos tipos de semáforos, nominados y no nominados. En este proyecto, usa­ remos semáforos no nominados. El código siguiente ilustra cómo se crea un semáforo: #include sem t sem;

/* Crear el semáforo e inicializarlo en 5 */ sem_init(¿sem, 0, 5);

La función sem_i ni t () crea e inicializa un semáforo. A esta función se le pasan tres paráme­ tros: (1) un puntero al semáforo, (2) un indicador que señala el nivel de compartición y (3) el valor inicial del semáforo. En este ejemplo, pasando el indicador 0, estamos señalando que este semáfo­ ro sólo puede ser compartido entre hebras que pertenezcan al mismo proceso que creó el semáfo­ ro. Un valor distinto de cero permitiría que otros procesos accedieran también al semáforo. En este ejemplo hemos inicializado el semáforo con el valor 5. En la Sección 6.5 hemos descrito las operaciones clásicas wai t {) y s i g n a l () de los semáfo­ ros. En Pthreads, las operaciones w a i t ( ) y s i g n a l () se denominan, respectivamente, sem_wait () y serr._post (). El ejemplo de código siguiente crea un semáforo binario mutex con un valor inicial de 1 e ilustra su uso para proteger una sección crítica: #include sem_t sem meeex; /* crear el semáfere */' sem_init (¿mutex, C, 1); /* adquirir el serái ero */ sem_waití¿mutex); /*** sección cirxt-ic3. ***/ /* liberar el semáforo */ sem_posc(¿mutex);

Ejercicios

213

Win32

Los detalles sobre la creación de hebras usando la API de Win32 están disponibles en el Capítulo 4. Consulte dicho capítulo para ver las instrucciones específicas. Bloqueos mútex de Win32 Los bloqueos mútex son un tipo de objeto despachador, como se ha descrito en la Sección 6.8.2. A continuación se muestra cómo crear un cerrojo mútex usando la función CreateMutex () . tfinclude HANDLE Mutex; Mutex = CreateMucex(NULL,

FALSE, NULL);

El primer parámetro hace referencia a un atributo de seguridad del cerrojo mútex. Estableciendo este parámetro como NULL, impediremos que cualquier hijo del proceso que crea el cerrojo mútex herede el descriptor del mútex. El segundo parámetro indica si el creador del mútex es el propietario inicial del cerrojo mútex. Pasar el valor FALSE indica que la hebra que crea el mútex no es el propietario inicial del mismo; en breve veremos cómo adquirir los bloqueos mútex. Por último, el tercer parámetro permite dar un nombre al mútex. Sin embargo, dado que hemos especificado el valor NULL, no damos un nombre al mútex en este caso. Si se ejecuta con éxito, CreateMutex () devuelve un descriptor HANDLE del cerrojo mútex; en caso contrario, devuelve NULL. En la Sección 6.8.2 hemos clasificado los objetos despachadores como señalizados y no señaliza­ dos. Un objeto señalizado estará disponible para su adquisición; una vez que se adquiere un obje­ to despachador (por ejemplo, un cerrojo mútex), el objeto pasa al estado no señalizado. Cuando el objeto se libera, vuelve al estado señalizado. Los cerrojos mútex se adquieren invocando la función WaitForSingleObj ect (), pasando a la función el descriptor HANDLE del cerrojo y un indicador para especificar cuánto tiempo se va a esperar. El siguiente código muestra cómo se puede adquirir el cerrojo mútex creado anterior­ mente: WaitForSingleObject(Mutex,

INFINITE);

El parámetro INFINITE indica que se esperará durante un período de tiempo infinito a que el cerrojo esté disponible. Se pueden usar otros valores que permiten que la hebra llamante deje de esperar si'él cerrojo no pasa a estar disponible dentro de una franja de tiempo especificada. Si el cerrojo se encuentra en estado señalizado, Wait.ForSingleObject () vuelve inmediatamente y el cerrojo pasa a estado no señalizado. Un cerrojo se libera (pasa al estado señalizado) invocando ReleaseMutex como sigue: ReleaseMutex(Mucex);

Semáforos de Win32 Los semáforos en la API de Win32 también son objetos despachadores y por tanto utilizan el mismo mecanismo de señalización que los bloqueos mútex. Los semáforos se crean de la forma siguiente: #include HANDLE Sera; Sera = CreateSeraaphore (NULL,

1, 5, NULL) , -

El primer y el último parámetros especifican un atributo de seguridad y el nombre del semá­ foro, de forma similar a como se ha descrito para los cerrojos mútex. El segundo y tercer paráme­

tros especifican el valor inicial y el valor máximo del semáforo. En este caso, el valor inicial del semáforo es 1 y su valor máximo es 5. Si se ejecuta satisfactoriamente, CreateSemaphore () devuelve un descriptor, HANDLE, del cerrojo mútex; en caso contrarío, devuelve NULL.

214

Capítulo 6 Sincronización de procesos

Los semáforos se adquieren usando la misma función WaitForSingleOb ject () que los ble queos mútex. El semáforo Sera creado en este ejemplo se adquiere con la instrucción: WaitForSingleObject(Semaphore, INFINITE);

’

Si el valor del semáforo es > 0, el semáforo está en estado señalizado y por tanto será adquirí do por la hebra llamante. En caso contrario, la hebra llamante se bloquea indefinidamente, ya qujl hemos especificado INFINITE, hasta que el semáforo pase al estado señalizado. El equivalente de la operación signalQ en los semáforos de Win32 es la función! ReleaseSemaphore (). Se pasan tres parámetros a esta función: (1) el descriptor (HANDLE) delJ semáforo, (2) la cantidad en que se incrementa el valor del semáforo y (3) un puntero al valor ante-;! rior del semáforo. Podemos incrementar Sem en 1 con la siguiente instrucción: M ReleaseSemaphore(Sem, 1, NULL;;

^ m Tanto ReleaseSemaphore () como ReleaseMutex () devuelven 0 si se ejecutan con éxito;*? en caso contrario, devuelven un valor distinto de cero.

Notas bibliográficas

-•ss

Los algoritmos de exclusión mutua fueron tratados por primera vez en los clásicos documentos de Dijkstra [1965], Los algoritmos de Dekker (Ejercicio 6.1), la primera solución software correcta» al problema de exclusión»mutua de dos procesos, fue desarrollada por el matemático alemán T.| Dekker. Este algoritmo también fue estudiado en Dijkstra [1965], Una solución más sencilla al pro-* blema de exclusión mutua de dos procesos ha sido presentada por Peterson [1981] (Figura 6.2). Dijkstra [1965b] presentó la primera solución al problema de la exclusión mutua para n proce-» sos. Sin embargo, esta solución no establecía un límite superior para la cantidad de tiempo que un J proceso tiene que esperar antes de que pueda entrar en la sección crítica. Knuth [1966] presentó e l' primer algoritmo con un límite; este límite era 2" turnos. Una mejora del algoritmo de Knuth hecha por Debruijn [1967] redujo el tiempo de espera a n2 tumos, después de lo cual Eisenberg [1972] (Ejercicio 6.4) consiguió reducir el tiempo al límite mínimo de n—1 turnos. Otro algoritmo que también requiere n—1 turnos pero más sencillo de programar y comprender, es el algoritmo de la panadería, que fue desarrollado por Lamport [1974], Burns [1978] desarrolló el algoritmo de solución hardware que satisface el requisito de tiempo de espera limitado. Explicaciones generales sobre el problema de exclusión mutua se proporcionan en Lamport [1986] y Lamport [1991], Puede ver una colección de algoritmos para exclusión mutua en Raynal [1986]. El concepto de semáforo fue introducido por Dijkstra [1965a]. Patil [1971] examinó la cuestión de si los semáforos podrían resolver todos los posibles problemas de sincronización. Pamas [1975] estudió algunos de los defectos de los argumentos de Patil. Kosaraju [1973] continuó con el traba­ jo de Patil, enunciando un problema que no puede resolverse mediante las operaciones wait {) y signal (). Lipton [1974] se ocupa de las limitaciones de distintas primitivas de sincronización. Los problemas clásicos de coordinación de procesos que hemos descrito son paradigmas de una amplia clase de problemas de control de concurrencia. El problema del búfer limitado, el pro­ blema de la cena de los filósofos y el problema del barbero dormilón (Ejercicio 6.11) fueron suge­ ridos por Dijkstra [1965a] y Dijkstra [1971], El problema de los lectores-escritores fue sugerido por Courtois [1971], En Lamport [1977] se trata el tema de las lecturas y escrituras concurrentes. El problema de sincronización de procesos independientes se aborda en Lamport [1976]. El concepto de la región crítica fue sugerido por Hoare [1972] y Brinchhansen [1972]. El con­ cepto de monitor fue desarrollado por Brinchhansen [1973]. Hoare [1974 ] proporciona una des­ cripción completa de monitor. Kessels [1977] propuso una extensión del concepto de monitor para permitir la señalización automática. En Ben-Ari [1990] y Birrell [1989] se ofrece información gene­ ral sobre la programación concurrente. La optimización del rendimiento y el bloqueo de primitivas se han tratado en muchos trabajos, como Lamport [1987], Mellor-Crummey y Scott [1991] y Anderson [1990]. El uso de objetos com­ partidos que no requiere utilizar secciones críticas se ha estudiado en Herlihy [1993], Bershad

Notas bibliográficas

215

[1993] y Kopetz y Reisinger [1993], En trabajos como Culler et al. [199S], Goodman et al. [1989], Barnes [1993] y Herlihy y Moss [1993] se han descrito nuevas instrucciones hardware y su utiliza­ ción en la implementación de primitivas de sincronización. Algunos detalles sobre los mecanismos de bloqueo utilizados en Solaris se presentan en Mauro y McDougall [2001]. Observe que los mecanismos de bloqueo utilizados por el kemel se implementan también para las hebras del nivel de usuario, por lo que los tipos de bloqueos están disponi­ bles dentro y fuera del kernel. En Solomon y Russinovich puede encontrar detalles sobre la sincronización en Windows 2000. El esquema de registro de escritura anticipada fue presentado por primera vez en System R de Gray et al. [1981], El concepto de serialización fue formulado por Eswaran et al. [1976] en relación con su trabajo sobre control de concurrencia en System R. Eswaran et al. [1976] se ocupa del pro­ tocolo de bloqueo en dos fases. El esquema de control de concurrencia basado en marcas tempo­ rales se estudia en Reed [1983], Una exposición sobre diversos algoritmos de control de concurrencia basados en marcas temporales es la presentada por Bernstein y Goodman [1980].

cAorruLo

interbloqueos En un entorno de multiprogramación, varios procesos pueden competir por un número finito de recursos. Un proceso solicita recursos y, si los recursos no están disponibles en ese momento, el proceso pasa al estado de espera. Es posible que, algunas veces, un proceso en espera no pueda nunca cambiar de estado, porque los recursos que ha solicitado estén ocupados por otros proce­ sos que a su vez estén esperando otros recursos. Cuando se produce una situación como ésta, se dice que ha ocurrido un interbloqueo. Hemos hablado brevemente de esta situación en el Capítulo 6, al estudiar el tema de los semáforos. Quizá la mejor forma de ilustrar un interbloqueo es recurriendo a una ley aprobada a princi­ pios del siglo XX en Kansas, que decía: “Cuando dos trenes se aproximen a la vez a un cruce, ambos deben detenerse por completo y ninguno arrancará hasta que el otro haya salido”. En este capítulo, vamos a describir los métodos que un sistema operativo puede emplear para impedir o solventar los interbloqueos. La mayoría de los sistemas operativos actuales no propor­ cionan facilidades para la prevención de interbloqueos, aunque probablemente se añadan pronto dichos mecanismos. Los problemas de interbloqueo cada vez van a ser más habituales dadas las tendencias actuales: el gran número de procesos, el uso de programas multihebra, la existencia de muchos más recursos dentro de un sistema y la preferencia por servidores de archivos y bases de datos con transacciones de larga duración, en sustitución de los sistemas de procesamiento por lotes.

OBJETIVOS DEL CAPÍTULO • Describir los interbloqueos, que impiden que un conjunto de procesos concurrentes completen sus tareas. • Presentar una serie de métodos para prevenir o evitar los interbloqueos en un sistema informá­ tico.

7.1

Modelo de sistema Un sistema consta de un número finito de recursos, que se distribuyen entre una serie de proce­ sos en competición. Los recursos se dividen en varios tipos, constando cada uno de ellos de un cierto número de instancias. El espacio de memoria, los ciclos de CPU, los archivos y dispositivos de E/S (como impresoras y unidades de DVD) son ejemplos de tipos de recursos. Si un sistema tiene dos CPU, entonces el tipo de recurso CPU tiene dos instancias. De forma similar, el tipo de recurso impresora puede tener cinco instancias distintas. Si un proceso solicita una instancia de un tipo de recurso, la asignación de cualquier instancia del tipo satisfará la solicitud. Si no es así, quiere decir que las instancias no son idénticas y, por tanto, los tipos de recursos no se han definido apropiadamente. Por ejemplo, un sistema puede 217

218

Capítulo 7 Interbloqueos

disponer de dos impresoras. Puede establecerse que estas dos impresoras pertenezcan a un i tipo de recurso si no importa qué impresora concreta imprime cada documento de salida, embargo, si una impresora se encuentra en el noveno piso y otra en el sótano, el personal del i no piso puede no considerar equivalentes ambas impresoras y puede ser necesario, por definir una clase de recurso distinta para cada impresora. Un proceso debe solicitar cada recurso antes de utilizarlo y debe liberarlo después de usad Un proceso puede solicitar tantos recursos como necesite para llevar a cabo las tareas que teii asignadas. Obviamente, el número de recursos solicitados no puede exceder el total de recur disponibles en el sistema: en otras palabras, un proceso no puede solicitar tres impresoras si el tema sólo dispone de dos. En modo de operación normal, un proceso puede emplear un recurso sólo siguiendo secuencia: 1. Solicitud. Si la solicitud no puede ser concedida inmediatamente (por ejemplo, si el re so está siendo utilizado por otro proceso), entonces el proceso solicitante tendrá que espera S ^ hasta que pueda adquirir el recurso. |g¡

2. Uso. El proceso puede operar sobre el recurso (por ejemplo, si el recurso es una impresora/* * el proceso puede imprimir en ella). 3. Liberación. El proceso libera el recurso. La solicitud y liberación de los recursos son llamadas al sistema-/ como se ha explicado en el Capítulo 2. Como ejemplos de llamadas al sistema tendríamos la solicitud y liberación de dispo-' sitivos [re q u e st () y r e l e a s e () ], la apertura y cierre de archivos [open () y c i ó s e () ] y la asignación y liberación de memoria [ a l l o c a t e () y f re e () ]. La solicitud y liberación de los recursos que el sistema operativo no gestiona puede hacerse mediante las operaciones wai t () y s ig n a l () de los semáforos, o a través de la adquisición y liberación de un cerrojo mútex. Cada vez que un proceso o una hebra emplea un recurso gestionado por el kemel, el sistema operativo comprueba que el proceso ha solicitado el recurso y que éste ha sido asignado a dicho proceso. Una tabla del sistema registra si cada recurso está libre o ha sido asignado; para cada recurso asig­ nado, la tabla también registra el proceso al que está asignado actualmente. Si un proceso solicita un recurso que en ese momento está asignado a otro proceso, puede añadirse a la cola de proce­ sos en espera para ese recurso. Un conjunto de procesos estará en un estado de interbloqueo cuando todos los procesos del conjunto estén esperando a'que se produzca un suceso que sólo puede producirse como resulta­ do de la actividad de otro proceso del conjunto. Los sucesos con los que fundamentalmente vamos a trabajar aquí son los de adquisición y liberación de recursos. El recurso puede ser un recurso físi­ co (por ejemplo, una impresora, una unidad de cinta, espacio de memoria y ciclos de CPU) o un recurso lógico (por ejemplo, archivos, semáforos y monitores). Sin embargo, también otros tipos de sucesos pueden dar lugar a interbloqueos (por ejemplo, las facilidades IPC descritas en el Capítulo 3). Para ilustrar el estado de interbloqueo, considere un sistema con tres unidades regrabables de CD. Suponga que cada proceso está usando una de estas unidades. Si ahora cada proceso solicita otra unidad, los tres procesos entrarán en estado de interbloqueo. Cada uno de ellos estará espe­ rando a que se produzca un suceso, “la liberación de la unidad regrabable de CD”, que sólo puede producirse como resultado de una operación efectuada por uno de los otros procesos en espera. Este ejemplo ilustra un interbloqueo relativo a un único tipo de recurso. Los interbloqueos también pueden implicar tipos de recursos diferentes. Por ejemplo, conside­ re un sistema con una impresora y una unidad de DVD. Suponga que el proceso P¡ está usando la unidad de DVD y el proceso P- la impresora. Si P¡ solicita la impresora y P; solicita la unidad de DVD, se producirá un interbloqueo. Los programadores que desarrollen aplicaciones multihebra deben prestar especial atención a este tipo de problemas. Los programas multihebra son buenos candidatos para los interbloqueos, porque las distintas hebras pueden competir por la utilización de los recursos comparti\1 CAI Vr .D. D .

7.2 Caracterización de los interbloqueos

219

Caracterización de los interbloqueos En un interbloqueo, los procesos nunca terminan de ejecutarse y los recursos del sistema están ocupados, lo que impide que se inicien otros trabajos. Antes de pasar a ver los distintos métodos para abordar el problema de los interbloqueos, veamos en detalle sus características.

Lí—rm o 7 In terb loq u eos

%^-iS - . * ... *

. ...

f.‘l*».

.n

*£3 s- .¿«l

, 3S MÚTEX (Cont.)

INTERBLOQUEO «*%.'r*

■*¿

.

J*

“ ’» -

*

. ,* Sí*

r «. * **■• - f'M

«guadojnattíx, (2) primer^mutex. Se^puedé'pxQ^^,iinc.íhterbloqüéo slheb'ig , adquiere pxi^3^mut,^^yientras bebra^dx^^cw ^6- segundojmateqj. ■* ObserveApiep mclüsofaunque se.pdeda'producff R¡ y signirmm que el proceso P, ha solicitado una instancia del tipo de recurso R¡ y que actualm ente está esperando dicho recurso. Una arista dirigida desde el tipo de recurso R- al proceso P, se indica mediante R, p. y quiere decir que se ha asignado una instancia del tipo de recurso R¡ al proceso e Lna arista dirigida P¡ -» R; se denomina arista de solicitud, m ientras que una arista dirigida R, >P se denomina arista de asignación. Gráficamente, representamos cada proceso P, con un círculo y cada tipo de recurso R- con un rectángulo. Puesto que el tipo de recurso R; puede tener más de una instancia, representam os cada

7.2 Caracterización de los interbloqueos

221

instancia mediante un punto dentro del rectángulo. Observe que una arista de solicitud sólo apun­ ta a un rectángulo R¡, mientras que una arista de asignación también debe asociarse con uno de los puntos contenidos en el rectángulo. Cuando el proceso P, solicita una instancia del tipo de recurso R(, se inserta una arista de soli­ citud en el grafo de asignación de recursos. Cuando esta solicitud se concede, la arista de solici­ tud se transforma instantáneamente en una arista de asignación. Cuando el proceso ya no necesita acceder al recurso, éste se libera y la arista de asignación se borra. La Figura 7.2 muestra el grafo de asignación de recursos que ilustra la situación siguiente: • Conjuntos P, R y E: o P = (Pv P2, P3j o R = {Rv R2, R3, R4} o E — {P |—^R |, P2—>R3,R^—>P2, R2—>P->, R2—^

R3—^P 3}

• Instancias de recursos o Una instancia del tipo de recurso R, o Dos instancias del tipo de recurso R2 o Una instancia del tipo de recurso R3 o Tres instancias del tipo de recurso R4 • Estados de los procesos o El proceso P3 retiene una instancia del tipo de recurso R2 y está esperando una instan­ cia del recurso Rv o El proceso P2 retiene una instancia del tipo de recurso R3 y está esperando una instan­ cia del recurso R3. o El proceso P3 retiene una instancia del recurso R3. Dada la definición de un grafo de asignación de recursos, podemos demostrar que, si el grafo no contiene ningún ciclo, entonces ningún proceso del sistema está interbloqueado. Si el gra­ fo contiene un ciclo, entonces puede existir un interbloqueo. Si cada tipo de recurso tiene exactamente una instancia, entonces la existencia de un ciclo implica necesariamente que se ha producido un interbloqueo. Además, aunque haya tipos de re­ cursos con más de una instancia, si el ciclo implica sólo a un determinado conjunto de tipos de recursos, cada uno de ellos con una sola instancia, entonces existirá un interbloqueo: cada uno de los procesos implicados en el ciclo estará interbloqueado. En este caso, la presencia de un ciclo en el grafo es condición necesaria y suficiente para la existencia de interbloqueo.

ñ,

r

3

«4

Figura 7.2 Grafo de asignación de recursos.

222

Capítulo 7 Interbloqueos

fí,

R3

fl4 Figura 7.3

Grafo de asignación de recursos con un interbloqueo.

f

Si cada tipo de recurso tiene varias instancias, entonces la existencia de un ciclo no necesaria-* mente implica que se haya producido un interbloqueo. En este caso, la existencia de un ciclo en el grafo es condición necesaria, pero no suficiente, para la existencia de interbloqueo. Para ilustrar este concepto, volvamos al grafo de asignación de recursos de la Figura 7.2.; Supongamos que el proceso P3 solicita una instancia del tipo de recurso R2. Dado que actualmen­ te no hay disponible ninguna instancia, se añade al grafo una arista de solicitud P3 -> R2 (Figura; 7.3). En esta situación, en el sistema existen dos ciclos como mínimo: Pa —>R4 -> P2 -» R3

P3 -» R2-> P\

P2 —> R3—^ P3 —^ R2 —>P2 Los procesos Pv P2 y P3 se interbloquean. El proceso P2 está esperando para acceder al recurso R3, que está retenido por el proceso P3. El proceso P3 está esperando a que Pt o P2 liberen el recur­ so R2. Además, el proceso Pt está esperando a que el proceso P2libere el recurso Rv Ahora consideremos el grafo de asignación de recursos de la Figura 7.4. En este ejemplo, tene­ mos también un ciclo P-[-> RT—> P3 —> R2 —> Pt Sin embargo, no existe ningún interbloqueo. Observe que el proceso P4 puede liberar su ins­ tancia del tipo de recurso R2. Dicho recurso se puede asignar a P3, rompiendo así el ciclo. En resumen, si un grafo de asignación de recursos no tiene un ciclo, entonces el sistema no está en estado de interbloqueo. Si existe un ciclo, entonces el sistema puede o no estar en esta-

Figura 7.4 Grafo de asignación de recursos con un ciclo pero sin interbloqueo.

7.3 Métodos para tratar los interbloqueos

223

do de interbloqueo. Esta observación es importante a la hora de tratar el problema de los inter­ bloqueos.

Métodos para tratar los interbloqueos En general, podemos abordar el problema de los interbloqueos de una de tres formas: • Podemos emplear un protocolo para impedir o evitar los interbloqueos, asegurando que el sistema nunca entre en estado de interbloqueo. • Podemos permitir que el sistema entre en estado de interbloqueo, detectarlo y realizar una recuperación. • Podemos ignorar el problema y actuar como si nunca se produjeran interbloqueos en el sis­ tema. La tercera solución es la que usan la mayoría de los sistemas operativos, incluyendo UNIX y W indows; entonces, es problema del desarrollador de aplicaciones el escribir programas que resuelvan posibles interbloqueos.

A continuación, vamos a exponer brevemente cada uno de los tres métodos mencionados; más adelante, en las Secciones 7.4 a 7.7, presentaremos algoritmos detallados. Sin embargo, antes de continuar, debemos mencionar que algunos investigadores han argumentado que ninguno de los métodos básicos resulta apropiado, por sí solo, para abordar el espectro completo de problemas relativos a la asignación de recursos en los sistemas operativos. No obstante, estos métodos bási­ cos se pueden combinar, permitiéndonos seleccionar un método óptimo para cada clase de recur­ so existente en el sistema. Para garantizar que nunca se produzcan interbloqueos, el sistema puede emplear un esquema de prevención de interbloqueos o un esquema de evasión de interbloqueos. La prevención de interbloqueos proporciona un conjunto de métodos para asegurar que al menos una de las con­ diciones necesarias (Sección 7.2.1) no pueda cumplirse. Estos métodos evitan los interbloqueos restringiendo el modo en que se pueden realizar las solicitudes. Veremos estos métodos en la Sección 7.4. La evasión de interbloqueos requiere que se proporcione de antemano al sistema operativo información adicional sobre qué recursos solicitará y utilizará un proceso durante su tiempo de vida. Con estos datos adicionales, se puede decidir, para cada solicitud, si el proceso tiene que esperar o no. Para decidir si la solicitud actual puede satisfacerse o debe retardarse, el sistema necesita considerar qué recursos hay disponibles en ese momento, qué recursos están asignados a cada proceso y las futuras solicitudes y liberaciones de cadaproceso. Explicaremos estos esque­ mas en la Sección 7.5. Si un sistema no emplea un algoritmo de prevención de interbloqueos ni un algoritmo de eva­ sión, entonces puede producirse una situación de interbloqueo. En este tipo de entorno, el siste­ ma puede proporcionar un algoritmo que examine el estado del mismo para determinar si se ha producido un interbloqueo y otro algoritmo para recuperarse de dicho interbloqueo (si realmen­ te se ha producido). Veremos estas cuestiones en las Secciones 7.6 y 7.7. Si un sistema no garantiza que nunca se producirá un interbloqueo, ni proporciona un meca­ nismo para la detección y recuperación de interbloqueos, entonces puede darse la situación de que el sistema esté en estado de interbloqueo y no tenga forma ni siquiera de saberlo. En este caso, el interbloqueo no detectado dará lugar a un deterioro del rendimiento del sistema, ya que habrá recursos retenidos por procesos que no pueden ejecutarse y, a medida que se realicen nuevas soli­ citudes de recursos, cada vez más procesos entrarán en estado de interbloqueo. Finalmente, el sis­ tema dejará de funcionar y tendrá que reiniciarse manualmente. Aunque este método no parece un sistema viable para abordar el problema del interbloqueo, se usa en la mayoría de los sistemas operativos, como hemos señalado anteriormente. En muchos sistemas, los interbloqueos se producen de forma bastante infrecuente (por ejemplo, una vez a! año); por tanto, este método es más barato que los métodos de prevención,'-'de evasión o de detec­ ción y recuperación, que deben utilizarse constantemente. Asimismo, en algunas circunstancias,

Capítulo 7 Interbloqueos

224

un sistema puede estar congelado pero no interbloqueado; por ejemplo, esta situación darse si un proceso en tiempo real que se ejecuta con la prioridad más alta (o cualquier pro que se ejecute con un planificador sin desalojo) nunca devuelve el control al sistema operativo! sistema debe disponer de métodos de recuperación manual para tales condiciones y puede ¡ plemente, usar esas mismas técnicas para recuperarse de los interbloqueos.

7.4

Prevención de interbloqueos Como se ha dicho en la Sección 7.2.1, para que se produzca un interbloqueo deben cumplirse] cuatro condiciones necesarias. Asegurando que una de estas cuatro condiciones no se cumpl podemos prevenir la aparición de interbloqueos. Vamos a abordar este método examinando cal una de las cuatro condiciones por separado.

7.4.1 Exclusión mutua La condición de exclusión mutua se aplica a los recursos que no pueden ser compartidos. Pqj ejemplo, varios procesos no pueden compartir simultáneamente una impresora. Por el contrario los recursos que sí pueden compartirse no requieren acceso mutuamente excluyente y, por taníi no pueden verse implicados en un interbloqueo. Los archivos de sólo lectura son un buen ejer pío de recurso que puede compartirse. Si varios procesos intentan abrir un archivo de sólo lect ra al mismo tiempo, puede concedérseles acceso al archivo de forma simultánea. Un proceso no necesita esperar nunca para acceder a un recurso compartible. Sin embargo, en general, no pode mos evitar los interbloqueos negando la condición de exclusión mutua, ya que algunos recurso son intrínsecamente no compartióles.

7.4.2 Retención y espera

3BT

Para asegurar que la condición de retención y espera nunca se produzca en el sistema, debemos garantizar que, cuando un proceso solicite un recurso, el proceso no esté reteniendo ningún otro! recurso. Un posible protocolo consiste en exigir que cada proceso solicite todos sus recursos (y que esos recursos se le asignen) antes de comenzar su ejecución. Podemos implementar este mecanis­ mo requiriendo que las llamadas al sistema que solicitan los recursos para un proceso precedan a todas las demás llamadas al sistema. Una posible alternativa sería un protocolo que permitiera a un proceso solicitar recursos sólo cuando no tenga ninguno retenido. Un proceso puede solicitar algunos recursos y utilizarlos. Sin embargo, antes de solicitar cualquier recurso adicional, tiene que liberar todos los recursos que tenga asignados actualmente. Para ilustrar la diferencia entre estos dos protocolos, consideremos un proceso que copia datos de una unidad de DVD en un archivo en disco, ordena el archivo y luego imprime los resultados en una impresora. Si hay que solicitar todos los recursos antes de iniciar la ejecución, entonces el proceso tendrá que solicitar inicialmente la unidad de DVD, el archivo de disco y la impresora. El proceso retendrá la impresora durante todo el tiempo que dure la ejecución, incluso aunque sólo la necesite al final. El segundo método permite al proceso solicitar inicialmente sólo la unidad de DVD y el archi­ vo de disco. El proceso realiza la copia de la unidad de DVD al disco y luego libera ambos recur­ sos. El proceso tiene entonces que solicitar de nuevo el archivo de disco y la impresora. Después de copiar el archivo de disco en la impresora, libera estos dos recursos y termina. Ambos protocolos tienen dos desventajas importantes. Primero, la tasa de utilización de los recursos puede ser baja, dado que los recursos pueden asignarse pero no utilizarse durante un período largo de tiempo. Por ejemplo, en este caso, podemos liberar la unidad de DVD y el archi­ vo de disco y luego solicitar otra vez el archivo de disco y la impresora, sólo si podemos estar seguros de que nuestros datos van a permanecer en el archivo. Si no podemos asegurarlo, enton­ ces tendremos que solicitar todos los recursos desde el principio con ambos protocolos.

7.4 Prevención de interbloqueos

225

La segunda desventaja es que puede producirse el fenómeno de inanición: un proceso que necesite varios recursos muy solicitados puede tener que esperar de forma indefinida, debido a que al menos uno de los recursos que necesita está siempre asignado a algún otro proceso.

7.4.3 Sin desalojo La tercera condición necesaria para la aparición de interbloqueos es que los recursos que ya están asignados no sean desalojados. Para impedir que se cumpla esta condición, podemos usar el pro­ tocolo siguiente: si un proceso está reteniendo varios recursos y solicita otro recurso que no se le puede asignar de forma inmediata (es decir, el proceso tiene que esperar), entonces todos los recursos actualmente retenidos se desalojan. En otras palabras, estos recursos se liberan implíci­ tamente. Los recursos desalojados se añaden a la lista de recursos que el proceso está esperando. El proceso sólo se reiniciará cuando pueda recuperar sus antiguos recursos, junto con los nuevos que está solicitando. Alternativamente, si un proceso solicita varios recursos, primero comprobaremos si están dis­ ponibles. Si lo están, los asignaremos. Si no lo están, comprobaremos si están asignados a algún otro proceso que esté esperando recursos adicionales. Si es así, desalojaremos los recursos desea­ dos del proceso en espera y los asignaremos al proceso que los ha solicitado. Si los recursos no están ni disponibles ni retenidos por un proceso en espera, el proceso solicitante debe esperar. Mientras espera, pueden desalojarse algunos de sus recursos, pero sólo si otro proceso los solici­ ta. Un proceso sólo puede reiniciarse cuando se le asignan los nuevos recursos que ha solicitado y recupera cualquier recurso que haya sido desalojado mientras esperaba. A menudo, este protocolo se aplica a tipos de recursos cuyo estado puede guardarse fácilmen­ te y restaurarse más tarde, como los registros de la CPU y el espacio de memoria. Generalmente, no se puede aplicar a recursos como impresoras y unidades de cinta.

7.4.4 Espera circular La cuarta y última condición para la aparición de interbloqueos es la condición de espera circular. Una forma de garantizar que esta condición nunca se produzca es imponer una ordenación total de todos los tipos de recursos y requerir que cada proceso solicite sus recursos en un orden cre­ ciente de enumeración. Para ilustrarlo, sea R ~ {Rv R2, . . ., Rm} el conjunto de tipos de recursos. Asignamos a cada tipo de recurso un número entero unívoco, que nos permitirá comparar dos recursos y determinar si uno precede al otro dentro de nuestra ordenación. Formalmente, definimos una función uno-auno F:R —>N, donde N es el conjunto de los números naturales. Por ejemplo, si el conjunto de tipos de recursos R incluye unidades de cinta, unidades de disco e impresoras, entonces la función F se define como sigue: F(unidad de cinta) = 1 F(unidad de disco) = 5 F(impresora) = 12 Podemos considerar el siguiente protocolo para impedir los interbloqueos: cada proceso puede solicitar los recursos sólo en orden creciente de enumeración. Es decir, un proceso puede solicitar inicialmente cualquier número de instancias de un cierto tipo de recurso, por ejemplo R_¡; a conti­ nuación, el proceso puede solicitar instancias del tipo de recursos R; si y sólo si F(R;) > F(R;). Si se necesitan varias instancias del mismo tipo de recurso, se ejecuta una única solicitud para todos ellos. Por ejemplo, usando la función definida anteriormente, un proceso que desee utilizar la uni­ dad de cinta y la impresora al mismo tiempo debe solicitar en primer lugar la unidad de cinta y luego la impresora. Alternativamente, podemos requerir que, si un proceso solicita una instancia del tipo de recurso R(-, tiene que liberar primero cualquier recurso R,, tal que F(R,) > F(R,). Si se usan estos dos protocolos, entonces la condición de espera circular no puede llegar a cum­ plirse. Podemos demostrar este hecho suponiendo que existe una espera circular (demostración por reducción al absurdo). Sea el conjunto de los procesos implicados en la espera circular { P q , Py

Capítulo 7 Interbloqueos

226

..., Pn}, donde P¡ espera para acceder al recurso R¡, que está retenido por el proceso P ¡+1 (enlosé ces se utiliza la aritmética de módulos, por lo que P„ espera un recurso Rn retenido por Entonces, dado que el proceso P,+1 está reteniendo el recurso R¡ mientras solicita el recurso r M tiene que cumplir que F(R,) < F(Ri+1) para todo i. Esta condición quiere decir que F(R0) < F(R ... < F(R„) < F(R0). Por transitividad, F(R0) < F(R0), lo que es imposible. Por tanto, no puede < una espera circular. Podemos implementar este esquema en los programas de aplicación definiendo una orde ción entre todos los objetos de sincronización del sistema. Todas las solicitudes de objetos dei cronización se deben hacer en orden creciente. Por ejemplo, si el orden de bloqueo en el pros Pthread mostrado en la Figura 7.1 era F(primer_mutex) = 1 F(segundo_mutex) = 5

entonces hebra_dos no puede solicitar los bloqueos sin respetar el orden establecido. Tenga presente que el definir una ordenación o jerarquía no impide, por sí sólo, la aparición c interbloqueos. Es responsabilidad de los desarrolladores de aplicaciones escribir programas i respeten esa ordenación. Observe también que la función F debería definirse de acuerdo conl orden normal de utilización de los recursos en un'sistema. Por ejemplo, puesto que normalmenh la unidad de cinta se necesita antes que la impresora, sería razonable definir F(unidad de cinta} F(impresora). Aunque garantizar que los recursos se adquieran en el orden apropiado es responsabilidad! los desarrolladores de aplicaciones, puede utilizarse una solución software para verificar que lo bloqueos se adquieren en el orden adecuado, y proporcionar las apropiadas advertencias cuand es una secuencia segura para el estado de asignación actual si, para cada P¿, las solicitudes de recursos que P, pueda todavía hacer pueden ser satisfechas mediante los recursos actualmente disponibles, junto con los recursos retenidos por todos los P¡, con j < i. En esta situa­ ción, si los recursos que P¡ necesita no están inmediatamente disponibles, entonces P, puede espe­ rar hasta que todos los P- hayan terminado. Cuando esto ocurra, P¡ puede obtener todos los recursos que necesite, completar las tareas que tenga asignadas, devolver sus recursos asignados y terminar. Cuando P, termina, Pl+1 puede obtener los recursos que necesita, etc. Si tal secuencia no existe, entonces se dice que el estado del sistema es inseguro. Un estado seguro implica que no puede producirse interbloqueo. A la inversa, todo estado de interbloqueo es inseguro. Sin embargo, no todos los estados inseguros representan un interblo­ queo (Figura 7.5).Un estado inseguro puede llevar a que aparezca un interbloqueo. Siempre y cuando el estado sea seguro, el sistema operativo podrá evitar los estados inseguros (y de inter­ bloqueo). En un estado inseguro, el sistema operativo no puede impedir que los procesos solici­ ten recursos de tal modo que se produzca un interbloqueo: el comportamiento de los procesos es el que controla los estados inseguros. Con el fin de ilustrar este tema, consideremos un sistema con 12 unidades de cinta magnética y tres procesos: Pq, P1 y P2. El proceso P0 requiere 10 unidades de cinta, el proceso P1 puede nece­ sitar como mucho 4 unidades de cinta y el proceso P2 puede necesitar hasta 9 unidades de cinta. Suponga que, en el instante f0, el proceso P0 está reteniendo 5 unidades de cinta, el proceso P1 está usando 2 unidades de cinta y el proceso P2 está reteniendo 2 unidades de cinta (por tanto, quedan 3 unidades de cinta libres).

P0 Pa P2

Necesidades máximas

Necesidades actuales

10 4 9

5 2 2

En el instante fg, el sistema está en estado seguro. La secuencia < Pv P0, P2> satisface la condi­ ción de seguridad. Al proceso Pt se le pueden asignar inmediatamente todas sus unidades de cinta, después de lo cual el proceso terminará por devolverlas (el sistema tendrá entonces 5 uni­ dades de cinta disponibles); a continuación, el proceso-P0 puede tomar todas sus unidades de cinta y devolverlas cuando termine (el sistema tendrá entonces 1 0 unidades de cinta disponibles); y, por último, el proceso P2 puede obtener todas sus unidades de cinta y devolverlas (el sistema tendrá entonces 1 2 unidades de cinta disponibles). Un sistema puede pasar de un estado seguro a un estado inseguro. Suponga que, en el instan­ te fj, el proceso P-, hace una solicitud y se le asigna una unidad de cinta más. El estado del siste­ ma dejará de ser seguro. En este momento, sólo pueden asignarse todas sus unidades de cinta al proceso P-¡; cuando las devuelva, el sistema tendrá sólo 4 unidades de cinta disponibles. Dado que el proceso P0 tiene asignadas cinco unidades pero tiene un máximo de 10, puede solicitar 5 uni­ dades de cinta más; como no están disponibles, el proceso P0 debe esperar. De forma similar, el proceso P2 puede solicitar 6 unidades de cinta más y tener que esperar, dando lugar a un interblo-

Capítulo 7 Interbloqueos

Figura 7.5 Espacio de los estados seguro, inseguro y de interbloqueo. queo. El error se ha cometido al aprobar la solicitud del proceso P2 de usar una unidad más. Si, hubiéramos hecho esperar a P2 hasta que los demás procesos hubieran terminado y liberado sus recursos, habríamos evitado el interbloqueo. Conocido el concepto de estado seguro, podemos definir algoritmos para evitar los interblo­ queos que aseguren que en el sistema nunca se producirá un interbloqueo. La idea consiste sim­ plemente en garantizar que el sistema siempre se encuentre en estado seguro. Inicialmente, el sistema se encuentra en dicho estado. Cuando un proceso solicita un recurso que está disponible en ese momento, el sistema debe decidir si el recurso puede asignarse de forma inmediata o el pro­ ceso debe esperar. La solicitud se concede sólo si la asignación deja al sistema en estado seguro. Con este esquema, si un proceso solicita un recurso que está disponible, es posible que tenga que esperar. Por tánto, la tasa de utilización del recurso puede ser menor que si no se utilizara este algoritmo.

7.5.2 Grafo de asignación de recursos Si tenemos un sistema de asignación de recursos con sólo una instancia de cada tipo de recurso, puede utilizarse una variante del grafo de asignación de recursos definido en la Sección 7.2.2 para evitar los interbloqueos. Además de las aristas de solicitud y de asignación ya descritas, vamos a introducir un nuevo tipo de arista, denomina arista de declaración. Una arista de declaración P¡ -» Rj indica que el proceso P, puede solicitar el recurso Ry en algún instante futuro. Esta arista es similar a una arista de solicitud en lo que respecta a la dirección, pero se representa en el grafo mediante una línea de trazos. Cuando el proceso P, solicita el recurso R-, la arista de declaración P¡ —> Rj se convierte en una arista de solicitud. De forma similar, cuando un proceso P¡ libera un recurso R¡, la arista de asignación Rj —> P, se reconvierte en una arista de declaración P, —» R¡. Observe que los recursos deben declararse de antemano al sistema, es decir, antes de que el pro­ ceso P¡ inicie su ejecución, todas sus aristas de declaración deben estar indicadas en su grafo de asignación de recursos. Podemos suavizar esta condición permitiendo que se pueda añadir al grafo una arista de declaración P¡ —>R/ sólo si todas las aristas asociadas con el proceso P; son aris­ tas de declaración. Supongamos que el proceso P¡ solicita el recurso Ry. La solicitud se puede conceder sólo si la conversión de la arista de solicitud P¡ —» Ryen una arista de asignación R; —»P, no da lugar a la for­ mación de un ciclo en el grafo de asignación de recursos. Observe que realizamos la comproba­ ción de si el estado es seguro utilizando un algoritmo de detección de ciclos. Los algoritmos de detección de ciclos en este grafo requieren del orden de n2 operaciones, donde n es el número de procesos del sistema. Si no se crea un ciclo, entonces la asignación del recurso dejará al sistema en un estado seguro. Si se encuentra un ciclo, entonces la asignación colocaría al sistema en un estado inseguro. Por tanto, el proceso P, tendrá que esperar para que su solicitud sea satisfecha. Para ilustrar este algoritmo, consideremos el grafo de asignación de recursos de la Figura 7.6.'' Supongamos que P2 solicita el recurso R2. Aunque R~, actualmente está libre, no podemos asignar-

7.5 Evasión de interbloqueos

229

«i

Figura 7.6 Grato de asignación de recursos para evitar los interbloqueos. «i

Figura 7.7 Un estado inseguro en un grato de asignación de recursos. lo a P2, ya que esta acción crearía un ciclo en el grafo (Figura 7.7). La existencia de un ciclo indica que el sistema se encuentra en un estado inseguro. Si Px solicita R2, y P2 solicita Rt, entonces se producirá un interbloqueo.

7.5.3 Algoritmo del banquero El algoritmo del grafo de asignación de recursos no es aplicable a los sistemas de asignación de recursos con múltiples instancias de cada tipo de recurso. El algoritmo para evitar interbloqueos que vamos a describir a continuación es aplicable a dicho tipo de sistema, pero es menos eficien­ te que el método basado en el grafo de asignación de recursos. Habitualmente, este algoritmo se conoce con el nombre de algoritmo del banquero; se eligió este nombre porque el algoritmo podría utilizarse en los sistemas bancarios para garantizar que el banco nunca asigne sus fondos dispo­ nibles de tal forma que no pueda satisfacer las necesidades de todos sus clientes. Cuando entra en el sistema un proceso nuevo, debe declarar el número máximo de instancias de cada tipo de recurso que puede necesitar. Este número no puede exceder el número total de recursos del sistema. Cuando un usuario solicita un conjunto de recursos, el sistema debe deter­ minar si la asignación de dichos recursos dejará al sistema en un estado seguro. En caso afirmati­ vo, los recursos se asignarán; en caso contrario, el proceso tendrá que esperar hasta que los otros procesos liberen los suficientes recursos. Deben utilizarse varias estructuras de datos para implementar el algoritmo del banquero. Estas estructuras de datos codifican el estado del sistema de asignación de recursos. Sea n el número de procesos en el sistema y m el número de tipos de recursos. Necesitamos las siguien­ tes estructuras: • Available (disponibles). Un vector de longitud m que indica el número de recursos dispo­ nibles de cada tipo. Si Available [/'] es igual a k, existen k instancias disponibles del tipo de recurso Rr • Max. Una matriz n x m que indica la demanda máxima de cada proceso. Si Mn.r[/] [/'] es igual a k, entonces el proceso P, puede solicitar como máximo k instancias del tipo de recurso Rr

230

Capítulo 7 Interbloqueos

• Allocation (asignación). Una matriz n X m que define el número de recursos de cadal actualmente asignados a cada proceso. Si Allocation[i]\j] es igual a k, entonces el proce tiene asignadas actualmente k instancias del tipo de recurso R;. • Need (necesidad). Una matriz n X m que indica la necesidad restante de recursos del proceso. Si Need[i]\j] es igual a k, entonces el proceso P, puede necesitar k instancias; tipo de recurso R, para completar sus tareas. Observe que Need[i][j] es igual a Mí«[í](j| Allocation[i][j]. Estas estructuras de datos varían con el tiempo, tanto en tamaño como en valor. Para simplificar la presentación del algoritmo del banquero, a continuación vamos a de cierta notación. Sean X e Y sendos vectores de longitud n. Decimos que X < Y si y sólo si X[¿1 Y[í] para todo i = 1 , 2 ,..., n. Por ejemplo, si X = (1 , 7, 3, 2) e Y = (0, 3, 2 , 1 ), entonces Y < X. Y si Y < X e Y * X . Podemos tratar cada fila de las matrices Allocation y Need como un vector y denomina Allocation, y Need¡. El vector Allocation, especifica los recursos actualmente asignados al procesol el vector Need-, especifica los recursos adicionales que el proceso P, podría todavía solicitar p| completar su tarea. 7.5.3.1 Algoritmo de seguridad Ahora podemos presentar el algoritmo para averiguar si un sistema se encuentra en estado seg ro o no. Este algoritmo puede describirse del siguiente modo: 1. Sean Work y Finish sendos vectores de longitud m y n, respectivamente. Inicializamos i vectores de la forma siguiente: Work = Available y Finish[i] = false para i = 0,1, ..., n - 1 . 2. Hallar i tal que a.

Fims/i[¿] = = false

b.

Need, satisface el requisi­ to de seguridad. Por tanto, podemos conceder inmediatamente la solicitud del proceso P^ Sin embargo, puede comprobarse que cuando el sistema se encuentra en este estado, una soli­ citud de valor (3, 3, 0) por parte de P4 no se puede conceder, ya que los recursos no están dispo-

Capítulo 7 Interbloqueos

nibles. Además, no se puede conceder una solicitud de valor (0, 2, 0) por parte de P0, incluso a« que los recursos estén disponibles, ya que el estado resultante es inseguro. Dejamos como ejercicio de programación para el lector la implementación del algoritmo i banquero.

Detección de interbloqueos M Si un sistema no emplea ni algoritmos de prevención ni de evasión de interbloqueos, entonces* puede producirse una situación de interbloqueo en el sistema. En este caso, el sistema debe pml porcionar: • Un algoritmo que examine el estado del sistema para determinar si se ha producido uj| interbloqueo. J • Un algoritmo para recuperarse del interbloqueo. En la siguiente exposición, vamos a estudiar en detalle estos dos requisitos en lo que concierne* tanto a los sistemas con una única instancia de cada tipo de recurso, como con varias instancias' 1 de cada tipo de recurso. Sin embargo, hay que resaltar de antemano que los esquemas de detec­ ción y recuperación tienen un coste significativo asociado, que incluye no sólo el coste (de tiempo de ejecución) asociado con el mantenimiento de la información necesaria y la ejecución del algo­ ritmo de detección, sino también las potenciales pérdidas inherentes al proceso de recuperación de un interbloqueo.

7.6.1 Una sola instancia de cada tipo de recurso Si todos los recursos tienen una única instancia, entonces podemos definir un algoritmo de detec­ ción de interbloqueos que utilice una variante del grafo de asignación de recursos, denominada grafo de espera. Obtenemos este grafo a partir del grafo de asignación de recursos eliminando los nodos de recursos y colapsando las correspondientes aristas. De forma más precisa, una arista de P, a P¡ en un grafo de espera implica que el proceso P¡ está esperando a que el proceso P- libere un recurso que P, necesita. En un grafo de espera existirá una arista P¡ -» P, si y sólo si el correspondiente grafo de asignación de recursos contiene dos aristas P, -> Rq y Rq —>P. para algún recurso Rq. A modo de ejemplo, en la Figura 7.8 se presentan un grafo de asignación de recursos y el correspondiente grafo de espera.

(a)

(b)

Figura 7.8 (a) Grafo de asignación de recursos, (b) Grafo de espera correspondiente.

7.6 Detección de interbloqueos

233

Como antes, existirá un interbloqueo en el sistema si y sólo si el grafo de espera contiene un ciclo. Para detectar los interbloqueos, el sistema necesita mantener el grafo de espera e invocar un algoritmo periódicamente que compruebe si existe un ciclo en el grafo. Un algoritmo para detectar un ciclo en un grafo requiere del orden de n2 operaciones, donde n es el número de vértices del grafo.

7.6.2 Varias instancias de cada tipo de recurso El esquema del grafo de espera no es aplicable a los sistemas de asignación de recursos con múlti­ ples instancias de cada tipo de recurso. Veamos ahora un algoritmo de detección de interbloqueos que pueda aplicarse a tales sistemas. El algoritmo emplea varias estructuras de datos variables con el tiempo, que son similares a las utilizadas en el algoritmo del banquero (Sección 7.5.3): • Available. Un vector de longitud m que indica el número de recursos disponibles de cada tipo. • Allocation. Una matriz n X m que define el número de recursos de cada tipo que están asignados actualmente a cada proceso. • Request. Una matriz n X m que especifica la solicitud actual efectuada por cada proceso. Si Rec¡uest[i]¡j] es igual a k entonces el proceso P¿ está solicitando k instancias más del tipo de recurso R;-. La relación < entre dos vectores se define en la Sección (7.5.3). Para simplificar la notación, de nuevo vamos a tratar las filas de las matrices Allocation y Request como vectores; los especifica­ remos con la notación Allocation¡ y Request¡. El algoritmo de detección que se describe aquí, simplemente investiga cada posible secuencia de asignación de los procesos que quedan por completarse. Compare este algoritmo con el algoritmo del banquero presentado en la Sección 7.5.3. 1. Work y Finish son vectores de longitud m y n, respectivamente. Inicialmente, Work = Available. Para i = 0 ,1 ,..., n - 1, si Allocationj * 0, entonces Finish[i] = false; en caso contrario, Finish[i] = true. 2. Hallar un índice i ^1 que a.

Finish[i] == false

b.

Requesti < Work

Si no existe tal i, ir al paso 4. 3. Work = Work + Allocationl Finish[i] = true Ir al paso 2 4. Si Finish[i\ == false, para algún i tal que 0 < i < n, entonces el sistema se encuentra en estado de interbloqueo. Además, si Finish[i] ==false, entonces el proceso P¡ está en el interbloqueo. Este algoritmo requiere del orden de rn X n2 operaciones para detectar si el sistema se encuen­ tra en un estado de interbloqueo. El lector puede estarse preguntando por qué reclamamos los recursos del proceso P, (en el paso 3) tan pronto como determinamos que RequestJ < Work (en el paso 2b). Sabemos que P, actualmen­ te no está implicado en un interbloqueo (dado que Request¡ < Work). Por tanto, adoptamos una acti­ tud optimista y suponemos que P¡ no requerirá más recursos para completar sus tareas y que terminará por devolver al sistema todos los recursos que tenga actualmente asignados. Si nuestra suposición es incorrecta, más adelante se producirá un interbloqueo y dicho in terb loq u eo se detectará la siguiente vez que se invoque el algoritmo de detección de interbloqueos. Para ilustrar este algoritmo, consideremos un sistema con cinco procesos P0 a P4 y tres tipos de recursos A, B y C. El tipo de recurso A tiene siete instancias, el tipo de recurso B tiene dos instan-

Capítulo 7 Interbloqueos

:;as y el tipo de recurso C tiene seis instancias. Suponga que en el instante T0 tenemos el siguió :e estado de la asignación de recursos: i Allocation

Request

Available

ABC 010 200 303 211 002

ABC 000 202 000 100 002

ABC 000

Po Pl Pl p5 Pl

Podemos afirmar que el sistema no se encuentra en estado de interbloqueo. En efecto, si eje :amos nuestro algoritmo, comprobaremos que la secuencia da como resultad®”: : :nish[í] == true para todo i. Suponga ahora que el proceso P2 hace una solicitud de una instancia más del tipo de rect 2. La matriz Request se modifica como sigue: Request ABC Po Pi

000

202 001 100

002

Ahora podemos afirmar que el sistema está en interbloqueo. Aunque podemos reclamar los?SSjS* 'ecursos retenidos por el proceso P0, el número de recursos disponibles no es suficiente para satisfacer las solicitudes de los restantes procesos. Por tanto, existe un interbloqueo entre los procesos: P2, p3 y P4.

7.6.3 Utilización del algoritmo de detección -^Cuándo debemos invocar el algoritmo de detección? La respuesta depende de dos factores: 1. ¿Con qué frecuencia se producirá probablemente un interbloqueo? 2 . ¿Cuántos procesos se verán afectados por el interbloqueo cuando se produzca?

'-Á ios interbloqueos se producen frecuentemente, entonces el algoritmo de detección debe invo­ carse frecuentemente. Los recursos asignados a los procesos en interbloqueo estarán inactivos aasta que el interbloqueo se elimine. Además, el número de procesos implicados en el ciclo de interbloqueo puede aumentar. Los interbloqueos se producen sólo cuando algún proceso realiza una solicitud que no se puede conceder de forma inmediata. Esta solicitud puede ser la solicitud final que complete una cadena de procesos en espera. En el caso extremo, podemos invocar el algoritmo de detección de nterbloqueos cada vez que una solicitud de asignación no pueda ser concedida inmediatamente. En este caso, podemos no sólo identificar el conjunto de procesos en interbloqueo sino también el proceso concreto que ha “causado” dicho interbloqueo. (En realidad, cada uno de los procesos en nterbloqueo-es una arista del ciclo que aparece en el grafo de recursos, por lo que todos ellos, conuntamente, dan lugar al interbloqueo.) Si existen muchos tipos de recursos diferentes, una solici­ tud puede crear muchos ciclos en el grafo de recursos, siendo completado cada ciclo por la solicitud más reciente y estando “causado” por ese proceso perfectamente identificable. Por supuesto, si se invoca el algoritmo de detección de interbloqueos para cada solicitud de recursos, esto dará lugar a una considerable sobrecarga en el tiempo de uso del procesador. Una alternativa más barata consiste, simplemente, en invocar el algoritmo a intervalos menos frecuen­ tes, por ejemplo una vez por hora o cuando la utilización de la CPU caiga por debajo del 40 por dentó. (Un interbloqueo puede paralizar eb'sistema y hacer que la utilización de la CPU disminu-

7.7 Recuperación de un interbloqueo

ya.) Si el algoritmo de detección se invoca en instantes de tiempo arbitrarios, pueden aparecer muchos ciclos en el grafo de recursos; en este caso, generalmente, no podremos saber cuál de los muchos procesos en interbloqueo ha “causado” el interbloqueo.

Recuperación de un interbloqueo Cuando el algoritmo de detección determina que existe un interbloqueo, tenemos varias alterna­ tivas. Una posibilidad es informar al operador de que se ha producido un interbloqueo y dejar que lo trate de forma manual. Otra posibilidad es dejar que sea el sistema el que haga la recuperación del interbloqueo de forma automática. Existen dos opciones para romper un interbloqueo. Una de ellas consiste simplemente en interrumpir uno o más procesos para romper la cadena de espera circular. La otra consiste en desalojar algunos recursos de uno o más de los procesos bloqueados.

7.7.1 Terminación de procesos Para eliminar los interbloqueos interrumpiendo un proceso, se utiliza uno de dos posibles méto­ dos. En ambos métodos, el sistema reclama todos los recursos asignados a los procesos termina­ dos. • Interrum pir todos los procesos interbloqueados. Claramente, este método interrumpirá el ciclo de interbloqueo, pero a un precio muy alto: los procesos en interbloqueo pueden haber consumido un largo período de tiempo y los resultados de estos cálculos parciales deben descartarse y, probablemente, tendrán que repetirse más tarde. • Interrum pir un proceso cada vez hasta que el ciclo de interbloqueo se elim ine. Este

método requiere una gran cantidad de trabajo adicional, ya que después de haber interrum­ pido cada proceso hay que invocar un algoritmo de detección de interbloqueos para deter­ minar si todavía hay procesos en interbloqueo. Interrumpir un proceso puede no ser fácil. Si el proceso estaba actualizando un archivo, su ter­ minación hará que el archivo quede en un estado incorrecto. De forma similar, si el proceso esta­ ba imprimiendo datos en una impresora, el sistema debe reiniciar la impresora para que vuelva a un estado correcto antes de imprimir el siguiente trabajo. Si se emplea el método de terminación parcial, entonces tenemos que determinar qué proceso o procesos en interbloqueo deben cancelarse. Esta determinación es una decisión de política, simi­ lar a las decisiones sobre la planificación de la CPU. La cuestión es básicamente de carácter econó­ mico: deberemos interrumpir aquellos procesos cuya terminación tenga un coste mínimo. Lamentablemente, el término coste mínimo no es demasiado preciso. Hay muchos factores que influyen en qué procesos seleccionar, entre los que se incluyen: 1. La prioridad del proceso. 2. Durante cuánto tiempo ha estado el proceso ejecutándose y cuánto tiempo de adicional nece­ sita el proceso para completar sus tareas. 3. Cuántos y qué tipo de recursos ha utilizado el proceso (por ejemplo, si los recursos pueden desalojarse fácilmente). 4. Cuántos más recursos necesita el proceso para completarse. 5. Cuántos procesos hará falta terminar. 6. Si se trata de un proceso interactivo o de procesamiento por lotes.

7.7.2 Apropiación de recursos Para eliminar los interbloqueos utilizando el método de apropiación de recursos, desalojamos de forma sucesiva los recursos de los procesos y asignamos dichos recursos a otros procesos hasta que el ciclo de interbloqueo se interrumpa.

236

Capítulo 7 Interbloqueos

Si se necesita el desalojo para tratar los interbloqueos, entonces debemos abordar tres cuest

nes: 1. Selección de una víctim a. ¿De qué recursos hay que apropiarse y de qué procesos? Al io

que en la terminación de procesos, es necesario determinar el orden de apropiación de for que se minimicen los costes. Los factores de coste pueden incluir parámetros como el núi ro de recursos que está reteniendo un proceso en interbloqueo y la cantidad de tiempo gilí el proceso ha consumido hasta el momento durante su ejecución. ,|f 2. Anulación. Si nos apropiamos de un recurso de un proceso, ¿qué debería hacerse con dicho

proceso? Evidentemente, no puede continuar su ejecución normal, ya que no dispone para obtener el número de marco. Esta tarea requiere un acceso a memoria y nos proporciona el número de marco, que se combina con el desplazamiento de página para generar la dirección real. 1 Sólo entonces podremos acceder a la ubicación deseada de memoria. Con este esquema, hacen * falta dos accesos de memoria para acceder a un byte (uno para obtener la entrada de la tabla de = páginas y otro para obtener el byte). Por tanto, el acceso a memoria se ralentiza dividiéndose a la-í mitad. En la mayor parte de las circunstancias, este retardo es intolerable; para eso, es mejor uti- * lizar un mecanismo de intercambio de memoria. La solución estándar a este problema consiste en utilizar una caché hardware especial de * pequeño tamaño y con capacidad de acceso rápido, denominada búfer de consulta de traducción^ (TLB, translation look-aside buffer). El búfer TLB es una memoria asociativa de alta velocidad. Cada entrada del búfer TLB está compuesta de dos partes: una clave (o etiqueta) y un valor. " Cuando se le presenta un elemento a la memoria asociativa, ese elemento se compara simultáneámente con todas las claves. Si se encuentra el elemento, se devuelve el correspondiente campo de, valor. Esta búsqueda se realiza en paralelo de forma muy rápida, pero el hardware necesario es caro. Normalmente, el número de entradas del búfer TLB es pequeño; suele estar comprendido ' entre 64 y 1024. El búfer TLB se utiliza con las tablas de página de la forma siguiente: el búfer TLB contiene sólo unas cuantas entradas de la tabla de páginas; cuando la CPU genera una dirección lógica, se pre-': senta el número de página al TLB y si se encuentra ese número de página, su número de marco correspondiente estará inmediatamente disponible y se utilizará para acceder a la memoria. Toda esta operación puede llegar a ser tan sólo un 10 por ciento más lenta que si se utilizara una refe­ rencia a memoria no convertida. Si el número de página no se encuentra en el búfer TLB (lo que se conoce con el nombre de fallo de TLB), es necesario realizar una referencia a memoria para consultar la tabla de páginas. Una vez

obtenido el número de marco, podemos emplearlo para acceder a la memoria (Figura 8.11). Además, podemos añadir el número de página y el número de marco al TLB, para poder encon­ trar los correspondientes valores rápidamente en la siguiente referencia que se realice. Si el TLB ya está lleno, el sistema operativo deberá seleccionar una de las entradas para sustituirla. Las políti­ cas de sustitución utilizadas van desde una política aleatoria hasta algoritmos que lo que hacen es sustituir la entrada menos recientemente utilizada (LRU, least recently used). Además, algunos búferes TLB permiten cablear las entradas, lo que significa que esas entradas no pueden elimi­ narse del TLB. Normalmente, las entradas del TLB correspondientes al código del kernel están cableadas. Algunos búferes TLB almacenan identificadores del espacio de direcciones (ASID, addressspace identifier) en cada entrada TLB. Cada identificador ASID identifica unívocamente cada pro­ ceso y se utiliza para proporcionar mecanismos de protección del espacio de direcciones correspondiente a ese proceso. Cuando el TLB trata de resolver los números de página virtuales, verifica que el identificador ASID del proceso que actualmente se esté ejecutando se corresponda con el identificador ASID asociado con la página virtual. Si ambos identificadores no coinciden, el intento se trata como un fallo de TLB. Además de proporcionar protección del espacio de direccio­ nes, los identificadores ASID permiten al TLB contener entradas simultáneamente para varios pro­ cesos distintos. Si el TLB no soporta la utilización de identificadores ASID distintos, cada vez que se seleccione una nueva tabla de páginas (por ejemplo, en cada cambio de contexto), será necesa­ rio vaciar (o borrar) el TLB para garantizar que el siguiente proceso que se ejecute no utilice una información incorrecta de traducción de direcciones. Si no se hiciera así, el TLB podría incluir entradas antiguas que contuvieran direcciones virtuales válidas pero que tuvieran asociadas direcciones físicas incorrectas o no válidas que se correspondan con el proceso anterior.

8.4 Paginación

261

dirección lógica

tabla de páginas

Figura 8.11 Hardware de paginación con TLB. El porcentaje de veces que se encuentra un número de página concreto en el TLB se denomina tasa de acierto. Una tasa de acierto del 80 por ciento significa que hemos encontrado el número de página deseado en el TLB un 80 por ciento de las veces. Si se tarda 20 nanosegundos en consul­ tar el TLB y 100 nanosegundos en acceder a la memoria, entonces un acceso a memoria converti­ da (mapeada) tardará 120 nanosegundos cuando el número de página se encuentre en el TLB. Si no conseguimos encontrar el número de página en el TLB (20 nanosegundos), entonces será nece­ sario acceder primero a la memoria correspondiente a la tabla de páginas para extraer el número de marco (100 nanosegundos) y luego acceder al byte deseado en la memoria (100 nanosegundos), lo que nos da un total de 220 nanosegundos. Para calcular el tiempo efectivo de acceso a memo­ ria, ponderamos cada uno de los casos según su probabilidad: tiempo efectivo de acceso = 0,80 X 120 + 0,20 X 220 = 140 nanosegundos. En este ejemplo, vemos que se experimenta un aumento del 40 por ciento en el tiempo de acce­ so a memoria (de 100 a 140 nanosegundos). Para una tasa de acierto del 98 por ciento, tendremos tiempo efectivo de acceso = 0,98 x 120 + 0,02 x 220 = 12 2 nanosegundos. Esta tasa de acierto mejorada genera sólo un 22 por ciento de aumento en el tiempo de acceso. Exploraremos con más detalle el impacto de la tasa de acierto sobre el TLB en el Capítulo 9.

8.4.3 Protección La protección de memoria en un entorno paginado se consigue mediante una serie de bits de pro­ tección asociados con cada marco. Normalmente, estos bits se mantienen en la tabla de páginas. Uno de los bits puede definir una página como de lectura-escritura o de sólo lectura. Toda refe­ rencia a memoria pasa a través de la tabla de páginas con el fin de encontrar el número de marco correcto. Al mismo tiempo que se calcula la dirección física, pueden comprobarse los bits de pro-

262

Capítulo 8 Memoria principal

tección para verificar que no se esté haciendo ninguna escritura en una página de sólo le Todo intento de escribir una página de sólo lectura provocará una interrupción hardware al si; ma operativo (o una violación de protección de memoria). Podemos ampliar fácilmente este enfoque con el fin de proporcionar un nivel más fino de i tección. Podemos diseñar un hardware que proporcione protección de sólo lectura, de lecti escritura o de sólo ejecución, o podemos permitir cualquier combinación de estos accesos, propj donando bits de protección separados para cada tipo de acceso. Los intentos ilegales provoca una interrupción hardware hacia el sistema operativo. Generalmente, se suele asociar un bit adicional con cada entrada de la tabla de páginas; uní válido-inválido. Cuando se configura este bit como “válido”, la página asociada se encontrará* el espacio de direcciones lógicas del proceso y será, por tanto, una página legal (o válida! Cuando se configura el bit como “inválido”, la página no se encuentra en el espacio de direccíoS nes lógicas del proceso. Las direcciones ilegales se capturan utilizando el bit válido-inválido. EL sistema operativo configura este bit para cada página, con el fin de permitir o prohibir el acceso? a dicha página. V Suponga, por ejemplo, que en un sistema con un espacio de direcciones de 14 bits (0 a 16383)/^ tenemos un programa que sólo debe utilizar las direcciones comprendidas entre 0 y 10468. Dadoun tamaño de página de 2 KB, tendremos la situación mostrada en la Figura 8.12. Las direcciones de las páginas 0,1, 2, 3, 4 y 5 se convierten normalmente mediante la tabla de páginas, pero cual­ quier intento de generar una dirección en las páginas 6 o 7, sin embargo, se encontrará con el que bit válido-inválido está configurado como inválido, por lo que la computadora generará una inte ­ rrupción hacia el sistema operativo (referencia de página inválida). Observe que este esquema genera un problema: puesto que el programa sólo se extiende hasta :; la dirección 10468, todas las referencias que se hagan más allá de dicha dirección serán ilegales.;; Sin embargo, las referencias a la página 5 están clasificadas como válidas, por lo que los accesos a las direcciones que van hasta la posición 12287 son válidas. Sólo las direcciones comprendidas^ entre 12288 y 16383 están marcadas como inválidas. Este problema surge como resultado del; tamaño de página de 2 KB y refleja el problema de la fragmentación interna que sufren los meca­ nismos de paginación. 7ígv.“">r‘ i

f

página 0

00000

número de marco página 0

página 1

página 1

página 2

página 2 página 3 página 4 10.468

12.287

bit válido-inválido

"4V .-7i-v■A ‘8 *V*§

1

IV:

página 3 página 4

página 5 tabla de páginas

página 5

91"? «

Figura 8.12 Bit válido (v)-inválido (i) en una tabla de páginas.

8.4 Paginación

263

Los procesos raramente utilizan todo su rango de direcciones. De hecho, muchos procesos sólo emplean una pequeña fracción del espacio de direcciones que tiene disponible. Sería un desper­ dicio, en estos casos, crear una tabla de páginas con entradas para todas las páginas del rango de direcciones. La mayor parte de esta tabla permanecería sin utilizar, pero ocupando un valioso espacio de memoria. Algunos sistemas proporcionan mecanismos hardware especiales, en la forma de un registro de longitud de la tabla de páginas (PTLR, page-table length register), para indicar el tamaño de la tabla de páginas. Este valor se compara con cada dirección lógica para veri­ ficar que esa dirección se encuentre dentro del rango de direcciones válidas definidas para el pro­ ceso. Si esta comprobación fallara, se produciría una interrupción de error dirigida al sistema operativo.

8.4.4 Páginas com partidas Una ventaja de la paginación es la posibilidad de compartir código común. Esta consideración es particularmente importante en un entorno de tiempo compartido. Considere un sistema que de soporte a 40 usuarios, cada uno de los cuales esté ejecutando un editor de texto. Si el editor de texto está compuesto por 150 KB de código y 50 KB de espacio de datos, necesitaremos 8000 KB para dar soporte a los 40 usuarios. Sin embargo, si se trata de código reentrante (o código puro), podrá ser compartido, como se muestra en la Figura 8.13. En ella podemos ver un editor de tres páginas (cada página tiene 50 KB de tamaño, utilizándose un tamaño de página tan grande para simplificar la figura) compartido entre los tres procesos. Cada proceso tiene su propia página de datos. El código reentrante es código que no se auto-modifica; nunca cambia durante la ejecución. De esta forma, dos o más procesos pueden ejecutar el mismo código al mismo tiempo. Cada proceso tendrá su propia copia de los registros y del almacenamiento de datos, para albergar los datos requeridos para la ejecución del proceso. Por supuesto, los datos correspondientes a dos procesos distintos serán diferentes.

0 1

tabla de páginas para P, proceso

- ed 1

~W-.W datos t*-

2

datos 3 ‘

3

Ted tV

4 ” ed 2~.

P 1

ed 2 5 ed 3 datos 2

tabla de páginas para p

6

ed 3

7

datos 2

proceso P2 _3

8

4

_6 _2

9 10

tabla de páginas para p proceso P,

Figura 8.13 Compartición de código en un entorno paginado.

Capítulo 8 Memoria principal

264

Sólo es necesario mantener en la memoria física una copia del editor. La tabla de páginas de cada usuario se corresponderá con la misma copia física del editor, pero las páginas de datos se harán corresponder con marcos diferentes. Así, para dar soporte a 40 usuarios, sólo necesitaremos una copia del editor (150 KB), más 40 copias del espacio de datos de 50 KB de cada usuario. El espacio total requerido será ahora de 2.150 KB, en lugar de 8.000 KB, lo que representa un ahorro considerable. También pueden compartirse otros programas que se utilicen a menudo, como por ejemplo compiladores, sistemas de ventanas, bibliotecas de tiempo de ejecución, sistemas de base de datos, etc. Para poder compartirlo, el código debe ser reentrante. El carácter de sólo-lectura del código compartido no debe dejarse a expensas de la corrección de ese código, sino que el propio sistema operativo debe imponer esta propiedad. La compartición de memoria entre procesos dentro de un sistema es similar a la compartición del espacio de direcciones de una tarea por parte de las hebras de ejecución, descrita en el Capítulo 4. Además, recuerde que en el Capítulo 3 hemos descrito la memoria compartida como un método de comunicación interprocesos. Algunos sistemas operativos implementan la memo- ria compartida utilizando páginas compartidas. ,La organización de la memoria en páginas proporciona numerosos beneficios, además de per­ mitir que varios procesos compartan las mismas páginas físicas. Hablaremos de algunos de los otros beneficios derivados de este esquema en el Capítulo 9.

8.5

Estructura de la tabla de páginas En esta sección, vamos a explorar algunas de las técnicas más comunes para estructurar la tabla ' de páginas. ■

8.5.1 Paginación jerárquica La mayoría de los sistemas informáticos modernos soportan un gran espacio de direcciones lógi­ cas (232 a 264). En este tipo de entorno, la propia tabla de páginas llega a ser excesivamente gran-; de. Por ejemplo, considere un sistema con un espacio lógico de direcciones de 32 bits. Si el tamaño de página en dicho sistema es de 4 KB (212), entonces la tabla de páginas puede estar compues­ ta de hasta un millón de entradas (232/ 212). Suponiendo que cada entrada esté compuesta por 4 bytes, cada proceso puede necesitar hasta 4 MB de espacio físico de direcciones sólo para la tabla de páginas. Obviamente, no conviene asignar la tabla de páginas de forma contigua en memoria principal. Una solución simple a este problema consiste en dividir la tabla de páginas en fragmen­ tos más pequeños y podemos llevar a cabo esta división de varias formas distintas. Una de esas formas consiste en utilizar un algoritmo de paginación de dos niveles, en el que la propia tabla de páginas está también paginada (Figura 8.14). Recuerde nuestro ejemplo de una máquina de 32 bits con un tamaño de página de 4 KB; una dirección lógica estará dividida en un número de página de 20 bits y un desplazamiento de página de 12 bits. Puesto que la tabla de páginas está paginada, el número de páginas se divide a su vez en un número de página de 10 bits y un desplazamiento de página delO bits. De este modo, una dirección lógica tendría la estructu­ ra siguiente: número de página

10

10

desplazamiento de página

12

donde px es un índice a la tabla de páginas externa y p2 es el desplazamiento dentro de la página de la tabla de páginas externa. El método de traducción de direcciones para esta arquitectura se muestra en la Figura 8.15. Puesto que la traducción de las direcciones se realiza comenzando por la tabla de páginas externa y continuando luego por la interna, este esquema también se conoce con el nombre de tabla de páginas con correspondencia (mapeo) directa.

8.5 Estructura de la tabla de páginas

265

tabla de páginas externa

tabla de páginas memoris

Figura 8.14 Un esquema de tabla de páginas en dos niveles. dirección lógica

Pi

P2

d

tabla de páginas externa página de la tabla de páginas

Figura 8.15 Traducción de una dirección para una arquitectura de paginación en dos niveles de 32 bits. La arquitectura VAX tam bién soporta una variante del m ecanism o de paginación en dos nive­ les. El VAX es una m áquina de 32 bits con un tamaño de página de 512 bytes. El espacio lógico de direcciones de un proceso se divide en cuatro secciones iguales, cada una de las cuales está com ­ puesta de 2 30 bytes. Cada sección representa una parte distinta del espacio lógico de direcciones de un proceso. Los primeros 2 bits de m ayor peso de la dirección lógica designan la sección apro­ piada, los siguientes 21 bits representan el núm ero lógico de página de dicha sección y los 9 bits finales representan un desplazam iento dentro de la página deseada. Particionando la tabla de páginas de esta m anera, el sistem a operativo puede dejar particiones sin utilizar hasta que un proceso las necesite. Una dirección en la arquitectura VAX tiene la estruc­ tura siguiente: sección

página

desplazamiento

266

Capítulo 8 Memoria principal

donde s designa el número de la sección, p es un índice a la tabla de páginas y d es el despí miento dentro de la página. Aunque se utiliza este esquema, el tamaño de una tabla de pá« de un sólo nivel para un proceso VAX que utilice una sección es de 221 bits * 4 bytes por entra 8 MB. Para reducir aún más la utilización de memoria principal, la arquitectura VAX pagiá tablas de páginas de los procesos de usuario. Para un sistema con un espacio lógico de direcciones de 4 bits, un esquema de paginación dos niveles ya no resulta apropiado. Para ilustrar este punto, supongamos que el tamaño de l na en dicho sistema fuera de 4 KB (212). En este caso, la tabla de páginas estaría compuest^f hasta 252 entradas. Si utilizáramos un esquema de paginación en dos niveles, las tablas de págjn internas podrían tener (como solución más fácil) una página de longitud, es decir, contener! entradas de 4 bytes. Las direcciones tendrían la siguiente estructura: página externa

página interna desplazamiento

La tabla de páginas externas estará compuesta de 242 entradas, es decir, 2U bytes. La fon obvia para evitar tener una tabla tan grande consiste en dividir la tabla de páginas externa enl mentos más pequeños. Esta técnica se utiliza también en algunos procesadores de 32 bits, pa aumentar la flexibilidad y la eficiencia. Podemos dividir la tabla de páginas externas de varias formas. Podemos paginar la tabla i páginas externa, obteniendo así un esquema de paginación en tres niveles. Suponga que la tabí de páginas externa está formada por páginas de tamaño estándar (210 entradas o 212 bytes); espacio de direcciones de 64 bits seguirá siendo inmanejable: segunda página externa

pagina externa

32

10

rL

pagina interna

desplazamiento

;Pi

10

12

La tabla de páginas externas seguirá teniendo 234 bytes de tamaño. ^ El siguiente paso sería un esquema de paginación en cuatro niveles, en el que se paginaría tam--J bién la propia tabla de páginas externas de segundo nivel. La arquitectura SPARC (con direcciona-J miento de 32 bits) permite el uso de un esquema de paginación en tres niveles, mientras que la arquitectura 68030 de Motorola, también de 32 bits, soporta un esquema de paginación en cuatro niveles. Para las arquitecturas de 64 bits, las tablas de páginas jerárquicas se consideran, por lo gene- : ral, inapropiadas. Por ejemplo, la arquitectura UltraSPARC de 64 bits requeriría siete niveles de paginación (un número prohibitivo de accesos a memoria) para traducir cada dirección lógica.

8.5.2 Tablas de páginas hash Una técnica común para gestionar los espacios de direcciones superiores a 32 bits consiste en uti­ lizar una tabla hash de páginas, donde el valor hash es el número de página virtual. Cada entra­ da de la tabla hash contiene una lista enlazada de elementos que tienen como valor hash una misma ubicación (con el fin de tratar las colisiones). Cada elemento está compuesto de tres campos: (1) el número de página virtual, (2) el valor del marco de página mapeado y (3) un punto del siguiente elemento de la lista enlazada. El algoritmo funciona de la forma siguiente: al número de página virtual de la dirección vir­ tual se le aplica una función hash para obtener un valor que se utiliza como índice para la tabla hash. El número de página virtual se compara con el campo 1 del primer elemento de la lista enla­ zada. Si hay una correspondencia, se utiliza el marco de página correspondiente (campo 2) para formar la dirección física deseada. Si no se produce una correspondencia, se exploran las subsi­ guientes entradas de la lista enlazada hasta encontrar el correspondiente número de página vir­ tual. Este esquema se muestra en la Figura 8.16.

8.5 Estructura de la tabla de páginas

267

tabla hash Figura 8.16 Tabla de páginas hash. También se ha propuesto una variante de este esquema que resulta más adecuada para los espacios de direcciones de 64 bits. Esta variante utiliza tab las de p ágin as en clú ster, que son simi­ lares a las tablas de páginas hash, salvo porque cada entrada de la tabla hash apunta a varias pági­ nas (como por ejemplo 16) en lugar de a una sola página. De este modo, una única entrada de la tabla de páginas puede almacenar las correspondencias (mapeos) para múltiples marcos de pági­ na física. Las tablas de páginas en cluster son particularmente útiles para espacios de direcciones d isp ersos en los que las referencias a memoria son no continuas y están dispersas por todo el espacio de direcciones.

8.5.3 Tablas de páginas invertidas Usualmente, cada proceso tiene una tabla de páginas asociada. La tabla de páginas incluye una entrada por cada página que el proceso esté utilizando (o un elemento por cada dirección virtual, independientemente de la validez de ésta). Esta representación de la tabla resulta natural, ya que los procesos hacen referencia a las páginas mediante las direcciones virtuales de éstas. El sistema operativo debe entonces traducir cada referencia a una dirección física de memoria. Puesto que la tabla está ordenada según la dirección virtual, el sistema operativo podrá calcular dónde se encuentra en la tabla la entrada de dirección física asociada y podrá utilizar dicho valor directa­ mente. Pero una de las desventajas de este método es que cada tabla de página puede estar com­ puesta por millones de entradas. Estas tablas pueden ocupar una gran cantidad de memoria física, simplemente para controlar el modo en que se están utilizando otras partes de la memoria física. Para resolver este problema, podemos utilizar una tabla de páginas invertida. Las tablas de páginas invertidas tienen una entrada por cada página real (o marco) de la memoria. Cada entra­ da está compuesta de la dirección virtual de la página almacenada en dicha ubicación de memo­ ria real, e incluye información acerca del proceso que posee dicha página. Por tanto, en el sistema sólo habrá una única tabla de páginas y esa tabla sólo tendrá una entrada por cada página de memoria física. La Figura 8.17 muestra la operación de una tabla de páginas invertida. Compárela con la Figura 8.7, donde se muestra el funcionamiento de una tabla de páginas estándar. Las tablas de páginas invertidas requieren a menudo que se almacene un identificador del espacio de direc­ ciones (Sección 8.4.2) en cada entrada de la tabla de páginas, ya que la tabla contiene usualmente varios espacios de direcciones distintos que se hacen corresponder con la memoria física. Almacenar el identificador del espacio de direcciones garantiza que cada página lógica de un pro­ ceso concreto se relacione con el correspondiente marco de página física. Como ejemplos de siste­ mas que utilizan las tablas de páginas invertidas podemos citar el PowerPC y la arquitectura UltraSPARC de 64 bits.

268

Capítulo 8 Memoria principal

tabla de páginas

Figura 8.17 Tabla de páginas invertida. Para ilustrar este método, vamos a describir una versión simplificada de la tabla de páginasj invertida utilizada en IBM RT. Cada dirección virtual del sistema está compuesta por una tripleta s a6ííStíES3^»5Gtk í| l^ .'V Í . ,*S, exclüsiveLock.releaseO;' . ; .

-» IP3 ..ui

’ // esto bloquea a', la segunda mitad^de.1 archivo

/** Ahora leer los'" datos

.

{

■ - ^f i l >a l l y t « r é >. >*1 if. (exclusiv ---•"- - ’■• ’ exclusiveLdcfefrelease ( ) if (sharedLoclT T^" niiXD'U* \? sharedLÓck'. reiease {-) ; ¿i v “' ■ jt'-S '* .

<

*

compartido

■/

// liberar el bloqueo exclüsiveLock.release (); } cafch (java.i o .IOException ioe) System.err.println(ioe); ¿ _

.** .

-

.■>ki *■ x

•___________

Figuraíl ÓIV^Ejémplo de Moqueo de archivos en Java. cS ¡sr-g w ^ j£T

¿,.

-

bloqueo exclusivo, el sistem a operativo im pedirá a todos los demás procesos que accedan al archi­ vo bloqueado. Por ejem plo, suponga que un proceso adquiere un bloqueo exclusivo sobre el archi­ vo s y s t e m . lo a . Si tratam os de abrir s y s t e m . l o g desde otro proceso (por ejem plo, un editor de texto), el sistem a operativo im pedirá dicho acceso hasta que se libere el bloqueo exclusivo. Esta

10.1 Concepto de archivo

339

prohibición tendrá lugar incluso si el editor de textos se ha escrito de forma que no adquiera explí­ citamente el bloqueo. Alternativamente, si el bloqueo es del tipo sugerido, el sistema operativo no impedirá que el editor de textos adquiera un acceso a sy stem . lo g . En este caso, será necesario escribir el editor de textos de modo que adquiera manualmente el bloqueo antes de acceder al archivo. En otras palabras, si el esquema de bloqueo es obligatorio, el sistema operativo garanti­ za la integridad de los bloqueos, mientras que para los bloqueos sugeridos, es responsabilidad de los desarrolladores software garantizar que se adquieran y liberen apropiadamente los distintos bloqueos. Como regla general, los sistemas operativos Windows adoptan un mecanismo de blo­ queo obligatorio, mientras que los sistemas UNIX emplean bloqueos sugeridos. El uso de los bloqueos de archivo requiere que se adopten las mismas precauciones que para la sincronización normal de procesos. Por ejemplo, los programadores que estén desarrollando software para sistemas con bloqueo obligatorio deben tener cuidado en mantener los bloqueos de archivo exclusivos únicamente mientras estén accediendo al archivo; en caso contrario, impedi­ rían que otros procesos accedieran también al archivo. Además, debe tomarse alguna medida para garantizar que dos o más procesos no se interbloqueen al tratar de adquirir bloqueos sobre archi­ vos.

10.1.3 Tipos de archivo Cuando diseñamos un sistema de archivos (de hecho, cuando diseñamos todo un sistema opera­ tivo) siempre debemos considerar si el sistema operativo debe reconocer y soportar el concepto de tipo de archivo. Si un sistema operativo reconoce el tipo de un archivo, podrá operar con ese archivo de formas razonables. Por ejemplo, uno de los errores más comunes es que un usuario trate de imprimir la versión objeto o versión binaria de un programa. Esta operación produce nor­ malmente información sin sentido; sin embargo, sí que se podría imprimir correctamente el con­ tenido de ese archivo si el sistema operativo sabe que el archivo está en formato objeto o formato binario. Una técnica común para implementar los tipos de archivo consiste en incluir el tipo como parte del nombre de archivo. El nombre se divide en dos partes: un nombre y una extensión, usualmen­ te separadas por un carácter de punto (Figura 10.2). De esta forma, el usuario y el sistema opera­ tivo pueden determinar, con sólo analizar el nombre, cuál es el tipo de cada archivo. Por ejemplo, la mayoría de los sistemas operativos permiten a los usuarios especificar los nombres de archivo como una secuencia de caracteres seguida de un punto y terminada por una extensión formada por caracteres adicionales. Por ejemplo de nombres de archivo podríamos citar resume.doc, Server,java y ReaderThread.c. El sistema utiliza la extensión para indicar el tipo del archivo y el tipo de operaciones que pueden realizarse con dicho archivo. Por ejemplo, sólo los archivos con exten­ sión .com, .exe o .bat pueden ejecutarse. Los archivos .com y .exe son dos tipos de archivos ejecuta­ bles binarios, mientras que un archivo .bat es un archivo de procesamiento por lotes que contiene, en formato ASCII, una serie de comandos dirigidos al sistema operativo. MS-DOS sólo reconoce unas pocas extensiones, pero los programas de aplicación también utilizan las extensiones para indicar los tipos de archivo en los que están interesadas. Por ejemplo, los ensambladores esperan que los archivos fuente tengan una extensión .asm, y el procesador de textos Microsoft Word espe­ ra que sus archivos terminen con una extensión .doc. Estas extensiones no son obligatorias, por lo que un usuario podría especificar un archivo sin la extensión (para ahorrarse unas cuantas pulsa­ ciones de tecla) y la aplicación buscará un archivo que tenga el nombre especificado y la extensión necesaria. Puesto que estas extensiones no están soportadas por el sistema operativo, pueden con­ siderarse como “sugerencias” dirigidas a las aplicaciones que operan con las mismas. Otro ejemplo de la utilidad de los tipos de archivo podemos extraerlo del sistema operativo TOPS-20. Si el usuario trata de ejecutar un programa objeto cuyo archivo fuente ha sido modifi­ cado (o editado) desde que se produjo el archivo objeto, el archivo fuente se recompilará automá­ ticamente. Esta función garantiza que el usuario siempre ejecute un archivo objeto actualizado. En caso contrario, el usuario podría perder una cantidad de tiempo considerable ejecutando el anti­ guo archivo objeto. Para que esta función sea posible, el sistema operativo debe poder diferenciar el archivo fuente del archivo objeto, con el fin de verificar la fecha en que cada archivo fue creado

Capítulo 10 Interfaz del sistema de archivos

F ig u ra 1 0 .2

Tipos com unes d e archivo.

o modificado por última vez, así como determinar el lenguaje del programa puente (para utilizar el compilador correcto). Considere, también, el sistema operativo Mac OS X. En este sistema, cada archivo tiene un tipo, como por ejemplo TEXT (para los archivos de texto) o APPL (para las aplicaciones). Cada archivo tiene también un atributo de creador, que contiene el nombre del programa que lo creó. Este atri­ buto es configurado por el sistema operativo durante la llamada c r e a t e (), por lo que su uso es impuesto y soportado por el propio sistema. Por ejemplo, un archivo producido por un procesa­ dor de textos tendrá como creador el nombre del procesador de textos. Cuando el usuario abra dicho archivo, haciendo doble clic con el ratón sobre el icono que lo representa, el procesador de textos se invoca automáticamente y el archivo se carga en memoria, listo para ser editado. El sistema UNIX utiliza un simple n ú m e r o m á g ic o almacenado al principio de algunos archi­ vos para indicar, aproximadamente, el tipo del archivo: programa ejecutable, archivo de procesa­ miento por lotes (o s c rip t d e la shell), archivo PostScript, etc. No todos los archivos tienen números mágicos, por lo que la funcionalidad del sistema no puede basarse exclusivamente en esta información. UNLX tampoco almacena el nombre del programa que creó el archivo. En UNIX sí que se permiten las sugerencias en forma de extensión del nombre del archivo, pero estas exten­ siones ni son obligatorias ni el sistema operativo depende de ellas; principalmente, su objetivo es ayudar a los usuarios a determinar el tipo de contenido del archivo. Esas extensiones pueden ser utilizadas o ignoradas por cada aplicación concreta, correspondiendo dicha decisión al programa­ dor de la aplicación!

10.1.4 Estructura de los archivos Los tipos de archivo también pueden usarse para indicar la estructura interna del archivo. Como hemos mencionado en la Sección 10.1.3, los archivos fuente y objeto tienen estructuras que se corresponden con las expectativas de los programas que se van a encargar de leerlos. Además, ciertos archivos deben adaptarse a una estructura^requerida, comprensible por parte del sistema operativo. Por ejemplo, el sistema operativo requiere que los archivos ejecutables tengan una

10.1 Concepto de archivo

341

estructura concreta, para poder determ inar en qué parte de la m em oria cargar el archivo y dónde está ubicada la prim era instrucción. Algunos sistem as operativos am plían esta idea y utilizan un conjunto de estructuras de archivos soportadas por el sistem a, con una serie de operaciones espe­ ciales para m anipular los archivos que tengan dichas estructuras. Por ejem plo, el sistem a operati­ vo VM S de D EC tiene un sistem a de archivos que soporta tres estructuras de archivo definidas. Este punto nos lleva a una de las desventajas de que el sistem a operativo soporte m últiples estructuras de archivo: el tam año resultante del sistem a operativo es excesivo. Si el sistem a ope­ rativo define cinco tipos distintos de estructuras, necesitará contener el código para soportar esas estructuras de archivo. A dem ás, todo archivo puede necesitar definirse com o uno de los tipos de archivo soportados por el sistem a operativo. Cuando una aplicación nueva requiera inform ación estructurada en alguna form a que no esté soportada por el sistem a operativo, pueden aparecer graves problem as. Por ejem plo, suponga que un sistem a soporta dos tipos de archivo: archivos de texto (com­ puestos de caracteres ASCII separados por un retom o de carro y un avance de línea) y archivos eje­ cutables binarios. En estas condiciones, si nosotros (com o usuarios) querem os definir un archivo cifrado para evitar que el contenido pueda ser leído por personas no autorizadas, es posible que ninguno de los dos tipos de archivo nos resulte apropiado. El archivo cifrado no está com puesto por líneas de texto A SC II, sino que está form ado por bits (aparentem ente) aleatorios. Al mismo tiem po, aunque parezca ser un archivo binario, no es ejecutable. Com o resultado, es posible que tengam os que ignorar o m alutilizar el m ecanism o de tipos de archivo del sistem a operativo, o renunciar a im plem entar nuestro esquem a de cifrado. A lgunos sistem as operativos im ponen (y soportan) un núm ero m ínim o de estructuras de archi­ vo. Este enfoque ha sido adoptado en UN IX, en M S-D O S y en otros sistem as. UN IX considera que cada archivo es una secuencia de bytes de 8 bits, sin que el sistem a operativo realice ninguna inter­ pretación de dichos bits. Este esquem a proporciona una m áxim a flexibilidad, pero un escaso soporte: cada program a de aplicación debe incluir su propio código para interpretar los archivos de entrada de acuerdo con la estructura apropiada. Sin em bargo, todos los sistem as operativos soportan al m enos una estructura (la de los archivos ejecutables) para que el sistem a pueda car­ gar y ejecutar program as. El sistem a operativo M acintosh tam bién soporta un núm ero m ínim o de estructuras de archi­ vo. Este sistem a espera que los archivos contengan dos partes: un subarchivo de recursos y un subarchivo de datos. El subarchivo de recursos contiene inform ación de interés para el usuario; por ejem plo, alm acena las etiquetas de los botones m ostrados por el program a. Un usuario extran­ jero podría re-etiquetar estos botones en su propio idiom a y el sistem a operativo M acintosh pro­ porciona herram ientas para perm itir la m odificación de la inform ación contenida en el subarchivo de recursos. El subarchivo de datos contiene código de program a o datos, que son los contenidos tradicionales de los archivos. Para realizar la misma tarea en un sistem a UN IX o M S-D O S, el pro­ gram ador necesitaría m odificar y recom pilar el código fuente, a m enos que definiera su propio archivo de datos m odificable con el usuario. Claram ente, resulta útil que el sistem a operativo soporte estructuras que vayan a ser utilizadas frecuentem ente y que ahorren al program ador un esfuerzo sustancial. La existencia de muy pocas estructuras hace que la tarea de program ación resulte poco cóm oda, m ientras que si existen dem asiadas el sistem a operativo crece sin m edida y los program adores pueden llegar a verse confundidos.

10.1.5 Estructura interna de los archivos Internam ente, localizar un determ inado desplazam iento dentro de un archivo puede ser com pli­ cado para el sistem a operativo. Los sistem as de disco suelen tener un tam año de bloque bien defi­ nido, que está determ inado por el tamaño de un sector. Todas las operaciones de E / S de disco se realizan en unidades de un bloque (registro físico) y todos los bloques tienen el mismo tamaño. Resulta poco probable que el tam año del registro físico se corresponda exactam ente con la longi­ tud deseada de los registros lógicos. Los registros lógicos pueden incluso variar en longitud. Una solución com ún a este problem a consiste en em paquetar varios registros lógicos dentro de los blo­ ques físicos.

342

Capítulo 10 Interfaz del sistema de archivos

Por ejemplo, el sistema operativo UNIX define todos los archivos como simples flujos de bytes. Cada byte es direccionable de manera individual, a partir de su desplazamiento con respecto al principio (o al final) del archivo. En este caso, el tamaño de registro lógico es un byte. El sistema de archivos empaqueta y desempaqueta automáticamente los bytes en los bloques físicos del disco (por ejemplo, 512 bytes por bloque) según sea necesario. El tamaño del registro lógico, el tamaño del bloque físico y la técnica de empaquetamiento .... . determinan cuántos registros lógicos se almacenarán en cada bloque físico. El empaquetamiento puede ser realizado por el programa de aplicación del usuario o por el sistema operativo. En cualquiera de los dos casos, podemos considerar el archivo como una secuencia de bloques. Todas las funciones de E/S básicas operan en términos de bloques. La conversión entre registros lógicos y bloques físicos es un problema software relativamente simple. Puesto que el espacio de discos se asigna siempre en bloques, generalmente se desperdiciará una parte del último bloque de cada archivo. Si cada bloque tiene 512 bytes, por ejemplo, enton­ ces un archivo de 1949 bytes tendría cuatro bloques (2048 bytes); los últimos 99 bytes se desper­ diciarían. Ese desperdicio que se produce al tratar de mantener la información almacenada en unidades de bloques (en lugar de bytes) se conoce con el nombre de fragmentación interna. Todos los sistemas de archivos sufren el problema de la fragmentación interna; además, cuanto = más grande sea el tamaño del bloque, mayor será esa fragmentación interna.

10.2 Métodos de acceso Los archivos almacenan información. Cuando hace falta utilizarla, es necesario acceder a esta información y leerla en la memoria de la computadora. Puede accederse a la información conte­ nida en el archivo en varias formas distintas. Algunos sistemas sólo proporcionan un método de acceso para los archivos, mientras que otros sistemas, como por ejemplo los de IBM, soportan muchos métodos de acceso y elegir el método adecuado para cada aplicación concreta constituye uno de los principales problemas de diseño.

10.2.1 Acceso secuencial El método de acceso más simple es el acceso secuencial. La información del archivo se procesa por orden, un registro después de otro. Este modo de acceso es, como mucho, el más común; por ejemplo, los editores y compiladores suelen acceder a los archivos de esta forma. Las lecturas y escrituras constituyen el grueso de las operaciones realizadas con un archivo. Una operación de lectura (leer siguiente) lee la siguiente porción del archivo e incrementa automá­ ticamente un puntero de archivo, que controla la ubicación de E/S. De forma similar, la operación de escritura (escribir siguiente) añade información al final del archivo y hace que el puntero avan­ ce hasta el final de los datos recién escritos (el nuevo final del archivo). Dichos archivos podrán reinicializarse para situar el puntero al principio de los mismos y, en algunos sistemas, puede que un programa sea capaz de saltar hacia adelante o hacia atrás n registros, para algún cierto valor entero n, quizás sólo para n = 1. El acceso secuencial, que se ilustra en la Figura 10.3, está basado en un modelo de archivo que se corresponde con las cintas magnéticas y funciona tanto en los dis­ positivos de acceso secuencial como en los de acceso aleatorio.

10.2.2 Acceso directo Otro método es el acceso directo o acceso relativo. Un archivo está compuesto de registros lógi­ cos de longitud fija que permiten a los programas leer y escribir registros rápidamente, sin nin­ gún orden concreto. El método de acceso directo se basa en un modelo de archivos que se corresponde con los dispositivos de disco, ya que los discos permiten el acceso aleatorio a cual­ quier bloque de un archivo. Para el acceso directo, el archivo se considera como una secuencia numerada de bloques o registros. Por tanto, podemos leer el bloque 14, luego leer el bloque 53 y luego escribir el bloque 7. No existe ninguna restricción en cuanto ai orden de lectura o escritura en los archivos de acceso directo.

10.2 Métodos de acceso

343

posición actual

inicio

lectura o escritura ;*►

Figura 10.3 Archivo de acceso secuencial. Los archivos de acceso directo tienen una gran utilidad para el acceso inm ediato a grandes can­ tidades de inform ación; las bases de datos suelen im plem entarse con archivos de este tipo. Cuando se recibe una consulta relativa a un tem a concreto, se calcula qué bloque contiene la res­ puesta y luego se lee ese bloque directam ente para proporcionar la inform ación deseada. C om o ejem plo sim ple, en un sistem a de reserva de billetes de avión, podríamos alm acenar toda la inform ación acerca de un vuelo concreto (por ejem plo, el vuelo 713) en el bloque identifi­ cado por el núm ero de vuelo. Así, el núm ero de asientos disponibles en el vuelo 713 estará alm a­ cenado en el bloque 713 del archivo de reservas. Para alm acenar inform ación acerca de un conjunto de m ayor tam año, com o por ejem plo un conjunto de personas, podríam os calcular una función hash con los nom bres de las personas o realizar una búsqueda en un pequeño índice alm acenado en m em oria para determ inar el bloque que hay que leer o analizar. En el m étodo de acceso directo, las operaciones de archivo deben m odificarse para incluir el núm ero de bloque com o parám etro. Así, tendrem os operaciones tales com o leer n, donde n es el núm ero de bloque, en lugar de leer siguiente, y escribir n, en lugar de escribir siguiente. Una téc­ nica alternativa consiste en retener las operaciones de leer siguiente y escribir siguiente, com o con el acceso secuencial, y añadir una operación posicionar archivo en n, donde n minúscula es el núm ero de bloque. Entonces, para realizar una operación leer n, ejecutaríam os primero posicionar en n y luego leer siguiente. El núm ero de bloque proporcionado por el usuario al sistem a operativo es norm alm ente un núm ero de b lo q u e relativo. Un núm ero de bloque relativo es un índice referido al com ienzo del archivo. Así, el prim er bloque relativo del archivo será el 0, el siguiente será el 1, etc., aun cuando la dirección de disco absoluta real del bloque pueda ser 14703 para el prim er bloque y 3192 para el segundo. La utilización de núm eros de bloque relativos perm ite al sistem a operativo decidir dónde hay que colocar el archivo (lo que se denom ina el problem a de asignación, que se analiza en el Capítulo 11) y ayuda a im pedir que el usuario acceda a porciones del sistem a de archivos que no form en parte de su archivo. A lgunos sistem as hacen que los números de bloque relativos com iencen en 0, m ientras que otros com ienzan en 1 . ¿Cóm o satisface el sistem a una solicitud referida al registro N de un archivo? Suponiendo que tengam os una longitud de registro lógico igual a N, la solicitud relativa al registro N se transfor­ ma en una solicitud de E/S donde se piden L bytes com enzando en la ubicación L * (N) dentro del archivo (suponiendo que el prim er registro sea N = 0). Puesto que los registros lógicos tienen un tam año fijo, tam bién resulta fácil leer, escribir o borrar un registro. No todos los sistem as de archivos soportan tanto el acceso secuencial com o el acceso directo a los archivos. Algunos sistem as sólo perm iten el acceso secuencial a archivos, m ientras que otros sólo soportan el acceso directo. A lgunos sistem as requieren que los archivos se definan com o secuenciales o directos en el m om ento de crearlos y a dichos archivos sólo se podrá acceder de una form a que sea coherente con su declaración. Podem os sim ular fácilm ente el acceso secuencial en un archivo de acceso directo sim plem ente m anteniendo una variable cp que defina nuestra posi­ ción actual, com o se ilustra en la Figura 10.4. Sin em bargo, sim ular un archivo de acceso directo sobre un archivo de acceso secuencial es extrem adam ente poco eficiente y engorroso.

10.2.3 Otros m étodos de acceso Pueden construirse otros m étodos de acceso por encim a del m étodo de acceso directo. Estos m éto­ dos im plican, generalm ente, la construcción de un índice para el archivo. El índice, como los indi-

344

Capítulo 10 Interfaz del sistema de archivos

acceso secuencial

í"—J ._■w

^féef-siguih _ .>.4

im plem entación para el acceso directo

leer cprw’A - ' rfcf.

i.i"-

~

■ escnbir

-*i ''i F ig u ra 10 .4

.'

?■p ~ cp +J->

‘ ‘

Simulación del acceso secuencial sobre un archivo de acceso directo.

ces de la parte posterior de un libro, contiene punteros a los distintos bloques. Para encontrar un registro dentro del archivo, primero exploramos el índice y luego usamos el puntero para acceder al archivo directamente y para hallar el registro deseado. Por ejemplo, un archivo con una lista de precios de venta podría incluir los códigos de produc­ to universales (UPC, universal product code) de los elementos, junto con los precios asociados. Cada registro consistirá en un UPC de 10 dígitos y un precio de 6 dígitos, lo que nos da una longi­ tud de registro de 16 bytes. Si nuestro disco tiene 1024 bytes por bloque, podremos almacenar 64 registros en cada bloque. Un archivo con 120000 registros ocuparía unos 2000 bloques (2 millones de bytes). Si mantenemos el archivo almacenado según el código UPC, podemos definir un índice compuesto por el primer valor UPC de cada bloque. Este índice tendría 2000 entradas de 10 dígi­ tos cada una, es decir, 20000 bytes, y podría por tanto almacenarse en memoria. Para hallar el pre­ cio correspondiente a un elemento concreto, podemos hacer una búsqueda binaria en el índice y, con esta búsqueda, determinar exactamente qué bloque contiene el registro deseado, después de lo cual accederemos a este bloque. Esta estructura nos permite explorar un archivo de gran tama­ ño con un número relativamente bajo de operaciones de E/S. Con los archivos de gran tamaño, el propio archivo del -índice puede ser demasiado grande como para almacenarlo en la memoria. Una solución consiste en crear un índice del archivo índi­ ce. El archivo de índice principal contendría punteros a los archivos de índice secundarios que a su vez apuntarían a los propios elementos de datos. Por ejemplo, el método de acceso secuencial indexado de IBM (ISAM, indexed sequential-access method) utiliza un pequeño índice maestro que apunta a los bloques de disco de un índice secundario. Los bloques de índice secundario apuntan a los propios índices del archivo. El archivo se almacena ordenado según una determinada clave. Para localizar un elemento concreto, primero hacemos una búsqueda binaria en el índice princi­ pal, que nos proporcionará el número de bloque de índice secundario. A continuación, leemos este bloque y utilizamos de nuevo una búsqueda binaria para hallar el bloque que contiene el registro deseado. Finalmente, se realiza una búsqueda secuencial dentro de este bloque. De esta forma, puede localizarse cualquier registro a partir de su clave mediante, como mucho,

archivo de índice F ig u ra 10.5

archivo relativo

Ejem plos de archivo de índice y dá archivos relativos.

10.3 Estructura de directorios

345

dos lecturas de acceso directo. La Figura 10.5 muestra una situación similar, implementada mediante los archivos de índice y archivos relativos de VMS.

10.3 Estructura de directorios Hasta este punto, hemos estado analizando “un sistema de archivos”. En realidad, los sistemas pueden tener cero o más sistemas de archivos y los sistemas de archivos pueden ser de tipos varia­ dos. Por ejemplo, un sistema Solaris típico puede tener unos cuantos sistemas de archivos UFS, un sistema de archivos VFS y algunos sistemas de archivos NFS. En el Capítulo 11 se analizan los deta­ lles de la implementación de los sistemas de archivos. Los sistemas de archivos de las computadoras pueden, por tanto, tener una gran complejidad. Algunos sistemas almacenan millones de archivos en terabytes de disco. Para gestionar todos estos datos, necesitamos organizados de alguna manera y esta organización implica el uso de directorios. En esta sección, vamos a analizar el tema de la estructura de directorios. Pero prime­ ro, es necesario explicar algunas características básicas de la estructura de almacenamiento.

10.3.1 Estructura de alm acenam iento Un disco (o cualquier dispositivo de almacenamiento que sea lo suficientemente grande) puede utilizarse completamente para un sistema de archivos. Sin embargo, en ciertas ocasiones es dese­ able colocar múltiples sistemas de archivos en un mismo disco o utilizar partes de un disco para un sistema de archivos y otras partes para otras cosas, como por ejemplo para espacio de inter­ cambio o como espacio de disco sin formato (ra w ). Estas partes se conocen con diversos nombres, como p a r tic io n e s , fra n ja s o (en el mundo IBM) m in id is c o s . Podemos crear un sistema de archivos en cada una de estas partes del disco. Como veremos en el siguiente capítulo, las partes también pueden combinarse para formar estructuras de mayor tamaño, conocidas con el nombre de v o lú ­ m e n e s , y también pueden crearse sistemas de archivos en dichos volúmenes. Pero por el momen­ to, en aras de la claridad, utilizaremos el término volumen simplemente para referimos a un espacio de almacenamiento que alberga un sistema de archivos. Cada volumen puede considerar­ se como si fuera un disco virtual. Los volúmenes pueden también almacenar múltiples sistemas operativos, permitiendo que un sistema se inicie en cualquiera de ellos y ejecute dicho sistema operativo. Cada volumen que contenga un sistema de archivos debe también contener información acer­ ca de los archivos almacenados en el sistema. Esta información se almacena como entrada en un d ire c to rio d e d is p o s itiv o o ta b la d e c o n te n id o s d e l v o lu m e n . El directorio del dispositivo (más comúnmente conocido simplemente como d ir e c to rio ) almacena información de todos los archivos de dicho volumen, como por ejemplo el nombre, la ubicación, el tamaño y el tipo. La Figura 10.6 muestra una organización típica de un sistema de archivo.

partición A -<

- disco 2

►disco 1 partición C partición B ■<

> disco 3

Figura 10.6 Una organización típica de un sistema de archivos.

346

Capítulo 10 Interfaz del sistema de archivos

10.3.2 Introducción a ios directorios El directorio puede considerarse como una tabla de símbolos que traduce los nombres de archivó! a sus correspondientes entradas de directorio. Si adoptamos esta visión, es fácil comprender que| el propio directorio puede organizarse de muchas formas. Queremos poder insertar entradas,* borrar entradas, buscar unq entrada conociendo su nombre y enumerar todas las entradas det| directorio. En esta sección, vamos a examinar diversos esquemas para definir la estructura lógica : del sistema de directorios. í Cuando consideremos una estructura de directorio concreta, tendremos que tener presentes las^ operaciones que habrá que realizar con el directorio: • Búsqueda de un archivo. Tenemos que poder explorar la estructura de directorio para encontrar la entrada correspondiente a un archivo concreto. Puesto que los archivos tienen! nombres simbólicos y los nombres similares pueden indicar que existe una relación entre los archivos, también queremos poder encontrar todos los archivos cuyos nombres se correspondan con un patrón concreto. • C rear un archivo. Es necesario poder crear nuevos archivos y añadirlos al directorio.

• B orrar un archivo. Cuando un archivo ya no es necesario, queremos poder eliminarlo del' directorio. • Listar un directorio. Tenemos que poder enumerar los archivos contenidos en un directo­

rio y el contenido de la entrada de directorio correspondiente a cada uno de los archivos de la lista. • R enom brar un archivo. Puesto que el nombre de un archivo representa su contenido para, los usuarios, debemos poder cambiar el nombre cuando el contenido o el uso del archivo varíen. Renombrar un archivo puede también significar que se modifique su posición den­ tro de la estructura de directorio. • R ecorrer el sistem a de archivos. Puede que queramos acceder a todos los directorios y a todos los archivos contenidos dentro de una estructura de directorios. Para conseguir una mayor fiabilidad, resulta conveniente guardar el contenido y la estructura de todo el siste­ ma de archivos a intervalos regulares. A menudo, esto se suele hacer copiando todos los archivos en una cinta magnética. Esta técnica proporciona una copia de seguridad para el caso de que se produzca un fallo del sistema. Además, si un archivo ya ha dejado de utili­ zarse, el archivo puede copiarse en cinta y puede liberarse el espacio de disco ocupado por ese archivo, con el fin de que lo reutilicen otros archivos. En las siguientes secciones, vamos a describir los esquemas más comunes que se usan para definir la estructura lógica de un directorio.

10.3.3 Directorio de un único nivel La estructura de directorio más simple es el directorio de un único nivel. Todos los archivos están contenidos en el mismo directorio, que resulta fácil de mantener y de comprender (Figura 10.7). Sin embargo, un directorio de un único nivel tiene limitaciones significativas cuando el núme­ ro de archivos se incrementa o cuando el sistema tiene más de un usuario. Puesto que todos los archivos se encuentran en el mismo directorio, deberán tener nombres distintivos. Si dos usuarios llaman a su archivo de datos test, se violará la regla de unicidad de los nombres. Por ejemplo, en una clase de programación, 23 estudiantes denominaron al programa correspondiente a la segun­ da de las prácticas realizadas prog2, mientras que otros 11 lo denominaron assignl. Aunque los nombres de archivo se seleccionan, por regla general, de modo que reflejen el contenido del archi­ vo, a menudo están limitados en longitud, lo que complica la tarea de hacer que esos nombres de archivos sean unívocos. El sistema operativo MS-DOS sólo permite utilizar nombres de archivo de once caracteres; UNIX, por el contrario, permite hasta 255 caracteres. Incluso aunque sólo haya un usuario en un directorio de un único nivel, p u ed e que ese usua­ rio tenga dificultades para recordar los nombres de todos los archivos a m e d id a que se increm en-

10.3 Estructura de directorios

archivos o

% j

o

F ig u ra 1 0 .7

O

O

O

347

Ó

Directorio de un único nivel.

ta el número de archivos. No resulta extraño que un usuario tenga cientos de archivos en su sis­ tema informático y un número igual de archivos adicionales en otros sistemas. Controlar todos esos archivos es una tarea extremadamente compleja.

10.3.4 Directorio en dos niveles Como hemos visto, los directorios de un único nivel conducen a menudo a que exista confusión entre los nombres de archivo de los distintos usuarios. La solución estándar consiste en crear un directorio separado para cada usuario. En la estructura de directorio de dos niveles, cada usuario tiene su propio directorio de archi­ vos de usuario (UFD, user file directory). Cada uno de los UFD tiene una estructura similar, pero sólo incluye los archivos de un único usuario. Cuando un trabajo de un usuario se inicia o cuan­ do un usuario se conecta al sistema, se explora el directorio maestro de archivos (MFD, master file directory) del sistema. El MFD está indexado por el nombre de usuario o por el número de cuenta y cada una de sus entradas apunta al UFD de dicho usuario (Figura 10.8). Cuando un usuario hace referencia a un archivo concreto, sólo se explora su propio UFD. Por tanto, cada uno de los usuarios puede tener archivos con el mismo nombre, siempre y cuando los nombres de archivo dentro de cada UFD sean unívocos. Para crear un archivo para un usuario, el sistema operativo sólo explora el UFD de ese usuario para comprobar si ya existe otro archivo con el mismo nombre. Para borrar un archivo, el sistema operativo confina su búsqueda al UFD local y no puede, por tanto, borrar accidentalmente un archivo de otro usuario que tenga el mismo nombre. Los propios directorios de usuario deben poder crearse y borrarse según sea necesario. Para ello se ejecuta un programa especial del sistema, con el nombre de usuario apropiado y la corres­ pondiente información de cuenta. El programa crea un nuevo UFD y añade una entrada para él en el MFD. La ejecución de este programa puede estar restringida a los administradores del sistema. La asignación de espacio de disco para las direcciones de usuario puede gestionarse mediante las técnicas explicadas en el Capítulo 11 para los propios archivos. Aunque la estructura de directorio en dos niveles resuelve el problema de la colisión de nom­ bres, sigue teniendo ciertas desventajas. Esta estructura aísla efectivamente a un usuario y otro y ese aislamiento es una ventaja cuando los usuarios son completamente independientes, pero puede llegar a ser una desventaja cuando los usuarios quieren cooperar en una cierta tarea y poder acceder a los archivos del otro. Algunos sistemas simplemente no permiten que un usuario acce­ da a los archivos locales de otro usuario.

directorio maestro usuario 1 usuario 2 usuario 3 usuario 4 de archivos

directorio de archivos del usuario

O O O O

ü

©

© o

Figura 10.8 Estructura de directorios en dos niveles.

o

o

348

Capítulo 10 Interfaz del sistema de archivos

Si queremos permitir ese tipo de acceso, cada usuario debe tener la posibilidad de especificarla un archivo que pertenezca al directorio de otro usuario. Para denominar a los archivos de mané|| ra unívoca en una estructura de directorio de dos niveles, debemos proporcionar tanto el nombngl de usuario como el nombre del archivo. Un directorio en dos niveles puede verse como unjH estructura de árbol, o de árbol invertido, de altura 2. La raíz del árbol es el MFD y sus descendiere! tes directos son los UFD. Los descendientes de los UFD son los propios archivos, que actúan comol hojas del árbol. Al especificar un nombre de usuario y un nombre de archivo, estamos definiendo! una ruta dentro del árbol que va desde la raíz (el MFD) hasta una hoja (el archivo especificadoj|| Por tanto, un nombre de usuario y un nombre de archivo definen un nombre de ruta. Cada archi-i vo del sistema tiene un nombre de ruta y para designar a un archivo de manera unívoca, el usuá^j rio debe conocer el nombre de ruta del archivo deseado. s| Por ejemplo, si el usuario A quiere acceder a su propio archivo denominado test, simplemente! puede referirse a él como test. Sin embargo, para acceder al archivo denominado test del usuario! B (cuyo nombre de entrada de directorio es userb), puede que tenga que utilizar la notación| / userb/ test. Cada sistema tiene su propia sintaxis para nombrar los archivos contenidos en losí directorios que no pertenecen al propio usuario. J Se necesita una sintaxis adicional para especificar el volumen de un archivo. Por ejemplo, en! MS-DOS un volumen se especifica mediante una letra seguida de un carácter de dos puntos. Por? tanto, una especificación de archivo podría tener el siguiente aspecto C:/ userb/ test. Algunos sis-! temas van todavía más allá y separan las partes de la especificación correspondientes al volumen,j al nombre del directorio y al nombre del archivo. Por ejemplo, en VMS, el archivo login.com puedej especificarse como u:[sst.jdeck]login.com;l, donde u es el nombre del volumen, sst es el nombre delj directorio, jdeck es el nombre del subdirectorio y 1 es el número de versión. Otros sistemas sirreí plemente tratan el nombre del volumen como parte del nombre de directorio. El primer nombrej que se proporcione será el del volumen y el resto se referirá al directorio y al archivo. Por ejem-1 pío, / u/ pbg/ test podría especificar el volumen u, el directorio pbg y el archivo test. | Un caso especial de esta situación es el que se refiere a los archivos del sistema. Los programas'; proporcionados como parte del sistema (cargadores, ensambladores, compiladores, rutinas de uti-x lidad, bibliotecas, etc.) están generalmente definidos como archivos. Cuando se proporcionan los comandos apropiados al sistema operativo, el cargador carga estos archivos y los ejecuta. Muchos; intérpretes de comandos simplemente tratan dicho comando como el nombre de un archivo que hay que cargar y ejecutar. Tal como hemos definido el sistema de directorios, este nombre de archivos se buscaría en el UFD actual. Una solución consiste en copiar los archivos del sistema dentro de cada UFD, pero copiar todos los archivos del sistema implicaría desperdiciar una can­ tidad enorme de espacio (si los archivos del sistema requieren 5 MB, soportar a 12 usuarios reque­ riría 5 X 12 = 60 MB simplemente para las copias de los archivos del sistema). La solución estándar consiste en complicar el procedimiento de búsqueda ligeramente. Se defi­ ne un directorio de usuario especial para contener los archivos del sistema (por ejemplo, el usua­ rio 0). Cada vez que se proporciona un nombre de archivo para cargarlo, el sistema operativo analiza primero el UFD local; si encuentra allí el archivo, lo utiliza, pero si no lo encuentra, el sis­ tema explora automáticamente el directorio de usuario especial que contiene los archivos del sistema. La secuencia de directorios que se exploran cada vez que se proporciona un nombre de archivos se denomina ruta de búsqueda. La ruta de búsqueda puede emplearse para contener un número ilimitado de directorios que haya que explorar cada vez que se proporcione un nombre de comando. Este método es el más utilizado en UNIX y MS-DOS. También pueden diseñarse los sistemas de modo que cada usuario tenga su propia ruta de búsqueda.

10.3.5 Directorios con estructura de árbol Una vez que hemos visto cómo puede contemplarse un directorio en dos niveles como un árbol de dos niveles, la generalización natural consiste en ampliar la estructura de directorios para que sea un árbol de altura arbitraria (Figura 10.9). Esta generalización permite a los usuarios crear sus propios subdirectorios y organizar sus archivos correspondientemente. Los árboles son la estruc­ tura de directorio más común. Cada árbol tiene un directorio raíz y todos los archivos del sistema tienen un nombre de ruta distintivo.

10.3 Estructura de directorios

349

l l S

i ■hex ' POQPt

F ig u ra 1 0 .9

Estructura de directorio en forma de árbol.

Cada directorio (o subdirectorio) contiene un conjunto de archivos o subdirectorios. Un direc­ torio es simplemente otro archivo, pero que se trata de forma especial. Todos los directorios tie­ nen el mismo formato interno. Un bit de cada entrada de directorio define si esa entrada es un archivo (0) o un subdirectorio (1). Se utilizan llamadas al sistema especiales para crear y borrar los directorios. En el uso normal, cada proceso tiene un directorio actual. Ese directorio actual debe contener la mayor parte de los archivos que actualmente interesen al proceso. Cuando se hace referencia a un archivo, se explora el directorio actual. Si se necesita un archivo que no se encuentre en el direc­ torio actual, entonces el usuario deberá normalmente especificar un nombre de ruta o cambiar el directorio actual, para situarse en el directorio donde fue almacenado ese archivo. Para cambiar de directorio, se proporciona una llamada al sistema que toma como parámetro un nombre de directorio y lo utiliza para redefinir el directorio actual. Así, el usuario puede cambiar su directo­ rio actual cada vez que lo desee. Entre una llamada al sistema change d i r e c t o r y (cambiar directorio) y la siguiente, todas las llamadas al sistema open analizarán el directorio actual en busca del archivo especificado. Observe que la ruta de búsqueda puede o no contener una entra­ da especial que signifique “el directorio actual". El directorio actual inicial de la shell de inicio de sesión de un usuario se designa en el momen­ to de comenzar el trabajo del usuario o en el momento en que el usuario inicia la sesión. El siste­ ma operativo analiza el archivo de cuentas (o alguna otra ubicación predefinida) con el fin de localizar la entrada correspondiente a este usuario (para propósitos de contabilización). En el archivo de cuentas habrá almacenado un puntero (o el nombre) al directorio inicial del usuario. Este puntero se copia en una variable local de ese usuario que especifica el directorio actual ini­ cial del mismo. A partir de esa shell, pueden arrancarse otros procesos. El directorio actual de cada subproceso será, usualmente, el directorio actual que su proceso padre tenía en el momento de crear el subproceso. Los nombres de ruta pueden ser de dos tipos: absolutos y relativos. Un nombre de ruta absolu­ to comienza en la raíz y sigue una ruta descendente hasta el archivo especificado, indicando los nombres de los directorios que componen la ruta. Un nombre de ruta relativo define una ruta a partir del directorio actual. Por ejemplo, en el sistema de archivos con estructura de árbol de la Figura 10.9, si el directorio actual es rooi/ssdll'nail, entonces el nombre de ruta relativo prt/first hará referencia al mismo archivo que el nombre de ruta absoluto root/spell/mail/prt/first.

350

Capítulo 10 Interfaz del sistema de archivos

Permitir a un usuario definir sus propios subdirectorios hace que el usuario pueda imponed una estructura a sus archivos. Esta estructura puede dar como resultado que se utilicen directo-” rios separados para los archivos asociados con diferentes temas (por ejemplo, el subdirectorio qu|| nosotros creamos para almacenar el texto de este libro) o con diferentes tipos de información (pójl ejemplo, el directorio programs puede contener programas puente; el directorio bin puede almace-¡ nar todos los binarios, etc.). *§ Una decisión interesante de política dentro de un directorio con estructura de árbol es la que se refiere a qué hacer si se borra un directorio. Si el directorio está vacío, podemos simplemente borrar la entrada correspondiente dentro del directorio que lo contuviera. Sin embargo, suponga que el directorio que hay que borrar no está vacío, sino que contiene varios archivos o subdirec­ torios. Podemos adoptar una de dos soluciones. Algunos sistemas, como MS-DOS, no permiten: borrar un directorio a menos que esté vacío; por tanto, para borrar un directorio, el usuario debe* primero borrar todos los archivos contenidos en ese directorio. Si existen subdirectorios, este pro-, cedimiento debe aplicarse recursivamente a los mismos, para que también puedan ser borrados. Esta técnica puede dar como resultado que haya que realizar una gran cantidad de trabajo. Otra técnica alternativa, como la adoptada por el comando rm de UNIX, consiste en proporcionar una opción: cuando se hace una solicitud para borrar un directorio, también se borran todos los archt’ vos y subdirectorios de dicho directorio. Las dos técnicas son fáciles de Ímplementar y la decisión entre una y otra es cuestión de la política que se adopte. La última de las dos políticas menciona­ das es más cómoda, pero también es más peligrosa, porque puede eliminarse una estructura de directorios completa con un único comando. Si se ejecutara por error ese comando, puede que fuera necesario restaurar un gran número de archivos y directorios (suponiendo que exista una copia de seguridad). Con un sistema de directorios con estructura de árbol, podemos permitir que los usuarios acce­ dan a los archivos de otros usuarios, además de acceder a los suyos propios. Por ejemplo, el usua­ rio B puede acceder a un archivo del usuario A especificando su nombre de ruta; el usuario B puede especificar un nombre de ruta relativo o absoluto. Alternativamente, el usuario B puede cambiar el subdirectorio actual para situarse en el directorio del usuario A y acceder al archivo simplemente proporcionando su nombre. Una ruta a un archivo en un directorio con estructura de árbol puede ser más larga que las 1 rutas típicas de los directorios en dos niveles. Para permitir a los usuarios acceder a los programas sin tener que recordar esos largos nombres de ruta, el sistema operativo Macintosh automatizaba la búsqueda de los programas ejecutables. Este sistema mantiene un archivo, denominado Desktop File, que contiene los nombres y ubicaciones de todos los programas ejecutables que ha encontra­ do. Cuando se añade un nuevo disco duro o disquete al sistema, o cuando se accede a la red, el sistema operativo recorre la estructura de directorios en busca de programas ejecutables que pueda haber en el dispositivo y almacena la información pertinente. Este mecanismo soporta la funcionalidad de ejecución mediante doble clic que hemos descrito anteriormente. Un doble clic sobre un archivo hace que se lea su atributo de creador y que se explore el archivo Desktop File en busca de una correspondencia. Si se encuentra una correspondencia, se inicia el programa ejecu­ table apropiado, utilizando como entrada el archivo sobre el que se ha hecho clic. La familia Microsoft Windows de sistemas operativos (95,98, NT, 2000, XP) mantiene una estructura de direc­ torio en dos niveles ampliada, asignando letras de unidad a los dispositivos y a los volúmenes (Sección 10.4).

10.3.6 Directorios en un grato acíclico Considere dos programadores que estén trabajando en un proyecto conjunto. Los archivos asocia­ dos con dicho proyecto pueden almacenarse en un subdirectorio, separándolos de otros proyec­ tos y archivos de los dos programadores. Pero, como ambos programadores son igualmente responsables del proyecto, ambos quieren que el subdirectorio se encuentre dentro de su propio directorio. El subdirectorio común debe, por tanto, ser compartido. Cada directorio o archivo com­ partido existirá en el sistema de archivos en dos (o más) lugares simultáneamente.

1 0 3 Estructura de directorios

Figura 10 .10

351

Estructura de directorio en grafo acíclico.

Una estructura en árbol prohíbe la compartición de archivos o directorios. Por el contrario, un grafo acíclico (es decir, un grafo sin ningún ciclo) permite que los directorios compartan subdirectorios de archivos (Figura 10.10). El mismo archivo o subdirectorio puede estar en dos directorios diferentes. El grafo acíclico es una generalización natural del esquema de directorio con estructu­ ra de árbol. Es importante observar que un archivo (o directorio) compartido no es lo mismo que dos copias del archivo. Con dos copias cada programador puede ver su propia copia en lugar del ori­ ginal, pero si un programador modifica el archivo, esos cambios no se reflejarán en la copia del otro. Con un archivo compartido, sólo existe un archivo real, por lo que cualquier cambio realiza­ do por una persona será inmediatamente visible para la otra. La compartición es particularmente importante para los subdirectorios; cada nuevo archivo creado por una persona aparecerá auto­ máticamente en todos los subdirectorios compartidos, Cuando las personas trabajan en grupo, todos los archivos que quieran compartir pueden colo­ carse dentro de un directorio. El UFD de cada miembro del grupo contendrá como subdirectorio este directorio de archivos compartidos. Incluso en el caso de un único usuario, la organización de archivos del usuario puede requerir que algún archivo sea colocado en diferentes subdirecto­ rios. Por ejemplo, un programa escrito para un proyecto concreto podría tener que almacenarse tanto en el directorio correspondiente a todos los programas como en el directorio correspondien­ te a ese trayecto. Los archivos y subdirectorios compartidos pueden implementarse de diversas formas. Una manera bastante común, ejemplificada por muchos de los sistemas UNIX, consiste en crear una nueva entrada de directorio denominada enlace (link). Un enlace es, en la práctica, un puntero a otro archivo o subdirectorio. Por ejemplo, un enlace puede implementarse como un nombre de ruta absoluto o relativo. Cuando se realiza una referencia a un archivo, exploramos el directorio y, si la entrada del directorio está marcada como enlace, entonces se incluye el nombre del archi­ vo real dentro de la información del enlace. Para resolver el enlace, utilizamos el nombre de ruta con el fin de localizar el archivo real. Los enlaces pueden identificarse fácilmente por el formato que tienen en la entrada de directorio (o bien porque tengan un tipo especial en aquellos sistemas que soporten los tipos) y son, en la práctica, punteros indirectos nominados. El sistema operativo ignora estos enlaces a la hora de recorrer los árboles de directorio, con el fin de preservar la estruc­ tura acíclica del sistema. Otra técnica común para la implementación de archivos compartidos consiste simplemente en duplicar toda la información acerca de esos archivos en todos los directorios que compartan esos archivos. Así, ambas entradas serán idénticas. Un enlace es, claramente, diferente de la entrada ..•oOnA .l¡r„,'tr>rin. por lo oue ambas entradas no son iguales; sin embargo, las entradas de

352

Capítulo 10 Interfaz del sistema de archivos

directorio duplicadas hacen que el original y la copia sean indistinguibles. El principal problema con las entradas de directorio duplicadas es el de mantener la coherencia cuando se modifica un archivo. Una estructura de directorio en forma de grafo acíclico es más flexible que una estructura sim­ ple en árbol, pero también es más compleja. Es necesario prestar cuidadosa atención a determina­ dos problemas. Los archivos podrán tener ahora múltiples nombres de ruta absoluta. En consecuencia, puede haber nombres de archivo distintos que hagan referencia a un mismo archi­ vo. La situación es similar al problema de los alias en los lenguajes de programación. Si estamos intentando recorrer el sistema de archivos completo (para encontrar un archivo, para acumular estadísticas sobre todos los archivos o para copiar todos los archivos en un dispositivo de copia de seguridad) este problema cobra una gran importancia, ya que no conviene recorrer las estruc­ turas compartidas más de una vez. Otro problema es el que se refiere al borrado. ¿Cuándo puede desasignarse y reutilizarse el espacio asignado a un archivo compartido? Una posibilidad consiste en eliminar el archivo cuan­ do un usuario cualquiera lo borre, pero esta acción puede dejar punteros colgantes al archivo que ha dejado de existir. El problema puede complicarse si los punteros de archivo restantes contie­ nen direcciones reales de disco y ese espacio se reutiliza subsiguientemente para otros archivos; en ese caso, esos punteros colgantes pueden apuntar a un lugar cualquiera de esos nuevos ar­ chivos. En un sistema en el que la compartición se implemente mediante enlaces simbólicos, la situa­ ción es algo más fácil de manejar. El borrado de un enlace no tiene por qué afectar al archivo ori­ ginal, ya que sólo se elimina el enlace. Si lo que se elimina es la propia entrada del archivo, se desasignará el espacio del archivo, dejando que los enlaces cuelguen. Podemos buscar estos enla­ ces y eliminarlos también, pero a menos que se mantenga con cada archivo una lista de los enla­ ces asociados esta búsqueda puede ser bastante costosa. Alternativamente, podemos dejar esos enlaces hasta que se produzca un intento de utilizarlos, en cuyo momento podemos determinar que el archivo del nombre indicado por el enlace no existe y que no podemos resolver el nombre del enlace; el acceso se tratará exactamente' igual que se haría con cualquier otro nombre legal de archivo (en este caso, el diseñador del sistema debe considerar cuidadosamente qué hacer cuan­ do se borra un archivo y se crea otro archivo del mismo nombre, antes de que se utilice un enla­ ce simbólico al archivo original). En el caso de UNIX, cuando se borra un archivo se dejan los enlaces simbólicos y es responsabilidad del usuario darse cuenta de que el archivo original ya no existe o ha sido sustituido. Microsoft Windows (todas las versiones) utiliza la misma técnica. Otra técnica de borrado consiste en preservar el archivo hasta que se borren todas las referen­ cias al mismo. Para implementar esta técnica, debemos disponer de algún mecanismo para deter­ minar que se ha borrado la última referencia al archivo. Podríamos mantener una lista de todas las referencias al archivo (entradas de directorio o enlaces simbólicos). Cuando se establece un enlace o una copia de la entrada de directorio, se añade una nueva entrada a la lista de referen­ cias al archivo. Cuando se borra un enlace o una entrada de directorio, eliminamos la correspon­ diente entrada de la lista. El archivo se borrará cuando se vacíe su lista de referencias al archivo. El problema con esa técnica es el tamaño variable, y potencialmente grande, de la lista de refe­ rencias al archivo. Sin embargo, no es necesario que mantengamos la lista completa, sino que bas­ taría con mantener sólo un recuerdo del número de referencia. Añadir una nueva entrada de directorio o un nuevo enlace hará que se incremente el contador de referencias, mientras que borrar un enlace o una entrada hará que el contador se decremente. Cuando el contador sea 0, podrá borrarse el archivo, ya que no habrá más referencias a él. El sistema operativo UNIX utiliza esta técnica para los enlaces no simbólicos (o enlaces duros), manteniendo un contador de referen­ cias dentro del bloque de información del archivo (o inodo; véase el Apéndice A.7.2). Prohibiendo en la práctica que existan múltiples referencias a los directorios, podemos mantener una estructu­ ra de grafo acíclico. Para evitar problemas como los que se acaban de describir, algunos sistemas no permiten que existan enlaces o directorios compartidos. Por ejemplo, en MS-DOS, la estructura de directorio es una estructura de árbol en lugar de un grafé? acíclico.

10.3 Estructura de directorios

353

10.3.7 Directorio en form a de grafo general Uno de los problemas más graves que afectan a la utilización de una estructura en forma de grafo acíclico consiste en garantizar que no exista ningún ciclo. Si comenzamos con un directorio en dos niveles y permitimos a los usuarios crear subdirectorios, obtendremos un directorio con estructu­ ra de árbol. Es fácil darse cuenta de que la simple adición de nuevos archivos y subdirectorios a una estructura en árbol existente preserva la naturaleza y la estructura de árbol de ese directorio. Sin embargo, si añadimos enlaces a un directorio existente con estructura de árbol, la estructura en árbol se destruye, dando como resultado una estructura en grafo simple (Figura 10.11). La principal ventaja de un grafo acíclico es la relativa simplicidad de los algoritmos requeridos para recorrer el grafo y para determinar cuándo no existen ya más referencias a un archivo. Necesitamos poder evitar el tener que recorrer las secciones compartidas de un grafo cíclico dos veces, principalmente por razones de rendimiento. Si acabamos de explorar un subdirectorio com­ partido de gran tamaño en busca de un archivo concreto sin haber llegado a encontrarlo, necesi­ tamos evitar tener que volver a explorar dicho subdirectorio otra vez, ya que esa segunda búsqueda sería una pérdida de tiempo. Si permitimos que existan ciclos en el directorio, necesitaremos, de la misma manera evitar tener que buscar cualquier componente dos veces, por razones tanto de corrección como de ren­ dimiento. Un algoritmo mal diseñado podría provocar un bucle infinito que estuviera exploran­ do el ciclo continuamente, sin terminar nunca. Una solución consiste en limitar arbitrariamente el número de directorio a los que se accederá durante una búsqueda. Un problema similar existe cuando tratamos de determinar si un archivo puede ser borrado. Con las estructuras de directorio en grafo acíclico, un valor de 0 en el contador de referencia sig­ nificará que ya no hay más referencias al archivo o directorio, y que ese archivo puede ser borra­ do. Sin embargo, si existen ciclos, el contador de referencias puede no ser 0 incluso aunque ya no sea posible hacer referencia a un directorio de archivo. Esta anomalía resulta de la posibilidad de auto-referencia (o de un ciclo) en la estructura de directorio. En este caso, generalmente necesita­ mos utilizar un esquema de recolección de memoria para determinar cuándo se ha borrado la últi­ ma referencia y que, en consecuencia, puede reasignarse el espacio de disco. La recolección en memoria implica recorrer todo el sistema de archivos, marcando todos aquellos elementos a los que se pueda acceder. Después, una segunda pasada recopila todo aquello que no esté marcado, incluyéndolo en una lista de espacio libre (puede utilizarse un procedimiento similar de marca­ ción para garantizar que todo recorrido o búsqueda visitará cada elemento del sistema de archi­ vos una vez y sólo una vez). Sin embargo, la recolección de memoria para un sistema de archivos basado en disco consume muchísimo tiempo y raramente se la suele utilizar. La recolección de memoria sólo es necesaria debido a la posible existencia de ciclos dentro del grafo. Por tanto, es mucho más sencillo trabajar con estructuras de grafo acíclico. La-principal difi-

Figura 10.11 Directorio con forma de grafo general.

354

Capítulo 10 Interfaz del sistema de archivos

cuitad es la de evitar que aparezcan ciclos a medida que se añaden nuevos enlaces a la estructu-1 ra. ¿Cómo podemos saber si un nuevo enlace va a completar el ciclo? Existen algoritmos para' detectar la existencia de ciclos en los grafos; sin embargo, estos algoritmos son muy costoso# desde el punto de vista computacional, especialmente cuando el grafo se encuentra almacenado* en disco. Un algoritmo más simple en el caso especial de directorios y enlaces consiste en ignorar? • los enlaces durante el recorrido de los directorios. De este modo, se evitan los ciclos sin necesidad! de efectuar ningún procesamiento adicional. “

10.4 Montaje de sistem as de archivos De la misma forma que un archivo debe abrirse antes de utilizarlo, un sistema de archivos debe montarse para poder estar disponible para los procesos del sistema. Más específicamente, la estruc­ tura de directorios puede estar formada por múltiples volúmenes, que puede montarse para hacer, que estén disponibles dentro del espacio de nombres del sistema de archivos. El proceso de montaje es bastante simple. Al sistema operativo se le proporciona el nombre de: dispositivo y el punto de montaje que es la ubicación dentro de la estructura de archivos a la que* hay que conectar el sistema de archivos que se está montando. Normalmente, el punto de monta-' je será un directorio vacío. Por ejemplo, en un sistema UNIX, un sistema de archivos que conten­ ga los directorios principales de un usuario puede montarse como / home; después, para acceder ■ a la estructura de directorios contenida en ese sistema de archivos, podemos anteponer a los nom­ bres de directorio el nombre ¡home, como por ejemplo en /home/jane. Si montáramos ese sistema; de archivos bajo el directorio /users obtendríamos el nombre de ruta /users/jane, que podríamos utilizar para acceder al mismo directorio. A continuación, el sistema operativo verifica que el dispositivo contiene un sistema de archi-, vos válido. Para ello, pide al controlador del dispositivo que lea el directorio de dispositivo y veri­ fique que ese directorio tiene el formato esperado. Finalmente, el sistema operativo registra en su estructura de directorios que hay un sistema de archivo montado en el punto de montaje especi­ ficado. Este esquema permite al sistema operativo recorrer su estructura de directorios, pasando de un sistema de archivos a otro según sea necesario. Para ilustrar el montaje de archivos, considere el sistema de archivos mostrado en la Figura 10 .1 2 , donde los triángulos representan subárboles de directorios en los que estamos interesados. La Figura 10.12(a) muestra un sistema de archivos existente, mientras que la Figura 10.12(b) mues­ tra un volumen no montado que reside en / device/ dsk. En este punto, sólo puede accederse a los archivos del sistema de archivos existente. La Figura 10.13 muestra los efectos de mostrar en

Figura 10.12 Sistema de archivos, (a) Sistema existente, (b) Volumen no montado:-

10.5 Compartición de archivos

355

/

Figura 10.13 Punto de montaje. / users el volumen que reside en / device/ dsk. Si se desmonta el volumen, el sistema de archivos vuelve a la situación mostrada en la Figura 10.12. Los sistemas imponen una cierta semántica para clarificar la funcionalidad. Por ejemplo, un determinado sistema podría prohibir que se realizara un montaje en un directorio que contuviera archivos, o bien podría hacer que el sistema de archivos montado estuviera disponible en dichos directorios y ocultar los archivos existentes en dicho directorio hasta qué el sistema de archivos se desmontara, en cuyo momento se prohíbe el uso de ese sistema de archivos y se permite el acceso a los archivos originales contenidos en el directorio. Otro ejemplo, un determinado sistema podría permitir que se montara repetidamente el mismo sistema de archivos, en diferentes puntos de montaje; o, por el contrario, podría permitir un único montaje por cada sistema de archivos. Consideremos el ejemplo del sistema operativo Macintosh. Cuando el sistema encuentra un disco por primera vez (los discos duros se localizan en el momento de iniciar el sistema, mientras que los disquetes se detectan cuando se insertan en la unidad), el sistema operativo Macintosh busca un sistema de archivos en el dispositivo. Sí encuentra uno, monta automáticamente el sis­ tema de archivos en el nivel raíz, añadiendo a la pantalla un icono de carpeta cuya etiqueta coin­ cide con el nombre del sistema de archivos (tal como esté almacenado en el directorio del dispositivo). El usuario podrá entonces hacer clic sobre el icono y mostrar el sistema de archivos recién montado. La familia Microsoft Windows de sistemas operativos (95, 98, NT, 2000, XP) mantiene una es­ tructura ampliada de directorio en dos niveles, en la que a los dispositivos en los volúmenes se les asignan letras de unidad. Los volúmenes tienen una estructura de directorio en forma de grafo general asociada con la letra de la unidad. La ruta para un archivo específico toma la forma letraunidad: \ruta\al\archivo. Las versiones más recientes de Windows permiten montar un sistema de archivos en cualquier punto del árbol de directorios, al igual que en UNIX. Los sistemas operativos Windows descubren automáticamente todos los dispositivos y montan todos los sistemas de archi­ vo localizados en el momento de iniciar el sistema. En algunos sistemas, como UNIX, los co­ mandos de montaje son explícitos. Un determinado archivo de configuración del sistema contiene una lista de los dispositivos y puntos de montaje para realizar el montaje automático en el momen­ to de iniciar el sistema, pero pueden ejecutarse otras operaciones de montaje manualmente. Los temas relativos al montaje de sistema de archivos se analizan con más profundidad en la Sección 11.2.2 y en el Apéndice A.7.5.

10.5 Compartición de archivos En las secciones anteriores, hemos explorado los motivos que existen para compartir archivos y algunas de las dificultades que surgen al permitir a los usuarios compartir archivos. Dicha com-

356

Capítulo 10 Interfaz del sistema de archivos

partición de archivos es muy deseable para aquellos usuarios que quieran colaborar y reducir esfuerzo requerido para conseguir desarrollar un programa. Por tanto, los sistemas operativi orientados al usuario deben satisfacer la necesidad de compartir archivos a pesar de las dificuli des inherentes a este mecanismo. En esta sección, vamos a examinar algunos aspectos adicionales de la compartición de ar vos. Comenzaremos analizando diversas cuestiones generales que surgen en el instante en que permite a múltiples usuarios compartir los archivos. Una vez que se permite compartir los archivos a diversos usuarios, el desafío principal consiste en ampliar la compartición a múltiples sisti mas de archivos, incluyendo sistemas de archivos remotos y vamos a analizar también aquí esas dificultades. Finalmente, analizaremos el tema de qué hacer cuando tienen lugar acciones conflic3¡¡ tivas en los archivos compartidos; por ejemplo, si hay múltiples usuarios escribiendo en un archi­ vo, ¿debe permitirse que se lleven a cabo todas las escrituras o el sistema operativo debe, por contrario, proteger las acciones de los usuarios frente a las posibles interferencias con otras seccio-^g nes similares? jg

10.5.1 Múltiples usuarios

4

vm

Cuando un sistema operativo tiene múltiples usuarios, las cuestiones relativas a la compartición? de archivos, a la denominación de archivos y a la protección de archivos cobran una gran impor-ll tancia. Dada una estructura de directorio que permite que los usuarios compartan archivos, el sis-=| tema debe adoptar un papel de mediador en lo que a la compartición de archivos respecta. E|J¡ sistema puede permitir que un usuario acceda a los archivos de otros usuarios de manera predeíÜ terminada, o puede por el contrario requerir que los usuarios concedan explícitamente el acceso á* sus archivos. Estos son los problemas del control de acceso y de la protección, que trataremos enS! la Sección 1Q.6. ... „ yS Para implementar la compartición y los mecanismos de protección, el sistema debe mantene^ más atributos de los archivos y de los directorios que los que se necesitan en un sistema monou-S suario. Aunque históricamente se han adoptado diversos enfoques para satisfacer estos requisi-5 tos, la mayoría de los sistemas han terminado por evolucionar para usar el concepto de propietarioy (o usuario) de un archivo o directorio y el concepto de grupo. El propietario es el usuario que puedes| cambiar los atributos y conceder el acceso y que dispone del máximo grado de control sobre el archivo. El atributo de grupo define un subconjunto de usuarios que pueden compartir el acceso al archivo. Por ejemplo, el propietario de un archivo en un sistema UNIX puede ejecutar todas las = operaciones sobre el archivo, mientras que los miembros del grupo de un archivo sólo pueden eje­ cutar un subconjunto de esas operaciones, y todos los restantes usuarios podrán ejecutar otro sub­ conjunto de operaciones. El propietario del archivo es quien define exactamente qué operaciones pueden ser ejecutadas por los miembros del grupo y por los restantes usuarios. En la siguiente sección proporcionaremos más detalles sobre los atributos relativos a los permisos. Los identificadores del propietario y del grupo de un archivo (o directorio) determinado se almacenan junto con los otros atributos del archivo. Cuando un usuario solicita realizar una ope­ ración sobre un archivo, se puede comparar el ID del usuario con el atributo de propietario para determinar si el usuario solicitante es el propietario del archivo. De la misma manera, pueden compararse los identificadores de grupo. El resultado indicará qué permisos son aplicables. A continuación, el sistema aplicará dichos permisos a la operación solicitada y la autorizará o dene­ gará. Muchos sistemas disponen de múltiples sistemas de archivos locales, incluyendo volúmenes compuestos por un único disco o múltiples volúmenes almacenados en múltiples discos conecta­ dos. En estos casos, los procesos de comprobación de las identidades y de comprobación de los permisos son bastante sencillos, una vez que los sistemas de archivos hayan sido montados.

10.5.2 Sistemas de archivos remotos Don el advenimiento de las redes (Capítulo 16) se ha hecho posible la comunicación entre compu­ tadoras remotas. La interconexión por red permite la compartición de una serie de recursos que

10.5 Compartición de archivos

357

son distribuidos por un campus o incluso por todo el mundo. Uno de los recursos más obvios para compartir son los datos existentes, en la forma de archivos. Con la evolución de las tecnologías de red y de archivos, los métodos de compartición de archi­ vos remotos han ido cambiando. El primer método que se implemento implicaba la transferencia manual de archivos entre dos máquinas mediante programas como f tp. El segundo método prin­ cipal utiliza un sistem a de archivos distribuido (DFS, distributed file system) en el que los direc­ torios remotos son visibles desde una máquina local. En cierta forma, el tercer método, la W orld W ide W eb, es una reversión al primero de los métodos indicados. Se necesita un explorador para poder acceder a los archivos remotos y se utilizan operaciones independientes (esencialmente un envoltorio para f tp) para transferir los archivos. f tp se utiliza tanto para el acceso anónimo como para el acceso autenticado. El acceso anóni­ m o permite al usuario transferir archivos sin disponer de una cuenta en el sistema remoto. La World Wide Web utiliza casi exclusivamente un mecanismo de intercambio anónimo de archivos. DFS requiere una integración mucho más estrecha entre la máquina que está accediendo a los archivos remotos y la máquina que suministra los archivos. Esta integración añade un alto grado de complejidad, que vamos a describir en esta sección. 10.5.2.1

El m odelo cliente-servidor

Los sistemas de archivos remotos permiten a una computadora montar uno o más sistemas de archivos desde una o más máquinas remotas. En este caso, la máquina que contiene los archivos es el servidor, mientras que la máquina que trata de acceder a los archivos es el cliente. La relación cliente-servidor resulta muy común eri las máquinas conectadas por red. Generalmente, el servi­ dor declara ante los clientes que hay un cierto recurso disponible y especifica exactamente de qué recurso se trata (en este caso, qué archivos son) y exactamente para qué clientes está disponible. Un servidor puede dar servicio a múltiples clientes y cada cliente puede utilizar múltiples servi­ dores, dependiendo de los detalles de implementación de cada arquitectura cliente- servidor. El servidor especifica usualmente los archivos disponibles en el nivel de volumen o de direc­ torio. La identificación de los clientes resulta algo más complicada. Un cliente puede estar especi­ ficado por un nombre de red o por otro identificador, como por ejemplo una dirección IP, pero estas identidades pueden ser suplantadas o im itadas. Como resultado de la suplantación, un cliente no autorizado podría obtener acceso al servidor. Otras soluciones más seguras incluyen una autenti­ cación segura del cliente mediante claves cifradas. Desafortunadamente, los mecanismos de segu­ ridad presentan numerosos desafíos,, incluyendo garantizar la compatibilidad del cliente y el servidor (ambos deben usar los mismos algoritmos de cifrado) y la seguridad de los intercambios de claves (las claves interceptadas podrían, de nuevo, permitir un acceso no autorizado). Debido a la dificultad de resolver estos problemas, la solución más común consiste en emplear métodos de autenticación no seguros. En el caso de UNIX y en sus sistema de archivos en red (NFS, network file system), la autentica­ ción tiene lugar, de manera predeterminada, mediante la información de conexión de red del cliente. Según este esquema, los identificadores del usuario en el cliente y en el servidor deben corresponderse; si no lo hacen, el servidor no podrá determinar los derechos de acceso a los archi­ vos. Considere el ejemplo de un usuario que tenga un ID igual a 1000 en el cliente e igual a 2000 en el servidor. Una solicitud emitida por el cliente y dirigida al servidor que se refiera a un archi­ vo específico no podrá ser tratada apropiadamente, ya que el servidor trataría de comprobar si el usuario 1000 tiene acceso al archivo, en lugar de basar esa determinación en el verdadero ID del usuario, que es igual a 2000. En consecuencia, el acceso se concedería o se denegaría basándose en una información de autenticación incorrecta. El servidor debe confiar en que el cliente le presen­ te el ID de usuario correcto. Observe que los protocolos NFS permiten relaciones muchos a muchos, es decir, muchos servidores pueden proporcionar archivos a muchos clientes. De hecho, una máquina determinada puede ser a la vez un servidor para otros dientes NFS y un diente de otros servidores NFS. Una vez que el sistema de archivos remoto haya sido montado, las solicitudes de operaciones con los archivos se envían al usuario por cuenta del usuario a través de la red, utilizando el pro­ tocolo DFS. Normalmente, la solicitud de apertura de un archivo se envía junto con el ID del usua-

358

Capítulo 10 Interfaz del sistema de archivos

rio solicitante. El servidor aplica entonces las comprobaciones de acceso normales para deter nar si el usuario dispone de credenciales para acceder al archivo del modo solicitado. En consé cuencia, la solicitud será concedida o denegada. Si se la concede, se devuelve un descriptor di archivo a la aplicación cliente y esa aplicación puede a partir de ahí realizar lecturas, escrituras i otras operaciones con el archivo. Cuando haya terminado de acceder, el cliente cerrará el archivé El sistema operativo puede aplicar una semántica similar a la del montaje de un sistema de are vos local o puede utilizar una semántica distinta. ■ 10.5.2.2 Sistemas de información distribuidos Para hacer que los sistemas cliente-servidor sean más fáciles de gestionar, los sistemas de infmlift mación distribuidos, también conocidos como servicios de denominación distribuidos, propoi¡|j¡¡ cionan un acceso unificado a la información necesaria para la informática remota. El sistema d

V '

=-

;

Cpbg(CTI\pbg) fü S YSTEM

vl-V

C-;"A

f$ U s e rs (PBG-LAPT0 F\Users)

Add.. Rem ove Allow Deny

Perm issionsforGuest FullControl M odify Read&Execute Read W rite SpecialPerm issions

ü

Forspecialperm issionsorforadvanced6ettings, dickAdvanced. OK

□ -ü3

Advanced

Cancel

Figura 10.14 Gestión de listas de control de acceso en Windows XP. Algunos sistemas operativos monousuario (como M S-D O S y las versiones del sistema operati­ vo Macintosh anteriores a Mac OS X) proporcionan pocos mecanismos de protección de archivos. En aquellos casos en que estos sistemas antiguos están siendo conectados a redes en las que son necesarias la compartición y la comunicación de archivos, se están retroimplementando mecanis­ mos de protección en ellos. Diseñar una determinada funcionalidad para un nuevo sistema ope­ rativo es casi siempre más fácil que añadir una funcionalidad a un sistema operativo existente. Dichas actualizaciones suelen ser menos efectivas y no resultan transparentes. En una estructura de directorios multinivel, necesitamos proteger no sólo los archivos indivi­ duales sino también las colecciones de archivo contenidas en los subdirectorios; en otras palabras, necesitamos proporcionar un mecanismo para la protección de los directorios. Las operaciones de directorio que deben protegerse son algo distintas de las operaciones de archivo. Queremos con­ trolar la protección y borrado de los archivos de un directorio y, además, probablemente quera­ mos controlar si un usuario puede determinar la existencia de un determinado archivo dentro de un directorio. Algunas veces, el conocimiento de la existencia y del nombre de un archivo son sig­ nificativos por sí mismos, por lo que listar el contenido de un directorio debe ser una operación protegida. De forma similar, si un nombre de ruta hace referencia a un archivo dentro de un direc­ torio, debe permitirse al usuario acceder tanto al directorio como al archivo. En aquellos sistemas en los que los archivos puedan tener numerosos nombres de ruta (como por ejemplo los grafos acíclicos o los grafos generales), un cierto usuario puede tener diferentes derechos de acceso a un archivo concreto, dependiendo del nombre de ruta que utilice.

10.7 Resumen

365

.7 Resumen Un archivo es un tipo abstracto de datos definido e implementado por el sistema operativo. Se trata de una secuencia de registros lógicos donde cada registro puede ser un byte, una línea (de longitud fija o variable) o un elemento de datos más complejo. El sistema operativo puede sopor­ tar específicamente diversos tipos de registros o puede dejar dicho soporte a los programas de aplicación. La principal tarea del sistema operativo consiste en mapear el concepto de archivo lógico sobre los dispositivos de almacenamiento físico, como las cintas magnéticas o discos. Puesto que el tamaño del registro físico del dispositivo puede no coincidir con el tamaño del registro lógico, puede que sea necesario empaquetar los registros lógicos en los registros físicos. De nuevo, esta tarea puede ser soportada por el sistema operativo o dejada para que se encargue de ella el pro­ grama de aplicación. Cada dispositivo de un sistema de archivos mantiene una tabla de contenidos del volumen o un directorio del dispositivo en donde se indica la ubicación de los archivos dentro del dispositi­ vo. Además, resulta útil crear directorios que permitan organizar los archivos. Los directorios de un único nivel en los sistemas monousuario hacen que aparezcan problemas de denominación, ya . que cada archivo deberá tener un nombre distintivo. Los directorios en dos niveles resuelven este problema creando un directorio separado por cada usuario; cada usuario tendrá su propio direc­ torio, que contendrá sus propios archivos. El directorio enumera los archivos según su nombre e incluye la información sobre la ubicación del archivo dentro del disco, sobre la longitud del archi­ vo, sobre su tipo, su propietario, la fecha de su creación, la fecha de último uso, etc. La generalización natural de un directorio en dos niveles son los directorios con estructura de árbol. Un directorio con estructura de árbol permite al usuario crear subdirectorios para organi­ zar los archivos. Las estructuras de directorio en forma de grafo acíclico permiten a los usuarios compartir subdirec^WüÜ^yiifl'gWves, pero complican las tareas de búsqueda y de borrado. Una

366

Capítulo 10 Interfaz del sistema de archivos

estructura de grafo general proporciona una flexibilidad completa en lo que a la compartición de archivos y directorios se refiere, pero en ocasiones requiere mecanismos de recolección de memo­ ria para recuperar el espacio de disco no utilizado. Los discos están segmentados en uno o más volúmenes, cada uno de los cuales contiene un sis­ tema de archivos o puede dejarse "sin formato”. Los sistemas de archivos pueden montarse en las estructuras de nombres del sistema, para que estén disponibles para los usuarios. El esquema de nombres varía de un sistema operativo a otro. Una vez montados, los archivos del volumen esta­ rán disponibles para su uso. Los sistemas de archivos pueden desmontarse para impedir el acce­ so a los mismos o con propósitos de mantenimiento. La compartición de archivos depende de la semántica proporcionada por el sistema. Los archi­ vos pueden tener múltiples lectores, múltiples escritores o una serie de límites relativos a la com­ partición. Los sistemas de archivos distribuidos permiten que los hosts clientes monten volúmenes o directorios de los servidores, siempre y cuando puedan comunicarse entre sí a tra­ vés de la red. Los sistemas de archivos remotos presentan diversos desafíos en lo que respecta a la fiabilidad, a las prestaciones y a la seguridad. Los sistemas de información distribuidos mantie­ nen información sobre los usuarios, sobre los hosts y sobre el acceso, de modo que los clientes y servidores puedan compartir información de estado para gestionar el uso y el acceso a los ar­ chivos. Puesto que los archivos son el principal mecanismo de almacenamiento de información en la mayoría de los sistemas informáticos, es necesario proporcionar mecanismos de protección de los archivos. El acceso a los archivos puede controlarse separadamente para cada tipo de acceso: lec­ tura, escritura, ejecución, adición, borrado, listado de directorio, etc. La protección de archivos puede proporcionarse mediante contraseñas, mediante listas de acceso o mediante otras técnicas.

Ejercicios 10.1

Considere un sistema de archivos en el que pueda borrarse un archivo y en el que pueda reclamarse su correspondiente espacio de disco mientras todavía existen enlaces a dicho archivo. ¿Qué problemas pueden surgir si se crea un nuevo archivo en el mismo área de almacenamiento o con el mismo nombre de ruta absoluto? ¿Cómo pueden evitarse estos problemas?

10.2

La tabla de archivos abiertos se utiliza para mantener información acerca de los archivos que están actualmente abiertos. ¿Debe el sistema operativo mantener una tabla separada para cada usuario o simplemente mantener una tabla que contenga referencias a los archi­ vos a los que están accediendo actualmente todos los usuarios? Si dos programas o usua­ rios distintos están accediendo al mismo archivo, ¿deberían existir entradas separadas en la tabla de archivos abiertos?

10.3

¿Cuáles son las ventajas y desventajas de un sistema que proporcione bloqueos obligatorios en lugar de bloqueos sugeridos, cuyo uso se deja a la discreción del usuario?

10.4

¿Cuáles son las ventajas y desventajas de registrar el nombre del programa creador junto con los atributos del archivo (como hace, el sistema operativo Macintosh)?

10.5

Algunos sistemas abren automáticamente un archivo cuando se hace referencia por prime­ ra vez al mismo, y cierran el archivo cuando el trabajo correspondiente termina. Explique las ventajas y desventajas de este esquema, comparado con el esquema más tradicional en el que el usuario tiene que abrir y cerrar el archivo explícitamente.

10.6

Si el sistema operativo supiera que una cierta aplicación va a acceder a los datos de un archi­ vo de forma secuencial, ¿cómo podría aprovechar esta información para aumentar las pres­ taciones?

10.7

Proporcione un ejemplo de aplicación que podría beneficiarse de que el sistema operativo proporcionara soporte para el acceso aleatorio a archivos indexados.

Notas bibliográficas

367

10.8

Explique las ventajas y desventajas de soportar enlaces a archivos que crucen los puntos de montaje (es decir, el enlace hace referencia a un archivo que está almacenado en un volu­ men distinto).

10.9

Algunos sistemas proporcionan mecanismos de compartición de archivos manteniendo una única copia del archivo; otros sistemas mantienen varias copias, una para cada uno de los usuarios que están compartiendo el archivo. Explique las ventajas relativas de cada una de estas técnicas.

10.10 Explique las ventajas y desventajas de asociar con los sistemas de archivos remotos (alma­ cenados en servidores de archivos) una semántica de fallo distinta de la que se asocia con los sistemas de archivos locales. 10.11 ¿Cuáles son las implicaciones de soportar la semántica de coherencia de UNIX para el acce­ so compartido a aquellos archivos que estén almacenados en sistemas de archivos remotos?

Notas bibliográficas Un análisis general de los sistemas de archivos es el que se incluye en Grosshans [1986]. Golden y Pechura [1986] describieron la estructura de los sistemas de archivos para microcomputadoras. Los sistemas de base de datos y sus estructuras de archivos se describen en detalle en Silberschatz et al. [2001]. La primera implementación de una estructura de directorio multinivel es la del sistema MULTICS (Organick [1972]). La mayoría de los sistemas operativos implementan ahora estructuras de directorio multinivel. Entre ellos se incluye Linux (Bovet y Cesati [2002]), Mac OS X (http://wxmo. apple.com/macosx/), Solaris (Mauro y McDougall [2001]) y todas las versiones de Windows, inclu­ yendo Windows 2000 (Solomon y Russinovich [2000]). El sistema de archivos en red (NFS), diseñado por Sun Microsystems, permite distribuir las estructuras de directorio entre una serie de sistemas informáticos conectados por red. NFS se des­ cribe en detalle en el Capítulo 17, mientras que NFS versión 4 se describe en RFC3505 (http://www. ietf.org/rfc/rfc3530. txt). DNS fue propuesto por primera vez por Su [1982] y ha sufrido varias revisiones desde enton­ ces, habiendo Mockapetris [1987] añadido varias funcionalidades principales. Eastlake [1999] ha propuesto una serie de extensiones de seguridad para que DNS pueda almacenar claves de segu­ ridad. LDAP, también conocido como X.509, es' un subconjunto derivado del protocolo de directorio distribuido X.500. Fue definido por Yeong et al. [1995] y ha sido implementado en muchos siste­ mas operativos. Hay diversas investigaciones interesantes en marcha en el área de las interfaces en los sistemas de archivos y, en particular, sobre las cuestiones relativas a los atributos y a la denominación de los archivos. Por ejemplo, el sistema operativo Plan 9 de Bell Laboratories (Lucent Technology) hace que todos los objetos parezcan sistemas de archivos. Así, para mostrar una lista de los pro­ cesos del sistema, el usuario simplemente tiene que listar el contenido del directorio / proc. De forma similar, para mostrar la hora del día, el usuario sólo necesita escribir el nombre de archivo / dev/ time.

C A |^ y L O

Implementación de sistemas de archivos Como hemos visto en el Capítulo 10, el sistema de archivos proporciona el mecanismo para el almacenamiento en línea y para el acceso a los contenidos de los archivos, incluyendo datos y pro­ gramas. El sistema de archivos reside permanentemente en almacenamiento secundario, que está diseñado para albergar de manera permanente una gran cantidad de datos. Este capítulo se ocupa principalmente de los temas relativos al almacenamiento de archivos y al acceso a archivos en el medio más común de almacenamiento secundario, que es el disco. Exploraremos una serie de for­ mas para estructurar el uso de los archivos, para asignar el espacio del disco, para recuperar el espacio liberado, para controlar la ubicación de los datos y para realizar la interfaz entre otras par­ tes del sistema operativo y el almacenamiento secundario. A lo largo de todo el capítulo, presta­ remos especial atención a las cuestiones de rendimiento.

OBJETIVOS DEL CAPÍTULO • Describir los detalles de implementación de sistemas de archivos locales y estructuras de directorio. • Describir la implementación de sistemas de archivos remotos. • Explicar los algoritmos de asignación de bloques y de control de bloques libres, así como los compromisos inherentes a ellos.

11.1 Estructura de un sistem a de archivos Los discos constituyen el principal tipo de almacenamiento secundario para mantener sistemas de archivos. Tienen dos características que los convierten en un medio conveniente para el almace­ namiento de múltiples archivos: 1. El disco puede ser reescrito de manera directa; es posible leer un bloque del disco, modificar el bloque y volverlo a escribir en el mismo lugar. 2. Con un disco, se puede acceder directamente a cualquier bloque de información que conten­ ga. Por tanto, resulta simple acceder a cualquier archivo de forma secuencial aleatoria y el conmutar de un archivo a otro sólo requiere mover los cabezales de lectura-escritura y espe­ rar a que el disco termine de rotar. Analizaremos la estructura de los discos con más detalle en el Capítulo 12. En lugar de transferir un byte cada vez, las transferencias de E/S entre la memoria y el disco se realizan en unidades de bloques, para mejorar la eficiencia de E/S. Cada bloque tiene uno o más sectores. Dependiendo de la unidad de disco, los sectores varían entre 32 bytes y 4096 bytes; '.analmente, su tamaño es de 512 bvtes.

Capítulo 11 Implementación de sistemas de archivos

Para proporcionar un acceso eficiente y cómodo al disco, el sistema operativo impone uno o más sistemas de archivos, con los que los datos pueden almacenarse, localizarse y extraerse fácil- ‘ mente. Un sistema de archivos acarrea dos problemas de diseño bastante diferentes. El primer ' problema es definir qué aspecto debe tener el sistema de archivos para el usuario. Esta tarea impli- ca definir un archivo y sus atributos, las operaciones permitidas sobre los archivos y la estructu- " ra de directorio utilizada para organizar los archivos. El segundo problema es crear algoritmos y 3 estructuras de datos que permitan mapear el sistema lógico de archivos sobre los dispositivos físi- ' eos de almacenamiento secundario. El propio sistema de archivos está compuesto, generalmente, de muchos niveles diferentes. La estructura que se muestra en la Figura 11.1 es un ejemplo de diseño en niveles; cada nivel del diseño utiliza las funciones de los niveles inferiores para crear nuevas funciones que serán, a su vez, ; utilizadas por los niveles superiores a ese. j El nivel más bajo, el control de E/S, está compuesto por controladores de dispositivo y rutinas de tratamiento de interrupción, que se encargan de transferir la información entre la memoria , principal y el sistema de disco. Un controlador de dispositivo puede considerarse una especie de traductor: su entrada está compuesta por comandos de alto nivel tales como "extraer bloque 123"; ; su salida consta de instrucciones de bajo nivel específicas del hardware que son utilizadas por la I controladora hardware, que es quien establece la interfaz del dispositivo de E / S con el resto del’® sistema. El controlador de dispositivo escribe usualmente una serie de patrones de bits espedfi- | eos en ubicaciones especiales de la memoria de la controladora de E / S , para decir a la controladora en qué ubicación del dispositivo debe operar y que acción debe llevar a cabo. Los detalles acerca ¿ de los controladores de dispositivo de la infraestructura de E / S se cubren en el Capítulo 13. | El sistema básico de archivos sólo necesita enviar comandos genéricos al controlador de dis-^ positivo apropiado, con el fin de leer y escribir bloques físicos en el disco. Cada bloque físico se identifica mediante su dirección de disco numérica (por ejemplo, unidad 1, cilindro 73, pista 2, / sector 10 ). J El módulo de organización de archivos tiene conocimiento acerca de los archivos y de sus blo- J ques lógicos, así como de sus bloques físicos. Conociendo el tipo de asignación de archivos utili-zado y la ubicación del archivo, el módulo de organización de archivos puede traducir las direcciones lógicas de bloque a direcciones físicas de bloque, que serán las que envíe al sistema ^ básico de archivos para que realice las necesarias transferencias. Los bloques lógicos de cada archivo están numerados desde 0 (o 1) a N. Puesto que los bloques físicos que contienen los datos no suelen corresponderse con los números lógicos de bloque, es necesaria una tarea de traducción para localizar cada bloque. El módulo de organización de archivos incluye también el gestor de espacio libre, que controla los bloques no asignados y proporciona dichos bloques al módulo de organización de archivos cuando así se solicita. programas de aplicación

i sistema lógico de archivos

módulo de organización de archivos

I sistema básico de archivos

I control de E/S

I dispositivos

Figura 11.1 Sistema de archivos en niveles.

11.2 Implementación de sistemas de archivos

371

Finalmente, el sistema lógico de archivos gestiona la información de metadatos. Los metadatos incluyen toda la estructura del sistema de archivos, excepto los propios datos (es decir, el pro­ pio contenido de los archivos). El sistema lógico de archivos gestiona la estructura de directorio para proporcionar al módulo de organización de archivos la información que éste necesita, a par­ tir de un nombre de archivo simbólico. Este nivel mantiene la estructura de los archivos median­ te bloques de control de archivo. Un bloque dé control de archivo (FCB, file-control block) contiene información acerca del archivo, incluyendo su propietario, los permisos y la ubicación del contenido del archivo. El sistema lógico de archivos también es responsable de las tareas de protección y seguridad, que ya hemos analizado en el Capítulo 10 y que analizaremos con más profundidad en el Capítulo 14. Cuando se utiliza una estructura de niveles para la implementación de un sistema de archivos, se minimiza la duplicación de código. El código correspondiente al control de E/S y, en ocasiones, al sistema básico de archivos puede ser utilizado por múltiples sistemas de archivos. Cada siste­ ma de archivos puede tener entonces su propio sistema lógico de archivos y su propio módulo de organización de archivos. Hoy en día se utilizan muchos sistemas de archivos distintos. La mayoría de los sistemas ope­ rativos soportan más de un sistema. Por ejemplo, la mayoría de los CD-ROM están escritos en el formato ISO 9660, que es un formato estándar adoptado por consenso de los fabricantes de CDROM. Además de los sistemas de archivos para soportes extraíbles, cada sistema operativo tiene un (o más de un) sistema de archivos basado en disco. UNIX utiliza el sistema de archivos UNIX (UFS, UNIX file system), que está basado en el sistema FFS (Fast File System) de Berkeley. Windows NT, 2000 y XP soportan los formatos de sistema de archivos de disco FAT, FAT32 y NTFS (Windows NT File System), además de formatos de sistemas de archivos para CD-ROM, DVD y disquete. Aunque Linux soporta más de cuarenta sistemas de archivos distintos, el sistema de archivos estándar en Linux se denomina sistema de archivos extendido, siendo las versiones más comu­ nes ext2 y ext3. También existen sistemas de archivos distribuidos, en los que un sistema de archi­ vos que reside en un servidor puede montarse en uno o más clientes.

11.2 Im plem entación de sistemas de archivos Como hemos descrito en la Sección 10.1.2, los sistemas operativos implementan llamadas al siste­ ma open () y c i ó s e () para que los procesos soliciten acceder al contenido de los archivos. En esta sección, vamos a profundizar en las estructuras y operaciones utilizadas para implementar las acciones relativas a los sistemas de archivos.

11.2.1 Introducción Se utilizan varias estructuras en disco y en memoria para implementar un sistema de archivos. Estas estructuras varían dependiendo del sistema operativo y del sistema de archivos, aunque hay algunos principios básicos que son de aplicación general. En el disco, el sistema de archivos puede contener información acerca de cómo iniciar un sis­ tema operativo que esté almacenado allí, acerca del número total de bloques, del número y la ubi­ cación de los bloques libres, de la estructura de directorios y de los archivos individuales. En el resto del capítulo detallaremos muchas de estas estructuras, pero vamos a describirlas aquí bre­ vemente: • Un bloque de control de arranque (por cada volumen) puede contener la información que el sistema necesita para iniciar un sistema operativo a partir de dicho volumen. Si el disco no contiene un sistema operativo, este bloque puede estar vacío. Normalmente, es el primer bloque del volumen. En UFS, se denomina bloque de inicio. En NFTS, se denomina sector de arranque de la partición. • Un bloque de control de volumen (por cada volumen) contiene detalles acerca del volumen (o partición), tales como el número de bloques que hay en la partición, el tamaño de ios blo­ ques, el número de bloques libres y los punteros de bloques libres, así como un contador de

372

Capítulo 11 Implementación de sistemas de archivos

b lo q u es d e in fo rm a c ió n FCB lib res y p u n te ro s FCB. E n UFS, e sto se d e n o m in a su p erb loq u , en NFTS, esta in fo rm a ció n se a lm a ce n a en la ta b la m a e s tr a d e a rc h iv o s . •

Se u tiliz a u n a e s tru c tu ra d e d ire cto rio s p o r c a d a s is te m a d e a rc h iv o s p a r a re a liz a r los ari v o s . E n UFS, e sto in clu y e los n o m b re s d e los a rc h iv o s y lo s n o m b re s d e in o d o aso cia d o s. NFTS, e s ta in fo rm a c ió n se a lm a ce n a e n la ta b la m a e s tr a d e a rc h iv o s .

• Un bloque FTB por cada archivo contiene numerosos detalles acerca del archivo, incluy do los permisos correspondientes, el propietario, el tamaño y la ubicación de los bloques de datos. En UFS, esta estructura se denomina inodo. En NFTS, esta información se almace: dentro de la tabla maestra de archivos, que utiliza una estructura de base de datos relacii nal, con una fila por cada archivo. La información almacenada en memoria se utiliza tanto para la gestión de un sistema de archSI vos como para la mejora del rendimiento mediante mecanismos de caché. Los datos se cargan en el momento del montaje y se descartan cuando el dispositivo se desmonta. Las estructuras exis? tentes pueden incluir las que a continuación se describen: • Una tabla de montaje en memoria contiene información acerca de cada volumen montado! • Una caché de la estructura de directorios en memoria almacena la información relativa a lolP directorios a los que se ha accedido recientemente (para los directorios en los que hay que: montar los volúmenes, puede contener un puntero a la tabla del volumen). • La ta b la g lo b a l d e a rc h iv o s a b ie r to s contiene una copia del FCB de cada archivo abierto,5! además de otras informaciones. • La ta b la d e a r c h iv o s a b ie r to s d e c a d a p ro c e s o contiene un puntero a la entrada apropiada! de la entrada global de archivos abiertos, así como otras informaciones adicionales. Í¡¡j¡ Para crear un nuevo archivo, un programa de aplicación llama al sistema lógico de archivos. Eli sistema lógico de archivos conoce el formato de las estructuras de directorio y, para crear un ^ nuevo archivo, asigna un nuevo FCB (alternativamente, si la implementación del sistema de archivos crea todos los bloques FCB en el momento de creación del sistema de archivos, se asignará un ® FCB a partir del conjunto de bloques FCB libres). El sistema lee entonces el directorio apropiado en la memoria, lo actualiza con el nuevo nombre de archivo y el nuevo FCB y lo vuelve a escribir en g el disco. En la Figura 11.2 se muestra un FCB típico. Algunos sistemas operativos, incluyendo UNIX, tratan a los directorios exactamente igual que v a los archivos, salvo porque se tratará de un archivo cuyo campo de tipo indicará que es un direc­ torio. Otros sistemas operativos, incluyendo Windows NT, poseen llamadas al sistema diferentes ^ para los archivos y los directorios, v tratan a los directorios como entidades distintas de los archi­ vos. Independientemente de estas consideraciones estructurales de mayor nivel, el sistema lógico de archivos puede llamar al módulo de organización de archivos para mapear las operaciones de E /S de directorio sobre los números de bloque del disco, que se pasarán a su vez al sistema bási- ! co de archivos del sistema de control de E /S .

Figura 11.2 Un bloque de control de archivo típico.

11.2 Implementación de sistemas de archivos

373

Ahora que hemos creado un archivo, podemos utilizarlo para E /S . Pero primero, sin embargo, es necesario abrirlo. La llamada open () pasa un nombre de archivo al sistema de archivos. La lla­ mada al sistema open () primero busca en la tabla global de archivos abiertos para ver si el archi­ vo está siendo ya utilizado por otro proceso. En caso afirmativo, se crea una entrada en la tabla de archivos abiertos del proceso que apunte a la tabla global de archivos abiertos existente. Este algo­ ritmo puede ahorramos una gran cantidad de trabajo. Cuando un archivo está abierto, se busca en la estructura de directorios para encontrar el nombre de archivo indicado. Usualmente, se almacenan parte de la estructura de directorio en una caché de memoria para acelerar las opera­ ciones de directorio. Una vez encontrado el archivo, el FCB se copia en la tabla global de archivos abiertos existente en la memoria. Esta tabla no sólo almacena el FCB, sino que también controla el número de procesos que han abierto el archivo. A co n tin u a ció n , se c r e a u n a e n tra d a e n la tab la d e a rc h iv o s ab ie rto s d el p ro c e s o , co n u n p u n ­ tero a la e n tra d a d e la ta b la g lo b al d e a rc h iv o s a b ie rto s y a lg u n o s o tro s c a m p o s d e in fo rm a ció n . E sto s o tro s c a m p o s d e in fo rm a c ió n p u e d e n in clu ir u n p u n te ro a la u b ica ció n a ctu a l d e n tro del a rc h iv o (p a ra la sig u ie n te o p e r a c ió n read ( ) o write ( ) ) y el m o d o d e a c c e s o en q u e se h a a b ie r­ to el a rc h iv o . L a lla m a d a o p e n ( ) d e v u e lv e u n p u n te ro a la e n tr a d a a p ro p ia d a d e la tabla d e a rc h i­ v o s a b ie rto s d el p ro c e s o ; to d a s las o p e ra c io n e s d e a rc h iv o se re a liz a n a p a rtir d e ahí m e d ia n te e ste p u n te ro . E l n o m b re d el a rc h iv o p u e d e n o fo rm a r p a rte d e la tab la d e a rc h iv o s ab ierto s, y a q u e el sis te m a n o lo u tiliza p a r a n a d a u n a v e z q u e se h a lo c a liz a d o el FCB a p ro p ia d o en el d isco . Sin e m b a rg o , se lo p u e d e a lm a c e n a r en c a c h é , p a r a a h o r ra r tie m p o e n las su b sig u ie n te s a p e rtu r a s del m ism o a rc h iv o . E l n o m b re q u e se p ro p o rc io n a a e sa s e n tr a d a s v a ría d e u n o s siste m a s a o tro s. E n los s is te m a s UNIX se u tiliz a el té rm in o in g lé s f ile d e s c rip to r, m ie n tra s q u e W in d o w s p re fie re el té r­ m in o f ile h a n d le ; e n c a s te lla n o , u tiliz a m o s el té rm in o d e s c r ip to r d e a rc h iv o . E n co n se c u e n c ia , h a sta q u e se cie rre el a rc h iv o , to d a s la s o p e ra c io n e s co n el a rc h iv o se lle v a n a cab o m e d ia n te el d e s c rip to r d e a rc h iv o c o n te n id o en la ta b la d e a rc h iv o s a b ie rto .

Cuando un proceso cierra el archivo, se elimina la entrada de la tabla del proceso y se decre­ menta el contador de aperturas existente en la tabla global. Cuando todos los usuarios que hayan abierto el archivo lo cierren, los metadatos actualizados se copian en la estructura de directorio residente en el disco y se elimina la entrada de la tabla global de archivos abiertos. Algunos sistemas complican este esquema todavía más, utilizando el sistema de archivos como interfaz para otros aspectos del sistema, como por ejemplo la comunicación por red. Como ilus­ tración, en UFS, la tabla global de archivos abiertos almacena los inodos y otras informaciones para los archivos y directorios, pero también alberga información similar para las conexiones de red y para los dispositivos. De esta forma, puede usarse un mismo mecanismo para múltiples propósi­ tos. No deben infravalorarse los aspectos de almacenamiento en caché de las estructuras de los sis­ temas de archivos. La mayoría de los sistemas mantienen en la memoria toda la información acer­ ca de un archivo abierto, salvo los propios bloques de datos. El sistema BSD UNIX resulta bastante típico en su uso de cachés para tratar de ahorrar operaciones de E /S de disco. Su tasa media de aciertos de caché, que es del 85 por ciento, muestra que merece la pena implementar estas técni­ cas. El sistema BSD UNIX se describe en detalle en el Apéndice A. La Figura 11.3 resume las estructuras de operaciones utilizadas en la implementación de un sis­ tema de archivos.

11.2.2 Particiones y montaje La disposición de la información en un disco puede tener múltiples variantes, dependiendo del sistema operativo. Un disco puede dividirse en múltiples particiones, o bien un volumen puede abarcar múltiples particiones en múltiples discos. Analizaremos aquí el primero de esos dos tipos de disposición, mientras que del segundo, que puede en realidad considerarse una forma de tec­ nología RAID, se analizará en la Sección 12.7. Cada partición puede ser una partición “en bruto” (sin formato¡, que no contenga ningún sis­ tema de archivos, o una partición "procesada”, que sí contenga un sistema de archivos. Los dis­ cos sin formato se utilizan en aquellos casos en que no resulte apropiado emplear un sistema de

374

Capítulo 11 Implementación de sistemas de archivos

espacio de usuario

memoria del kemel

almacenamiento secundario

(b)

Figura 1 1 . 3

Estructuras en memoria de un sistema de archivos, (a) Apertura de un archivo. (b) Lectura de un archivo.

archivos. Por ejem plo, el espacio de intercam bio en UNIX puede utilizar una partición sin forma­ to, ya que ese espacio de intercam bio usa su propio form ato en el disco y no em plea un sistema de archivos. D e la m ism a form a, algunas bases de datos utilizan discos sin form ato y formatean los datos de la form a que m ejor se adapte a sus necesidades. Los discos sin form ato tam bién pue­ den alm acenar la inform ación que necesitan los sistem as de discos RAID, com o los m apas de bits que indican qué bloques están ubicados en espejo y cuáles han sido m odificados y necesitan ser duplicados. De form a sim ilar, los discos sin form ato pueden contener una base de datos en minia­ tura que alm acene la inform ación de configuración RAID, com o por ejem plo la inform ación que indique qué discos son m iem bro de cada conjunto RAID. El uso de discos sin form ato se analiza con m ás detalle en la Sección 12.5.1. La inform ación de arranque puede alm acenarse en una partición independiente. De nuevo, esa partición tiene su propio form ato, porque en el m om ento del inicio el sistem a no ha cargado aún los controladores de dispositivo para los sistem as de archivos y no puede, por tanto, interpretar el form ato de ningún sistem a de archivos. En lugar de ello, la inform ación de arranque es, usual­ m ente, una serie secuencial de bloques, que se cargan com o una im agen binaria en la m emoria. La ejecución de esa im agen binaria com ienza en una ubicación predefinida, com o por ejem plo el pri­ m er byte. Esta im agen de arranque puede contener m ás inform ación, a parte de las instrucciones relativas a cóm o iniciar un sistem a operativo específico. Por ejem plo, en un PC y en otros siste­ mas, la m áquina puede ser de arran qu e dual, pudiendo instalarse a m últiples sistem as operativos en dichos tipos de sistem as. ¿C óm o sabe el sistem a cuál de los sistem as operativos arrancar? Podem os alm acenar en el espacio de arranque un cargador de arranque que sea capaz de com­ prender m últiples sistem as de archivos y m últiples sistem as operativos; una vez cargado, ese car­ gador de arranque puede iniciar uno de los sistem as operativos disponibles en el disco. El disco puede tener m últiples particiones, cada una de las cuales contendrá un tipo diferente de sistema de archivos y un sistem a operativo distinto. La partición raíz, que contiene el kernel del sistem a operativo y, en ocasiones, otros archivos del sistema, se monta en el m om ento del arranque. O tros volúm enes pueden m ontarse automáti-

11.2 Implementación de sistemas de archivos

375

camente durante el arranque o pueden ser montados manualmente en algún momento posterior, dependiendo del sistema operativo. Como parte de una operación de montaje, el sistema operati­ vo verifica que el dispositivo contenga un sistema de archivos válido. Para realizar esa verifica­ ción, el sistema operativo pide al controlador del dispositivo que lea el directorio del dispositivo y verifique que éste directorio tiene el formato esperado. Si el formato no es válido, será necesa­ rio comprobar y posiblemente corregir la coherencia de la partición, con o sin intervención del usuario. Finalmente, el sistema operativo registrará en su tabla de montaje de la memoria que se ha montado un sistema de archivos, indicando el tipo de sistema de archivos de que se trata. Los detalles de esta función dependerán del sistema operativo. Los sistemas Microsoft Windows mon­ tan cada volumen en un espacio de nombres separado, que se designa mediante una letra y un carácter de dos puntos. Por ejemplo, para registrar que un sistema de archivos está montado en F :, el sistema operativo coloca un puntero al sistema de archivos dentro de un campo de la estruc­ tura de dispositivo correspondiente a F :. Cuando un proceso especifica dicha letra de unidad, el sistema operativo localiza el puntero apropiado al sistema de archivos y recorre las estructuras de directorio de dicho dispositivo hasta encontrar el archivo o directorio especificado. Las versiones más recientes de Windows pueden montar el sistema de archivos en cualquier punto dentro de la estructura de directorios existentes. En UNIX, los sistemas de archivos pueden montarse en cualquier directorio. El montaje se implementa configurando un indicador dentro de la copia en memoria del inodo correspondien­ te a dicho directorio. Ese indicador atestigua que el directorio es un punto de montaje. Otro campo apunta a una entrada dentro de la tabla de montaje, que indica qué dispositivo está montado allí. La entrada de la tabla de montaje contiene un puntero al superbloque del sistema de archivos exis­ tente en dicho dispositivo. Este esquema permite que el sistema operativo recorra su estructura de directorios, conmutando transparentemente entre sistemas de archivos de diferentes tipos.

11.2.3 Sistemas de archivos virtuales Queda claro, a partir de las explicaciones de la sección anterior, que los sistemas operativos modernos deben soportar concurrentemente múltiples tipos de sistemas de archivo. Pero, ¿cómo permite el sistema operativo integrar múltiples tipos de sistemas de archivos en una estructura de directorio? ¿Y cómo pueden los usuarios moverse transparentemente entre los distintos tipos de sistemas de archivos a medida que recorren el espacio de los sistemas de archivos. Vamos a ana­ lizar a continuación algunos de estos detalles de implementación. Un método obvio, pero subóptimo, de implementar múltiples tipos de sistemas de archivos consiste en escribir rutinas diferentes de acceso a directorios y a archivos para cada uno de los tipos existentes. Sin embargo, en lugar de usar esta solución, la mayoría de los sistemas operati­ vos, incluyendo UNIX, utilizan técnicas de orientación a objetos para simplificar, organizar y modularizar la implementación. El uso de estos métodos permite implementar tipos muy distin­ tos de sistemas de archivos dentro de una misma estructura, incluvendo sistemas de archivos de red, como por ejemplo NFS. Los usuarios pueden acceder a archivos que estén contenidos dentro de múltiples sistemas de archivos en el disco local, o incluso en sistemas de archivos disponibles a través de la red. Se utilizan estructuras de datos y procedimientos para aislar la funcionalidad básica de llama­ das al sistema de los detalles de implementación. Así, la implementación del sistema de archivos está compuesta de'tres niveles principales, como se muestra esquemáticamente en la Figura 11.4. El primer nivel es la interfaz del sistema de archivos, basada en las llamadas oper. { ) , r e a d l ), v/rice í ) y c i ó s e y en los descriptores de archivos. El segundo nivel se denomina sistema de archivos virtual (VFS, virtual file system); este nivel cumple dos importantes funciones: 1. Separa las operaciones genéricas del sistema de archivos con respecto a su implementación, definiendo una interfaz VFS muy clara. Pueden coexistir diversas implementaciones de la interfaz \TS en la misma máquina, permitiendo un acceso transparente a diferentes tipos de sistemas de archivos montados de modo local.

interfaz del sistema de archivos

interfaz VFS

sistema de archivos local tipo 1

sistema de archivos local tipo 2

sistema de archivos remoto tipo 1

red Figura 1 1 .4

Vista esquemática de un sistema de archivos virtual.

■j Otro problem a de los m ecanism os de asignación contigua es determ inar cuánto espacio se| necesita para un archivo. En el m om ento de crear el archivo, será necesario determ inar la can ti-« dad total de espacio que vam os a necesitar y asignar esa cantidad total. ¿Cóm o sabe el creador] (program a o persona) del archivo qué tam año va a tener éste? En algunos casos, esta determ ina-] ción puede ser bastante sim ple (por ejem plo, cuando se copia un archivo existente); sin embargo, i en general, el tam año de un archivo de salida puede ser difícil de estim ar. Si asignam os d e m a s ia j do poco espacio a un archivo, podem os encontram os con que el archivo no puede am pliarse.! Especialm ente con las estrategias de asignación de m ejor ajuste, puede que el espacio situado a;| am bos lados del archivo ya esté siendo utilizado, por tanto, no podem os am pliar el tam año del^j archivo sin desplazarlo a otro lugar. Entonces, existen dos posibilidades. La prim era es term inar! el program a de usuario, em itiendo el apropiado m ensaje de error. El usuario deberá entoncesj asignar m ás espacio y volver a ejecutar el program a. Estas ejecuciones repetidas pueden ser muy] costosas; para prevenirlas, el usuario sobreestim ará norm alm ente la cantidad de espacio necesa-f ría, lo que dará com o resultado un desperdicio de espacio considerable. La otra posibilidad con-f siste en localizar un hueco eje m ayor tam año, copiar el contenido del archivo al nuevo espacio y ! liberar el espacio anterior. Esta serie de acciones puede repetirse siem pre y cuando exista suficien­ te espacio, aunque pueden consum ir bastante tiempo. Sin em bargo, con este m étodo nunca será? necesario inform ar explícitam ente al usuario acerca de lo que está sucediendo; el sistem a co n ti-j nuará operando a pesar del problem a, aunque lo hará de form a cada vez más lenta. Incluso si la cantidad total de espacio necesario para un archivo se conoce de antem ano, el m ecanism o de preasignación puede ser poco eficiente. A un archivo que crezca lentam ente a lo largo de un período m uy dilatado (m eses o años) será necesario asignarle suficiente espacio para su tamaño final, aun cuando buena parte de ese espacio vaya a estar sin utilizar durante un largo tiempo. Por tanto, el archivo tendrá un alto grado de fragm entación interna. Para m inim izar estos problem as, algunos sistem as operativos utilizan un esquem a modificado de asignación contigua, m ediante el que se asigna inicialm ente un bloque contiguo de espacio y, posteriorm ente, si dicho espacio resulta no ser lo suficientem ente grande, se añade otro área de espacio contiguo, denom inado extensión. La ubicación de los bloques de un archivo se registra entonces m ediante una dirección y un núm ero de bloques, junto con un enlace al prim er bloque de la siguiente extensión. En algunos sistem as, el propietario del archivo puede establecer el tama­ ño de la extensión, pero este m odo de configuración puede hacer que dism inuya la eficiencia si el propietario realiza una estim ación incorrecta. La fragm entación interna puede continuar siendo un problem a si las extensiones son dem asiado grandes y la fragm entación externa puede llegar a ser un problem a a m edida que se asignen y desasignen extensiones de tam año variable. El siste­ m a de archivos com ercial Veritas utiliza las extensiones para optim izar el funcionam iento; se trata de un sustituto de altas prestaciones para el sistem a UFS estándar de UNIX.

11.4.2 Asignación enlazada El m ecanism o de asign ación enlazada resuelve todos los problem as de la asignación contigua. Con la asignación enlazada, cada archivo es una lista enlazada de bloques de disco, pudiendo estar dichos bloques dispersos por todo el disco. El directorio .contiene un puntero al prim er y al último bloque de cada archivo. Por ejem plo, un archivo de cinco bloques podría com enzar en el

11.4 Métodos de asignación

381

bloque 9 y continuar en el bloque 16, luego en el 1, después en el bloque 10 y, finalm ente, en el bloque 25 (Figura 11.6). C ada bloque contiene un puntero al bloque siguiente. D ichos punteros no están a disposición del usuario. C on este m ecanism o, si cada bloque tiene 512 bytes de tam año y una dirección de disco (el puntero) requiere 4 bytes, el usuario verá bloques de 508 bytes. Para crear un nuevo archivo, sim plem ente cream os una nueva entrada en el directorio. Con el m ecanism o de asignación enlazada, cada entrada de directorio tiene un puntero al prim er bloque de disco del archivo. Este puntero se inicializa con el valor nulo (el valor de puntero que indica el fin de la lista) para representar un archivo vacío. El campo de tam año tam bién se configura con el valor 0. U na escritura en el archivo hará que el sistem a de gestión de espacio libre localice un blo­ que libre y la inform ación se escribirá en este nuevo bloque y será enlazada al final del archivo. Para leer un archivo, sim plem ente leemos los bloques siguiendo los punteros de un bloque a otro. N o hay ninguna fragm entación externa con asignación enlazada y puede utilizarse cualquiera de los bloques de la lista de bloques libres para satisfacer una solicitud. No es necesario declarar el tam año del archivo en el m om ento de crearlo y el archivo puede continuar creciendo m ientras existan bloques libres. En consecuencia, nunca es necesario com pactar el espacio de disco. Sin em bargo, el m ecanism o de asignación enlazada tam bién tiene sus ventajas. El principal problem a es que sólo se lo puede utilizar de m anera efectiva para los archivos de acceso secuencial. Para encontrar el bloque f-ésimo de un archivo, podem os com enzar al principio de dicho archivo y seguir los punteros hasta llegar al bloque í-ésimo. C ada acceso a un puntero requiere una lectura de disco y algunos de ellos requerirán un reposicionam iento de cabezales. En conse­ cuencia, resulta m uy poco eficiente tratar de soportar una funcionalidad de acceso directo para los archivos de asignación enlazada. O tra desventaja es el espacio requerido para los punteros. Si un puntero ocupa 4 bytes de un bloque de 512 bytes, el 0,758 por ciento del espacio del disco se estará utilizando para los punte­ ros, en lugar de para alm acenar inform ación útil. Cada archivo requerirá un poco m ás de espacio de lo que requeriría con otros m ecanism os. La solución usual para este problem a consiste en consolidar los bloques en grupos, denom ina­ dos clusters, y asignar clusters en lugar de bloques. Por ejem plo, el sistema de archivos puede defi­ nir un cluster com o cuatro bloques y operar con el disco sólo en unidades de cluster. Los punteros utilizarán entonces un porcentaje mucho más pequeño del espacio de disco del archivo. Este m étodo perm ite que el m apeo entre bloques lógicos y físicos siga siendo sim ple, pero m ejora la tasa de transferencia del disco (porque hacen falta menos reposicionam ientos de los cabezales) v reduce el espacio necesario para la asignación de bloques y para la gestión de la lista de bloques libres. El coste asociado con esta técnica es un incremento en el grado de fragm entación interna, directorio

inicio 9

fin 25

Figura 11.6 Asignación eniazaoa dei espacio de c¡sco.

porque ahora se desperdiciará más espacio cuando un cluster esté parcialm ente lleno de lo que s j f desperdiciaba cuando sólo era un bloque lo que estaba parcialm ente lleno. Los clusters p u e d e jí tam bién utilizarse para m ejorar el tiempo de acceso a disco para m uchos otros algoritm os, así qu el se los utiliza en la m avoría de los sistem as de archivos. 2 Otro problem a de la asignación enlazada es la fiabilidad. Recuerde que los archivos están enlall zados m ediante punteros que están dispersos por todo el disco; considere ahora lo que sucederí|l si uno de esos punteros se pierde o resulta dañado. U n error en el softw are del sistem a operativól o un fallo del hardw are del disco podrían hacer que se interpretara incorrectam ente un puntero;! este error, a su vez, podría hacer que un enlace apuntara a la lista de bloques libres o a otro archi|¡ vo. Una solución parcial a este problem a consiste en utilizar listas de elem entos enlazadas, mien-1 tras que otra consiste en alm acenar el nom bre del archivo y el núm ero de bloque relativo en cada! bloque; sin em bargo, estos esquem as requieren desperdiciar todavía m ás espacio en cada archivo J Una variante im portante del m ecanism o de asignación enlazada es la que se basa en el uso dej una ta b la de a sig n ació n de a rch iv o s (FAT, file-allocation table). Este m étodo sim ple, pero eficien-i te, de asignación del espacio del disco se utiliza en los sistem as operativos MS-DOS y O S / 2. U n a' sección del disco al principio de cada volum en se reserva para alm acenar esa tabla, que tiene una; entrada por cada bloque del disco y está indexada según el núm ero de bloque. La FAT se utiliza! de form a bastante sim ilar a una lista enlazada. Cada entrada de directorio contiene el núm ero de? bloque del prim er bloque del archivo. La entrada de la tabla indexada según ese núm ero de blo-^ que contiene el núm ero de bloque del siguiente bloque del archivo. Esta cadena continua hasta el! últim o bloque, que tiene un valor especial de fin de archivo com o entrada de la tabla. Los bloques no utilizados se indican m ediante un valor de tabla igual a 0. Para asignar un nuevo bloque a um archivo, basta con encontrar la prim era entrada de la tabla con valor 0 y sustituir el anterior valor ¡ de fin de archivo por la dirección del nuevo bloque. Después, el 0 se sustituye por el valor de fur de archivo. U n ejem plo ilustrativo sería la estructura FAT m ostrada en la Figura 11.7, para un ' archivo com puesto por los bloques de disco 217, 618 y 339. ■ El esquem a de asignación FAT puede provocar un núm ero significativo de reposicionam iento; de los cabezales del disco, a m enos que la tabla FAT se alm acene en caché. El cabezal del disco debe m overse al principio del volum en para leer la FAT y encontrar la ubicación del bloque en cuestión, después de lo cual tendrá que m overse a la ubicación del propio bloque. En el caso peor, ambos m ovim ientos tendrá lugar para cada uno de los bloques. U na de las ventajas de este esquem a es que se m ejora el tiem po de acceso aleatorio, porque el cabezal del disco puede encontrar la ubica­ ción de cualquier bloque leyendo la inform ación de la FAT.

entradadedirectorio i te —st pgggg* bloquedeinicio nom bre 1

217

217

339

618

núm erodebloquesdedisco -1 FAT

Figura 11.7 Tabla de asignación de archivos.

11.4 Métodos de asignación

383

11.4.3 Asignación indexada El método de la asignación enlazada resuelve los problemas de fragmentación externa y de decla­ ración del tamaño que presentaba el método de la asignación contigua. Sin embargo, si no se uti­ liza una FAT, la asignación enlazada no puede soportar un acceso directo eficiente, ya que los punteros a los bloques están dispersos junto con los propios bloques por todo el disco y deben extraerse secuencialmente. El mecanismo de asignación indexada resuelve este problema agru­ pando todos los punteros en una única ubicación: el bloque de índice. Cada archivo tiene su propio bloque de índice, que es una matriz de direcciones de bloques de disco. La entrada í-ésima del bloque de índice apunta al bloque f-ésimo del archivo. El directorio contiene la dirección del bloque de índice (Figura 11.8). Para localizar y leer el bloque í-ésimo, uti­ lizamos el puntero contenido en la entrada z'-ésima del bloque de índice. Este esquema es similar al esquema de paginación descrito en la Sección 8.4. Cuando se crea el archivo, se asigna el valor nulo a todos los punteros del bloque de índice. Cuando se escribe por primera vez en el bloque í-ésimo, se solicita un bloque al gestor de espacio libre y su dirección se almacena en la entrada í-ésima del bloque de índice. El mecanismo de asignación indexada soporta el acceso directo, sin sufrir el problema de la fragmentación externa, ya que puede utilizarse cualquier bloque del disco para satisfacer una soli­ citud de más espacio. Sin embargo, el mecanismo de asignación indexada sí que sufre el proble­ ma del desperdicio de espacio. El espacio adicional requerido para almacenar los punteros del bloque de índice es, generalmente, mayor que el que se requiere en el caso de la asignación enla­ zada. Considere un caso común en el que tenemos un archivo de sólo uno o dos bloques. Con el mecanismo de asignación enlazada, sólo perderemos el espacio de un puntero por cada bloque, mientras que con el mecanismo de asignación indexada, es preciso asignar un bloque de índice completo, incluso si sólo uno o dos punteros de este bloque van a tener un valor distinto del valor nulo. Este punto nos plantea la cuestión de cuál debe ser el tamaño del bloque de índice. Cada archi­ vo debe tener un bloque de índice, así que ese bloque deberá ser lo más pequeño posible. Sin embargo, si el bloque de índice es demasiado pequeño, no podrá almacenar suficientes punteros para un archivo de gran tamaño y será necesario implementar un mecanismo para resolver este problema. Entre los mecanismos que pueden utilizarse para ello se encuentran los siguientes: • Esquema enlazado. Cada bloque de índice ocupa normalmente un bloque de disco. Por tanto, puede leerse y escribirse directamente. Para que puedan existir archivos de gran

Figura 11.8 Asignación indexada del espacio de disco.

C ap itu lo i i

im p iem eru aciu n a e sistem an ae arcm vos

tam año, podem os enlazar varios bloques de índice. Por ejem plo, un bloque de índice puede contener una pequeña cabecera que indique un nom bre del archivo y un conjunto formado por las prim eras 100 direcciones de bloque del disco. La siguiente dirección (la últim a pala­ bra del bloque de índice) será el valor nulo (para un archivo de pequeño tam año) o un pun­ tero a otro bloque de índice (para un archivo de gran tam año). U na variante de la representación enlazada consiste en utilizar un blo­ que de índice de prim er nivel para apuntar a un conjunto de bloques- de índice de segundo nivel, que a su vez apuntarán a los bloques del archivo. P ara acceder a un bloque, el siste­ m a operativo utiliza el índice de prim er nivel para encontrar un bloque de índice de segun­ do nivel y luego em plea dicho bloque para hallar el bloque de datos deseado. Esta técnica podría am pliarse hasta un tercer o cuarto nivel, dependiendo del tamaño m áxim o de archi­ vo que se desee. C on bloques de 4096 bytes, podríam os alm acenar 1024 bytes en un bloque de índice; dos niveles de índice nos perm itirían direccionar 1.048.576 bloques de datos, lo que equivale a un tam año de archivo de hasta 4 GB.

• ín d ic e m u ltin iv el.

•

O tra alternativa, utilizada con el sistem a UFS, consiste en mantener, por ejem plo, los prim eros 15 punteros del bloque de índice en el nodo del archivo. Los pri­ m eros 12 de estos punteros hacen referencia a b lo q u es d irecto s, es decir, contienen la d irec-. ción de una serie de bloques que alm acenan los datos del archivo. De este modo, los datos para los archivos de pequeño tam año (de no m ás de 12 bloques) no necesitan un bloque de' índice separado. Si el tam año de bloque es de 4 KB, podrá accederse directam ente a 48 KB de datos. Los siguientes tres punteros hacen referencia a b lo q u es in d irectos. El primero apunta a un b loq u e in d ire cto de un n iv el, que es un bloque de índice que no contiene datos sino las direcciones de otros bloques que alm acenan los datos. El segundo puntero hace referencia a un b lo q u e d o b lem en te in d irecto , que contiene la dirección de un bloque que alm acena las direcciones de otras series de bloques que contienen punteros a los propios bloques de datos. El últim o puntero contiene la dirección de un bloque trip lem en te indi­ recto . Con este m étodo, el núm ero de bloques que pueden asignarse a un archivo excede de la cantidad de espacio direccionable por los punteros d e archivo de 4 bytes que se utilizan en m uchos sistem as operativos. Un puntero de archivo de 32 bits sólo perm ite direccionar 232 bytes, es decir, 4 G B. M uchas im plem entaciones de UNIX, incluyendo Solaris y AIX de IBM, soportan ahora punteros de archivo de hasta 64 bits. Los punteros de este tamaño per­ m iten que los archivos y los sistem as de archivos tengan un tam año del orden de los terabytes. En la Figura 1 1 .9 se m uestra un inodo de UNIX.

E sq u e m a co m b in a d o .

Los esquem as de asignación indexados sufren de los m ism os problem as de rendim iento que el m ecanism o de asignación enlazada. Específicam ente, los bloques de índice pueden almacenarse en m em oria caché, pero los bloques de datos pueden estar distribuidos por todo un volumen.

11.4.4 Prestaciones Los m étodos de asignación que hem os expuesto varían en lo que respecta a su eficiencia de alm a­ cenam iento y a los tiem pos de acceso a los bloques de datos. A m bos criterios son im portantes a la hora de seleccionar el m étodo o m étodos apropiados para im plem entarlos en un sistem a operati­ vo. Antes de seleccionar un m étodo de asignación, necesitam os determ inar cóm o se utilizará el sistem a: un sistem a en el que el acceso sea preferentem ente secuencia! no debe utilizar el mismo m étodo que otro donde el acceso sea fundam entalm ente aleatorio. Para cualquier tipo de acceso, el m ecanism o de asignación contigua sólo requiere un acceso para extraer un bloque de disco. Puesto que podem os m antener fácilm ente la dirección del archi­ vo en m em oria, podem os calcular inm ediatam ente la dirección de disco del bloque i-ésimo (o del siguiente bloque) y leerlo directam ente. En el m ecanism o de asignación enlazada, tam bién podem os m antener en m em oria la dirección del siguiente bloque y leerlo directam ente. Este m étodo resulta adecuado para el acceso secuencial, pero para el acceso directo, un acceso al bloque í-ésimo puede requerir i lecturas de disco.

11.4 Métodos de asignación

385

datos datos datos bloques directos simplemente indirectos doblemente indirectos

datos datos datos

datos datos datos datos |

Figura 1 1 .9

Un inodo de UNIX.

Este problema muestra por qué no debe utilizarse el mecanismo de asignación enlazada para las aplicaciones que requieran acceso directo. Como resultado, algunos sistemas soportan los archivos de acceso directo utilizando un meca­ nismo de asignación contigua y emplean el mecanismo de asignación enlazada para el acceso secuencial. Para estos sistemas, debe declararse el tipo de acceso que va a realizarse en el momen­ to de crear el archivo. Los archivos creados para acceso secuencial estarán enlazados y no podrán utilizarse con acceso directo. Los archivos creados para acceso directo serán contiguos y podrán soportar tanto el acceso directo como el acceso secuencial, pero será necesario declarar su longi­ tud máxima en el momento de crear el archivo. En este caso, el sistema operativo deberá dispo­ ner de las estructuras de datos y los algoritmos apropiados para soportar ambos métodos de asignación. Los archivos pueden convertirse de un tipo a otro creando un nuevo archivo del tipo deseado, en el que se copiará el contenido del archivo antiguo. El archivo antiguo puede entonces borrarse, después de lo cual se renombrará el nuevo archivo. El esquema de asignación indexada es más complejo. Si el bloque de índice ya está en memo­ ria, puede realizarse el acceso directamente. Sin embargo, mantener en memoria el Hoque de índi­ ce requiere un espacio considerable. Si este espacio de memoria no está disponible, podemos tener que leer el primer el bloque de índice y luego el bloque de datos deseado. Para un índice en dos niveles, puede que sean necesarias dos lecturas de bloques de índice. Para un archivo extremada­ mente grande, acceder a un bloque situado cerca del final del archivo podría requerir leer todos los bloques de índice antes de leer el bloque de datos necesario. Así, las prestaciones del mecanis­ mo de asignación indexada dependerán de la estructura del índice, del tamaño del archivo y de la posición del bloque deseado. Algunos sistemas combinan la asignación contigua con.la asignación indexada, utilizando una asignación contigua para los archivos de pequeño tamaño (de hasta tres o cuatro bloques) y con­ mutando automáticamente a un mecanismo de asignación indexada si el tamaño del archivo crece. Puesto que la mayoría de los archivos son pequeños y la asignación contigua resulta eficien­ te para los pequeños archivos, las prestaciones medias pueden ser bastante buenas. Por ejemplo, la versión del sistema operativo UNIX de Sun Microsystems fue modificada en 1991 para mejorar el rendimiento del algoritmo de asignación del sistema de archivos. Las medi­ das de rendimiento indicaban que la tasa máxima de transferencia de disco en una estación de tra­ bajo típica (una SPARCstationl de 12 MIPS) ocupaba un 50 por ciento de la CPU v permitía obtener un ancho de banda de disco de sólo 1,5 MB por segundo. Para mejorar ¡as prestaciones, Sun rea-

386

Capítulo 11 Implementación de sistemas de archivos

lizó una serie de cam bios para asignar el espacio en clusters de 56 KB siem pre que fuera posibS (56 KB era el tamaño m áxim o de una transferencia DMA en los sistem as Sun en aquel momento! Este esquem a de asignación reduce la fragm entación externa y, por tanto, los tiem pos de busqué da y de latencia. Adem ás, se optim izaron las rutinas de lectura de disco para leer estos clustersc gran tam año. La estructura de los inodos se dejó sin m odificar. C om o resultado de estos cambié y de la introducción de los m ecanism os de lectura anticipada y de liberación postpuesta (de l cinta o en una unidad de disco sin intervención hum ana. Dos de los usos

principales de esta tecnología son la realización de copias de seguridad y los sistemas de alm ace-: nam iento jerárquico. La utilización de un intercam biador para copias de seguridad es muy sinvP pie: cuando se llena el cartucho, la com putadora instruye al intercam biador para que conmute aL cartucho siguiente. A lgunos intercam biadores albergan decenas de unidades y miles de cartu/' chos, con una serie de brazos robotizados que gestionan el m ovim iento de las cintas hacia las uni­ dades. Los sistem as de alm acenam iento jerárquico am plían el concepto de jerarquía de almacena- , m iento m ás allá dé la m em oria principal del alm acenam iento secundario (es decir, los discos mag­ néticos), para incorporar tam bién u n alm acenam iento terciario. El alm acenam iento terciario se3 im plem enta usualm ente com o un intercam biador de cintas o de discos extraíbles. Este nivel de la jerarquía de alm acenam iento tiene una mayor capacidad, es m ás barato y tam bién es más lento. ’ A unque el sistem a de m em oria virtual puede am pliarse de form a sencilla al almacenamiento “ terciario, esta am pliación raram ente se llevará a cabo en la práctica. La razón es que una extrac­ ción de datos de un intercam biador puede requerir decenas de segundos o incluso m inutos, y u í retardo tan grande resulta intolerable para los m ecanism os de paginación bajo dem anda y para; otros tipos de utilización de la m em oria virtual. La form a usual de incorporar el alm acenam iento terciario consiste en am pliar el sistema d S archivos. Los archivos de pequeño tam año y los frecuentem ente utilizados perm anecen en el discoj m agnético, m ientras que los archivos antiguos y de gran tam año que no se utilicen de m anera acti­ va se archivan en el intercam biador. En algunos sistem as de archivado de archivos, la entrada d(P directorio correspondiente al archivo se m antiene, pero el contenido del archivo deja de ocupar; espacio en el alm acenam iento secundario. Si una aplicación trata de abrir el archivo, se suspende la llam ada al sistem a o p e n () hasta que el contenido del archivo pueda leerse desde el almacena-, m iento terciario. Cuando el contenido vuelve a estar disponible en el disco magnético, la operaí ción o p e n () devuelve el control a la aplicación, que procederá a utilizar la copia de los datos residente en el disco. i? H oy en día, los sistem as de gestión del almacenamiento jerárquico (HSM, hierarchical s to fll ge m anagem ent) suelen encontrase en instalaciones que tengan grandes volúm enes de datos que! se utilicen raram ente, esporádicam ente o periódicam ente. Los actuales trabajos de investigación y* desarrollo en tecnologías HSM incluyen la extensión de estos conceptos para proporcionar uña gestión del ciclo de vida de la información (ILM , inform ation life-cycle m anagem ent). En es® tecnología, los datos se m ueven de disco a cinta y de vuelta a disco, según sea necesario, pero se borran de m anera planificada o de acuerdo con una cierta política. Por ejem plo, algunas instala­ ciones guardan los correos electrónicos durante siete años pero desean asegurarse de que se des-, truyan al final de ese período de siete años. En dicho m om ento, los datos podrían estar residiendo en disco, en una cinta HSM y en una cinta de copia de seguridad. La tecnología ILM centraliza el conocim iento acerca de la ubicación de los datos, de modo que puedan aplicarse las políticas ade­ cuadas en todas esas ubicaciones.

12.9.3 Cuestiones de rendimiento Al igual que sucede con cualquier otro com ponente del sistem a operativo, los tres aspectos más im portantes del rendim iento del alm acenam iento terciario son la velocidad, la fiabilidad y el coste. 12.9.3.1

V elocid ad

La velocidad del alm acenam iento terciario puede analizarse desde dos puntos de vista: ancho de banda y latencia. El ancho de banda se mide en bytes por segundo; el ancho de banda sostenido es la velocidad m edia de transferencia de datos durante una transferencia de gran envergadura, es decir, el núm ero de bytes dividido por el tiempo total de transferencia. El ancho de banda efec­ tivo m ide el prom edio para toda la duración de la operación de E/S, incluyendo el tiempo reque­ rido para efectuar las operaciones s e e k { í o l ó c a t e (), así com o el tiem po de conm utación de cartuchos en un intercam biador. En esencia, el ancho de banda sostenido es la velocidad de trans-

12.9 Estructura de almacenamiento terciario

439

ferencia de datos m ientras está transm itiéndose el flujo de datos, m ientras que el ancho de banda efectivo es la velocidad global de transferencia de datos proporcionada por la unidad. Cuando se habla de ancho de banda de una unidad, generalm ente se está haciendo referencia al ancho de banda sostenido. Para los discos extraíbles, el ancho de banda va desde unos pocos m egabytes por segundo para las unidades más lentas, hasta más de 40 M B por segundo para las unidades más rápidas. Las cin­ tas tienen un rango sim ilar de anchos de banda, desde unos cuantos m egabytes por segundo a m ás de 30 M B por segundo. El segundo aspecto que hay que analizar en lo que se refiere a la velocidad es la laten cia de acceso. Según esta m edida de rendim iento, los discos son m ucho m ás rápidos que las cintas: el alm acenam iento de un disco es, esencialm ente, bidim ensional: todos los bits están sim ultánea­ m ente disponibles para poder acceder a ellos. En un acceso a disco, sim plem ente se desplaza el brazo de la unidad hasta el cilindro seleccionado y se espera a que transcurra la latencia rotacio­ nal, que puede ser inferior a 5 m ilisegundos. Por contraste, el alm acenam iento en cinta es tridi­ m ensional: en cualquier m om ento dado, sólo una pequeña parte de la cinta es accesible por parte del cabezal, estando la m ayoría de los bits enterrados bajo cientos o m iles de capas de cinta bobi­ nada en el carrete. Un acceso aleatorio a una cinta requiere bobinar los carretes de la cinta hasta que el bloque seleccionado pase por debajo del cabezal de la cinta, lo que puede requerir decenas o centenares de segundos. Por tanto, podem os decir generalm ente que el acceso aleatorio en un cartucho de cinta es más de 1000 veces más lento que el acceso aleatorio en un disco. Si se está utilizando un intercam biador, la latencia de acceso puede ser significativam ente mayor. Para poder cam biar un disco extraíble, la unidad debe dejar de rotar y luego el brazo robotizado debe conm utar los cartuchos de disco, tras lo cual la unidad deberá com enzar a rotar de nuevo el cartucho recién introducido. Esta operación requiere varios segundos, lo que es 100 veces m ás lento que un acceso aleatorio dentro de un disco. Por tanto, la conm utación de discos en un intercam biador tiene un im pacto relativam ente alto sobre la velocidad de acceso. En las cintas, el tiem po requerido por el brazo robotizado es aproxim adam ente igual que para el caso de un disco. Pero para poder conm utar las cintas, generalm ente es necesario rebobinar la cinta anterior antes de poder sacarla de la unidad, y dicha operación puede requerir hasta unos 4 m inutos. Asim ism o, después de cargar una nueva cinta dentro de la unidad, pueden hacer falta varios segundos para que la unidad calibre su funcionam iento de acuerdo con la cinta y se prepa­ re para las operaciones de E / S . A unque un intercam biador de cintas no muy rápido puede tener un tiem po de conm utación de cinta de 1 o 2 m inutos, este tiem po no es mucho m ayor que el tiem­ po de acceso aleatorio a la propia cinta. Por tanto, para generalizar, podem os decir que el acceso aleatorio en un intercam biador de dis­ cos tiene una latencia de decenas de segundos, m ientras que el acceso aleatorio de un intercam ­ biador de cintas tiene una latencia de centenares de segundos; conm utar las cintas requiere mucho tiempo, pero conm utar los discos no requiere tanto. Sin em bargo, tenga cuidado con estas gene­ ralizaciones: algunos intercam biadores de cintas de gam a alta pueden rebobinar, expulsar, cargar una nueva cinta y realizar el avance rápido hasta un elem ento aleatorio de datos en m enos de 30 segundos. Si sólo prestam os atención a la velocidad de las unidades de un intercam biador, el ancho de banda y la latencia parecen razonables. Sin em bargo, si centram os nuestra atención en los propios cartuchos, nos encontram os con un terrible cuello de botella. C onsidere en prim er lugar el ancho de banda'. La relación ancho de banda/capacidad de alm acenam iento de una biblioteca robotizada es m ucho m enos favorable que en el caso de un disco fijo. Para leer todos los datos alm acena­ dos en un disco duró de gran tam año podríam os necesitar en tom o a una hora, m ientras que para leer todos los datos alm acenados en una biblioteca de cintas de gran volum en podríam os necesi­ tar años. La situación en lo que respecta a la latencia de acceso es casi igual de negativa. Como ilustración, si ponem os en cola 100 solicitudes dirigidas a una unidad de disco, el tiem po medio de espera será de entorno a un segundo. Sin em bargo, si ponem os en cola 100 solicitudes dirigi­ das a una biblioteca de cintas, ei tiempo m edia de espera podría ser de más de una hora. El bajo coste del alm acenam iento terciario es el resultado de disponer de m uchos cartuchos de bajo coste que com parten unas cuantas unidades muy caras; pero el m ejor uso que se puede dar a una biblio­

440

Capitulo 12 tstructura ae almacenamiento masivo

teca de soportes extraíbles es el alm acenam iento de datos que se utilicen de m anera infrecuer porque la biblioteca sólo puede satisfacer un núm ero relativam ente pequeño de solicitudes deÉ/| por hora. íg g 1 2 .9 .3 .2

F ia b ilid a d

Ü

A unque m uy a m enudo tendemos a pensar que buen rendim iento significa alta velocidad, otro ast to im portante del rendim iento es la fiabilidad. Si tratam os de leer ciertos datos y no podem os hacer! lo debido a un fallo de la unidad o del soporte físico, desde el punto de vista práctico el tierorv ll de acceso será infinitam ente largo y el ancho de banda será infinitam ente pequeño. Por tanto, es» im portante poder com prender cuál es el grado de fiabilidad de los soportes extraíbles. „^g! Los discos m agnéticos extraíbles son algo m enos fiables que los discos duros fijos, porque ef® cartucho tiene m ayor probabilidad de verse expuesto a condiciones de entorno dañinas, como poí§¡ ejem plo el polvo, los grandes cam bios de tem peratura y de hum edad y fuerzas m ecánicas debi«* das a golpes o a que se doble el soporte físico. Los discos ópticos se consideran bastante fiablesS porque la tapa que alm acena los bits está protegida por otra tapa de plástico o cristal transparen-i: te. La fiabilidad de la cinta m agnética varía enorm em ente, dependiendo del tipo de unida'dS A lgunas unidades de bajo coste desgastan las cintas después de unas cuantas docenas de usoÉg m ientras que otros tipos son lo suficientem ente poco agresivos como para perm itir millones de'4; reutilizaciones. Por com paración con el cabezal de un disco m agnético, el cabezal en una unidadÉi de cinta m agnética es uno de los puntos débiles. El cabezal de un disco vuela sobre el soporte físi-^r co, pero el cabezal de una cinta está en estrecho contacto con la propia cinta. La acción de frota|¡ m iento de la cinta puede term inar por desgastar el cabezal después de unos cuantos miles dg decenas de m iles de horas. E n resum en, podem os decir que una unidad de disco fijo tiende a ser m ás fiable que una uñrajjj dad de cinta o de disco extraíble, m ientras que un disco óptico tiende a ser m ás fiable que u n a! cinta o disco m agnético. Pero un disco m agnético fijo tiene una debilidad: un aterrizaje de cabefi zales en un disco duro destruye por regla general los datos, m ientras que el fallo de una unidadde cinta o de una unidad de disco óptico no provoca norm alm ente daños en el cartucho de™ datos. ;f f 1 2 .9 .3 .3

C o ste

El coste de alm acenam iento es otro factor im portante. He aquí un ejemplo concreto de la forma en; que los soportes extraíbles pueden reducir el coste global de alm acenam iento: suponga que un disco duro con una capacidad de X GB tiene un precio de 200 dólares. De esta cantidad, 190 dóla­ res corresponden a la carcasa, el m otor y la controladora y 10 dólares corresponden a los propios platos m agnéticos. El coste de alm acenam iento para este disco es de 200 dólares/X GB. Ahora,; suponga que podem os fabricar esos m ism os platos albergándolos en un cartucho extraíble. Para una unidad y 10 cartuchos, el precio total será 190 + 100 dólares y la capacidad será 10X GB, por lo que el coste de alm acenam iento es 29 dólares/X por gigabyte. Incluso aunque sea un poco más caro fabricar un cartucho extraíble, el coste por gigabyte del alm acenam iento extraíble puede ser m uy inferior que el coste por gigabyte de un disco duro, debido a que el coste de la unidad se reparte entre varios cartuchos extraíbles de bajo coste. Las Figuras 12.13,12.14 y 12.15 m uestran las tendencias de coste por m egabyte para la memo­ ria D R A M , para los discos duros m agnéticos y para las unidades de cinta. Los precios de estas grá­ ficas son los precios m ás bajos que hemos podido localizar analizando los anuncios de diversas revistas inform áticas y en la W orld W ide W eb al final de cada año. Estos precios reflejan las ten­ dencias en el m ercado inform ático de consum o en el que se m ueven la m ayoría de los lectores de estas revistas, donde los precios son bajos por com paración con los m ercados de las computado­ ras de tipo m ainfram e y m inicom putadoras. En el caso de las cintas, el precio es para una unidad con una cinta. El coste global del alm acenam iento en cinta se reduce mucho a m edida que se com­ pran m ás cintas para utilizarías con una m ism a unidad, porque el precio de una cinta es una pequeña fracción del precio de la unidad. Sin em bargo, en una biblioteca de cintas de gran tama-

12.9 Estructura de almacenamiento terciario

441

Figura 12.13 Precio por megabyte para las memorias DRAM, entre 1981 y 2004. ño que contenga m iles de cartuchos, el coste de alm acenam iento está dom inado por el coste de los cartuchos de cinta. En el m om ento de escribir estas líneas en 2004, el coste por GB de los cartuchos de cinta se situaba aproxim adam ente en el entorno de 2 dólares. El coste de la m em oria DRAM fluctúa enorm em ente. En el período com prendido entre 1981 y 2004, podem os ver tres caídas abruptas de precios (en tom o a 1981,1989 y 1996), correspondien­ do a los m om entos en que un exceso de producción provocó un colapso en el m ercado. Tam bién podem os ver dos períodos (alrededor de 1987 y 1993) donde la carestía en el m ercado provocó sig­ nificativos aum entos de precio. En el caso de los discos duros, la caída de los precios ha sido m ucho más sostenida, aunque parece haberse acelerado desde 1992. Los precios de las unidades de cinta tam bién cayeron de form a sostenida hasta 1997. Desde 1997, el precio por gigabyte de las unidades de cinta de bajo coste ha dejado de caer de form a tan rápida, aunque el precio de la tec­ nología de cinta de gama m edía (como por ejem plo DAT/DDS) ha continuado cayendo y ahora se aproxim a al de las unidades de bajo coste. N o se m uestran precios de las unidades de cinta anteriores a 1984 porque, com o ya hemos m encionado, las revistas utilizadas para realizar esta

Fioura 12.14

Precio cor meqabvre oara los discos duros magnéticos, entre 1981 y 2004.

442

Capítulo 12 Estructura de almacenamiento masivo

F ig u ra 1 2 .1 5

Precio por m egabyte para una unidad d e cinta, entre 1 9 84 y 20 04 .

com parativa en las tendencias de precios se dirigen al m ercado de la inform ática de consumo y las unidades de cinta no se utilizaban am pliam ente en este m ercado antes de 1984. Podem os ver en estas gráficas que el coste del alm acenam iento ha caído enorm em ente en los últim os 20 años. C om parando las gráficas, podem os tam bién ver que el precio del alm acena­ m iento en disco ha bajado en gran m edida en relación con el precio de la m em oria D R A M y de las cintas. El precio por m egabyte de los discos m agnéticos ha m ejorado en más de cuatro órdenes de m agnitud durante las últim as dos décadas, m ientras que la correspondiente m ejora para los chips de m em oria principal sólo ha sido de tres ordenes de m agnitud. La m emoria principal hoy en día es más de 100 veces más cara que el alm acenam iento en disco. El precio por m egabyte ha caído tam bién m ucho más rápidam ente para las unidades de disco que para las unidades de cinta. De hecho, el precio por m egabyte de una unidad de disco magné­ tico se está aproxim ando al de un cartucho de cinta (sin tener en cuenta el coste de la propia uni- dad). En consecuencia, las bibliotecas de cintas de pequeño y medio tam año tienen un coste de alm acenam iento m ás alto hoy en día que los sistem as de discos con una capacidad equivalente. La dram ática caída en los precios de los discos ha hecho que el alm acenam iento terciario lle­ gue a ser casi obsoleto: ya no disponem os de ninguna tecnología de alm acenam iento terciario que sea varios órdenes de m agnitud más barata que los discos m agnéticos. Parece, en consecuencia, que el renacim iento del alm acenam iento terciario deberá esperar a que se produzca algún cambio tecnológico revolucionario. Entre tanto, el alm acenam iento en cinta verá su uso lim itado prin­ cipalm ente a cosas tales com o las copias de seguridad de unidades de disco y el archivado defi­ nitivo en enorm es bibliotecas de cintas que excedan con m ucho la capacidad práctica de alm acenam iento de las grandes granjas de discos.

12.10 Resumen Las unidades de disco son los principales dispositivos de E /S de alm acenam iento secundario en la m ayoría de las com putadoras. La m ayoría de los dispositivos de alm acenam iento secundario son discos m agnéticos o cintas m agnéticas. Las unidades de disco m odernas están estructuradas corno una gran m atriz unidim ensional de bloques lógicos de disco cuyo tam año es, usualmente, de 512 bytes. Los discos pued en co n ectarse a un sistem a inform ático de dos form as distintas: (1) utilizando

los p u ertos de E /S locales de la co m p u tad o ra host o (2) utilizando una conexión de red, com o por ejem plo red es de área de alm acen am ien to.

12.10 Resumen

443

Las solicitudes de E /S de disco son generadas por el sistem a de archivos y por el sistem a de m em oria virtual. Cada solicitud especifica la dirección de disco a la que hay que referenciar, en la form a de un núm ero lógico de bloque. Los algoritm os de planificación de disco pueden m ejorar el ancho de banda efectivo, el tiem po m edio de respuesta y la varianza del tiempo de respuesta. A lgoritm os tales com o SSTF, SCAN, C-SCAN, LOOK y C-LOOK están diseñados para llevar a cabo tales optimizació'nes, erñpleando diversas estrategias de ordenación de la cola de solicitudes de disco. Las prestaciones pueden verse afectadas por el fenóm eno de la fragm entación externa. A lgunos sistem as disponen de utilidades que perm iten explorar el sistem a de archivos para iden­ tificar los archivos fragm entados, después de lo cual m ueven los bloques de un sitio a otro para reducir el grado de fragm entación. Desfragm entar un sistem a de archivos muy fragm entando puede m ejorar significativam ente las prestaciones, aunque el rendim iento del sistema se reducirá m ientras esté en m archa el proceso de desfragm entación. Los sistem as de archivos sofisticados, com o el sistem a Fast File System de UNIX, incorporan m uchas estrategias para controlar la frag­ m entación durante la asignación de espacio, por lo que no es necesario llevar a cabo reorganiza­ ciones del disco. El sistem a operativo gestiona los bloques de disco. En prim er lugar, es necesario form atear el disco a bajo nivel para crear los sectores en el hardw are sin form ato; los nuevos discos norm al­ m ente se adquieren ya preform ateados. Después, hay que particionar el disco, crear los sistem as de archivos y asignar bloques de arranque para alm acenar un programa de arranque del sistema. Finalm ente, cuando un bloque se corrom pa, el sistem a debe tener una form a de m arcar dicho blo­ que com o no utilizable o de sustituirlo desde el punto de vista lógico por otro bloque adicional libre. Puesto que disponer de un espacio de intercam bio con un com portam iento eficiente resulta clave para obtener un bu en rendim iento, los sistem as suelen puentear el sistem a de archivos y uti­ lizar un acceso al disco sin form ato para las operaciones de E/S de paginación. Algunos sistem as dedican una partición del disco sin form ato al espacio de intercam bio, m ientras que otros utilizan un archivo dentro del propio sistem a de archivos. Finalm ente, otros sistem as perm iten al usuario o al adm inistrador del sistem a que tomen la decisión sobre qué tipo de espacio de intercam bio uti­ lizar, ya que proporcionan am bas opciones. D ebido a la cantidad de espacio de alm acenam iento requerida en los sistem as de gran tamaño, norm alm ente se suelen hacer redundantes los discos utilizando algoritm os RAID. Estos algoritm os perm iten utilizar más de un disco para una operación determ inada y con ellos se puede garanti­ zar una operación continua e incluso una recuperación autom ática en caso de que se prod u zca un fallo de disco. Los algoritm os RAID se clasifican en diferentes niveles, proporcionando cada uno de ellos una cierta com binación d e m ecanism os de fiabilidad y de altas tasas de transferencia. El esquem a de registro con escritura anticipada requiere disponer de un sistema de alm acena­ m iento estable. Para im plem entar tal tipo de alm acenam iento, tenemos que replicar la inform a­ ción necesaria en m últiples dispositivos no volátiles de alm acenam iento (usualmente discos) con m odos de fallo independientes. Tam bién necesitamos actualizar la inform ación de m anera contro­ lada para garantizar que podam os recuperar los datos estables después de cualquier fallo que tenga lugar durante la transferencia de datos o la recuperación. El alm acenam iento terciario se construye a partir de unidades de disco o de cinta que utilizan soportes extraíbles. H ay disponibles m uchas tecnologías distintas, incluyendo cintas m agnéticas, discos m agnéticos y m agneto-ópticos extraíbles y discos ópticos. . . Para los discos extraíbles, el sistem a operativo proporciona generalm ente los servicios com ple­ tos de una interfaz de sistem a de archivos, incluyendo la gestión del espacio y la planificación de la cola de solicitudes. En m uchos sistem as operativos, el nom bre de un archivo en un cartucho extraíble es una com binación de un nom bre de unidad y de un nom bre de archivo dentro de dicha unidad. Este convenio es más sim ple, pero potencialm ente más confuso, que utilizar un nom bre que identifique un cartucho específico. Para las cintas, el sistem a operativo suele proporcionar sólo una interfaz sin formato. Muchos sistem as operativos no tienen ningún soporte integrado para sistem as intercam biadores. El soporte para intercam biadores puede proporcionarse m ediante un controlador de dispositivo o

444

Capítulo 12 Estructura de almacenamiento masivo

m ed ian te u n a aplicación p rivilegiada diseñada p ara la realización de cop ias de segu rid ad o para sistem as HSM.

Tres parám etros im portantes del rendim iento son el ancho de banda, la latencia y la fiabilidad. En los discos y las cintas nos encontram os con una gam a m uy am plia de anchos de banda, pero la latencia de acceso aleatorio para una cinta es generalm ente m ucho m ayor que para un disco. La operación de cam bio de cartuchos en un intercam biador es tam bién relativam ente lenta. Puesto que un intercam biador tiene una baja relación entre unidades y cartuchos, leer una gran parte de los datos en un intercam biador puede requerir un tiem po considerable. Los soportes ópticos, que protegen la capa sensible con un recubrim iento transparente, son generalm ente m ás robustos que los soportes m agnéticos, en los cuales el m aterial m agnético está m ás expuesto a daños físicos.

Ejercicios 12.1

N inguno de los algoritm os de planificación de disco, excepto FCFS, es realm ente equitativo (puede producirse el fenóm eno de m uerte por inanición). a. Explique por qué es cierta esta afirm ación. b. D escriba una form a de m odificar algoritm os tales com o SCAN para garantizar que sean equitativos. c. Explique por qué es im portante el objetivo de la distribución equitativa en un sistema de tiem po com partido. d. Proporcione tres o m ás ejem plos de circunstancias en las que sea im portante que el sistem a operativo no sea equitativo a la hora de satisfacer las solicitudes de E /S .

12.2

Suponga que una unidad de disco tiene 5000 cilindros, num erados de 0 a 4999. La unidad está sirviendo actualm ente una solicitud en el cilindro 143 y la solicitud anterior correspon­ dió al cilindro 125. La cola de solicitudes pendientes, en orden FIFO, es 8 6 ,1 4 7 0 , 913,1774, 9 4 8 ,1 5 0 9 ,1 0 2 2 ,1 7 5 0 ,1 3 0 C om enzando desde la posición actual del cabezal, ¿cuál será la distancia total (en cilindros) que el brazo del disco tendrá que m overse para satisfacer todas las solicitudes pendientes para cada uno de los siguientes algoritm os de planificación de disco? a. FCFS b. SSTF c. SCAN d. LOOK e. C-SCAN f.

12.3

C-LOOK

Los principios de física elem ental establecen que cuando se som ete un objeto a una acelera­ ción constante a, la relación entre la distancia d y el tiem po t está dada por d = ~ at2. Suponga que, durante una búsqueda, el disco del Ejercicio 12.2 acelera el brazo de disco a una velo­ cidad constante durante la prim era m itad de la búsqueda y luego frena el brazo de disco a la m ism a velocidad durante la segunda m itad de la búsqueda. Suponga que el disco puede realizar una búsqueda hasta un cilindro adyacente en 1 m ilisegundo y una búsqueda reco­ rriendo los 5000 cilindros en 18 m ilisegundos. a. La distancia de una búsqueda es el núm ero de cilindros que se m ueve el cabezal. Explique por qué el tiem po de búsqueda es proporcional a la raíz cuadrada de la dis­ tancia de c U.bC|lÍL-'CÍti.

Ejercicios

445

b. Escriba una ecuación para el tiem po de búsqueda en función de la distancia de bú s­ queda. Esta ecuación debe tener la form a t = x + y^ÍL, donde t es el tiempo en m ilise­ gundos y L es la distancia de búsqueda en cilindros. c. C alcule el tiempo total de búsqueda para cada uno de los algoritm os de planificación del Ejercicio 12.2. D eterm ine qué algoritm o-de planificación es el m ás rápido (el que tiene el tiempo total de búsqueda m enor). d. El porcentaje de aceleración es el tiem po ah o rrad o divid id o p or el tiem po original. ¿C uál es el porcentaje de aceleración del algoritm o de planificación m ás rápido, con resp ec­ to a FCFS?

12.4

Suponga que el disco del Ejercicio 12.3 rota a 7200 RPM. a. ¿Cuál es la latencia rotacional m edia en esta unidad de disco? b. ¿Q ué distancia de búsqueda puede recorrerse en el tiempo calculado en el apar­ tado a?

12.5

Escriba un program a Java para planificación de disco utilizando los algoritm os de planifi­ cación SCAN y C-SCAN.

12.6

Com pare las prestaciones de los algoritm os de planificación C-SCAN y SCAN, suponiendo una distribución uniform e de las solicitudes. C onsidere el tiempo m edio de respuesta, el tiem po com prendido entre la llegada de una solicitud y la term inación del servicio corres­ pondiente a dicha solicitud, la varianza en el tiem po de respuesta y el ancho de banda efec­ tivo. ¿C óm o dependen las prestaciones de los valores relativos del tiem po de búsqueda y de la latencia rotacional?

12.7

Las solicitudes no suelen estar uniform em ente distribuidas. Por ejem plo, cabe esperar que un cilindro que contenga la tabla FA T de un sistem a de archivos o los inodos tenga una m ayor tasa de acceso que un cilindro que sólo contenga archivos. Suponga que sabemos que el 50 por ciento de las solicitudes están dirigidas a un núm ero fijo pequeño de cilindros. a. ¿Sería especialm ente adecuado para este caso algunos de los algoritm os de planifica­ ción expuestos en este capítulo? Explique su respuesta. b. Proponga un algoritm o de planificación de disco que proporcione un rendim iento aun mejor, aprovechando este “punto caliente” del disco. c. Los sistemas de archivos norm alm ente localizan los bloques de datos m ediante una tabla de indirección, com o por ejem plo una tabla FA T en DOS o Jos inodos en UNIX. Describa una o más m aneras de aprovechar este m ecanism o de indirección para m ejo­ rar el rendim iento del disco.

12.8

¿Podría un esquema de organización RAID nivel 1 proporcionar un m ejor rendim iento para las solicitudes de lectura que un esquem a de organización RAID nivel 0 (con distribución en bandas no redundante de los datos)? En caso afirm ativo, ¿cómo?

12.9

Considere un esquem a de organización RAID nivel 5 com puesto por cinco discos, con la inform ación de paridad para cada conjunto de cuatro bloques en cuatro discos alm acenada en el quinto disco. ¿A cuántos bloques hay que acceder para llevar a cabo las siguientes ope­ raciones? a. Una escritura de un bloque de datos. b. Una escritura de siete bloques continuos de datos.

12.10 C om pare la tasa de transferencia que puede conseguirse en un esquem a de organización RAID nivel 5 con la que se puede obtener en un esquem a de organización RAID nivel 1 para

las siguientes operaciones: a. Operaciones de lechara en bloques aislados.

Capítulo 12 Estructura de almacenamiento masivo

b. O peraciones de lectura en m últiples bloques contiguos. 12.11 C om pare la velocidad de las operaciones de escritura que puede conseguirse en un esque­ ma de organización RAID nivel 5 con la que puede obtenerse en un esquema de organiza-' ción RAID nivel 1. 12.12 Suponga que dispone de una configuración m ixta, com puesta por discos con una organiza­ ción RAID nivel 1 y discos con una organización RAID nivel 5. Suponga que el sistem a tiene flexibilidad a la hora de decidir qué organización de discos utilizar para alm acenar cada archivo concreto. ¿Q ué archivos habría que alm acenar en los discos RAID nivel 1 y cuáles en los discos RAID nivel 5 para optim izar el rendim iento? 12.13 ¿Existe alguna form a de im plem entar un alm acenam iento verdaderam ente estable? Razone su respuesta. 12.14 La fiabilidad de una unidad de disco duro suele describirse en térm inos de una magnitud denom inada tiempo m edio entre fallos (M TBF, m ean tim e betw een failures). a. Si un sistem a contiene 1000 unidades de disco, cada una de las cuales tiene un MTBF igual a 750.000 horas, ¿cuál de las siguientes afirm aciones describe de form a más aproxim ada la frecuencia con la que se producirá un fallo de una unidad en esa gran­ ja de discos: una por cada 1000 años, una por siglo, una por década, una por año, una por mes, una por sem ana, una por día, una por hora, una por minuto o una por segundo? b. Las estadísticas de m ortalidad indican que, com o prom edio, los habitantes de los Estados U nidos tienen una probabilidad de 1 entre 1000 de m orir entre los 20 y los 21 años. Calcule el MTBF para las personas de 20 años. Pase este resultado de horas a años. ¿Q ué inform ación nos proporciona este valor de MTBF acerca de la esperanza de vida de una persona de 20 años? c. El fabricante garan tiza un MTBF de 1 millón de horas para un cierto m odelo de uni­ dad de disco. ¿Q ué p o d em os concluir acerca del núm ero de años durante los cuales está en garan tía una de estas unidades?

12.15 Explique las ventajas y desventajas relativas de las técnicas de utilización de sectores adi­ cionales y de deslizam iento de sectores. 12.16 Explique las razones por las que el sistem a operativo podría requerir inform ación precisa acerca del. m odo en que están alm acenados los bloques en el disco. ¿Cómo podría el siste­ ma operativo m ejorar la velocidad del sistem a de archivos utilizando esta inform ación? 12.17 El sistem a operativo trata generalm ente los discos extraíbles com o sistemas de archivos com partidos, pero las unidades de cinta las asigna a una única aplicación cada vez. Indique tres razones que puedan explicar este diferente tratam iento de los discos y las cintas. D escriba las características adicionales que necesitaría el sistema operativo para soportar un acceso com partido al sistem a de archivos en caso de em plear un intercam biador de cintas. ¿N ecesitarían tener alguna propiedad especial las aplicaciones que com partieran el inter­ cam biador de cintas o podrían utilizar los archivos com o si éstos residieran en el disco? Razone su respuesta. . . 12.18 ¿Cuáles serán los efectos en térm inos de coste y de prestaciones si el alm acenam iento en cinta tuviera la m ism a densidad de alm acenam iento por unidad de área que el alm acena­ m iento en disco? (La densidad de alm acen am ien to es el núm ero de o g ab its por centím e­ tro cuadrado). 12.19 Podem os utilizar estim aciones sim ples para com parar el coste y las prestaciones de un sis­ tem a de alm acenam iento con una capacidad en terabytes form ado enteram ente por discos con otro que incorpore alm acenam iento terciario. Suponga que cada uno de los discospnagnéticos tiene una capacidad de 10 GB, que su coste es de 1000 dólares, que perm iten trans-

s; \ j r nn„ ípoundn v que tienen una latencia media de acceso de 15 milisegundos.

Notas bibliográficas

447

Suponga que una biblioteca de cintas tiene un coste de 10 dólares por gigabvte, que perm i­ te transferir 10 MB por segundo y qu e tiene una latencia m edia de acceso de 20 segundos. Calcule el coste total, la tasa m áxim a total de transferencia de datos y el tiempo m edio de espera para un sistem a form ado exclusivam ente por discos. Si tiene que realizar algún tipo de suposición acerca de la carga de trabajo, describa esas suposiciones y justifíquelas. Ahora, suponga que sólo se utiliza frecuentem ente el 5 por ciento de los datos, los cuales deberán residir en disco, pero que el otro 95 por ciento se archiva en la biblioteca de cintas. Suponga tam bién qu e el sistem a de discos gestiona el 95 por ciento de las solicitudes y que la biblioteca gestiona el otro 5 por ciento. ¿Cuál será el coste total, la tasa m áxim a total de transferencia de datos y el tiem po de espera m edio para este sistem a de alm acenam iento jerárquico? 12.20 Im agine que ya se hubiera inventado una unidad de alm acenam iento holográfica. Suponga que la unidad holográfica costara 10000 dólares y tuviera un tiem po m edio de acceso de 40 m ilisegundos. Suponga tam bién que utilizara un cartucho de 100 dólares del tam año de un CD; dicho cartucho perm itiría alm acenar 40000 im ágenes y cada una es una im agen cuadra­ da en blanco y negro con una resolución de 6000 x 6000 píxeles (cada píxel requiere un bit de alm acenam iento). Suponga que la unidad puede leer o escribir una im agen en 1 milisegundo. Responda a las siguientes cuestiones: a. ¿Q ué posibles aplicaciones tendría este dispositivo?

b. ¿Cóm o afectaría este dispositivo al rendim iento de E/S de un sistema inform ático? c. ¿Q ué otros tipos de dispositivos de alm acenam iento, si es que hay alguno, quedarían obsoletos com o resultado de la invención de este dispositivo? 12.21 Suponga que un cartucho de disco óptico de 5,25 pulgadas y una sola cara tiene una densi­ dad de alm acenam iento de 1 GB por pulgada cuadrada. Suponga que una cinta m agnética tiene una densidad de alm acenam iento de 20 m egabits por pulgada cuadrada y que tiene 1/2 pulgadas de anchura y 1800 pies de longitud. Realice una estim ación de las capacida­ des de alm acenam iento de estos dos tipos de cartuchos. Suponga que existiera una cinta óptica que tuviera el mismo tam año físico que la cinta magnética pero la misma densidad de alm acenam iento que el disco óptico. ¿Qué volum en de datos podría alm acenar la cinta óptica? ¿Cuál podría ser el precio de m ercado de la cinta óptica si la cinta m agnética cuesta 25 dólares? (Nota: 1 pulgada = 2,54 cm ; 1 pie = 12 pulgadas). 12.22 Explique cóm o podría m antener el sistem a operativo una lista de espacio libre para un sis­ tema de archivos residente en cinta. Suponga que la tecnología de cinta es del tipo de sólo adición y que utiliza m arcas EO T y com andos l ó c a t e , s p a c e y r e a d _ p o s i t i o n com o se describe en la Sección 12.9.2.1.

Notas bibliográficas Un análisis de las m atrices redundantes de discos independientes (RAID) se presenta en Patterson et al. [1988] y en la detallada obra de C hen et al. [1994], Las arquitecturas de sistem as de discos para la inform ática de altas prestaciones se analiza en Katz et al. [1989]. Las extensiones de los sis­ temas RAID se presentan en VVilkes et al. [1996] y Yu et al. [2000]. Teorey v Pinkerton [1972] pro­ porciona uno de los prim eros análisis com parativos de los algoritm os de planificación de disco; en dicha obra se utilizan sim ulaciones en las que se m odela un disco de forma que el tiem po de búsqueda es lineal con respecto al núm ero de cilindros recorridos; para este disco, LOOK es una buena elección para longitudes de cola inferiores a 140, m ientras que C-LOOK resulta adecuado para longitudes de cola p or encim a de 100. King [1990] describe form as de m ejorar el tiem po de búsqueda m oviendo el brazo de disco cuando el disco no está realizando ninguna otra tarea. Seitzer et al. [1990] y Jacobson y VVilkes [1991] describen algoritm os de planificación de discos que u ... ... pn cl!Pn|r, latencia rotacional, adem ás del tiem po de búsqueda. Los sistem as de optím i-

Capítulo 12 Estructura de almacenamiento masivo

al. [2000]. W orthington et al. [1994] trata el tema de las prestaciones de los discos y dem uestra que los m ecanism os de gestión de defectos tienen un im pacto com pletam ente despreciable sobre esas prestaciones. La cuestión de cóm o ubicar los denom inados datos calientes para m ejorar los tiem­ pos de búsqueda ha sido considerada por Ruem m ler y W ilkes [1991] y A kyurek y Salem [1993], Ruem m ler y W ilkes [1994] describe un m odelo de rendim iento m uy preciso para una unidad de disco m oderna. W orthington et al. [1995] indica-cóm o'determ inar las propiedades de bajo nivel de los discos, com o la estructura de zonas, y el trabajo iniciado en esta obra se am plía en Schindler y G regory [1999]. Las cuestiones relativas a la gestión de potencia en los discos se analizan en D ouglis et al. [1994], Douglis et al. [1995], Greenaw alt [1994] y Golding et al. [1995]. El tam año de las operaciones de E/S y la aleatoriedad de la carga de trabajo tienen una consi­ derable influencia sobre las prestaciones de los discos. O usterhout et al. [1985] y Ruem m ler y W ilkes [1993] proporcionan num erosos datos interesantes sobre las características de las cargas de trabajo, incluyendo que la m ayoría de los archivos son de pequeño tam año, que la m ayoría de los archivos de reciente creación se borran poco tiempo después, que la m ayoría de los archivos que se abren para lectura se leen de m anera secuencial de principio a fin y que la m ayoría de las bús­ quedas son cortas. M cK usick et al. [1984] describe el sistem a FFS (Fast File System ) de Berkeley, que utiliza m uchas técnicas sofisticadas para obtener un buen rendim iento con diversos tipos de carga de trabajo. M cVoy y K leim an [1991] exponen m ejoras adicionales del sistem a FFS básico. Q uinlan [1991] describe cóm o im plem entar un sistem a de archivos en un alm acenam iento WORM con una caché en disco m agnético; Richards [1990] analiza la utilización de un sistem a de archi­ vos en un alm acenam iento secundario. M aher et al. [1994] proporciona una panorám ica de la inte­ gración de sistem as de archivos distribuidos y un alm acenam iento secundario. El concepto de jerarquía de alm acenam iento ha sido estudiado durante más de treinta años. Por ejem plo un artículo de 1970 de M attson et al. [1970] describe una técnica m atem ática para pre­ decir el rendim iento de una jerarquía de alm acenam iento. A lt [1993] describe la utilización de soportes de alm acenam iento extraíbles en un sistem a operativo com ercial y M iller y Katz [1993] describe las características del acceso al alm acenam iento terciario en un entorno de supercom putación. Benjam in [1990] proporciona una panorámica de los requerim ientos de alm acenam iento m asivos del proyecto EO SD IS en la NASA. La gestión y utilización de discos conectados por red y discos program ables se analizan en G ibson et al. [1997b], Gibson et al. [1997a], Riedel et al. [1998] y Lee y Thekkath [1996]. La tecnología de alm acenam iento holográfica es la m ateria de un artículo de Psaltis y Mok [1995]; una buena recopilación de artículos sobre este tema publicados desde 1963 es la que ha rea­ lizado Sincerbox [1994], A sthana y Finkelstein [1995] describe varias tecnologías de alm acena­ m iento em ergentes, incluyendo el alm acenam iento holográfico, la cinta óptica y la tecnología de trampas de electrones. Toigo [2000] proporciona una descripción detallada de la tecnología de disco m oderna y de varias tecnologías de alm acenam iento potenciales que podrían usarse en el futuro.

Sistemas de E/S Las dos tareas principales de una com putadora son la E/S y el procesam iento. En m uchos casos, la tarea principal es la E/S y el procesam iento es m eram ente incidental. Por ejem plo, cuando lee­ m os una página w eb o editam os un archivo, nuestro interés inm ediato es leer o introducir cierta inform ación, no calcular una respuesta. El papel del sistem a operativo en la E/S de la com putadora consiste en gestionar y controlar las operaciones y dispositivos de E/S. Aunque en otros capítulos aparecen tem as relacionados, vam os a juntar aquí las diversas piezas para dibujar una im agen com pleta de la E/S. Prim ero, des­ cribirem os los fundam entos del hardw are de E/S, porque la naturaleza de interfaz hardware im pone una serie de requisitos a la funcionalidad interna del sistem a operativo. A continuación, verem os los servicios de E/S proporcionados por el sistem a operativo y el m odo de integrar dichos servicios en la interfaz de E/S de las aplicaciones. D espués, explicarem os cóm o el sistema operativo establece el puente entre la interfaz hardw are y la interfaz de las aplicaciones. A nalizarem os tam bién el m ecanism o STREAMS de UNIX System V, que perm ite a las aplicaciones ensam blar dinám icam ente pipelines de código de controladores. Finalm ente, verem os los aspectos de rendim iento relativos a la E/S y los principios del diseño de sistem as operativos que m ejoran dicho rendim iento.

OBJETIVOS DEL CAPITULO •

Analizar la estructura dei subsistem a de E/s d e un sistem a operativa.

•

Explorar los principios en que se b a sa el hardware de E/S y los asp ecto s relativos a su comple­ jidad. ... . c .

• - Proporcionar detalles sobre el rendimiento del hardware y el software de E/S.

13.1 Introducción El control de los dispositivos conectados a la com putadora es una de las principales preocupacio­ nes de los diseñadores de sistem as operativos. Debido a que existe una variedad tan am plia de dispositivos de E/S tanto en lo respecta a sus funciones com o en cuanto a su velocidad de opera­ ción (considere, por ejem plo, un ratón, un disco duro y una juke box para CD-ROM), se necesitan diversos m étodos para controlar esos dispositivos. D ichos m étodos form an el subsistem a de E/S del kem el, que aísla al resto del kem e! de la com plejidad asociada con la gestión de los dispositivos de

E/S.

En el cam po de la tecnología de dispositivos de E/S se,experim entan dos tendencias que están en conflicto m utuo. De un lado, podem os ver una creciente estandarización de las interfaces soft­ w are y hardware; esta tendencia nos ayuda a incorporar generaciones m ejoradas de dispositivos

450

Capítulo 13 Sistemas de E/S

dentro de las com putadoras de sistem as operativos existentes. Por otro lado, podemos ver ur\a¡¡ variedad cada vez más am plia de dispositivos de E /S ; algunos nuevos dispositivos son tan distin-3 tos de los dispositivos anteriores que constituye todo un desafío incorporarlos en las com putadojf ras y los sistem as operativos. Este desafío se afronta m ediante una com binación de técnicas| hardw are y softw are. Los elem entos básicos del hardw are de E/S, com o los puertos, buses y corSi troladores de dispositivo, perm iten integrar una am plia variedad de dispositivos de E/s. Para¡¡ encapsular los detalles y las peculiaridades de diferentes tipos de dispositivos, el kernel de un sis^i tem a operativo se estructura de m odo que haga uso de m ódulos específicos controladores de dis-jj positivos. Los controladores de disp ositivo presentan al subsistem a de E/S una interfaz uniforme s de acceso a los dispositivos, de form a parecida a como las llam adas al sistem a proporcionan una., interfaz estándar entre la aplicación y el sistem a operativo. ‘

13.2 Hardware de E/S Las com putadoras interaccionan con una am plia variedad de tipos de dispositivos. La mayoría de esos dispositivos pueden clasificarse en una serie de categorías generales: dispositivos de almace- : nam iento (discos, cintas), dispositivos de transm isión (tarjetas de red, m ódem s) y dispositivos dé* interfaz hum ana (pantalla, teclado, ratón). O tros dispositivos son más especializados, como por ejem plo el volante de un avión de caza m ilitar o de una lanzadera espacial. En este tipo de aero-* naves, las personas proporcionan los datos de entrada a la com putadora de vuelo mediante una palanca y una serie de pedales controlados con los pies, y la com putadora envía una serie de com andos de salida que hacen que los m otores m uevan los alerones, los tim ones o las válvulas de com bustible. Sin em bargo, a pesar de la increíble variedad de dispositivos de E/S existentes, sólo”' son necesarios unos cuantos conceptos para com prender cóm o se conectan los dispositivos y cóm o puede el softw are controlar el hardw are asociado. Los dispositivos se com unican con los sistem as inform áticos enviando señales a través de un cable o incluso a través del aire. Cada dispositivo se com unica con la m áquina a través de un punto de conexión (o puerto), com o por ejem plo un puerto serie. Si los dispositivos utilizan un conjunto com ún de hilos, dicha conexión se denom ina bus. Un bus es un conjunto de hilos, junto con un protocolo rígidam ente definido que especifica el conjunto de m ensajes que pueden enviar­ se a través de esos hilos. En térm inos electrónicos, los m ensajes se transm iten m ediante patrones de tensiones eléctricas aplicadas a los hilos, con unos requisitos de tem porización bien definidos. Cuando el dispositivo A tiene un cable que se inserta en el dispositivo B, y el dispositivo B tiene un cable que se inserta en el dispositivo C, y el dispositivo C se inserta en un puerto de la compu­ tadora, este tipo de dispositivo se denom ina conexión en cascada. Las conexiones en cascada sue­ len funcionar com o un bus. Los busés se utilizan en m ultitud de ocasiones dentro de la arquitectura de los sistemas infor­ m áticos. En la Figura 13.1 se m uestra una estructura típica de un bus de PC. Esta figura muestra un bu s P C I (el bus com ún de los sistem as PC) que conecta el subsistem a procesador-m em oria con los dispositivos de alta velocidad y un bu s de expan sión qu e conecta los dispositivos relativam en­ te lentos, com o el teclado y los puertos serie y paralelo. En la parte superior derecha de la figura, podem os ver cuatro discos conectados a un bus SCSI que se inserta en una controladora SCSI. Una controladora es una colección de com ponentes electrónicos que perm ite controlar un puerto, un bus o un dispositivo. Un ejem plo sim ple de controladora de dispositivo sería la con­ troladora de un puerto serie: se trata de un único chip (o una parte de un chip) dentro de la con­ troladora que controla las señales que se transm iten a través de los hilos de un puerto serie. Por contraste, una controladora de bus SCSI no es tan sim ple; com o el protocolo SC SI es muy com ple­ jo, la controladora de bus SC SI se suele im plem entar m ediante una tarjeta de circuitos separada o (adaptadora h o s t) que se inserta en la com putadora. N orm alm ente, dicha tarjeta separada contie­ ne un procesador, m ícrocódigo y algo de m em oria privada para poder procesar los mensajes del protocolo SCSI. Algunos dispositivos tienen sus propias controladoras integradas. Si examinamos una unidad de disco, podem os ver una tarjeta de circuito en uno de los lados; dicha tarjeta es la ,, controladora de disco e im plem enta el lado correspondiente al disco para el protocolo utilizado en algún tipo de conexión, com o por ejem plo SC5¡ o ATA. Tiene el rrucrocódigo necesario y un

13.2 Hardware de E/S

monitor

451

procesador caché

controladora , gráfica

controladora puente/memoria

memoria

■hi«

controladora de discos IDE

interfaz bus de expansión

ptiérfo paralelo

teclado

| puerto 1 serie

Figura 13.1 Una estructura de buses típica en un PC. procesador para realizar diversas tareas, com o el m apeo de sectores erróneos, la pre-extracción, el alm acenam iento en búfer y el alm acenam iento en caché. ¿Cómo puede proporcionar com andos y datos el procesador a una controladora para llevar a cabo una transferencia de E/S? La respuesta sim ple es que la controladora dispone de uno o más registros para los datos y las señales de control. El procesador se com unica con la controladora leyendo y escribiendo patrones de bits en dichos registros. Una form a de llevar a cabo esta com u­ nicación es utilizando instrucciones de E/S especiales que especifican la transferencia de un byte o de una palabra a una dirección de puerto de E/S. La instrucción de E/S configura las líneas de bus para seleccionar el dispositivo apropiado y para leer o escribir bits en un registro del disposi­ tivo. A lternativam ente, la controladora de dispositivo puede soportar una E /S m apeada en m em oria. En este caso, los registros de control del dispositivo están m apeados en el espacio de direcciones del procesador. La CPU ejecuta las solicitudes utilizando instrucciones estándar de transferencia de datos para leer y escribir los registros de control del dispositivo. Algunos sistem as utilizan am bas técnicas. Por ejem plo, un PC utiliza instrucciones de E /S para controlar algunos dispositivos y E/S m apeada en m em oria para controlar otros. La Figura 13.2 m uestra las direcciones usuales de puertos de E/S en un PC. La controladora gráfica tiene puertos de E/S para las operaciones básicas de control, pero tam bién dispone de una gran región m apea­ da en m emoria para alm acenar el contenido de la pantalla. El proceso envía la salida a la pantalla escribiendo datos en esa región m apeada en m em oria. La controladora genera la im agen de pan­ talla basándose en el contenido de esa m em oria. Esta técnica resulta muy sim ple de utilizar; ade­ m ás, resulta m ás rápido escribir m illones de bytes en la m em oria gráfica que ejecutar m illones de instrucciones de E/S. Pero la facilidad de escritura en una controladora de E / S m apeada en m em o­ ria se ve com pensada por una desventaja; puesto que uno de los tipos más com unes de fallo de softw are es la escritura m ediante un puntero incorrecto en una región de memoria distinta de la que se pretendía, los registros de dispositivos m apeados en m em oria son vulnerables a la m odifi­ cación accidental por parte de los programas. Por supuesto, la memoria protegida nos ayuda a reducir este riesgo. Un puerto de E/S está com puesto típicam ente de cuatro registros, denom inados (1) registro de esladn ‘2< recistro de control, 13) reeistro de entrada de datos v (4) registro de salida de datos.

Capítulo 13 Sistemas de E/S

Figura 13 .2

Ubicaciones de los puertos de E/S de los dispositivos en un PC (parcial).

• El host lee el registro de entrada de datos para obtener la entrada. • El host escribe en el registro de salid a de datos para enviar la salida. • El registro de estado contiene bits que el host puede leer. Estos bits indican estados, com o por ejem plo si se ha com pletado la ejecución del com ando actual, si hay disponible un byte para ser leído en el registro de entrada de datos o si se ha producido una condición de error en el dispositivo. • El registro de con trol puede ser escrito por el host para iniciar un com ando o para cam biar el modo de un dispositivo. Por ejem plo, un cierto bit del registro de control de un puerto serie perm ite seleccionar entre com unicación full-dúplex y sem i-dúplex, otro bit activa la com probación de paridad, un tercer bit configura la longitud de palabra para que sea de 7 u 8 bits y otros bits seleccionan algunas de las velocidades soportadas por el puerto serie. Los registros de datos tienen norm alm ente entre 1 y 4 bytes de tamaño. A lgunas controladoras tienen chips FIFO que perm iten alm acenar varios bytes de datos de entrada y de salida, para expandir la capacidad de la controladora m ás allá del tam año que el registro de datos tenga. Un chip FIFO puede alm acenar una pequeña ráfaga de datos hasta que el dispositivo o host sea capaz de recibir dichos datos.

13.2.1 Sondeo El protocolo com pleto de interacción entre el host y una controladora puede ser intrincado, pero la noción básica de negociación resulta m uy sim ple. Vam os a explicar el concepto de negociación m ediante un ejem plo. Supongam os que se utilizan 2 bits para coordinar la relación productorconsum idor entre la controladora y el host. La controladora indica su estado m ediante el bit de ocupado en el registro de estado. La controladora activa el bit de ocupado cuando está ocupada tra­ bajando y borra el bit de ocupado cuando está lista para aceptar el siguiente com ando. El host indi­ ca sus deseos m ediante el bit de com ando preparado en el registro de comando: el host activa el bit de com ando preparado cuando hay disponible un com ando para que la controladora lo ejecute. En nuestro ejem plo, el host escribe la salida a través de un puerto, coordinándose con la controlado­ ra m ediante un procedim iento de negociación de la forma siguiente: 1. El host lee repetidam ente el bit de ocupado hasta que dicho bit pasa a cero. 2. El host activa el bit de escritura en el registro de com ando y escribe un byte en el registro de datos de salida. ~

13.2 Hardware de E/S

3. El

host activa

el bit de

453

com ando preparado.

4. C uando la controladora observa que está activado el bit de

ocupada.

comando preparado,

activa el bit de

5. La controladora lee el registro de com andos y ve el com ando de escritura. A continuación, lee el registro de salida de datos para obtener el byte y lleva a cabo' la E/S hacia el dispositivo.

6. La controladora borra el bit de com ando preparado, borra el bit de e rro r en el registro para indicar que la que ha finalizado.

E/S

de dispositivo ha tenido éxito

y

borra el bit

de ocupado

de estado

para indicar

Este bucle se repite para cada byte. En el paso 1, el host se encuentra en un estado de espera activa o sondeo: ejecuta un bucle, leyendo una y otra vez el registro de estado hasta que el bit de ocupada se desactiva. Si la controla­ dora y el dispositivo son de alta velocidad, este m étodo resulta razonable, pero si la espera puede ser larga, quizás convendría m ás que el host conm utara a otra tarea. Pero entonces, ¿cóm o puede saber el host cuando ha pasado a estar inactiva la controladora? En algunos dispositivos, el host debe dar servicio al dispositivo rápidam ente o se producirá una pérdida de datos. Por ejem plo, cuando llega un flujo de datos a través de un puerto serie o desde el teclado, el pequeño búfer de la controladora se desbordará si el host espera dem asiado antes de leer los bytes, con lo que podría producirse una pérdida de datos. En m uchas arquitecturas inform áticas, para sondear un dispositivo basta con tres ciclos de ins­ trucciones de CPU: leer un registro del dispositivo, efectuar una operación de and lógica para extraer un bit de estado y s a lta r si ese bit es distinto de cero. Obviam ente, la operación básica de sondeo resulta m uy eficiente. Pero el sondeo pasa a ser ineficiente cuando se le ejecuta de m anera repeti­ da para encontrar únicam ente que sólo en raras ocasiones está listo el dispositivo para ser servido, m ientras otras tareas útiles de procesam iento que podría haber ejecutado la CPU perm anecen sin hacer. En tales casos, puede ser m ás eficiente que la controladora hardware notifique a la CPU cuándo ha pasado el dispositivo a estar listo para el servicio, en lugar de forzar a la CPU a sonde­ ar repetidam ente el dispositivo para ver si se ha term inado la operación de E/S. El m ecanism o hardw are que perm ite a un dispositivo notificar los eventos a la CPU se denomina interrupción.

13.2.2 Interrupciones El m ecanism o básico de interrupción funciona de la form a siguiente. El hardware de la CPU tiene un hilo denom inado lín ea de solicitu d de in terru p ción que la CPU com prueba después de ejecu­ tar cada instrucción. Cuando la CPU detecta que una controladora ha activado una señal a través de la línea de solicitud de interrupción, la CPU guarda el estado actual y salta a la ru tina de trata­ m ien to de in terru pcion es situada en una dirección fija de la m em oria. La rutina de tratam iento de interrupciones determ ina la causa de la interrupción, lleva a cabo el procesam iento necesario, realiza una restauración del estado y ejecuta una instrucción r e t u r n freír, i n t e r r u p t para volver a situar la CPU en el estado de ejecución anterior a que se produjera la interrupción. D ecim os que la controladora del dispositivo genera una interrupción enviando una determ inada señal a través de la línea de solicitud de interrupción, la CPU atrapa la interrupción y la despacha a la rutina de tratam iento de interrupciones y la rutina borra la interrupción dando servicio al dis­ positivo. La Figura 13.3 resum e el ciclo de E/S dirigido por interrupción. El m ecanism o básico de interrupción perm ite a la CPU responder a un suceso asincrono, com o es el caso en que una controladora de dispositivo pasa a estar lista para ser servida. Sin em bargo, en los sistem as operativos m odernos necesitam os funciones más sofisticadas de tratam iento de interrupciones:

1 . N ecesitam os poder diferir el tratam iento de una interrupción durante las secciones de proce­ sam iento crítico. 2. N ecesitam os una form a eficiente de despachar la interrupción a la rutina de tratam iento de interrupciones apropiada para un cierto dispositivo sin necesidad de sondear prim ero todos ve*- - •ió 1 ha generado la interrupción.

Capítulo 13 Sistemas de E/S

CPU

controladora de E/S

1 el controlador de dispositivo inicia la E/S

la CPU comprueba las interrupciones entre las instrucciones

ía CPU recibe una interrupción y transfiere el control a la rutina de tratamiento de interrupciones

las condiciones de entrada preparada/ salida completa o error generan lina señal de interrupción

6 la CPU continúa el procesamiento de la tarea interrumpida

Figura 13 .3

Ciclo de E/S dirigido por interrupción.

3. Necesitam os interrupciones m ultinivel, de m odo que el sistem a operativo pueda distinguir entre interrupciones de alta y baja prioridad, y pueda responder con el grado de urgencia apropiado. En el hardw are inform ático m oderno, estas tres funcionalidades las proporciona la CPU y el hard­ w are de la controladora de in terru p cion es. La m ayoría de los procesadores tienen dos líneas de solicitud de interrupción. Una de ellas es la in terru p ción no en m ascarable, que está reservada para sucesos tales com o los errores de m em oria no recuperables. La segunda línea de interrupción es enm ascarable: puede ser desacti­ vada por la CPU antes de la ejecución de secuencias de instrucciones críticas que no deban ser inte­ rrumpidas. La interrupción enm ascarable es la que las controladoras de dispositivo utilizan para solicitar servicio. El m ecanism o de interrupción acepta una d irección, que es el núm ero que selecciona una ruti­ na específica de tratam iento de interrupciones de entre un pequeño conjunto de rutinas disponi­ bles. En la m ayoría de las arquitecturas, esta dirección es un desplazam iento dentro de una tabla denom inada vector de in terru pcion es. Este vector contiene las direcciones de m em oria de las ruti­ nas especializadas de tratam iento de interrupciones. El propósito de un m ecanism o de interrup­ ciones vectorizado es red u cir la necesidad de que una única rutina de tratam iento de interrupciones tenga que analizar todas las posibles fuentes de interrupción para determ inar cuál es la que necesita servicio. En la práctica, sin em bargo, las com putadoras tienen más dispositivos (y por tanto más rutinas y tratam ientos de interrupciones) que direcciones existentes en el vector de interrupción. Una form a com ún de resolver este problem a consiste en utilizar la técnica del encad enam iento de in terru pcion es, en la que cada elem ento del vector de interrupciones apunta

13.2 Hardware de E/S

455

a la cabeza de una lista de rutinas de tratam iento de interrupción. C uando se genera una interrup­ ción, se llam a una a una a las rutinas de la lista correspondiente, hasta que se encuentre una ruti­ na que pueda dar servicio a la solicitud. Esta estructura representa un com prom iso entre el gasto asociado a disponer de una tabla de interrupciones de gran tam año y la poca eficiencia que se experim enta a la hora de despachar las interrupciones a una única rutina de tratamiento. La Figura 13.4 ilustra el diseño del vector de interrupción para el procesador Intel Pentium . Los sucesos num erados de 0 a 31, que son no enm ascarables, se utilizan para señalizar diversas con­ diciones de error. Los sucesos com prendidos entre 32 y 255, que son enm ascarables, se utilizan para cosas tales com o las interrupciones generadas por los dispositivos. El m ecanism o de interrupciones tam bién im plem enta un sistem a de n iv eles de prioridad de in terru pción. Este m ecanism o perm ite a la CPU diferir el tratam iento de las interrupciones de ba­ ja prioridad sin enm ascarar todas las interrupciones, y hace posible que una interrupción de alta prioridad desaloje a otra interrupción de prioridad m ás baja. Los sistem as operativos m odernos interactúan con el m ecanism o de interrupciones de varias form as distintas. D urante el arranque, el sistem a operativo com prueba los buses hardw are para determ inar qué dispositivos existen e instalar las rutinas de tratam iento de interrupción corres­ pondientes dentro del vector de interrupciones. Durante la E/S, las diversas controladoras de dis­ positivo generan interrupciones cuando están listas para ser servidas. Estas interrupciones significan que se ha com pletado una operación de salida, o que hay disponibles datos de entrada o que se ha detectado un fallo. El m ecanism o de interrupciones se u tiliza tam bién para gestionar una am plia variedad de excep ciones, com o la división por cero, el acceso a direcciones de m em o­ ria protegidas o no existentes, o el intento de ejecutar una instrucción privilegiada en m odo usua­ rio. Los sucesos que generan interrupciones tienen una propiedad en com ún: son sucesos que inducen a la CPU a ejecutar una rutina urgente y autocontenida. Los sistem as operativos tienen otros usos adecuados para un m ecanism o hardw are y softw are eficiente que guarde una pequeña cantidad de inform ación de estado del procesador y luego invo­ que una rutina privilegiada dentro del kernel. Por ejem plo, m uchos sistem as operativos utilizan el

Figura 13.4 Tabla de vectores de sucesos en el procesador Intel

Pentium.

456

Capítulo 13 Sistemas de E/S

m ecanism o de interrupciones para la paginación de la m em oria virtual. Un fallo de página es una excepción que genera una interrupción. La interrupción suspende el proceso actual y salta a la rutina de procesam iento de fallo de página dentro del kernel. Esta rutina de tratam iento guarda el estado del proceso, m ueve el proceso a la cola de espera, realiza la gestión de la caché de páginas, planifica una operación de E /S para extraer la página, planifica otro proceso para reanudar la eje­ cución y luego vuelve de la interrupción. Otro ejem plo es el de la im plem entación de las llam adas al sistem a. Usualm ente, los progra­ m as utilizan llam adas a biblioteca para realizar llam adas al sistem a. Estas rutinas de biblioteca com prueban los argum entos proporcionados por la aplicación, construyen una estructura de datos para entregar esos argum entos al kernel y luego ejecutan una instrucción especial denomi­ nada in terru p ción softw are. Esta instrucción tiene un operando que identifica el servicio del ker­ nel deseado. C uando un proceso ejecuta la interrupción softw are, el hardware de interrupción guarda el estado del código de usuario, conm uta a m odo supervisor y realiza el despacho a la ruti­ na del kernel que im plem enta el servicio solicitado. La interrupción softw are tiene una prioridad de interrupción relativam ente baja, com parada con la que se asigna a las interrupciones de los dis­ positivos: ejecutar una llam ada al sistem a por cuenta de una aplicación es m enos urgente que dar servicio a una controladora de dispositivo antes de que su cola FIFO se desborde, provocando la pérdida de datos. Las interrupciones tam bién pueden usarse para gestionar el flujo de control dentro del kernel. Por ejem plo, considere el procesam iento requerido para com pletar una lectura de disco. Uno de los pasos es copiar los datos desde el espacio del kernel al búfer de usuario; esta operación de copia lleva m ucho tiem po pero no es urgente, así que no debe bloquear el tratam iento de otras interrup­ ciones de alta prioridad. Otro paso consiste en iniciar la siguiente E /S pendiente para esa unidad de disco. Este paso tiene una m ayor prioridad: si querem os utilizar los discos eficientem ente, necesitam os com enzar la siguiente E /S en cuanto se com plete la anterior. En consecuencia, hay una pareja de rutinas de tratam iento de interrupción que im plem entan el código del kernel necesa­ rio para com pletar una lectura de disco. La rutina de tratam iento de alta prioridad registra el esta­ do de E /S , borra la interrupción del dispositivo, com ienza la siguiente E /S pendiente y genera una interrupción de baja prioridad para com pletar la tarea. Posteriorm ente, cuando la CPU no esté ocu­ pada con otro trabajo de alta prioridad, se despachará la interrupción de prioridad m ás baja. La rutina de tratam iento correspondiente com pletará la E /S de nivel de usuario copiando los datos desde los búferes del kernel al espacio de la aplicación y luego invocando al planificador para colo­ car la aplicación en la cola de procesos preparados. Las arquitecturas de kernel con estructura de hebras están bien adaptadas para im plementar m últiples prioridades de interrupción y para im poner la precedencia del tratamiento de interrup­ ciones sobre el procesam iento no urgente correspondiente a las rutinas del kernel y de las aplica­ ciones. Vam os a ilustrar este aspecto m ediante el kernel de Solaris. En Solaris, las rutinas de tratam iento de interrupciones se ejecutan com o hebras del kernel, reservándose un rango de prio­ ridades altas para estas hebras. Estas prioridades proporcionan a las rutinas de tratam iento de interrupciones precedencia frente al código de aplicación y frente a las tareas adm inistrativas del kernel e im plem entan las relaciones de prioridad entre las propias rutinas de tratam iento de inte­ rrupciones. El m ecanism o de prioridades hace que el planificador de hebras de Solaris desaloje a las rutinas de tratam iento de interrupciones de baja prioridad en favor de las de prioridad más alta, y la im plem entación del m ecanism o de hebras perm ite al hardw are m ultíprocesador ejecutar concurrentem ente varias rutinas de tratam iento de interrupciones. La arquitectura de interrupcio­ nes de UNIX y de W indow s XP se describe en el A péndice A y en el Capítulo 22, respectivamente. En resum en, las interrupciones se utilizan extensivam ente en los sistem as operativos m oder­ nos para gestionar sucesos asincronos y para saltar a rutinas en m odo supervisor dentro del ker­ nel. Para que las tareas m ás urgentes se lleven a cabo prim ero, las com putadoras m odernas utilizan un sistem a de prioridades de interrupciones. Las controladoras de dispositivo, los fallos hardw are y las llam adas al sistema generan interrupciones para provocar la ejecución de rutinas del kernel. Dado que las interrupciones se utilizan de form a tan constante para el procesam iento m ás crítico en térm inos de tiempo, se necesita que el tratam iento de las interrupciones sea eficien­ te para obtener un buen rendim iento del sistema.

13.2 Hardware de E/S

457

13.2.3 Acceso directo a m em oria Para un dispositivo que realice transferencias de gran tam año, com o por ejem plo una unidad de disco, parece bastante poco apropiado utilizar un caro procesador de propósito general para com ­ probar dicho estado y para escribir datos en un registro de una controladora de byte en byte, lo cual es un proceso que se denom ina F/S p r o g r a m a d a (PIO, program m ed I/O ). La m ayoría de las com putadoras evitan sobrecargar a la CPU principal con las tareas PIO, descargando parte de este trabajo en un procesador de propósito especial denom inado controladora de a c c e s o d ire c to a m e m o r ia (DMA, direct-rnemory-access). Para iniciar una transferencia de DMA, el host describe un bloque de com ando DMA en la m em oria. Este bloque contiene un puntero al origen de una trans­ ferencia, u n puntero al destino de la transferencia y un contador del núm ero de bytes que hay que transferir. La CPU escribe la dirección de este bloque de com andos en la controladora DMA y luego continúa realizando otras tareas. La controladora de DMA se encarga entonces de operar el bus de m em oria directam ente, colocando direcciones en el bus para realizar las transferencias sin ayuda de la CPU principal. En las com putadoras de tipo PC, uno de los com ponentes estándar es una con­ troladora de DMA sim ple, y las tarjetas de E /S con c o n tr o l m a e s tr o d e l b u s para PC suelen conte­ ner su propio hardw are de DMA de alta velocidad. El p ro ce d im ie n to d e n e g o cia ció n en tre la co n tr o la d o ra d e DMA y la co n tro la d o ra d e d isp o sitiv o se realiza m e d ia n te u n p a r d e h ilos d e n o m in a d o s D M A - r e q u e s t y D M A -a c k n o w le d g e . L a c o n ­ tro la d o ra d e d isp o sitiv o c o lo c a u n a señ al en el hilo D M A - r e q u e s t c a d a v e z q u e h a y d isp on ib le p a ra tra n sfe re n cia u n a p a la b ra d e d a to s. E s ta señ al h a c e q u e la c o n tr o la d o ra d e DMA to m e el co n ­ trol d el b u s d e m e m o ria , co lo q u e la d ire cció n d e se a d a en lo s h ilo s d e d ire cció n d e m e m o ria y co lo ­ q u e u n a señ al en el hijo D M A -a c k n o w le d g e . C u a n d o la c o n tr o la d o ra d e d isp o sitiv o recib e la señ al D M A -a c k n o w le d g e , tran sfiere la p a la b ra d e d a to s a m e m o ria y b o rra la señ al D M A - r e q u e s t . Una vez finalizada la transferencia com pleta, la controladora de DMA interrum pe a la CPU. Este

proceso se ilustra en la Figura 13.5. Cuando la controladora de DMA tom a el control del bus de m em oria, se im pide m om entáneam ente a la CPU acceder a la m em oria principal, aunque podrá seguir accediendo a los elem entos de datos alm acenados en sus cachés principal y secundaria. 1. Se indica al controlador de dispositivo que transfiera datos del disco al búfer situado f en la dirección X. j 2. 5. La controladora de DMA transfiere los bytes al búfer X, incrementando la dirección de memoria y decrementando C hasta que C = 0.

caché a?

1

controladora de DMA/bus/ interrupciones

CPU

J-1l

6. Cuando C = 0, DMA interrumpe la CPU para señalizar la terminación de la transferencia.

El controlador de I dispositivo le dice a la L controladora de disco que transfiera C bytes ' desde el disco al búfer situado en la dirección X.

^bua.ECk controladora de diiscoslD ~

3. La controladora de disco inicia una transferencia de DMA. 4. La controladora de disco envía cada byte a la controladora de DMA.

Figura 13.5 Pasos de una transferencia de DMA.

™™'teXI Í i f

458

Capítulo 13 Sistemas de E/S

A u n q u e este p ro c e s o d e r o b o d e cic lo s p u e d e ra le n tiz a r los c á lc u lo s re a liz a d o s p o r la CPU, d escar-j g a r el trab ajo d e tra n sfe re n c ia d e d a to ; e n u n a c o n tr o la d o ra d e DMA su ele m e jo ra r el ren d im ien -l to g lo b al d el siste m a . A lg u n a s a rq u ite c tu ra s d e c o m p u ta d o ra u tiliz a n d ire ccio n e s d e m em orial física p a ra las o p e ra c io n e s d e DMA, m ie n tra s q u e o tra s re a liz a n u n a c c e s o d ire cto a m e m o ria v i r ­ tu a l (DVMA, d ir e c t v irtu al m e m o r y access), u tiliz a n d o d ire cc io n e s v irtu a le s q u e se rá n tra d u cid a s a d ire cc io n e s físicas. El m e c a n is m o d e DVMA p u e d e re a liz a r u n a tra n sfe re n cia e n tre d o s dispositi­ v o s m a p e a d o s e n m e m o ria sin la in te rv e n ció n d e la CPU y sin u s a r la m e m o ria p rin cip a l. . «

En un kernel de modo protegido, el sistem a operativo im pide generalm ente que los procesos 1 ejecuten directam ente com andos de los dispositivos. Esto protege a los datos frente a las violacio­ nes de los m ecanism os de control de acceso y tam bién protege al sistem a frente al uso erróneo de las controladoras de dispositivo que pudiera provocar un fallo catastrófico del sistema. En lugar ’ de usar esos m ecanism os, el sistem a operativo exporta una serie de funciones que un proceso con los suficientes privilegios puede utilizar para acceder a las operaciones de bajo nivel sobre el hard­ w are subyacente. En un kernel sin protección de m emoria, los procesos pueden acceder directa­ m ente a las controladoras de dispositivo. Este acceso directo puede usarse para obtener un mayor rendim iento, ya que puede evitar determ inadas com unicaciones dentro del kernel, determinados cam bios de contexto y el paso por diversas capas del softw are del kem el. Desafortunadamente, este m ecanism o afecta a la seguridad v a la estabilidad del sistem a, por lo que la tendencia en los sistem as operativos de propósito general es proteger a la m em oria y a los dispositivos de modo que el sistem a pueda tratar de defenderse frente a las aplicaciones erróneas o m aliciosas.

13.2.4 Resumen del hardware de E/S A unque los aspectos hardw are de las operaciones de E/S son com plejos cuando se consideran con el nivel de detalle requerido durante el diseño del hardw are electrónico, los conceptos que acaba­ m os de describir son suficientes para com prender m uchas de las funciones de E/S de los sistemas operativos. Repasem os los conceptos principales: • U n bus. •

U na con trolad o ra.

•

U n p u erto de E/S y su s registros.

•

El p ro ced im ien to de n eg ociación en tre el host v una co n tro lad o ra de dispositivo.

• La ejecu ció n de este pro ced im ien to m ed ian te un b u cle de so n d eo o m ed ian te interrup­ ciones. •

La d escarg a c e este trabajo en una co n tro lad o ra de DMA para las tran sferen cias de gran en v erg ad u ra.

A n te rio rm e n te en esta secció n , hem os p ro p o rcio n ad o un ejem p lo básico del p ro ced im ien to de n eg o cia ció n q u e tiene lu g ar en tre u na co n tro lad o ra de d isp o sitiv o y el host. En realid ad , la am plia v aried ad de d isp o sitiv o s d isp o n ib les co n stitu y e un p ro blem a para los en cargad os de im plem en­ tar un sistem a op erativ o. C ad a tipo de d isp o sitiv o tiene su p ro p io con ju n to de cap acid ad es, sus p ro p ias d efin icio n es de b its de control v su s p rop ios p ro to co lo s para in teractu ar con el host, y tod os ellos son d iferen tes. ¿C ó m o podem os d iseñ ar el sistem a o p erativ o para poder co n ectar nue­ vos d isp o sitiv o s a la co m p u ta d o ra sin reescrib ir el propio sistem a op erativ o? Y, cu an d o los dispo­ sitiv o s v arían tan a m p liam en te, ¿cóm o p u ed e p ro p o rcio n ar el sistem a op erativ o u na interfaz có m o d a y u n ifo rm e de E/S a todas las ap licacio n es? V am os a tratar a co n tin u ació n de responder a estas p reg u n tas.

13.3 Interfaz de E/S de las aplicaciones E n esta secció n , vam os a h a b la r de las :écn icas de estru ctu ració n y de las in terfaces del sistem a o p era tiv o qu e permuten tratar de uro. form a están d ar y u n iform e a los d isp o sitiv o s de E/S. E x p licarem o s, p o r e;em plo, có m o puede una ap licación ab rir un arch iv o en disco sin sab er de qué

13.3 Interfaz de E/S de las aplicaciones

controladora controladora controladora de de de dispositivo dispositivo dispositivo de teclado de ratón SCSI !

i

SCSI

controladora controladora controladorai de de j de dispositivo dispositivo dispositivo ! de bus PCI de disquete ATAPI i

.......................................

i

dispositivos i ■teclado

•••

ratón

•••

459

bus PCI

i

i

f

unidades dispositivos! ATAPI ¡ de (discos, j disquete cintas) | i

Figura 13.6 Estructura de E/S de un kernel. tipo de disco se trata, v verem os tam bién cóm o pueden añadirse nuevos discos v otros dispositi­ vos a una com putadora sin perturbar el sistema operativo. Al igual que otros problem as com plejos de ingeniería del softw are, la técnica utilizada aquí se basa en los conceptos de abstracción, encapsulación y descom posición del softw are en niveles. Específicam ente, podemos abstraer las diferencias de detalle existentes entre los dispositivos de E/S identificando unos cuantos tipos generales de dispositivo. Para acceder a cada tipo general se utiliza un conjunto estandarizado de funciones, es decir, una interfaz. Las diferencias se encapsulan en m ódulos del kernel denom inados controladores del dispositivo que están personalizados internam ente para cada dispositivo pero exportan una de las interfaces estándar. La Figura 13.6 ilustra cóm o se estructuran en niveles de softw are las partes del kem el relacionadas con la E/S. El propósito de la capa de controladores de dispositivo es ocultar a ojos del subsistema de E/S del kernel las diferencias existentes entre las controladoras de dispositivo, de forma similar a como las llam adas al sistema de E/S encapsulan el com portam iento de los dispositivos en unas cuantas clases genéricas que ocultan a ojos de las aplicaciones las diferencias hardware. Hacer el subsiste­ ma de E/S independiente del hardw are sim plifica el trabajo del desarrollador de sistemas opera­ tivos y tam bién beneficia a los fabricantes de hardw are. Éstos pueden diseñar los nuevos dispositivos para que sean com patibles con una interfaz de controladora host existente (como por ejem plo SCS1-2), o pueden escribir controladores de dispositivo para im plem entar la interfaz del nuevo hardw are con una serie de sistem as operativos populares. De este modo, podemos conec­ tar nuevos periféricos a una com putadora sin esperar a que el fabricante del sistema operativo desarrolle el correspondiente código de soporte. D esafortunadam ente para los fabricantes de dispositivos hardware, cada tipo de sistema ope­ rativo tiene sus propios estándares en cuanto a la interfaz del controlador de dispositivo. Un dis­ positivo determ inado puede com ercializarse junto con m últiples controladores de dispositivo, com o por ejem plo controladores para MS-DOS, W indow s 95/98, W indow s N T / 2000 v Solaris. Los dispositivos pueden variar desde muchos puntos de vista, com o se ilustra en la Figura 13.7. • F lu jo de caracteres o bloque. Un dispositivo de flujo de caracteres transfiere los bvtes uno a uno, mientras que un dispositivo de bloque transfiere un bloque de bvtes como una sola unidad.

Capítulo 13 Sistemas de I^S

F ig u ra 1 3 .7

C aracterísticas de los dispositivos de E/S.

• Acceso secu en cial o aleatorio. U n dispositivo secuencial transfiere los datos en un orden fijo determ inado por el dispositivo, m ientras que el usuario de un dispositivo de acceso aleatorio puede instruir al dispositivo para que se posicione en cualquiera de las ubicacio­ nes disponibles de alm acenam iento de datos. • Sín cron o o asincrono. Un dispositivo síncrono realiza transferencias de datos con tiempos de respuesta predecibles. Un dispositivo asincrono exhibe unos tiempos de respuesta irre­ gulares o no predecibles. • C om p artible o dedicado. Un dispositivo com partible puede ser usado de form a concu­ rrente por varios procesos o hebras; un dispositivo dedicado no puede ser com partido de esta form a. • V elocid ad de operación. Las velocidades de los dispositivos van desde unos pocos bytes por segundo a unos cuantos gigabytes por segundo. • Lectura-escritura, sólo lectura o sólo escritura. A lgunos dispositivos realizan tanto entra­ da com o salida, pero otros sólo soportan una única dirección de transferencia de los datos. En lo que respecta al acceso por parte de las aplicaciones, m uchas de estas diferencias quedan ocultas gracias al sistem a operativo, y los dispositivos se agrupan en unos cuantos tipos conven­ cionales. Los estilos resultantes de acceso al dispositivo han dem ostrado ser en la práctica muy útiles y de aplicación general. A unque las llam adas exactas al sistem a pueden diferir de unos sis­ temas operativos a otros, las categorías de dispositivo son bastante estándar. Los principales sis­ temas de acceso incluyen la E/S de bloque, la E/S de flujo de caracteres, el acceso a archivos mapeados en m em oria y los sockets de red. Los sistem as operativos también proporcionan llama­ das especiales al sistem a para acceder a unos cuantos dispositivos adicionales, com o por ejemplo un reloj o un contador. A lgunos sistem as operativos proporcionan un conjunto de llam adas al sis­ tema para dispositivos de visualización gráfica, de vídeo y de audio. La m ayoría de los sistem as operativos tam bién tienen un escape (o puerta trasera) que pasa de manera transparente una serie de com andos arbitrarios desde una aplicación a un controlador de dispositivo. En UNIX. esta llam ada al sistem a es i o c c l {) (que quiere "control de E/S"). La llam a­ da ai sistem a í o c t i • perm ite a las aplicaciones acceder a cualquier funcionalidad que pueda im plem entarse por algún controlador de dispositivo, sin necesidad de inventar una nueva llam a­ da ai sistema La llamada al sistem a i o c t l () tiene tres argum entos. El primero es un descriptor

13.3 Interfaz de E/S de las aplicaciones

461

de archivo que conecta la aplicación con el controlador haciendo referencia a un dispositivo hard­ ware gestionado por ese controlador. El segundo es un valor entero que selecciona uno de los com andos im plem entados en el controlador. El tercero es un puntero a una estructura de datos arbitraria en m em oria que perm ite que la aplicación y el controlador se intercam bien cualquier dato o cualquier inform ación de control necesaria.

13.3.1 Dispositivos de bloques y de caracteres La interfaz de dispositivo de b lo q u es captura todos los aspectos necesarios para acceder a unida­ des de disco y a otros dispositivos orientados a bloques. El dispositivo debe com prender com an­ dos tales com o r e a d O o w r i t e ( ) ; s i se trata de un dispositivo de acceso aleatorio, también se espera que disponga de un com ando s e e k () para especificar qué bloque hay que transferir a continuación. Las aplicaciones acceden norm alm ente a este tipo de dispositivos m ediante una interfaz de sistem a de archivos. Podem os ver que r e a d O , w r i t e () y s e e k () capturan el com portam iento esencial de los dispositivos de alm acenam iento de bloques, de modo que las aplicaciones quedan aisladas de las diferencias de bajo nivel que puedan existir entre los disposi­ tivos. El propio sistem a operativo, al igual que algunas aplicaciones com o los sistem as de gestión de bases de datos, pueden preferir acceder a un dispositivo de bloques como si fuera una simple m atriz lineal de bloques. Este m odo de acceso se denom ina en ocasiones E/S sin form ato o en bruto. Si la aplicación realiza su propio alm acenam iento en búfer, la utilización de un sistema de archivos provocaría un alm acenam iento en búfer adicional e innecesario. De la m ism a form a, sí la aplicación proporciona su propio m ecanism o de bloqueo de regiones o de bloques de archivos, los servicios de bloqueo del sistem a operativo serían redundantes com o m ínim o y contradictorios en el caso peor. Para evitar estos conflictos, los m ecanism os de acceso a dispositivos sin formato pasan el control del dispositivo directam ente a la aplicación, dejando que el sistem a operativo no interfiera en la tarea. Desafortunadam ente, con este m ecanism o no se pueden realizar servicios del sistema operativo para ese dispositivo. Una solución de com prom iso que cada vez se está adop­ tando de form a más com ún consiste en que el sistem a operativo incluya un m odo de operación con los archivos en el que se desactiven el alm acenam iento en búfer y los m ecanism os de bloqueo. En el m undo UNIX, este m odo se denom ina í/S directa. Los m ecanism os de acceso a archivos m apeados en memoria pueden im plem entarse por enci­ ma de los controladores de dispositivos de bloques. En lugar de ofrecer operaciones de lectura y escritura, una interfaz de m apeo en memoria proporciona acceso al alm acenam iento en disco m ediante una matriz de bytes de la memoria principal. La llamada al sistema que m apea un archi­ vo en la memoria devuelve la dirección de m em oria virtual que contiene úna copia del archivo. Las propias transferencias de datos se analizan únicam ente cuando son necesarias para satisfacer el acceso a la imagen en m em oria. Puesto que las transferencias se gestionan m ediante el mismo m ecanism o que se em plea para el acceso a m em oria virtual con paginación bajo dem anda, la E/S mapeada en memoria resulta m uy eficiente. El m apeo en m em oria también es cóm odo para los program adores, ya que el acceso a un archivo m apeado en memoria es tan sim ple com o leer y escribir en la memoria. Los sistem as operativos que ofrecen m em oria virtual utilizan com únm en­ te la interfaz de mapeo para los servicios del kem el. Por ejemplo, para ejecutar el programa, el sis­ tema operativo mapea el archivo ejecutable en la m em oria y luego transfiere el control a la dirección de entrada de ese código ejecutable. La interfaz de mapeo también se utiliza com únm en­ te para que el kernel acceda al espacio de intercam bio en el disco. El teclado es un ejem plo de dispositivo al que se accede m ediante una interfaz de flu jo de caracteres. Las llamadas básicas al sistema en esta interfaz permiten a las aplicaciones leer o escri­ bir un carácter, m ediante las llam adas g e t ;) y p u t {). Por encim a de esta interfaz, pueden cons­ truirse bibliotecas que perm itan el acceso de línea en línea, con servicios de alm acenam iento en búfer y edición (por ejem plo, cuando un usuario escribe un carácter de retroceso, se elimina del flujo de entrada el carácter anterior). Este estilo de acceso resulta cómodo para dispositivos de entrada tales com o ios teclados, los ratones v los m ódem s que producen datos de entrada "espon' ■ > < . • ohh rm ru eden necesariam ente ser rred ichos por la aplicación. Este esti­

462

Capítulo 13 Sistemas de I/S

lo de acceso tam bién resulta adecuado para dispositivos de salida tales com o las im presoras y las tarjetas de sonido, que se adaptan naturalm ente al concepto de u n flujo lineal de bytes.

13.3.2 Dispositivos de red Puesto que las características de velocidad y de direccionam iento de la E/S de red difieren signi­ ficativam ente de las de la E/S de disco, la m ayoría de los sistem as operativos proporcionan una interfaz de E/S de red que es diferente de la interfaz r e a d () - w r i t e () - s e e k () utilizada para los discos. Una interfaz disponible en m uchos sistem as operativos, incluyendo UNIX y W indows NT, es la interfaz de s o c k e t s de red. La palabra socket en inglés hace referencia a las tomas de electricidad existentes en las paredes de una vivienda: en esas tom as podem os conectar cualquier electrodom éstico. Por analogía, las llam adas al sistem a de la interfaz sockets, perm iten a la aplicación crear un socket, conectar el Soc­ ket local a una dirección rem ota (lo que conecta esta aplicación al socket creado por otra aplicación), quedar a la espera de que cualquier aplicación rem ota se conecte al socket local y enviar y recibir paquetes a través de la conexión. Para soportar la im plem entación de servidores, la interfaz de soc­ kets tam bién proporciona una función denom inada s e l e c t () que gestiona un conjunto de soc­ kets. Una llam ada a s e l e c t () devuelve inform ación acerca de qué sockets tienen un paquete a la espera de ser recibido y qué sockets disponen del espacio para aceptar un paquete que haya que enviar. La utilización de s e l e c t () elim ina los m ecanism os de sondeo y de espera activa que serí­ an necesarios para la E / s A e red en caso de que esta llamada no existiera. Estas funciones encapsulan el com portam iento esencial de las redes, facilitan d o enorm em ente la creación de aplicaciones distribuidas que pueden utilizar cualquier hardw are de red y cualquier pila de pro­ tocolos subyacentes. Tam bién se vienen im plem entando m uchas otras técnicas de com unicación interprocesos y de com unicación por red. Por ejem plo, W indow s NT proporciona una interfaz para la tapeta de inter­ faz de red y una segunda interfaz para los protocolos de red (Sección C.6). En UNIX, que tiene un largo historial de cam po de pruebas para las tecnologías de red, podem os encontrar canaliza­ ciones sem i-dúplex, colas FIFO full-dúplex, conexiones STREAMS full-dúplex, colas de m ensajes y sockets. En el A péndice A (Sección A. 9) se proporciona inform ación sobre los m ecanism os de com unicación por red en UNIX.

13.3.3 Relojes y temporizadores La m ayoría de las com putadoras disponen de relojes v tem porizadores hardw are que proporcio­ nan tres funciones básicas: • Proporcionar la hora actual. • Proporcionar el tiem po transcurrido. • Configurar un tem porizador para que provoque la ejecución de la operación X en el ins­ tante T. El sistem a operativo, así com o las aplicaciones que tengan restricciones tem porales críticas uti­ lizan intensivam ente estas funciones. D esafortunadam ente, las llam adas al sistem a que implem entan estas funciones no están estandarizadas entre unos sistem as operativos y otros. El hardw are necesario para m edir el tiem po transcurrido y para provocar la ejecución de ope­ raciones se denom ina tem porizador de intervalo program able. Se puede configurar el tempori­ zador para esperar una cierta cantidad de tiem po y luego generar una interrupción, y se lo puede configurar para hacer esto una sola vez o para repetir el proceso de m odo que se generen interrup­ ciones periódicas. El planificador utiliza este m ecanism o para generar una interrupción que pro­ vocará el desalojo de un proceso al final de su correspondiente franja tem poral de ejecución. El subsistem a de E/S de disco utiliza este m ecanism o para invocar la orden de volcar en el disco periódicam ente los búferes caché sucios y el subsistema de red lo utiliza para cancelar aquellas operaciones que estén progresando de forma demasiado lenta debido a fallos de red o a la con-

13.3 Interfaz de F/S de las aplicaciones

463

gestión. El sistem a operativo puede tam bién proporcionar una interfaz para que los procesos de usuario utilicen tem porizadores. El sistem a operativo puede soportar m ás solicitudes de temporización que el núm ero de canales hardw are de tem porización disponibles, sim ulando relojes vir­ tuales. Para hacer esto, el kem el (o el controlador del dispositivo tem porizador) m antiene una lista de las interrupciones deseadas por sus propias rutinas y por las solicitudes de usuario, ordenadas de acuerdo con el instante en que van a producirse, de la m ás próxim a a la más lejana. El kernel considera el tem porizador para dar servicio a la interrupción más próxim a. Cuando el tem poriza­ dor interrum pe, el kem el señaliza dicho suceso al proceso solicitante y recarga el tem porizador con la siguiente interrupción de la secuencia. En m uchas com putadoras, la frecuencia de interrupciones generada por el reloj hardw are está com prendida entre 18 y 60 tics por segundo. Esta resolución no es m uy buena, ya que una com ­ putadora m oderna puede ejecutar centenares de m illones de instrucciones por segundo. La preci­ sión de los disparadores está lim itada por esta baja resolución del tem porizador, adem ás de por el procesam iento adicional que se requiere para la gestión de los relojes virtuales. Adem ás, si se utilizan los tics del tem porizador para m antener el reloj del sistem a, dicho reloj puede llegar a experim entar una deriva. En la m ayoría de las com putadoras, el reloj hardw are se construye a partir de un contador de alta frecuencia. En algunas com putadoras, puede leerse el valor de este contador en un registro del dispositivo, en cuyo caso el contador puede considerarse un reloj de alta resolución. A unque este reloj no genera interrupciones, sí que perm ite realizar m ediciones precisas de intervalos de tiempo.

13.3.4 E/S bloqueante y no bloqueante Otro aspecto de la interfaz de llam adas al sistema es el relativo a la elección entre E/S bloqueante y no bloqueante. Cuando una aplicación ejecuta una llam ada al sistem a blo q u ean te, se suspende la ejecución de la aplicación. En ese instante, la aplicación se pasa de la cola de ejecución del sis­ tema operativo a una cola de espera. Después de que se com plete la llam ada al sistem a, vuelve a colocarse la aplicación en la cola de ejecución, donde pasará a ser elegible para reanudar su ejecu­ ción, en cuyo m om ento se le entregarán los valores devueltos por la llam ada al sistema. Las accio­ nes físicas realizadas por los dispositivos de E/S son generalm ente asincronas, consum iendo una cantidad variable o im predecible de tiempo. De todos m odos, la m ayoría de los sistem as operati­ vos utilizan llam adas al sistem a bloqueantes para la interfaz de las aplicaciones, porque el código de aplicación bloqueante es m ás fácil de entender que el no bloqueante. Algunos procesos de nivel de usuario necesitan una E/S no blo q u ean te. Un ejem plo sería una interfaz de usuario que recibe la entrada de teclado y de ratón m ientras que está procesando y m ostrando datos en la pantalla. Otro ejemplo sería una aplicación de vídeo que leyera imágenes de un archivo en disco m ientras que sim ultáneam ente las descom prim e y m uestra la salida en la pantalla. Una form a en que el desarrollador dé una aplicación puede solapar la ejecución con las opera­ ciones de E/S consiste en escribir una aplicación m ultihebra. Algunas hebras pueden realizar lla­ madas al sistem a bloqueantes m ientras que otras continúan ejecutándose. Los desarrolladores de Solaris utilizaron esta técnica para im plementar una biblioteca de nivel de usuario para la E/S asincrona, liberando a los desarrolladores de aplicaciones de esa tarea. Algunos sistem as operati­ vos proporcionan llam adas al sistem a de E/S no bloqueante. Una llam ada no bloqueante no detie­ ne la ejecución de la aplicación durante un período de tiempo prolongado. En lugar de ello, la llam ada vuelve rápidam ente, con un valor de retorno que indica cuántos bytes se han transferido. Una alternativa a las llam adas al sistema no bloqueantes consiste en utilizar llam adas al siste­ ma asincronas. Una llam ada al sistem a asincrona vuelve inm ediatam ente, sin esperar a que la operación de E/S se com plete. La aplicación continúa entonces ejecutando su código. La term ina­ ción de la operación de E/S se com unica a la aplicación en algún instante futuro, configurando alguna variable en el espacio de direcciones de la aplicación o generando una señal o interrupción softw are o ejecutando una rutina de retroiiam ada que se ejecuta fuera del flujo lineal de control de la aplicación. La diferencia entre las llamadas al sistem a no bloqueantes v asincronas es que una operación r e a d (} no bloqueante vuelve inm ediatam ente con los datos que haya disponibles

u a p iru io J.O jib te n id s u e c /o

Figura 13.8 Dos métodos de E/S: (a) síncrono y (b) asincrono. (el núm ero com pleto de bytes solicitados, un núm ero m enor o ningún byte en absoluto), mientras que una llamada r e a d () asincrona solicita una transferencia que se realizará de m odo completo pero que se com pletará en algún instante futuro. Estos dos m étodos de E/S se ilustran en la Figura 13.8. Un buen ejem plo de com portam iento no bloqueante es la llam ada al sistema s e l e c r () para los sockets de red. Esta llam ada al sistem a acepta un argum ento que especifica un tiempo de espe­ ra m áxim o: si le asignam os el valor 0, la aplicación puede efectuar un sondeo de la actividad de red sin bloquearse. Pero utilizar s e l e c t () introduce una carga de procesam iento adicional, por­ que la llam ada s e l e c t () sólo com prueba si la E/S es posible. Para realizar una transferencia de datos, hay que ejecutar después de s e l e c t () algún tipo de com ando r e a d {) o w r i r e { ).U na variación de esta técnica, que podem os encontrar en M ach, es la llamada de lectura m últiple blo­ queante. Esta llam ada especifica las lecturas deseadas para varios dispositivos en una única lla­ mada al sistem a v vuelve en cuanto se com pleta una de las lecturas.

13.4 Subsistema de E/S del kernel Un kernel proporciona m uchos servicios relacionados con la E/S. Varios de los servicios fplanifi­ cación, alm acenam iento en búfer, alm acenam iento en caché, gestión de colas, reserva de disposi­ tivos y tratam iento de errores) son proporcionados por el subsistem a de E/S del kernel y se construyen sobre la infraestructura form ada por el hardw are y los controladores de dispositivo. El subsistem a de E/s tam bién es responsable de protegerse a sí m ismo de los procesos erróneos y de los usuarios m aliciosos.

13.4.1 Planificación de E/S Planificar un conjunto de solicitudes de E/S significa determ inar un orden adecuado en e! que eje­ cutarlas. El orden en el que las aplicaciones realizan las llam adas al sistema no suele ser la mejor elección. La planificación puede m ejorar el rendim iento global del sistema, perm ite com partir el acceso a los dispositivos equitativam ente entre los distintos procesos y puede reducir el tiempo de espera m edio requerido para que la E/S se com plete. He aquí un ejem plo simple para ilustrar estos aspectos: suponga que el brazo de un disco está situado cerca del principio del m ism o v que tres aplicaciones distintas ejecutan llam adas de lectura bloqueantes dirigidas a dicho disco. La aplica­ ción 1 solicita un bloque situado cerca del final del disco, la aplicación 2 solicita otro situado cerca del principio y la aplicación 3 solicita un bloque en parte interm edia del disco. El sistema opera­ tivo puede reducir la distancia recorrida por el brazo del disco sirviendo a las aplicaciones en el orden 2, 3, 1. Reordenar el servicio de las distintas solicitudes de esta manera es la esencia de los m ecanism os de planificación de E/S.

13.4 Subsistema de í/S del kernel

dispositivo: impresora láser estado: ocupada

dispositivo: unidad de disco 2 estado: ocupada

465

solicitud para impresora láser dirección: 38546 longitud: 1372

►solicitud para unidad de disco 2 archivo: xxx operación: lectura dirección: 43046 longitud: 20000

solicitud para unidad de disco 2 archivo: yyy operación: escritura dirección: 03458 longitud: 500

Figura 13.9 Tabla de estado de los dispositivos. Los desarrolladores de sistem as operativos im plem entan los m ecanism os de planificación m anteniendo una cola de espera de solicitudes para cada dispositivo. Cuando una aplicación eje­ cuta una llam ada al sistem a de E /S bloqueante, la solicitud se coloca en la cola correspondiente a dicho dispositivo. El planificador de E /S reordena la cola para m ejorar la eficiencia global del sis­ tema y el tiem po medio de respuesta experim entado por las aplicaciones. El sistem a operativo puede tratar también de ser equitativo, de m odo que ninguna aplicación reciba un servicio espe­ cialm ente pobre, o puede proporcionar un servicio prioritario a las solicitudes más sensibles al retardo. Por ejemplo, las solicitudes procedentes del subsistem a de memoria virtual pueden tener prioridad sobre las solicitudes realizadas por las aplicaciones. En la Sección 12.4 se detallan diver­ sos algoritm os de planificación para la E /S de disco. Cuando un kernel soporta m ecanism os de E /S asincrona, debe ser capaz de controlar m últiples solicitudes de E /S al m ism o tiempo. Con este fin, el sistem a operativo puede asociar la cola de espera con una tabla de e sta d o del d isp o sitiv o . El kernel se encarga de gestionar esta tabla, que contiene una entrada por cada dispositivo de E/S, com o se m uestra en la Figura 13.9. Cada entra­ da en la tabla indica el tipo, la dirección y el estado (no funcional, inactivo u ocupado) del dispo­ sitivo. Si el''dispositivo está ocupado con una solicitud, se alm acenarán en la entrada de la tabla correspondiente a dicho dispositivo el tipo de la solicitud y otros parámetros. Una form a en que el subsistem a de E /S m ejora la eficiencia en la com putadora es planificando las operaciones de E/S. O tra form a es utilizando espacio de alm acenam iento en la m em oria prin­ cipal o en disco m ediante técnicas denom inadas alm acenam iento en búfer, alm acenam iento en caché v gestión de colas.

13.4.2 Alm acenam iento en búfer Un b ú fer és'un área de m em oria que alm acena datos m ientras se están transfiriendo entre dos dis­ positivos o entre un dispositivo y una aplicación. El alm acenam iento en búfer se realiza por tres razones. Una razón es realizar una adaptación de velocidades entre el productor v el consum idor de un flujo de datos. Suponga, por ejem plo, que se está recibiendo un archivo vía m ódem para su alm acenam iento en el disco duro. El m ódem es unas 1000 veces más lento que el disco duro, por lo que se crea un búfer en m em oria principal para acum ular los bvtes recibidos del m ódem . Una vez que ha llegado un búfer com pleto de datos, puede escribirse el búfer en disco en una sola ope­ ración. Puesto que la escritura en el disco no es instantánea y el m ódem sigue necesitando un lugar para alm acenar ¡os datus adicionares entrantes, se utilizan los búferes. Después de que el módem llene ei primer búfer, se solicita la escritura en disco v el m ódem com ienza entonces a — u.-.mr oue e ] primero se escribe en el disco. Para cuando el módem

Capítulo 13 Sistemas de E/S

bus gigaplane

bus SCSI fast ethernet disco duro ethernet impresora láser

0,01

0,1

10

100

'

Figura 13.10 Velocidades de transferencia de dispositivos en las máquinas Sun Enterprise 6000 (escala logarítmica). haya llenado el segundo búfer, la escritura en disco del prim ero deberá haberse com pletado, por lo que el m ódem podrá conm utar de nuevo al prim er búfer m ientras se escribe en el disco el con­ tenido del segundo. Esta técnica de doble bú fer desacopla al productor de datos del consumidor de los mismos, relajando así los requisitos de tem porización entre ellos. La necesidad de este des­ acoplam iento se ilustra en la Figura 13.10, donde se indican las enorm es diferencias en velocida­ des de los dispositivos para un hardware típico de una com putadora. Un segundo uso del alm acenam iento en búfer consiste en realizar la adaptación entre disposi­ tivos que tengan diferentes tamaños de transferencia de datos. Dichas disparidades son especial­ m ente com unes en la conexión por red de com putadoras, en la que se utilizan intensivam ente los búferes para la fragm entación y recom posición de m ensajes. En el lado em isor, se fragm entan los m ensajes de gran tam año en pequeños paquetes de red. Estos paquetes se envían a través de la red y el lado receptor los coloca en un búfer de recom posición, para form ar una im agen de los datos de origen. Un tercer uso del alm acenam iento de un búfer es el de soportar la sem ántica de copia en la E / S de las aplicaciones. Un ejem plo nos permitirá clarificar cuál es el significado del concepto de "sem ántica de copia”. Suponga que una aplicación dispone de un búfer de datos que desea escri­ bir en disco. La aplicación ejecutará la llamada al sistem a w r i t e {), proporcionando un puntero al búfer v un núm ero entero que especifique el núm ero de bytes que hay que escribir. Después de que vuelva la llam ada al sistem a, ¿qué sucede si la aplicación cam bia el contenido del búfer? Con la sem án tica de copia, se garantiza que la versión de los datos escrita en el disco será la versión existente en el m om ento en que la aplicación ejecute la llamada al sistema, independientem ente de los cam bios posteriores que la aplicación pueda realizar en el búfer. Una form a sim ple en la que el sistem a operativo puede garantizar la semántica de copia es que la llam ada al sistema w r i t e ( < copie los datos de la aplicación en un búfer del kernel antes de devolver el control a la aplicación. La escritura en disco se realiza a partir del búfer del kernel, de modo que los cambios subsiguientes realizados en el bufer de la aplicación no tendrán ningún efecto. La copia de datos

13.4 Subsistema de E/S del kernel

46;

entre búíeres del kernel y el espacio de datos de la aplicación resulta bastante com ún en los siste­ m as operativos, a pesar de la carga de procesam iento adicional que esta operación introduce, v A razón de que resulte bastante com ún es que se trate de una sem ántica m uy limpia. Puede obtener­ se el m ism o efecto de m anera m ás eficiente utilizando de form a inteligente los m ecanism os de m apeo en m em oria virtual y de protección de páginas m ediante funciones de copia durante A escritura.

13.4.3 Alm acenam iento en caché U na caché es una región de m em oria rápida que alberga copias de ciertos datos. El acceso a a copia alm acenada en caché es m ás eficiente que el acceso al original. Por ejem pio ’.as instruccio­ nes del proceso actualm ente en ejecución están alm acenadas en el disco, alm acenadas en la caché de la memoria física y alm acenadas tam bién en las cachés principal y secundaria de la CPU. La diferencia entre u n búfer y u na caché es que un búfer puede alm acenar la única copia existente de un elem ento de datos, m ientras que una caché, por definición, alm acena sim plem ente en un dis­ positivo de alm acenam iento m ás rápido una copia de un elem ento que reside en algún otro lugar. El alm acenam iento en caché y el alm acenam iento en búfer son funciones bien diferenciadas, aunque en ocasiones puede utilizarse una m ism a región de memoria para am bos propósitos. Por ejem plo, para preservar la sem ántica de copia y para permitir una eficiente planificación de la E/S de disco, el sistem a operativo utiliza búferes en memoria principal para alm acenar los datos dei disco. Estos búferes tam bién se em plean com o caché, para m ejorar la eficiencia de E/S para aque­ llos archivos que estén com partidos por varias aplicaciones o que estén siendo escritos y vueltos a leer de form a rápida. C uando el kem el recibe una solicitud de E/S de archivo, accede primero a la caché de búfer para ver si dicha región del archivo ya está disponible en la m em oria principal. En caso afirm ativo, podem os editar o diferir una E/S de disco física. A sim ism o, las escrituras en disco se acum ulan en la caché del búfer durante varios segundos, con el fin de com poner grandes transferencias de datos y perm itir así una planificación eficiente de las operaciones de escritura. Esta estrategia de retardar las escrituras para m ejorar ¡a eficiencia de E/S se analiza, en el contex­ to del acceso a archivos rem otos, en la Sección 17.3.

13.4.4 Gestión de colas y reserva de dispositivos Una cola de disp ositivo es un búfer que alm acena la salida dirigida a un dispositivo, com o por ejem pio una im presora, que no pueda aceptar flujos de datos entrelazados. Aunque una im preso­ ra sólo puede dar servicio a un cierto trabajo cada vez, es posible que varias aplicaciones quieran im prim ir sus datos d esalid a de m anera concurrente, sin que la salida de unas aplicaciones se m ez­ cle con la de otras. El sistem a operativo resuelve este problem a interceptando toda la salida diri­ gida a la im presora. La salida de cada aplicación se alm acena tem poralm ente en un archivo de disco separado. Cuando una aplicación term ina de imprimir, el sistem a de gestión de colas pone el correspondiente archivo tem poral en la cola de salida de la impresora. El sistema de gestión de colas va copiando los archivos de salida en la im presora de uno en uno. En algunos sistem as ope­ rativos, estas colas de im presión se gestionan m ediante un proceso dem onio del sistema. En otros, se gestiona m ediante una hebra interna al kernel. En cualquiera de los dos casos el sistem a opera­ tivo proporciona una interfaz de control que perm ite a los usuarios y a los adm inistradores del sistem a visualizar la cola de solicitudes de im presión, eliminar los trabajos no deseados antes de que lleguen a im prim irse, suspender la im presión mientras se está solventando algún error de im presora, etc. Algunos dispositivos, com o las unidades de cinta v las impresoras, no pueden m ultiplexar las solicitudes de E/S de m últiples aplicaciones concurrentes. La gestión de colas de im presión es una de las form as en que el sistem a operativo puede coordinar estas operaciones concurrentes de sali­ da. Otra form a de tratar con el acceso concurrente a ios dispositivos consiste en proporcionar faci­ lidades explícitas de coordinación. Algunos sistem as operativos (incluyendo VMS) proporcionan soporte para el acceso exclusivo a los dispositivos, permitiendo a los procesos asignar un disposi­ tivo inactivo y d e s a s e a r l o cuando ya no sea necesario. Otros sistem as operativos imponen un

468

Capítulo 13 Sistemas de E/S

lím ite de un sólo descriptor de archivo abierto para tales dispositivos. M uchos sistem as operati­ vos proporcionan funciones que perm iten a los procesos coordinar entre sí el acceso exclusivo. P0r ejem plo, W indow s NT proporciona llam adas al sistem a para realizar una espera hasta que un objeto dispositivo pase a estar disponible. Tam bién dispone de un parám etro de la llamada al sis­ tem a o p en () que declara los tipos de acceso que deben perm itirse a otras hebras concurrentes En estos sistem as, es responsabilidad de las aplicaciones evitar los interbloqueos.

13.4.5 Tratamiento de errores Un sistem a operativo que utilice m em oria protegida puede defenderse frente a m uchos tipos dt errores hardw are y de las aplicaciones, de m odo que cada pequeño error no provoque un fallo com pleto del sistem a. Los dispositivos y las transferencias de E /S pueden fallar de muchas for­ m as, debido a razones transitorias (como por ejem plo cuando una red se sobrecarga) o a razones “perm anentes” (com o por ejem plo si falla una controladora de disco). Los sistem as operativos pueden a m enudo com pensar de m anera efectiva los fallos transitorios. Por ejemplo, un fallo de una operación r e a d () de disco provoca que se reintente la operación r e a d () y un error en una operación s e n d () a través de la red provoca una operación de reenvío r e s e n d (), si el protoco­ lo así lo especifica. Desafortunadam ente, si un com ponente im portante experim enta un fallo de carácter perm anente, resulta poco probable que el sistem a operativo pueda recuperarse. Com o regla general, una llam ada de E /S al sistem a devolverá un bit de inform ación acerca de! estado de la llam ada, m ediante el que se indicará si ésta ha tenido éxito o no. En el sistema ope­ rativo UNIX, se u tiliza una variable entera adicional denom inada e r r n o para devolver un códi­ go de error (de en tre un centenar de valores posibles) que indica la naturaleza general del falle (por ejem plo, argum ento fuera de rango, puntero erróneo o archivo no abierto). Por contraste, ciertos tipos de hardw are pueden proporcionar inform ación de error altam ente detallada, aun que m uchos de los sistem as operativos actuales no están diseñados para transm itir esta informa ción a la aplicación. Por ejem plo, un fallo en un dispositivo SCSI se docum enta por parte del protocolo SCSI en tres niveles de detalle: una c la v e d e tip o que identifica la naturaleza genera del fallo, com o por ejem plo un error hardw are o una solicitud ilegal; un c ó d ig o de tip o a d id o n a l que indica la categoría del fallo, com o por ejem plo un parám etro erróneo de com ando o ur fallo de auto-test; y un c u a lif ic a d o r a d ic io n a l d e l c ó d ig o d e tip o que proporciona todavía má: detalle, com o por ejem plo qué parám etro del com ando era erróneo o qué subsistem a hardwan ha fallado al hacer el auto-test. Adem ás, m uchos dispositivos SCSI m antienen páginas internas dt inform ación de registro de errores que pueden ser solicitadas por el host, aunque raramente s< -solicitan.

13.4.6 Protección de E/S Los errores están estrecham ente relacionados con las cuestiones de protección. Un proceso d usuario puede intentar accidental o deliberadam ente interrum pir la operación norm al de un sis tema, tratando de ejecutar instrucciones de E /S ilegales. Podem os utilizar v a rio s mecanism os pan garantizar que ese tipo de problem as no aparezcan en el sistem a. Para evitar que los usuarios realicen operaciones de E/S ilegales, definimos todas las instruc d o n es de E/S com o instrucciones privilegiadas. A sí, los usuarios no pueden ejecutar instruccione de E/S directam ente, sino que tienen que hacerlo a través del sistem a operativo. Para llevar a cab una operación de E/S, el program a de usuario ejecuta una llam ada al sistem a para solicitar que t sistem a operativo realice esa operación de E/S por cuenta suya (Figura 13.11). El sistem a operat; vo, ejecutándose en m odo m onitor, com prueba que la solicitud es válida y, en caso afirmative realiza la E/S solicitada. A continuación, el sistem a operativo devuelve el control al usuario. A dem ás, habrá que utilizar el sistem a de protección de m em oria para proteger todas las ubi caciones de m em oria m apeada y de los puertos de E/S frente a los acces os de los usuario.Observe que el kernel no puede sim plem ente denegar todos los accesos de los usuarios. La maye ría de ios juegos gráficos y del softw are de edición y reproducción de vídeo necesitan acceso dire>to a la m em oria de la controladora gráfica m apeada en m em oria, con el fin de acelerar la veiocida

13.4 Subsistema de E/S del kemel

469

kernel

9 realizar E/S

volver al usuario

programa de usuario

Figura 13.11 Utilización de una llamada al sistema para realizar la E'S. de los gráficos (por ejem plo). El kernel puede en este caso proporcionar un m ecanismo de bloqueo para perm itir que se asigne a un proceso cada vez una cierta sección de la memoria gráfica (que representará una ventana en la pantalla).

13.4.7 Estructuras de datos del kemel El kem el necesita m antener inform ación de estado acerca del uso de los com ponentes de E/S. El kem el hace esto m ediante diversas estructuras de datos internas al kem el, com o por ejemplo la tabla de archivos abiertos de la Sección 11.1. El kernel utiliza m uchas estructuras sim ilares para controlar las conexiones de red, las com unicaciones con los dispositivos de tipo carácter y otras actividades de E/S. UNIX proporciona acceso de sistema de archivos a diversas entidades, como los archivos de usuario, los dispositivos sin form ato y los espacios de direcciones de los procesos. Aunque cada una de estas actividades soporta una operación r e a d (), la sem ántica difiere. Por ejemplo, para leer un archivo de usuario, el kem el necesita com probar la caché de búfer antes de decidir si debe realizar una E/S de disco. Para leer un disco sin form ato, el kem el necesita garantizar que el tama­ ño de la solicitud sea un m últiplo del tamaño del sector de disco y que esté alineada con una fron­ tera de sector. Para leer la im agen de un proceso, sim plem ente basta con copiar los datos desde m emoria. UNIX encapsula estas diferencias dentro de una estructura uniform e utilizando una téc­ nica de orientación a objetos. El registro de archivos abiertos, m ostrado en la Figura 13.12, contie­ ne una tabla de despacho que alm acena punteros a las rutinas apropiadas, dependiendo del tipo de archivo. Algunos sistemas operativos utilizan m étodos de orientación a objetos de forma todavía más intensiva. Por ejemplo, W indow s NT utiliza una im plem entación de paso de m ensajes para la E / S . Cada solicitud de E / S se convierte en un m ensaje que se envía a través de! kem el al gestor de E / S y luego al controlador de dispositivo, cada uno de los cuales puede m odificar el contenido del mensaje. Para las operaciones de salida, el m ensaje contiene los datos que hay que escribir. Para las operaciones de entrada, el m ensaje contiene un búfer para recibir los datos. La técnica de paso de m ensajes puede añadir carea de proceso adicional, por com paración con las técnicas procedí-

Capítulo 13 Sistemas de E/S

tabla global de archivos del sistema

tabla de ¡nodos activos

tabla de información d e red

memoria del kernel

F ig u ra 1 3 .1 2

Estructura de E/S del

kernel de UNIX.

m entales que utilizan estructuras de datos com partidas, pero sim plifica la estructura y el diseño del sistem a de E/S y añade un grado considerable de flexibilidad.

13.4.8 Resumen del subsistem a de e/ s del

kernel

En resum en, el subsistem a de E/S coordina una am plia colección de servicios disponibles paralas aplicaciones y para otras partes del kernel. El subsistem a de E/S supervisa los siguientes procedi­ mientos: • G estión del espacio de nom bres para archivos y dispositivos. • Control de acceso a los archivos y dispositivos. • Control de operaciones (por ejem plo, un m ódem no puede ejecutar una operación s e e k ()). • Asignación de espacio en el sistem a de archivos. • A signación de dispositivos. • A lm acenam iento en búfer. • A lm acenam iento en caché y gestión de colas de im presión. • Planificación de E/S. • M onitorización del estado de los dispositivos, tratam iento de errores y recuperación de tallos. • Configuración e iniciaiización de controladores de dispositivos. Los niveles superiores del subsistem a de E/S acceden a los dispositivos a través de la interfaz uniform e proporcionada por los controladores de dispositivo.

13.5 Transformación de las solicitudes de E/S en operaciones hardware

471

13.5 Transformación de las solicitudes de E/S en operaciones hardware A nteriorm ente, hem os descrito el procedim iento de negociación entre un controlador de disposi­ tivo y una tarjeta controladora de dispositivo, pero no hemos explicado cóm o conecta el sistema operativo una solicitud de aplicación con un conjunto de hilos- de red o con un sector de disco específico. V am os a considerar el ejem plo de la lectura de un archivó de disco. La aplicación hace referencia a los datos m ediante el nom bre del archivo. Dentro de un disco, el sistem a de archivos m apea los nom bres de archivo m ediante una serie de directorios para averiguar la asignación de espacio del archivo. Por ejem plo, en MS-DOS, el nom bre se m apea sobre un núm ero que indica una entrada dentro de la tabla de acceso a los archivos y dicha entrada de la tabla nos dice qué blo­ ques de disco están asignados al archivo. En UNIX, el nom bre se m apea sobre un núm ero de inodo, y el correspondiente inodo contiene la inform ación de asignación de espacio. ¿Cómo se realiza la conexión entre el nom bre del archivo y la controladora de disco (la dirección del puerto hardw a­ re o los registros m apeados en m emoria de la controladora)? Prim ero, vam os a considerar el caso de MS-DOS, que es un sistem a operativo relativam ente simple. La prim era parte de un nom bre de archivo MS-DOS, situado delante del carácter de dos puntos, es una cadena que identifica un dis­ positivo hardw are específico. Por ejem plo, c: es la primera parte de todos los nom bres de archivo que hagan referencia al disco duro principal. El hecho de que c: represente el disco duro principal está pre-escrito dentro del sistem a operativo; c: se m apea sobre una dirección de puerto específi­ ca a través de una tabla de dispositivos. Debido al separador de los dos puntos, el espacio de nom ­ bres de dispositivos está separado del espacio de nom bres del sistema de archivos dentro de cada dispositivo. Esta separación hace que resulte sencillo para el sistema operativo asociar una funcio­ nalidad adicional con cada dispositivo. Por ejem plo, resulta fácil invocar los m ecanism os de ges­ tión de colas de im presión para los archivos que se escriban en la impresora. Si, en lugar de ello, el espacio de nom bres de los dispositivos está incorporado dentro del espa­ cio de nom bres norm al del sistem a de archivos, como es el caso en UNIX, los servicios de nom bres norm ales del sistem a de archivos se proporcionan de m anera automática. Si el sistema de archi­ vos proporciona m ecanism os de control de propiedad y de control de acceso para todos los nom ­ bres de archivo, entonces los dispositivos tendrán propietarios y m ecanism os de control de acceso. Puesto que los archivos se alm acenan en dispositivos, dicha interfaz proporciona acceso al sistem a de E/S en dos niveles: los nom bres pueden utilizarse para acceder a los propios disposi­ tivos o para acceder a los archivos alm acenados en los dispositivos. UNIX representa los nom bres de los dispositivos dentro del espacio de nom bres normal del sis­ tema de archivos. A diferencia de un nom bre de archivo MS-DOS, que tiene un separador de dos puntos, un nom bre de ruta UNIX no tiene una separación clara de la parte correspondiente al dis­ positivo. De hecho, ninguna parte concreta del nom bre de ruta es el nom bre de un dispositivo. UNIX tiene una tab la de m o n taje que asocia prefijos de los nom bres de ruta con nombres de dis­ positivo específicos. Para resolver el nom bre de ruta, UNIX busca el nom bre en la tabla de m onta­ je para localizar el prefijo correspondiente de mayor longitud; la entrada correspondiente de la tabla de m ontaje proporcionará el nom bre de dispositivo. Este nom bre de dispositivo tam bién tiene la form a de un nom bre dentro del espacio de nombres del sistema de archivos. Cuando UNIX busca este nom bre en las estructuras de directorio del sistema de archivos, lo que encuentra no es un núm ero de inodo, sino un núm ero de dispositivo . El número de dispo­ sitivo principal identifica un controlador de dispositivo al que habrá que llam ar para tratar las operaciones de E/S dirigidas a este dispositivo. El número de dispositivo secundario se pasa al controlador de dispositivo com o índice para una tabla de dispositivos. La entrada correspondien­ te de la tabla de dispositivos proporciona la dirección de puerto o la dirección mapeada en m em o­ ria del controlador de dispositivo. Los sistem as operativos m odernos obtienen una gran flexibilidad de estas m últiples etapas de tablas de búsqueda dentro de la ruta com prendida entre una solicitud y una controladora física de dispositivo. Los m ecanism os que pasan las solicitudes entre las aplicaciones y los controladores son generales, por lo que podem os introducir nuevos dispositivos y controladores en una com ­ putadora sin necesidad de recom pilar el kernel. De hecho, algunos sistem as operativos tienen la capacidad de cargar controladores de dispositivo bajo demanda. En el m om ento del arranque, el

472

Capítulo 13 Sistemas de E/S

sistem a com prueba los buses hardw are para determ inar qué dispositivos están presentes y luego carga los controladores necesarios, inm ediatam ente o cuando sean requeridos por primera vez por una solicitud de E/S. Vam os a describir ahora el ciclo típico de vida de una solicitud de lectura bloqueante, como se m uestra en la Figura 13.13. La figura sugiere que una operación de E/S requiere muchos pasos dis­ tintos que consum en, entre todos, un núm ero enorm e de ciclos de CPU. 1. U n proceso ejecuta una llam ada al sistem a bloqueante r e a d {) dirigida a un descriptor de archivo o a un archivo que se haya abierto anteriorm ente.

proceso de usuario

E/S completada, datos de entrada disponibles o salida terminada

vuelta de la llamada al sistema

subsistema de E/S del kemel

^enviar solicitud a^controladorde, dtsposrtrvo, bloqueando el proceso si resulta apropiado

subsistema de E/S del kemel

procesar solicitud, enviar comandos a la controladora, configurar controladora para bloquearse hasta que haya úna interrupción

controlador de dispositivo

comandos de la controladora de dispositivo

rutina de tratamiento

de interrupciones

transferir datos (en caso apropiado) al proceso y devolver código de terminación o de error

determinar qué E/S se ha completado, indicando el cambio de estado ai subsistema de E/S

recibir interrupción, almacenar datos en el búfer del controlador de dispositivo en caso de entrada, enviando señal para desbloquear controlador de dispositivo

1 interrupción

* / ;

monitorizar dispositivo, interrumpir cuando E/S se haya completado

controlador de dispositivo

------ E/S completada, generación de la interrupción

Figura 13.13 Ciclo de vida de una solicitud de E/S.

13.6 Streams

473

2. El código de la llam ada al sistem a en el kem el com prueba la corrección de los parám etros. En el caso de una operación de entrada, si los datos ya están disponibles en la caché de búfer, los datos se devuelven en el proceso y se com pleta la solicitud de E/S. 3. En caso contrario, es necesario realizar una E/S física. El proceso se elim ina de la cola de eje­ cución y se coloca en la cola de espera en el dispositivo, planificándose la solicitud de E/S. Eventualm ente, el subsistem a de E/S enviará la solicitud al controlador de dispositivo. D ependiendo del sistem a operativo, la solicitud se envía m ediante una llam ada a subrutína o un m ensaje interno al kem el. 4. El controlador de dispositivo asigna espacio de búfer del kernel para recibir los datos y pla­ nifica la E/S. Eventualm ente, el controlador envía los com andos a la tarjeta controladora de dispositivo escribiendo en los registros de control del dispositivo. 5. La controladora del dispositivo opera el hardw are del dispositivo para realizar la transferen­ cia de datos.

6. El controlador puede realizar un sondeo para ver la inform ación de estado y recolectar los datos, o puede haber configurado una transferencia de DMA hacia la m em oria del kem el. Estam os asum iendo que la transferencia es gestionada por una controladora de DMA, que generará una interrupción cuando la transferencia se com plete. 7. La rutina correcta de tratam iento de interrupciones recibirá la interrupción a través de la tabla de vectores de interrupción, alm acenará los datos necesarios, efectuará una señaliza­ ción dirigida al controlador de dispositivo y volverá de la interrupción.

8. El controlador de dispositivo recibe la señal, determ ina qué solicitud de E/S se ha com pleta­ do, determ ina el estado de la solicitud y señaliza al subsistem a de E/S del kem el que la soli­ citud se ha com pletado. 9. El k em el transfiere los datos a los códigos de retom o al espacio de direcciones del proceso solicitante y m ueve el proceso de la cola de espera a la cola de procesos preparados. 10. Al m over el proceso a la cola de procesos preparados se desbloquea el proceso. Cuando el planificador asigne la CPU al proceso, éste reanudará su ejecución en el punto correspondien­ te a la term inación de la llam ada al sistema.

13.6 Streams UNIX System V tiene un m ecanism o interesante, denom inado STREAMS, que perm ite a una apli­ cación com poner dinám icam ente pipelines de código controlador de dispositivo. Un stream es una conexión full-dúplex entre un controlador de dispositivo y un proceso de nivel de usuario. Consiste de una cabecera de stre a m que efectúa la interfaz con el proceso de usuario, un extremo de controlador que controla el dispositivo y cero o más m ódulos stre a m com prendidos entre ellos. La cabecera de stream , el extrem o de controlador y cada m ódulo contienen una pareja de colas: una cola de lectura y una cola de escritura. Se utiliza un m ecanism o de paso de mensajes para transferir los datos entre las distintas colas. La estructura STREAMS se muestra en la Figura 13.14. Los m ódulos proporcionan la funcionalidad del procesam iento STREAMS; se insertan en un stream utilizando la llam ada al sistem a i o c t l (). Por ejem plo, un proceso puede abrir un dispo­ sitivo de puerto serie m ediante un stream y puede insertar un m ódulo para gestionar la edición de los datos de entrada. Puesto que los m ensajes se intercam bian entre las colas situadas en los m ódulos adyacentes, una cola de un m ódulo puede desbordar otra cola adyacente. Para evitar que esto ocurra, cada cola puede soportar un m ecanism o de con trol de flu jo . Sin el control de flujo, una cola aceptará todos ios m ensajes y los enviará inm ediatam ente a la cola situada en el m ódulo adyacente, sin alm acenarlos en búfer. Una cola que soporte el m ecanismo de control de flujo alm acenará en búfer los m ensajes y no aceptará m ensajes cuando no tenga espacio de búfer suficiente. Este proceso im plica intercam biar m ensajes de control entre las colas situadas en m ódulos adyacentes.

474

Capítulo 13 Sistemas de E/S

cola de lectura

cola de escritura módulos

cola de lectura

F ig u ra 1 3 .1 4

cola de escritura

La estructura S T R E A M S .

U n proceso de usuario escribe datos en un dispositivo utilizando la llam ada al sistema w r i t e () o p u tm s g O . La llam ada al sistem a w r i t e () escribe datos sin formato en el stream, m ientras que p u tm sg (} perm ite al proceso de usuario especificar un m ensaje. Independiente­ m ente de la llam ada al sistem a utilizada para el proceso de usuario, la cabecera de stream copia los datos en un m ensaje y entrega éste a la cola correspondiente al siguiente módulo de la secuen­ cia. Esta copia de m ensaje continúa hasta que el m ensaje se copia en el extrem o del controlador y, por tanto, en el dispositivo. De form a similar, el proceso de usuario lee datos de la cabecera del stream utilizando las llam adas al sistem a r e a d () o g e tm s g (). Si se utiliza r e a d (), la cabecera de stream extrae un m ensaje de su cola adyacente y devuelve datos norm ales (un flujo no estruc­ turado de bytes) al proceso. Si se usa g e t:n s g (), se devuelve un m ensaje al proceso. La E/S de tipo STREAMS es asincrona (o no bloqueante), excepto cuando el proceso de usuario se com unica con la cabecera de stream. Cuando escribe en e l stream, el proceso de usuario se blo­ quea, asum iendo que la siguiente cola utilice un m ecanism o de control de flujo, hasta que haya espacio suficiente para copiar el mensaje. De form a sim ilar, el proceso de usuario se bloqueará al leer del stream, hasta que haya datos disponibles. El extrem o del controlador es sim ilar a una cabecera de stream o a un m ódulo, en el sentido de que dispone de una cola de lectura y otra de escritura. Sin em bargo, el extrem o del controlador debe responder a las interrupciones, como por ejem plo la que se genera cuando hay un paquete listo para ser leído de la red. A diferencia de la cabecera de stream, que puede bloquearse si no puede copiar un m ensaje en la siguiente cola de la secuencia, el extrem o del controlador debe ges­ tionar todos los datos entrantes. Los controladores deben soportar tam bién m ecanism os de con­ trol de flujo. Sin em bargo, si el búfer de un dispositivo está lleno, el dispositivo suele recurrir al procedim iento de elim inar los m ensajes entrantes. Considere una tarjeta de red cuyo búfer de entrada esté lleno; la tarjeta de red deberá sim plem ente elim inar los m ensajes adicionales hasta que haya suficiente espacio de búfer com o para alm acenar los m ensajes entrantes. El beneficio de utilizar stream s es que proporciona un m arco de trabajo con el que se puede im plem entar una técnica m odular e increm ental de escritura de controladores de dispositivos y protocolos de red. Los distintos m ódulos pueden ser usados por stream s diferentes y, por tanto, por diferentes dispositivos. Por ejem plo, un m ódulo de red puede ser usado tanto por una tarjeta

13.7 Rendimiento

475

de red Ethernet com o por una tarjeta de red token-ring. A dem ás, en lugar de tratar la E /S de los dispositivos orientados a caracteres com o un flujo de bytes no estructurado, STREAMS perm ite añadir soporte para im plem entar las fronteras entre m ensajes y la inform ación de control que deben intercam biarse los m ódulos. El soporte para STREAMS está m uy extendido entre la m ayoría de las variantes de UNIX, y es el m étodo preferido para escribir protocolos y controladores de dis­ positivo. Por ejem plo, UNIX System V y Solaris im plem entan el m ecanism o de sockets utilizando STREAMS.

.7 Rendimiento La E /S es uno de los factores que más afectan al rendim iento del sistem a. Estas operaciones im po­ nen una intensa dem anda a la CPU para ejecutar código de los controladores de dispositivo y para planificar los procesos de form a equitativa y eficiente a m edida que se bloquean y desbloquean. Los cam bios de contexto resultantes im ponen una gran carga de trabajo a la CPU y a sus cachés hardw are. Las operaciones de E /S tam bién ponen al descubierto cualquier falta de eficiencia que exista en los m ecanism os de tratam iento de interrupciones del kem el. Adem ás, la E /S carga al bus de m em oria durante la copia de datos entre las controladoras y la m em oria física y, de nuevo, durante las copias entre los búferes del kem el y el espacio de datos de las aplicaciones. Tratar de satisfacer adecuadam ente todas esas dem andas es una de las principales preocupaciones de los arquitectos de un sistem a inform ático. A unque las com putadoras m odernas pueden gestionar m uchos m iles de interrupciones por segundo, el tratam iento de interrupciones es una tarea relativam ente cara en términos de proce­ sam iento: cada interrupción hace que el sistem a realice un cam bio de estado, ejecute la rutina de tratam iento de la interrupción y luego restaure el estado. Las operaciones de E /S program adas pueden ser m ás eficientes que las E /S dirigidas por interrupciones, si el núm ero de ciclos inverti­ dos en las esperas activas no resulta excesivo. La term inación de una operación de E /S hace, típi­ cam ente, que se desbloquee un proceso, lo que provoca la sobrecarga asociada al correspondiente cam bio de contexto. El tráfico de red tam bién puede provocar una alta tasa de cam bios de contexto. Considere, por ejem plo, un inicio de sesión rem oto en una m áquina desde otra. Cada carácter escrito en la m áqui­ na local debe transportarse hasta la m áquina rem ota. En la m áquina local, el carácter se escribe en el teclado, se genera una interrupción de teclado y el carácter se pasa a través de la rutina de tra­ tam iento de interrupción al controlador de dispositivo, al kem el y luego al proceso de usuario. El proceso de usuario ejecuta una llamada de E /S de red al sistem a para enviar el carácter a la pági­ na rem ota. El carácter fluye entonces hacia el kem el local, a través de los niveles de red que cons­ truyen un paquete de red y hacia el controlador del dispositivo de red. El controlador del dispositivo de red transfiere el paquete a la tarjeta controladora de red, que envía el carácter y genera una interrupción. La interrupción pasa de nuevo a través del kem el para hacer que se com ­ plete la llam ada de E /S de red al sistema. Ahora, el hardw are de red del sistem a rem oto recibe el paquete y se genera una interrupción. El carácter se desem paqueta según los protocolos de red y se entrega al dem onio de red apropia­ do. El dem onio de red identifica qué sesión rem ota es la im plicada y pasa el paquete al subdem onio apropiado para dicha sesión. A lo largo de este flujo, se producen cam bios de contexto y cam bios de estado (Pigura 13.15). Usualm ente, el receptor devuelve el carácter com o eco al trans­ m isor, y dicha operación duplica la cantidad de trabajo que hay que realizar. Para elim inar los cam bios de contextos necesarios para m over cada carácter entre los dem onios del kem el, los desarrolladores de Solaris reim plem entaron el dem onio teln et ufiiizando hebras internas al kem el. Sun estim a que esta m ejora perm ite increm entar el núm ero m áxim o de inicios de sesión de red desde unos cuantos centenares a unos cuantos miles en un servidor de gran tamaño. Otros sistem as utilizan p ro c e s a d o re s fro n ta le s separados para la E /S de terminales con el fin de reducir la carga de interrupciones en la CPU principal. Por ejem plo, un c o n c e n tra d o r d e te r m i­ n a le s puede m ultiplexar el tráfico de centenares de term inales rem otos'con un único puerto en una com putadora de gran tamaño. Un c a n a l d e l/S es una CPU dedicada, de propósito especial,

Capítulo 13 Sistemas de E/S

F ig u ra 13 .1 5

C om unicaciones entre com putadoras.

q u e p o d e m o s e n c o n tra r en las c o m p u ta d o r a s d e tipo m a in fra m e y e n o tro s siste m a s d e a lta g am a . L a tarea d e u n can al es d e s c a rg a r el trab a jo d e E /S d e la CPU p rin cip a l. L a id ea es q u e lo s ca n a le s h ace n q u e lo s d a to s flu v an d e m a n e ra s u a v e , m ie n tra s q u e la CPU p rin cip a l q u e d a lib re p a r a p ro ­ c e s a r los d a to s . Al igu al q u e las c o n tr o la d o ra s d e d is p o s itiv o v las c o n tr o la d o ra s d e DMA qu e p o d e m o s e n c o n tra r en las c o m p u ta d o r a s d e m e n o r ta m a ñ o , u n ca n a l p u e d e p ro c e s a r p ro g ra m a s m á s g e n e ra le s y so fisticad o s, d e m o d o q u e los ca n a le s p u e d e n o p tim iz a rs e p a ra d e r t o s tip o s de c a r g a s d e trab ajo .

Podem os em plear diversos prind pios para m ejorar la eficiencia de la E /S : •

R e d u c ir el n ú m e ro d e ca m b io s d e co n te x to .

•

R e d u c ir el n ú m e ro d e v e ce s q u e lo s d a to s d e b e n c o p ia r s e en m e m o ria m ie n tra s p a s a n d e sd e el d is p o s itiv o a la a p lic a ció n o v ic e v e rs a .

• Reducir la frecuencia de las interrupciones utilizando transferendas de gran tam año, con­ troladoras inteligentes y m ecanism os de sondeo (si puede m inim izarse la espera activa). • Increm entar la concurrencia utilizando controladoras preparadas para DMA o canales, con el tín de descargar a la CPU de las operaciones sim ples d e copia de datos.

13.7 Rendimiento

477

• D esplazar las prim itivas de procesam iento al hardw are, para perm itir que se ejecuten en las controladoras de dispositivo, de form a concurrente con las operaciones de la CPU y del bus. • Equilibrar el rendim iento de la CPU, del subsistem a de m em oria, del bus y de la E/S, por­ que cualquier sobrecarga en una de esas áreas provocará la aparición de tiempos m uertos en las otras. Los dispositivos varían enorm em ente en cuanto a com plejidad. Por ejem plo, un ratón es sim ­ ple: los m ovim ientos y los clics de los botones del ratón se convierten en valores num éricos que se pasan desde el hardware, a través del controlador de dispositivo del ratón, hasta la aplicación. Por contraste, la funcionalidad proporcionada por el controlador de dispositivos de disco de W indow s NT es m uy com pleja. No sólo gestiona los discos individuales sino que tam bién im plem enta m atrices RAID (Sección 12.7). Para hacer esto, convierte las solicitudes de lectura o escritu­ ra de las aplicaciones en un conjunto coordinado de operaciones de E/S de disco. Adem ás, im plem enta algoritm os sofisticados de tratam iento de errores y de recuperación y lleva a cabo num erosos pasos para optim izar el rendim iento del disco. ¿D ónde debe im plem entarse la funcionalidad de E/S, en el hardw are del dispositivo, en el con­ trolador del dispositivo o en el software de aplicación? En ocasiones podem os observar la progre­ sión que se ilustra en la Figura 13.16. • Inicialm ente, im plem entam os los algoritm os de E/S experim entales en el nivel de aplica­ ción, porque el código de aplicación es flexible y los errores de aplicación raram ente provo­ can un fallo catastrófico del sistema. Además, desarrollando el código en el nivel de aplica­ ción, evitam os la necesidad de reiniciar el sistem a o recargar controladores de dispositivo después de cada cam bio de código. U na im plem entación de nivel de aplicación puede ser poco eficiente, sin em bargo, debido a la carga adicional im plicada por los cam bios de con­ texto y debido a que la aplicación no puede aprovechar las estructuras de datos internas al kernel y la funcionalidad del kernel (como los eficientes m ecanism os de intercam bio de m en­ sajes internos al kernel, los m ecanism os m ultihebra y los m ecanism os de bloqueo). • Cuando un algoritm o de nivel de aplicación ha dem ostrado su utilidad, podemos reim plem entarlo en el kernel. Esto puede m ejorar el rendim iento, pero el esfuerzo de desarrollo es m ucho mayor, porque un ■:ernel de un sistema operativo es un sistem a software muy com ­ plejo y de gran envergadura. Adem ás, las im plem entaciones internas al kernel deben depu­ rarse exhaustivam ente para evitar la corrupción de los datos y los fallos catastróficos del sis­ tema.

Figura 13.16 Progresión de la funcionalidad de los dispositivos.

Capítulo 13 Sistemas de E/S

• El rendim iento más alto puede obtenerse m ediante una im plem entación especializada en hardware, bien en el dispositivo o en la tarjeta controladora. Las desventajas de una implem entación hardw are incluyen la dificultad y el coste de realizar mejoras ulteriores o de corregir errores, el tiem po de desarrollo adicional (meses en lugar de días) y la m enor flexi­ bilidad. Por ejem plo, una controladora hardw are RAID puede no proporcionar ningún medio para que el kernel influya en el orden o la ubicación de las lecturas o escrituras de blo­ ques individuales, incluso si el kernel tiene inform ación especial acerca de la carga de traba­ jo que podría perm itir al kernel m ejorar el rendim iento de E /S .

13.8 Resumen Los elem entos hardw are básicos im plicados en las operaciones de E /S son los buses, las controla­ doras de dispositivo y los propios dispositivos. La tarea de m over datos entre los dispositivos y la memoria principal es llevada a cabo por la CPU com o E /S program ada o se descarga en una con­ troladora de DMA. El m ódulo del kernel que controla un dispositivo se denom ina controlador de dispositivo. La interfaz de llam adas al sistem a que se proporciona a las aplicaciones está diseña­ da para gestionar varias categorías básicas de hardw are, incluyendo dispositivos de bloques, dis­ positivos orientados a carácter, archivos m apeados en m em oria, sockets de red y tem porizadores de intervalos program ables. Las llam adas al sistem a bloquean usualm ente al proceso que las emite, pero el propio kernel y algunas aplicaciones que no pueden quedar inactivas m ientras están esperando a que una operación de E /S se com plete pueden utilizar llamadas no bloqueantes y lla­ m adas asincronas. El subsistem a de E /S del kernel proporciona num erosos servicios. Entre estos podem os citar la planificación de E /S , el alm acenam iento en búfer, el alm acenam iento en caché, la gestión de colas de im presión, la reserva de dispositivos y el tratam iento de errores. Otro servicio, el de traducción de nom bres, realiza la conexión entre los dispositivos hardw are y los nom bres de archivos sim bó­ licos usados por las aplicaciones. Este servicio im plica varios niveles de m apeo que efectúan la tra­ ducción entre los nom bres form ados por cadenas de caracteres y las direcciones de dispositivo y controladores de dispositivo específicos, así com o la traducción de éstos a las direcciones físicas de los puertos de E /S y de las controladoras de bus. Este m apeo puede llevarse a cabo dentro del espacio de nom bres del sistem a de archivos, com o sucede en UNIX, o en un espacio de nombres de dispositivo separado, com o sucede en MS-DOS. STREAMS es una im plem entación y una m etodología para hacer que los controladores sean reutilizables y fáciles de em plear. Con este m ecanism o, se pueden apilar los controladores, pasando los datos a través de ellos de form a secuencial y bidiréccional para su procesam iento. Las llam adas de E /S al sistem a son costosas en térm inos de tiempo de procesador, debido a la gran cantidad de niveles de softw are existentes entre un dispositivo físico y la aplicación. Estos niveles im ponen la sobrecarga de los cam bios de contexto necesarios para cruzar la frontera de protección del kernel, así com o la sobrecarga derivada del tratam iento de señales e interrupciones necesario para dar servicio a los dispositivos de E /S y la carga adicional de la CPU y del sistem a de m em oria que se requiere para copiar datos entre los búferes del kernel y el espacio de la apli­ cación.

Ejercicios 13.1

Cuando aparecen m últiples interrupciones de diferentes dispositivos aproxim adam ente al mism o tiem po, puede utilizarse un esquem a de prioridades para determ inar el orden en que se debe dar servicio a las distintas interrupciones. Analice las cuestiones que habrá que tomar en consideración a la hora de asignar prioridades a las diferentes interrupciones.

13.2

¿Cuáles son las ventajas y desventajas de soportar un m ecanism o de E /S m apeado en m em oria para los registros de control de los dispositivos?

13.3

Considere los siguientes escenarios de E /S en un PC m onousuario:

Capitulo 13 bistemas de c/b

M ilenkovic [1987] analiza la com plejidad de los m étodos de E /S y de su im plementación. El uso y la program ación de los diversos m ecanism os de com unicación interprocesos y protocolos de red en UNIX se explora en Stevens [1992]. Brain [1996] docum enta la interfaz de aplicaciones de W indow s NT. La im plem entación de E /S en el sistem a operativo M IN IX de ejem plo se describe en Tanenbaum y W oodhull [1997], C uster [1994] incluye inform ación detallada sobre la implem entación de la E /S m ediante paso de m ensajes en NT. Para obtener más detalles sobre el tratam iento de la E /S en el nivel hardw are y la funcionali­ dad de m apeo de m em oria, las fuentes m ás adecuadas son los m anuales de referencia de los pro­ cesadores (M otorola [1993] e Intel [1993]). H ennessy y Patterson [2002] describe las cuestiones relativas a los sistem as m ultiprocesador y a los problem as de coherencia de caché.. Tanenbaum [1990] describe el diseño de hardw are de E /S a bajo nivel y Sargent y Shoem aker [1995] propor­ cionan una guía de program ación para el hardw are y softw are de bajo nivel de un PC. El m apa de direcciones de los dispositivos de E /S en un IBM PC se proporciona en IBM [1983]. El núm ero de m arzo de 1 9 9 4 de IEEE Com puter está dedicado al hardw are y softw are avanzado de E/S . Rago [1993] realiza un buen análisis de STREA M S.

Parte Cinco

Protección y seguridad Los m ecanism os de protección controlan el acceso a un sistem a lim itando los tipos de acceso a archivos perm itidos a los usuarios. Además, los m ecanism os de protección deben garantizar que sólo los procesos que hayan obtenido la adecuada autorización del sistem a operativo puedan operar sobre los segm en­ tos de m em oria, la CPU y otros recursos. La protección se proporciona m ediante un m ecanism o que controla el acce­ so de los program as, de los procesos o de los usuarios a los recursos definidos por un sistem a inform ático. Este m ecanism o debe proporcionar un m edio para especificar los controles que hay que imponer, junto con algún m odo de im po­ nerlos. La seguridad garantiza la autenticación de los usuarios del sistema, con el fin de proteger la integridad de la información alm acenada en el m ism o (tanto datos com o código), así com o la de los recursos físicos del sistem a inform áti­ co. El sistem a de seguridad im pide los accesos no autorizados, la destrucción o manipulación m aliciosas de los datos y la introducción accidental de incohe­ rencias.

W

V 9 A

Protección L o s p ro c e s o s e n u n s is te m a o p e ra tiv o d e b e n p ro te g e rs e d e la s a ctiv id a d e s re a liz a d a s p o r o tro s p ro c e s o s . P a ra p ro p o rc io n a r d ic h a p ro te c ció n , p o d e m o s u tiliz a r d iv e rs o s m e c a n is m o s p a ra g a ra n ­ tiz a r q u e só lo lo s p ro c e s o s q u e h a y a n o b te n id o la a d e c u a d a a u to riz a ció n d e l siste m a o p e r a tiv o p u e d a n o p e r a r so b re lo s a rc h iv o s , los s e g m e n to s d e m e m o ria , so b re la CPU y so b re o tro s re c u rs o s d e l sis te m a .

El concepto de protección hace referencia a u n m ecanism o para controlar el acceso de los pro­ gram as, de los procesos o de los usuarios a los recursos definidos por el sistem a inform ático. Este m ecanism o debe proporcionar un m edio de especificar los controles que hay que im poner, junto con un m odo de im ponerlos. Podem os distinguir entre los conceptos de protección y seguridad; este últim o es una m edida de la confianza en que se puedan preservar la integridad de un siste­ m a y de sus datos. La garantía de seguridad es un tem a m ucho más am plio que la protección, y la analizarem os en el Capítulo 15.

V- SÁnalizaí los objetivos y principios de la protección en un sistema informático moderno. • Éxplicar cómójse utilizan los dominios de protección junto cori'una matriz de acceso para especiv ficar los recurebs a los que un proceso puede acceder.- r „ ’ * • •*- • Examinar losjsistemas de protección Basados en capacldadesry basados en él lenguaje. . '■ * '

- — . ---

r5- .____________________________________________ _ r r

^

*•

14.1 Objetivos de la protección A m edida que los sistem as inform áticos se han hecho m ás sofisticados y a m edida que su rango de aplicaciones se ha ido increm entando, tam bién ha crecido la necesidad de proteger la integri­ dad de esos sistem as. La protección se concebía originalm ente com o algo asociado a los sistem as operativos m ultiprogram ados, de m odo que los usuarios que no fueran de confianza pudieran com partir de m anera segura un espacio lógico de nom bres com ún, com o por ejem plo un directo­ rio de archivos, o com partir un espacio físico de nom bres com ún, com o por ejem plo la m emoria. Los conceptos m odernos de protección han evolucionado para increm entar la fiabilidad de cual­ quier sistem a com plejo que haga uso de recursos com partidos. N ecesitam os proporcionar protección por diversas razones. La m ás obvia es la necesidad de im pedir una violación m aliciosa e intencionada de una restricción de acceso por parte de un usua­ rio. Sin em bargo, tiene una m ayor im portancia general la necesidad de garantizar que cada com ­ ponente de program a activo en un sistem a utilice los recursos del sistem a sólo en ciertas form as 483

Capítulo 14 Protección

que sean coherentes con las políticas establecidas. Este requerim iento tiene un carácter prim ord ial! si se quiere disponer de un sistem a fiable. 3 Los m ecanism os de protección pueden m ejorar la fiabilidad detectando los errores latentes erfi las interfaces definidas entre los distintos subsistem as com ponentes. La detección tem prana d é f errores de interfaz puede a m enudo im pedir que un subsistem a correcto se vea contam inado p o rl otro que no esté funcionando adecuadam ente. U n recurso no protegido no puede defenderse fren-1 te al uso (o m al uso) por parte de un usuario no autorizado o incom petente. U n sistem a orien tad o! a la protección proporcionará m edios para distinguir entre el uso autorizado y el no autorizado. J El papel de la protección en un sistem a inform ático es proporcionar un m ecanism o para la í im posición de las políticas que gobiernen el uso de recursos. Estas políticas pueden establecerse! ! de diversas form as. Algunas están fijas en el diseño de un sistem a, m ientras que otras se formu-^ lan al adm inistrar ese sistem a. Existen tam bién otras que son definidas por los usuarios in d iv id u é les para proteger sus propios archivos y program as. U n sistem a de protección deberá tener lajj flexibilidad suficiente para poder im poner una diversidad de políticas. | Las políticas de uso de recursos pueden variar según la aplicación y tam bién pueden variar a| lo largo del tiem po. Por estas razones, la protección no es sólo cuestión del diseñador de un siste-jg ma operativo. El program ador de aplicaciones necesita utilizar tam bién los m ecanism os de pró3¡ tección, para defender de un uso incorrecto los recursos creados y soportados por un subsistem a* de aplicación. E n este capítulo, describirem os los m ecanism os de protección que el sistem a operad tivo debe proporcionar para que los diseñadores de aplicaciones puedan usarlos a la hora de dise^| ñar su propio softw are de protección. vi O bserve que los m ecanism os son distintos de las políticas. Los m ecanism os determ inan cóm o se l llevará algo a cabo; las políticas deciden qu é es lo que hay que hacer. La separación entre p o lítica^ y m ecanism os resulta im portante si querem os ten er una cierta flexibilidad. Es probable que lajsl políticas cam bien de un lugar a otro o a lo largo del tiem po. En el caso peor, cada cam bio de polí|| tica requeriría u n cam bio en el m ecanism o subyacente; la u tilización de m ecanism os generales nosl perm ite evitar este tipo de situaciones. • 4|

14.2 Principios de la protección Frecuentem ente, podem os utilizar un principio director a lo largo de un proyecto, com o pueda sen el diseño de u n sistem a operativo. A ju stam os a este principio sim plifica las decisiones de diseño y hace que el sistem a continúe siendo coherente y fácil de com prender. U no de los principios directores clave y que ha resistido al paso del tiem po a la hora de proporcionar protección es el principio d el m ín im o p rivileg io . Este principio dicta que a los program as, a los usuarios, inclu­ so a los sistem as se les concedan únicam ente los suficientes privilegios para llevar a cabo sus ta­ reas. Considere la analogía de u n guardia de seguridad que dispusiera de una tarjeta m agnética. Si esta tarjeta le perm ite entrar sim plem ente en las áreas públicas que está vigilando, un mal uso de esa tarjeta provocará un daño m ínim o. Sin em bargo, si esa tarjeta perm ite acceder a todas las ; áreas, el daño derivado del robo, la pérdida, el m al uso, la copia u otro tipo de actividad com pro­ m etida realizada con la tarjeta será m ucho m ayor. Un sistem a operativo que s’e ajuste al principio del m ínim o privilegio im plem entará sus carac­ terísticas, program as, llam adas ai sistem a y estructuras de datos de m odo que el fallo o el com ­ prom iso de un com ponente provoquen un daño m ínim o y no perm itan realizar m ás que u n daño m ínim o. El desbordam iento de un búfer en un dem onio del sistem a puede hacer, com o por ejem­ plo, que el dem onio falle, pero no debería p erm itirla ejecución de código contenido en la pila del proceso que perm itiera a un usuario rem oto obtener privilegios m áxim os y acqeder al sistem a com pleto (com o sucede de form a dem asiado frecuente hoy en día). Dicho sistem a operativo tam bién proporcionará llam adas al sistem a y servicios que perm itan escribir aplicaciones con controles de acceso de granularidad fina. Proporcionará m ecanism os para activar los privilegios cuando sean necesarios y desactivarlos cuando dejan de serlo. Tam ­ bién resulta ventajosa la creación de pistas de auditoría para todos ios accesos a funciones privi-

14.3 Dominio de protección

485

legiadas. La pista de auditoría perm ite al program ador, al adm inistrador del sistem a o a los m iem ­ bros de las fuerzas del orden revisar todas las actividades realizadas en el sistem a que estén rela­ cionadas con los m ecanism os de protección y de seguridad. La gestión de los usuarios con el principio del m ínim o privilegio im plica crear una cuenta sepa­ rada para cada usuario, con sólo los privilegios que ese usuario necesite. U n operador que nece­ site m ontar cintas y realizar copias de seguridad de archivos del sistem a tendrá sólo acceso a esos com andos y archivos que necesita para llevar a cabo su tarea. Algunos sistem as im plem entan m ecanism os de control de acceso basado en roles (RBAC, role-based access control) para propor­ cionar esta funcionalidad. Las com putadoras im plem entadas dentro de una instalación que se ajuste al principio del m ínim o privilegio pueden lim itarse a ejecutar servicios específicos, a acceder a m áquinas host rem otas a través de servicios específicos y a hacer esto sólo durante períodos específicos. N orm al­ m ente, estas restricciones se im plem entan activando y desactivando cada servicio y m ediante lis­ tas de control de acceso, com o se describe en las Secciones 10.6.2 y 14.6. El principio de m ínim o privilegio puede ayudar a obtener un entorno inform ático m ás seguro. D esafortunadam ente, con frecuencia no lo hace. Por ejem plo, W indows 2000 tiene integrado un com plejo esquem a de protección, a pesar de lo cual tiene m uchos agujeros de seguridad. Por com ­ paración, Solaris se considera relativam ente seguro, aunque es una variante de UNIX, que históri­ cam ente se diseñó teniendo m uy poco presentes los m ecanism os de protección. U na de las razones para esta diferencia puede ser que W indow s 2000 tiene m ás líneas de código y m ás servi­ cios que Solaris, por lo que tiene m ás com ponentes a los que dotar de seguridad y proteger. Otra razón podría ser que el esquem a de protección de W indow s 2000 es incom pleto o protege los aspectos incorrectos del sistem a operativo, dejando otras áreas vulnerables.

14.3 Dominio de protección U n sistem a inform ático es una colección de procesos y objetos. Por objetos querem os definir tanto o b je to s hardw are (com o la CPU, los segm entos de m em oria, las im presoras, los discos y las uni­ dades de cinta) y o b jeto s softw are (com o archivos, program as y semáforos). Cada objeto tiene un nom bre distintivo que lo diferencia de todos los demás objetos del sistem a y sólo se puede acce­ der a cada objeto m ediante operaciones significativas bien definidas. Los objetos son, esencial­ m ente, tipos abstractos de datos. Las operaciones posibles pueden depender de cada objeto. Por ejem plo, en una CPU lo único que se puede hacer es ejecutar código. En los segm entos de m em oria se puede leer y escribir, m ientras que en un CD-ROM o un DVD-ROM sólo puede leerse. Las unidades de cinta pueden ser leídas, escritas y rebóbinadas. Los archivos de datos pueden crearse, abrirse, leerse, escribirse, cerrarse y borrarse; los archivos de program a pueden leerse, escribirse, ejecutarse y borrarse. A un proceso sólo se le debe perm itir acceder a aquellos recursos para los que tenga autoriza­ ción: A dem ás, en cualquier instante determ inado/un proceso sólo debería poder acceder a aque­ llos recursos que necesite actualm ente para com pletar su tarea. Este segundo requisito, al que com únm ente se denom ina principio de la necesidad de conocer, resulta útil a la hora de lim itar la cantidad de daño que u n proceso erróneo pueda provocar en el sistema. Por ejem plo, cuando el proceso p invoca el procedim iento A(), el procedim iento sólo debe poder acceder a sus propias variables y a los parám etros form ales que se le hayan pasado; no debería poder acceder a todas las variables del proceso p. D e form a sim ilar, considere el caso en que el proceso p invoca un com ­ pilador para com pilar un archivo concreto. El com pilador no debería poder acceder a archivos arbitrariam ente, sino que sólo debería acceder a un subconjunto bien definido de los archi­ vos (com o por ejem plo el archivo fuente, el archivo de listado, etc.) relacionados con el archivo que hay que com pilar. A la inversa, el com pilador puede tener archivos privados que utilice para propósitos de contabilización o de optim ización y a los que el proceso p no debería poder acceder. El principio de la necesidad de conocer es sim ilar al principio del m ínim o privilegio del que hem os hablado en la Sección 14.2, en el sentido de que los objetivos de los m ecanism os de protec­ ción son m inim izar los riesgos de las posibles violaciones de seguridad.

486

Capítulo 14 Protección

14.3.1 Estructura de dom inios Para facilitar este esquem a, un proceso opera dentro de un dom inio de protección, que especifi­ ca los recursos a los que el proceso puede acceder. C ada dom inio define un conjunto de objetos y los tipos de operaciones que pueden invocarse sobre cad a objeto. La capacidad de ejecutar una operación sobre u n objeto es un derecho de acceso. U n dom inio es una colección de derechos de acceso, cada uno de los cuales es una pareja ordenada . Por ejem­ plo, si el dom inio D tiene el derecho de acceso , entonces un proceso que se ejecute en el dom inio D podrá leer y escribir el archivo F; sin em bargo, no podrá realizar nin­ guna otra operación sobre ese objeto. Los dom inios no tienen por qué ser disjuntos, sino que pueden com partir derechos de acceso. Por ejem plo, en la Figura 14.1, tenem os tres dom inios: Dv D2 y D3. El derecho de acceso < 0 ^ {print}> es com partido por D2 y D3, lo que im plica que un proceso que se ejecute en cualquiera de ' estos dos dom inios podrá im prim ir el objeto 0 4. O bserve que un proceso deberá ejecutarse en el dom inio D4 para leer y escribir el objeto Ov m ientras que sólo los procesos en el dom inio D3 pue­ den ejecutar el objeto 0 1. La asociación entre un proceso y un dom inio puede ser estática, si el conjunto de recursos dis­ ponibles para el proceso está fijo durante la vida del proceso, o dinám ica. Com o cabría e sp era r,* establecer dom inios dinám icos de protección es m ás com plicado que establecer dom inios estáti-.; eos de protección. Si la asociación entre los procesos y los dom inios es fija y querem os adherim os al principio de la necesidad de conocer, deberá haber disponible un m ecanism o para cam biar el contenido de un dom inio. La razón deriva del hecho de que un proceso puede ejecutarse en dos fases distintas y : puede, por ejem plo, necesitar acceso de lectura en una fase y acceso de escritura en la otra. Si un.., dom inio es estático, deberem os definir el dom inio para que incluya tanto el acceso de lectura com o el de escritura; sin em bargo, esta disposición proporciona m ás derechos de los necesarios en cada una de las dos fases, ya que tenem os acceso de lectura en la fase donde sólo necesitam os" acceso de escritura, y viceversa. P or tanto, se violaría el principio de la necesidad de conocer. . Debem os perm itir que se m odifique el contenido de un dom inio para que siem pre refleje el míni­ m o necesario de derechos de acceso. Si la asociación es dinám ica, habrá disponible un m ecanism o para perm itir la conm utación de d om inio, perm itiendo al proceso conm utar de un dom inio a otro. Tam bién podem os perm itir que se m odifique el contenido de un dom inio. Si no podem os cam biar el contenido de un dominio, podem os proporcionar el m ism o efecto creando un nuevo dom inio con el contenido modificado y conm utando a este nuevo dom inio cuando queram os cam biar el contenido del dominio. Un dom inio puede llevarse a la práctica de diversas form as: • Cada usuario puede ser un dom inio. En este caso, el conjunto de objetos a los que se podrá acceder dependerá de la identidad del usuario. La conm utación de dom inios tiene lugar cuando cam bia el usuario, es decir, generalm ente cuando un usuario cierre la sesión y otro usuario la inicie. • Cada proceso puede ser un dom inio. En este caso, el conjunto de objetos a los que se podrá acceder dependerá de la identidad del proceso. La conm utación de dom inio tendrá lugar cuando un proceso envíe un m ensaje a otro proceso y espere una respuesta.

D1

D2

D3

Figura 14.1 Sistema con tres dominios de protección.

14.3 Dominio de protección

487

• Cada procedim iento puede ser un dom inio. En este caso, el conjunto de objetos a los que se podrá acceder se corresponderá con las variables locales definidas dentro del procedi­ m iento. La conm utación de dom inios sólo se produce cuando se lleva a cabo una llam ada a procedim iento. H ablarem os de la conm utación de dom inios con m ás detalle en la Sección 14.4. C onsidere el m odelo estándar de m odo dual (modo m onitor-usuario) de la ejecución de siste­ m as operativos. Cuando un proceso se ejecuta en m odo m onitor, puede ejecutar instrucciones pri­ vilegiadas y obtener así un control com pleto del sistem a inform ático. Por contraste, cuando un proceso se ejecuta en m odo usuario, sólo puede invocar instrucciones no privilegiadas. En conse­ cuencia, sólo se podrá ejecutar dentro de su espacio de m em oria predefinido. Estos dos modos protegen al sistem a operativo (que se ejecuta en el dom inio m onitor) de los procesos de usuario (que se ejecutan en el dom inio de usuario). En un sistem a operativo m ultiprogram ado, dos dom i­ nios de protección son insuficientes, ya que cada usuario quiere tam bién estar protegido frente a los otros usuarios. Por tanto, necesitam os u n esquem a m ás elaborado. Vam os a ilustrar dicho tipo de esquem as exam inando dos sistem as operativos im portantes: UNIX y MULTICS, para ver el modo en que se han im plem entado en ellos estos conceptos.

14.3.2 Un ejemplo: UNIX En el sistem a operativo UNIX, un dom inio está asociado con el usuario. La conm utación de dom i­ nio se corresponde con un cam bio tem poral en la identificación del usuario. Este cam bio se lleva a cabo a través del sistem a de archivos de la form a siguiente: con cada archivo hay asociada una identificación de propietario y un bit de dom inio (conocido com o bit setuid); cuando el bit setuid está activado y un usuario ejecuta dicho archivo, el ID de usuario se configura con el valor corres­ pondiente al propietario del archivo; sin em bargo, cuando el b it está desactivado, el ID de usuario no se m odifica. Por ejem plo, cuando un usuario A (es decir, un usuario con userlD = A) com ienza a ejecutar un archivo propiedad de B, cuyo bit de dom inio asociado está desactivado, el valor userlD del proceso se configura con el valor A . Cuando el bit setuid está activado, el valor userlD se con­ figura de m odo que se corresponda con el propietario del archivo: B. Cuando el proceso termina, se da por finalizado este cam bio tem poral del valor de userlD . Tam bién se utilizan otros m étodos para cam biar los dom inios en aquellos sistem as operativos en los que se utilizan las identidades de los usuarios para la definición de dom inios, porque casi todos los sistem as necesitan proporcionar dicho tipo de m ecanism o. Este m ecanism o se utiliza cuando algún recurso que sea privilegiado con carácter general tenga que ser puesto a disposición de la población general de usuarios. Por ejem plo, puede ser deseable perm itir a los usuarios acce­ der a una red sin que tengan que escribir sus propios program as de interconexión por red. En dicho caso, en un sistem a UNIX, activaríam os el bit setuid de un program a de com unicación por red, haciendo que el ID de usuario cam bie cuando se ejecute el program a. El ID de usuario cam ­ biará para corresponderse con el de un usuario que tenga el privilegio de acceder a la red (como por ejem plo root, el ID de usuario m ás potente). U n problem a con este m étodo es que si un usua­ rio consigue crear un archivo con el ID de usuario root y con el bit setuid activado, dicho usuario podrá convertirse en root y hacer lo que quiera en el sistem a. El m ecanism o setuid se analiza con m ás detalle en el A péndice A. - U na alternativa a este m étodo que se utiliza en otros sistem as operativos consiste en situar los program as privilegiados en un directorio especial. El sistem a operativo se diseña para m odificar -el ID de usuario de cualquier program a que se ejecute desde este directorio, bien para asignarle un valor igual al equivalente de root o el ID de usuario del propietario del directorio. Esto elimina un problem a de seguridad, que es el de los program as setuid creados y ocultados (utilizando nom bres extraños de archivos o directorios) por los piratas inform áticos para su uso posterior. Sin em bargo, este m étodo es m enos flexible que el que se utiliza en UNIX. Todavía m ás restrictivos, y por tanto m ás protectores, son los sistem as que sim plem ente no perm iten cam biar el ID de usuario. En estos casos, deben utilizarse técnicas especiales para perm i­ tir á los usuarios acceder a recursos privilegiados. Por ejem plo, puede iniciarse durante el arran­ q u e del sistem a un proceso dem onio y ejecutarse com o un ID de usuario especial. Los usuarios

488

Capítulo 14 Protección

ejecutan entonces u n program a independiente, que envía solicitudes a este proceso cada vez que necesiten usar el recurso privilegiado. Este m étodo se utiliza en el sistem a operativo TOPS-20. E n cualquiera de estos sistem as, debe tenerse un gran cuidado a la hora de escribir los progra­ m as privilegiados. C ualquier descuido puede provocar una total falta de protección en el sistema. G eneralm ente, estos program as son los prim eros en ser atacados por aquellas personas que tratan de irrum pir dentro de un sistem a; desafortunadam ente, los atacantes fienen éxito en m uchas oca­ siones. Por ejem plo, la seguridad se ha visto rota en m uchos sistem as UNIX debido a la funciona­ lidad setuid. H ablarem os en detalle de los tem as de seguridad en el Capítulo 15.

14.3.3 Un ejem plo: MULTICS E n el sistem a MULTICS, los dom inios de protección están organizados jerárquicam ente en una estructura de anillos concéntricos. Cada anillo se corresponde con un único dom inio (Figura 14.2). Los anillos están num erados de 0 a 7. Sean D, y D] dos anillos de dom inio cualquiera. S i ; < ¿, entonces D¡ es un subconjunto de D;, es decir, un proceso que se ejecute en el dom inio D¡ tiene más privilegios que otro que se ejecu te en el dom inio D¡. U n proceso que se ejecute en el dom inio D0 será el que tenga m ás privilegios. Si sólo existen dos anillos, este esquem a es equivalente al modo m onitor-usuario de ejecución, donde el m odo m onitor corresponderá a D0 y el m odo usuario corresponderá a D v MULTICS tiene u n espacio de direcciones segm entado; cada segm ento es un archivo y cada seg­ m ento está asociado con uno de los anillos. La descripción de un segm ento incluye una entrada que identifica el n úm ero de anillo. Adem ás, incluye tres bits de acceso para controlar la lectura, la escritura y la ejecución. La asociación entre segm entos y anillos es una decisión de política en la qu e aquí no estam os interesados. C on cada proceso hay asociado un contador de núm ero actual de anillo, que identifica el anillo en el que se está ejecutando el proceso actualm ente. Cuando un proceso se esta ejecutando en el anillo i, no puede acceder a u n segm entos asociado con el anillo j (j < i), pero sí podrá acceder a un segm ento asociado con el anillo k (k > i). Sin em bargo, el tipo de acceso estará restringido de acuerdo con los bits de acceso asociados con ese segmento. L a co n m u ta c ió n d e d o m in io s en MULTICS tien e lu gar cu an d o u n p ro ceso cru za de u n anillo a o tro in v o ca n d o u n p ro ce d im ie n to situ ad o en u n anillo d iferen te. O b v iam en te, esta con m u tació n d eb e re a liz a rse d e fo rm a co n tro la d a ; en caso con trario, u n p ro ceso p od ría co m en zar a ejecutar c ó d ig o en el a n illo 0 y n o se p ro p o rcio n a ría n in gu n a p ro tecció n . Para p erm itir u na con m u tació n c o n tro la d a d e d o m in io , m o d ifica m o s el cam p o d e anillo del d escrip to r de seg m en to con el fin de in clu ir la sig u ien te in fo rm a ció n :

• Fronteras de acceso. U na pareja de enteros, b l y b2, tal q u e b l < b2.

anillo1 anilloN — 1

Figura 14.2 Estructura de anillos de MULTICS.

14.4 Matriz de acceso

489

• L ím ite. U n entero b3 tal que b3 > b2. • L ista de puertas. Identifica los puntos de entrada (o puertas) en los que pueden invocarse los segm entos. Si un proceso que está ejecutando en el anillo i invoca u n procedim iento (o segm ento) con fron­ teras de acceso (b l, b2), entonces la llam ada será perm itida si b l < i < b2, y el núm ero actual de ani­ llo del proceso seguirá siendo i. En caso contrario, se produce una interrupción softw are dirigida al sistem a operativo y la situación se trata de la form a siguiente: • Si i < b l, entonces, se perm ite que tenga lugar la llam ada, porque tenem os una transferen­ cia a un anillo (o dom inio) con m enores privilegios. Sin em bargo, si se pasan parám etros que hagan referencia a segm entos situados en un anillo m enor (es decir, segm entos no acce­ sibles para el procedim iento invocado), entonces estos segm entos deberán copiarse en un área a la que sí pueda acceder el procedim iento invocado. • Si i > b2, entonces sólo se perm ite que se produzca la llam ada si b3 es m ayor o igual que i y la llam ada ha sido dirigida a uno de los puntos de entrada designados en la lista de puer­ tas. Este esquem a perm ite que procesos con derechos de acceso lim itados invoquen proce­ dim ientos en los anillos inferiores que tengan m ás derechos de acceso, pero sólo de una m anera cuidadosam ente controlada. La principal desventaja de la estructura en anillos (o jerárquica) es que no nos perm ite im po­ n er el principio de la necesidad de conocer. En particular, si un objeto debe estar accesible en el dom inio D, pero no en el dom inio D¡, entonces debem os tener j < i. Pero este requisito significa que todos los segm entos accesibles en D¿ serán tam bién accesibles en Dj. El sistem a de protección de MULTICS es, generalm ente, m ás com plejo y m enos eficiente que los utilizados en los sistem as operativos actuales. Si el m ecanism o de protección interfiere con la faci­ lidad de uso del sistem a o reduce significativam ente el rendim iento del m ism o, habrá que ponde­ rar cuidadosam ente su uso poniéndolo en relación con el propósito del sistem a. Por ejem plo, conviene tener un sistem a de protección com plejo en una com putadora que vaya a ser utilizada por una universidad para procesar las notas de los estudiantes y que tam bién vaya a ser usada por los estudiantes para sus trabajos de curso. Sin em bargo, un esquem a de protección sim ilar no sería adecuado para una com putadora utilizada para cálculo m asivo, en la que la velocidad de proce­ so es el criterio m ás im portante. Conviene separar el m ecanism o dé la política de protección, para perm itir que un mismo sistem a tenga una protección com pleja o sim ple posible dependiendo de las necesidades de sus usuarios. Para separar el m ecanism o de la política, necesitam os un m ode­ lo de protección más general.

.4 Matriz de acceso N uestro m odelo de protección puede contem plarse de form a abstracta com o una m atriz, denom i­ nada m atriz de acceso. Las filas de la m atriz de acceso representan dom inios y las colum nas repre­ sentan objetos. Cada entrada de la m atriz está com puesta de un conjunto de derechos de acceso. Puesto que la colum na define los objetos explícitam ente, podem os om itir el nom bre del objeto del derecho de acceso. La entrada a c c e s s (i,j) define el conjunto de operaciones que un proceso que se ejecute en el dom inio D, puede invocar sobre el objeto 0 ; . Para ilustrar estos conceptos, vamos a considerar la m atriz de acceso m ostrada en la Figu­ ra 14.3. H ay cuatro dom inios y cuatro objetos: tres archivos (Fv F2, F3) y una im presora láser. U n proceso que se ejecute en el dom inio D x podrá leer los archivos Fx y F3. U n proceso que se ejecu­ te en el dom inio D 4 tendrá los mismos privilegios que otro que se ejecute en el dom inio Dv pero adem ás tam bién podrá escribir en los archivos Fx y F3. O bserve que a la im presora láser sólo podrán acceder los procesos que se ejecuten en el dom inio D2. El esquem a basado en m atriz de acceso nos proporciona m ecanism os para especificar una diversidad de políticas. El m ecanism o consiste en im plem entar la m atriz de -acceso y garantizar que las propiedades sem ánticas que hemos esbozado se cum plan. M ás específicam ente, debem os

Capítulo 14 Protección

Figura 14.3

Matriz de acceso.

garantizar que u n proceso que se ejecute en el dom inio D¡ sólo pueda acceder a los objetos espe­ cificados en la pila i y únicam ente según perm itan las entradas de la m atriz de acceso. La m atriz de acceso puede im plem entar decisiones de política relativas a la protección. Las decisiones de política im plican qué derechos deben incluirse en la entrada (i,j). Tam bién debemos/ definir el dom inio en el que cada proceso se habrá de ejecutar. Esta últim a política es usualm ente ¿ definida por el sistem a operativo.. ¿ Los usuarios norm alm ente deciden el contenido de las entradas de la m atriz de acceso. Cuando un usuario crea un nuevo objeto Oy, se añade la colum na Oy a la m atriz de acceso, con las apropia^, das entradas de inicialización, según determ ine el creador. El usuario puede decidir introducir| algunos derechos en determ inadas entradas de la colum na j y otros derechos en otras entradas^ según sea necesario. La m atriz de acceso proporciona el m ecanism o apropiado para definir e im plem entar un con­ trol estricto de la asociación tanto estática com o dinám ica en tre procesos y dom inios. Cuando con-' m utam os un proceso de un dom inio a otro, ejecutam os una operación ( s w it c h ) sobre un objeto (el dom inio). Podem os controlar la conm utación de dom inios incluyendo los dom inios entre lo s ; objetos de la m atriz de acceso. De form a sim ilar, cuando cam biam os el contenido de la m atriz de acceso, realizam os una operación sobre un objeto: la propia m atriz de acceso. De nuevo, podemos controlar estos cam bios incluyendo la propia m atriz de acceso com o un objeto. De hecho, puesto que cada entrada de la m atriz de acceso puede m odificarse individualm ente, debem os considerar cada entrada de la m atriz de com o un objeto que hay que proteger. Ahora, sólo necesitam os con­ siderar las operaciones que sean posibles sobre estos objetos (dom inios y m atriz de acceso) y deci­ dir cóm o querem os que los procesos puedan ejecutar dichas operaciones. Los procesos deben poder conm utar de un dom inio a otro. La conm utación del dom inio D¡ al dom ino Dy estará perm itida si y sólo si el derecho de acceso s w i t c h e a c c e s s P o r tanto, en la Figura 14.4, un proceso que se ejecute en el dom inio D 2 podrá conm utar al dom inio D 3 o al dom inio D4. Un proceso en el dom inio D 4 podrá conm utar al dom inio D1 y un dom inio D 1 podrá conm utar al dom inio D2. Perm itir una m odificación controlada del contenido de las entradas de la m atriz de acceso: requiere tres operaciones adicionales: co p y , o w n er y c o n t r o l . Vam os a exam inar estas opera­ ciones a continuación. L . La capacidad de copiar un derecho de acceso de un dom inio (o fila) de la m atriz de acceso a otro se denota m ediante un asterisco (*) añadido al derecho de acceso. El derecho de copia permi­ te copiar el derecho de acceso sólo dentro de la colum na (es decir, para el objeto) en la que esté definido el derecho. Por ejem plo, en la Figura 14.5(a), un proceso que se ejecute en el dom inio D2 podrá copiar la operación elegida en cualquier entrada asociada con el archivo F2. Por tanto, la m atriz de acceso de la Figura 14.5(a) podrá m odificarse para obtener la m atriz de acceso m ostra­ da en la Figura 14.5(b). Este esquem a tiene dos variantes:

14.4 Matriz de acceso

491

Figura 14.4 Matriz de acceso de la Figura 14.3 incluyendo los dominios como objetos.

(b) Figura 14.5 Matriz de acceso con derechos de copia. 1 . U n derecho se copia de a c c e s s (i,j) a a c c e s s (k,f); y a continuación se elim ina de a c c e s s Esta acción es una transferencia de un derecho, en lugar de una copia. 2. La propagación del derecho de copia puede estar limitada. Es decir, cuando el derecho R* se copia de a c c e s s ( r j) a a c c e s s (k,j), sólo se crea el derecho R (no R*). Un proceso que se eje­ cute en el dom inio Dk no podrá copiar a su vez el derecho R. Un sistem a puede seleccionar sólo uno de estos tres derechos de copia, o puede proporcionar los tres identificándolos com o derechos distintos: copia, transferencia y copia limitada. Tam bién necesitam os u n m ecanism o para perm itir la adición de nuevos derechos y la elim ina­ ción de algunos derechos. El derecho owner controla estas operaciones. Si a c c e s s (i,j) incluye el derecho owner, entonces u n proceso que se ejecute en el dom inio D¡ podrá añadir y elim inar cu al­ quier derecho en cualquier entrada de la colum na j. Por ejem plo, en la Figura 14.6(a), el dom inio D ¡ es el propietario de F1 y por tanto puede añadir y borrar cualquier derecho válido en la colum ­ na F1. De form a sim ilar, el dom inio D 2 es el propietario de F 2 y F 3 y puede, por tanto, añadir y elim inar cualquier derecho válido dentro de estas dos colum nas. Así, la m atriz de acceso de la Figura 14.6(a) puede m odificarse para obtener la m atriz de acceso m ostrada en la Figura 14.6(b).

492

Capítulo.14 Protección

Figura 14.6

Matriz de acceso con derechos de propietario.

Los derechos de copia y el derecho de propietario perm iten a un proceso m odificar las entradas^ de una colum na. Tam bién hace falta un m ecanism o para m odificar las entradas de una fila. Eli derecho control sólo es aplicable a los objetos dominio. Si a c c e s s (i,j) incluye el derecho control,|¡ entonces un proceso que se ejecute en el dom inio D, puede elim inar cualquier derecho de acceso de la fila ;. P or ejem plo, suponga que, en la Figura 14.4, incluim os el derecho control en ' a c c e s s ( D 2, D4). Entonces, un proceso que se ejecute en el dom inio D 2 podría m odificar el domi­ nio D 4, com o se m uestra en la Figura 14.7. Los derechos de copia y el derecho de propietario proporcionan un m ecanism o para lim itar la propagación de derechos de acceso. Sin em bargo, no nos proporcionan las herram ientas apropia­ das para im pedir la propagación (ó revelación) de inform ación. El problem a de garantizar qué" ninguna inform ación que se alm acenara inicialm ente en un objeto pueda m igrar fuera de su entor­ no de ejecución se denom ina p roblem a del con fin am iento. Este problem a es, en general, irreso­ luble (véanse las referencias en las N otas bibliográficas).

N. dominio

objeto' •ft

f2

■ '- f3

¡mpres. láser

■Da

,D .~ -

-

-

í*

Figura 14.7 Matriz de acceso modificada de la Figura 14.4.

V-7-%

-

14.5 Implementación de la matriz de acceso

493

Estas operaciones sobre los dom inios y la m atriz de acceso no son en sí m ismas im portantes, pero ilustran la capacidad del m odelo de la m atriz de acceso para perm itir la im plem entación y control de requisitos de protección dinám icos. Pueden crearse dinám icam ente nuevos objetos y nuevos dom inios e incluirlos en el m odelo de la m atriz.de acceso. Sin embargo, sólo hem os m ostrado que el m ecanism o básico existe; los diseñadores del sistem a y los usuarios deben tomar las decisiones de política relativas a qué dom inios deben poder acceder a qué objetos y en qué m anera.

14.5 Im plem entación de la m atriz de acceso ¿Cóm o puede im plem entarse efectivam ente la m atriz de acceso? En general, la m atriz será algu­ na vez dispersa, es decir, la m ayoría de las entradas estarán vacías. Aunque existen técnicas de representación de estructuras de datos para representar m atrices dispersas, no resultan particu­ larm ente útiles para esta aplicación, debido a la form a en que se utiliza la funcionalidad de pro­ tección. E n esta sección, vam os a describir prim ero varios m étodos de im plem entar la m atriz de acceso y luego vam os a com parar los distintos m étodos.

14.5.1 Tabla global La im plem entación m ás sim ple de la m atriz de acceso es una tabla global com puesta de un con­ ju n to de tripletas ordenadas . Cada vez que se ejecuta una ope­ ración M sobre u n objeto 0 ; dentro del dom inio D,, se analiza la tabla global en busca de una tripleta , con M e Rk. Si se encuentra esta tripleta, se perm ite que la operación conti­ núe; en caso contrario; se genera una condición de excepción (o error). Esta im plem entación tiene varias desventajas. La tabla es usualm ente m uy grande y no puede, por tanto, ser conservada en m em oria principal, por lo que hacen falta operaciones adicionales de E/S. A m enudo se utilizan técnicas de m em oria virtual para gestionar esta tabla. A dem ás, resulta difícil aprovechar las agrupaciones especiales de objetos o dom inios. Por ejem plo, si todo el m undo puede leer un objeto concreto, es necesario definir una entrada separada en cada uno de los dom inios.

14.5.2 Listas de acceso para los objetos Cada colum na de la m atriz de acceso puede im plem entarse com o una lista de acceso de un obje­ to, com o se escribe en la Sección 10.6.2. Obviam ente, las entradas vacías pueden descartarse. La lista resultante para cada objeto estará com puesta por una serie de parejas ordenadas , que definen todos los dom inios que tengan un conjunto de derechos de acce­ so no vacío para dicho objeto. Esta técnica puede extenderse fácilm ente para definir una lista m ás un conjunto predeterm ina­ do de derechos de acceso. Cuando se intenta realizar una operación M sobre un objeto Oj en el dom inio D¡, buscam os en la lista de acceso del objeto 0 ;- una entrada , con M e Rk. Si se encuentra esa entrada, perm itim os la operación; en caso contrario, com probam os el conjunto pre­ determ inado. Si M está en el conjunto predeterm inado, perm itim os el acceso. Si no lo está, se deniega el acceso y se produce una condición de excepción. Para aum entar la eficiencia, podem os com probar prim ero el conjunto predeterm inado y luego buscar en la lista de acceso.

14.5.3 Listas de capacidades para los dom inios En lugar de asociar las colum nas de la m atriz de acceso con los objetos en form a de listas de acce­ so, podem os asociar cada fila con su dominio. U na lista de capacidades para un dom inio es una lista de objetos ju n to con las operaciones perm itidas sobre esos objetos. Cada objeto.se suele repre­ sentar m ediante su dirección o nom bre físico, denom inada capacidad. Para ejecutar la operación M sobre el objeto O,, el proceso ejecuta la operación M especificando la capacidad (o puntero) para

Capítulo 14 Protección

el objeto 0 ¡ com o parám etro. La sim ple p o sesió n de la capacidad significa que el acceso está pe¡SB| La lista de capacidades está asociada con un dom inio, pero un proceso que se ejecute en e l s B dom inio no puede nunca acceder directam ente a ella. Por el contrario, la lista de capacidades e g JB en sí m ism a un objeto protegido, m antenido por el sistem a operativo y al que el usuario s ó lo !S puede acceder indirectam ente. El m ecanism o de protección basado en capacidades descansa e n e f B hecho de que nunca se perm ite a las capacidades m igrar a ningún espacio de direcciones que s e l l directam ente accesible por parte de un proceso de usuario (donde podrían ser modificadas). todas las capacidades son seguras, el objeto al que protegen tam bién estará defendido frente í| H accesos no autorizados. - < js 9 Las capacidades se propusieron originalm ente com o una especie de puntero seguro, para sa tislS facer la necesidad de protección de los recursos que se preveía que iba a ser necesaria a m e d id !® que los sistem as inform áticos m ultiprogram ados se generalizaran. La idea de un puntero inhereng|¡| tem ente protegido proporciona una base para la protección que puede extenderse hacia el n iv e y S de las aplicaciones. t | | ¡Í Para proporcionar una protección inherente, debem os distinguir las capacidades de otros o b je¡J| tos y debem os interpretarlas m ediante u na m áquina abstracta sobre la que se ejecuten los p r o g r jS S mas de m ayor nivel. Las capacidades se suelen distinguir de otros tipos de datos en una de dos?» • C ada objeto tiene una etiqueta para denotar su tipo, es decir, para indicar si se trata de un1¡¡5 capacidad o de un dato accesible. Las propias etiquetas no deben ser directam ente a c c e s i j* bles por parte de u n program a de aplicación. Puede utilizarse soporte hardw are o firm w ljH re para im poner esta restricción. A unqu e sólo hace falta un bit para distinguir entre capad|§g dades y otros objetos, a m enudo se utilizan bits adicionales. Esta extensión perm ite queelnj hardw are etiquete todos los objetos con su tipo. De este m odo, el hardw are puede d istin gS guir enteros, núm eros en com a flotante, punteros, valores booleanos, caracteres, instruccio|B nes, capacidades y valores no inicializados, sim plem ente consultando sus etiquetas. ...¿ f i a • A lternativam ente, el espacio de direcciones asociado con un program a puede dividirse en#| dos partes. Una parte es accesible para el program a y contiene las instrucciones y los datos. norm ales del program a. La otra parte, que contiene la lista de capacidades, sólo es accesible por el sistem a operativo. Para soportar este m ecanism o, resulta útil disponer de un espacio de m em oria segm entado (Sección 8.6). 5 Se han desarrollado diversos sistem as de protección basados en capacidades; describiremos * brevem ente esos sistem as en la Sección 14.8. El sistem a operativo M ach también utiliza una versión del m ecanism o de protección basado en capacidades y esa versión se describe en el ^ A péndice B. y

14.5.4 Un m ecanism o de bloqueo-clave

a

El esqu em a de bloq u eo-clave es un com prom iso entre las listas de acceso y las listas de capacida­ des. Cada objeto tiene una lista de patrones de bit distintivos, denom inados bloqueos. De forma sim ilar, cada dom inio tiene una lista de patrones de bit distintivos, denom inados claves. U n pro- “ ceso que se ejecute dentro de un dom inio podrá acceder a un objeto sólo si dicho dom inio tiene : una clave que se corresponda con uno de los bloqueos del objeto. Al igual que con las listas de capacidades, la lista de claves de un dom inio debe ser gestiona­ da por el sistem a operativo por cuenta del dom inio. Los usuarios no están autorizados a exami­ nar o m odificar la lista de claves (o de bloqueos) directam ente.

14.5.5 Comparación Vam os ahora a com parar las diversas técnicas de im plem entación de las m atrices de acceso. La utilización de una tabla global resulta m uy sim ple; sin em bargo, la tabla puede ser bastante gran-

14.6 Control de acceso

495

de y a m enudo no podem os aprovecham os de las agrupaciones especiales de objetos o dominios. Las listas de acceso se corresponden directam ente con las necesidades de los usuarios; cuando un usuario crea un objeto, puede especificar los dom inios que pueden al acceder, así com o las opera­ ciones perm itidas. Sin em bargo, puesto que la inform ación de derechos de acceso para un dom i­ nio concreto no está localizada, resulta difícil determ inar el conjunto de derechos de acceso de cada dom inio. A dem ás, hay que com probar cada acceso al objeto, lo que requiere explorar la lista de acceso. En un sistem a de gran envergadura con listas de acceso largas, esta búsqueda puede consum ir m ucho tiempo. Las listas de capacidades no se corresponden directam ente con las necesidades de los usuarios; resultan útiles, sin em bargo, para localizar inform ación para un proceso determ inado. El proceso que esté intentando realizar el acceso deberá presentar una capacidad para dicho acceso. Entonces, el sistem a de protección sólo necesita verificar que la capacidad es válida. La revocación de capacidades, sin em bargo, puede resultar poco eficiente (Sección 14.7). El m ecanism o de bloqueo-clave, com o hem os m encionado, representa un com prom iso entre las listas de acceso y las listas de capacidades. El m ecanism o puede ser a la vez efectivo y flexible, dependiendo de la longitud de las claves. Esas claves pueden pasar seguram ente de un dominio a otro. A dem ás, los privilegios de acceso pueden revocarse de m anera efectiva m ediante la sim ­ ple técnica de cam biar algunos de los bloqueos asociados con el objeto (Sección 14.7). La m ayoría de los sistem as usan una com binación de listas de acceso y capacidades. Cuando un proceso trata por prim era vez de acceder a un objeto, se analiza la lista de acceso. Si se denie­ ga el acceso, se genera una condición de excepción. En caso contrario, se crea una capacidad y se la asocia al proceso. Las referencias adicionales utilizarán la capacidad para dem ostrar directa­ m ente que el acceso está perm itido. Después del últim o acceso, se destruye la capacidad. Esta estrategia se utiliza en el sistem a MULTICS y en el sistem a CAL. Com o ejem plo del m odo en que funciona dicha estrategia, considere un sistem a de archivos en el que cada archivo tenga una lista de acceso asociada. C uando un proceso abre un archivo, se explora la estructura de directorio para encontrar el archivo, se com prueban los perm isos de acce­ so y se asignan los búferes. Toda esta inform ación se registra en una nueva entrada dentro de la tabla de archivos asociada con el proceso. La operación devuelve un índice a esta tabla para el archivo recién abierto. Todas las operaciones sobre el archivo se realizan especificando el índice de la tabla de archivos. La entrada de la tabla de archivos apunta, a su vez, al archivo y a sus búfe­ res. Cuando se cierra el archivo, se borra la entrada de la tabla de archivos. Puesto que la tabla de archivos es m antenida por el sistem a operativo, el usuario no puede corrom perla accidentalm en­ te. Así, el usuario sólo puede acceder a aquellos archivos que hayan sido abiertos. Puesto que el acceso se com prueba en el m om ento de abrir el archivo, la protección está garantizada. Esta estra­ tegia se utiliza en el sistem a UNIX. El derecho de aceso deberá seguir com probándose para cada acceso, y la entrada de la tabla de archivos incluye una capacidad únicam ente para las operaciones perm itidas. Si el archivo se abre para lectura, se coloca una capacidad para acceso de lectura dentro de la entrada de la tabla de archivos. Si se realiza un intento de escribir en el archivo, el sistem a identificará esta violación de la protección com parando la operación solicitada con la capacidad incluida en la entrada de la tabla de archivos.

14.6 Control de acceso En la Sección 10.6.2 hem os descrito cóm o pueden usarse los controles de acceso a los archivos den­ tro de un sistem a de archivos. A cada archivo y directorio se le asignan un propietario, un grupo o posiblem ente una lista de usuarios y para cada una de estas entidades se asigna una inform a­ ción de control de acceso. Podemos añadir una función sim ilar a otros aspectos de un sistema inform ático. Un buen ejem plo de esta estrategia es el que podem os en co n traren Solaris 10. . Solaris 10 am plía el sistem a de protección disponible en el sistem a operativo Sun M icrosystem s añadiendo explícitam ente el principio del m ínim o privilegio m ediante el control de acceso basa­ do en ro les (RBAC, role-based access control). Esta funcionalidad gira en tom o a los privilegios. Un privilegio es el derecho a ejecutar una llam ada al sistem a o a usar una opción dentro de dicha

496

Capítulo 14 Protección

ejecución con privilegios del rol 1

I

Figura 14.8

Control de acceso basado en roles en Solaris 10.

"3Í

•.

-£¡f¡*á

llam ada al sistem a (como por ejem plo, abrir u n archivo con acceso de escritura). Podemos asignaBj privilegios a los procesos, lim itando éstos a exactam ente el tipo de acceso que necesitan para üejj| var a cabo su tarea. Los privilegios y program as tam bién pueden asignarse a roles. A los usuarios^ se les asignan roles (o los usuarios adoptan roles) basándose en contraseñas asignadas a los roles?! D e esta form a, un usuario puede adoptar un rol que activa u n privilegio, perm itiendo al usuariójj ejecutar un program a para llevar a cabo una tarea específica, com o se ilustra en la Figura 14.8. EslaJ im plem entación de los privilegios reduce el riesgo de seguridad asociado con los superusuarios y* con los program as setuid. áj Observe que esta funcionalidad es sim ilar a la m atriz de acceso descrita en la Sección 1 4.4s Explorarem os esta relación con m ás detalle en los ejercicios del final del capítulo. , |§

14.7 Revocación de derechos de acceso

?

En un sistem a de protección dinám ico, puede que necesitem os en ocasiones revocar derechos de acceso a objetos com partidos por diferentes usuarios. En este punto pueden surgir diversas cues­ tiones acerca de la revocación: • In m ed iata o diferida. ¿La revocación tiene lugar inm ediatam ente o se produce de forma diferida? Si se difiere la revocación, ¿podem os averiguar cuándo tendrá lugar? • S electiv a o general. Cuando se revoca un derecho de acceso a un objeto, ¿afecta a todos los usuarios que tienen derecho de acceso a ese objeto o podem os especificar un grupo selec­ cionado de usuarios cuyos derechos de acceso deben revocarse? • P arcial o total. ¿Podem os revocar un subconjunto de los derechos asociados con un objeto o debem os revocar todos los derechos de acceso al objeto? • T em p o ral o perm anente. ¿Podem os revocar el acceso perm anentem ente (es decir, el dere­ cho de acceso revocado nunca volverá a estar disponible), o podem os revocar el acceso y luego obtenerlo de nuevo? Con un esquem a basado en lista de acceso, la revocación resulta sencilla. Se analiza la lista de acceso en busca de los derechos de acceso que hay que revocar y se los borra de la lista. La revo­ cación es inm ediata y puede ser general o selectiva, total o parcial y perm anente o temporal. Las capacidades, sin em bargo, presentan un problem a m ucho m ás difícil de cara a la revoca­ ción. Puesto que las capacidades están distribuidas por todo el sistem a, debem os encontrarlas

14.8 Sistemas basados en capacidades

497

antes de poder revocarlas. Entre los esquem as que pueden utilizarse para im plem entar la revoca­ ción en un sistem a basado en capacidades podem os citar: • R ead qu isición . Periódicam ente, se borran las capacidades de cada dom inio. Si un proceso quiere usar una capacidad, puede que se encuentre con que esa capacidad ha sido borrada. El proceso puede entonces tratar de volver a adquirir la capacidad. Si se ha revocado el acce­ so, el proceso no será capaz de efectuar esa readquisición. • R etropunteros. Con cada objeto se m antiene una lista de punteros, que hace referencia a todas las capacidades asociadas con ese objeto. Cuando se necesita realizar una revocación, podem os seguir esos punteros, cam biando las capacidades según sea necesario. Este esque­ m a fue adoptado en el sistem a MULTICS. Es un sistem a m uy general, aunque su im plem en­ tación es costosa. • In d irección. Las capacidades apuntan indirectam ente, en lugar de directamente, a los obje­ tos. Cada capacidad apunta a una entrada unívoca dentro de una tabla global, que a su vez apunta al objeto. Im plem entam os la revocación analizando la tabla global en busca de la entrada deseada y borrándola. Entonces, cuando se intenta realizar un acceso, se verá que la capacidad está apuntando a una entrada ilegal de la tabla. Las entradas de la tabla pue­ den reutilizarse para otras capacidades sin ninguna dificultad, ya que tanto la capacidad com o la entrada de la tabla contienen el nom bre distintivo del objeto. El objeto asociado a una capacidad y su entrada de la tabla deben corresponderse. Este esquem a fue adoptado en el sistem a CAL. El sistem a no perm ite la revocación selectiva. • C laves. U na clave es un patrón distintivo de bits que puede asociarse con una capacidad. Esta clave se define en el m om ento de crear la capacidad y no puede ser nunca m odificada ni inspeccionada por el proceso que posee la capacidad. Con cada objeto hay asociada una clave m aestra; esa clave puede definirse o sustituirse m ediante la operación s e t - k e y . Cuando se crea una capacidad, se asocia con esa capacidad el valor actual de la clave m aes­ tra. Cuando se ejerce esa capacidad, su clave se com para con la clave maestra. Si las dos cla­ ves coinciden, se perm ite que la operación continúe; en caso contrario, se genera una condi­ ción de excepción. El proceso de revocación sustituye la clave m aestra con un nuevo valor m ediante la operación s e t - k e y , invalidando todas las capacidades anteriores para este objeto. Este esquem a no perm ite la revocación selectiva, ya que con cada objeto sólo hay aso­ ciada una clave m aestra. Si asociam os una lista de claves con cada objeto, entonces podrá im plem entarse la revocación selectiva. Finalm ente, podem os agrupar todas las claves en una tabla global de claves. U na capacidad será válida sólo si su clave se corresponde con alguna de las claves de la tabla global. Im plem entam os la revocación elim inando de la tabla esa clave que se corresponda. Con este esquem a, podem os asociar una clave con varios obje­ tos y puede haber tam bién varias claves asociadas con un único objeto, proporcionando así la m áxim a flexibilidad. En los esquem as basados en claves, las operaciones de definición de claves, de inser­ ción de claves en listas y de borrado de claves de las listas no deben estar disponibles para todos los usuarios. En particular, sería razonable perm itir que sólo el propietario de un objeto pueda configurar las claves de dicho objeto. Esta elección, sin em bargo, es una deci­ sión de política que el sistem a de protección puede im plem entar pero que no debe definir a priori.

14.8 Sistemas basados en capacidades

^

En esta sección, vam os a repasar dos sistem as de protección basados en capacidades. Estos siste­ mas varían tanto en lo que se refiere a su com plejidad com o en el tipo de políticas que pueden im plem entarse sobre ellos. En ninguno de los dos sistem as se utiliza am pliam ente, pero constitu­ yen casos de prueba interesantes para verificar los análisis teóricos relativos'”a los m ecanism os de protección.

Capítulo 14 Protección

14.8.1 Un ejemplo: Hydra H ydra es un sistem a de protección basado en capacidades que proporciona una consid erable; xibilidad. El sistem a conoce e interpreta un conjunto fijo de posibles derechos de acceso. Este derechos incluyen form as básicas de acceso tales com o el derecho de leer, escribir o ejecutar segm ento de m em oria. A dem ás, un usuario (del sistem a de protección) puede declarar otros de chos. La interpretación de los derechos definidos por el usuario se lleva a cabo exclusivam ente i el program a de usuario, pero el sistem a proporciona protección de acceso para el uso de est derechos, adem ás de para el uso de los derechos definidos por el sistema. Estas característica constituyen un avance significativo en la tecnología de protección. Las operaciones sobre los objetos se definen procedim entalm ente. Los procedim ientos que? im plem entan tales operaciones son en sí m ism os una form a de objeto y se accede a ellos indirec? tam ente a través de capacidades. Los nom bres de los procedim ientos definidos por el usuaricr _ deben ser identificados ante el sistem a de protección para que éste pueda gestionar los objetos defff tipo definido por el usuario. C uando se da a conocer a H ydra la definición de un objeto, los nom¡¡| bres de las operaciones que pueden realizarse en este tipo de objetos pasan a ser derech os a u x i l l liares. Los derechos auxiliares pueden describirse en una capacidad para una instancia del tipo objeto. Para que un proceso realice una operación sobre un objeto tipado, la capacidad que tienág para ese objeto deberá contener entre sus derechos auxiliares el nom bre de la operación que se estl|¡ invocando. Esta restricción perm ite discrim inar los derechos de acceso instancia por instancia proceso por proceso. H ydra tam bién proporciona un m ecanism o de am p lificació n de derechos. Este esquem a ¡ m ite certificar un procedim iento com o de confianza para que actúe sobre un parám etro form al dc un tipo especificado por cu enta de cualquier proceso que disponga de un derecho para ejecutar e procedim iento. Los derechos que m antiene un procedim iento de confianza son independientes dg los derechos-que tenga el proceso que realiza la invocación y pueden ser m ucho m ás amplios. Si em bargo, dicho procedim iento no debe ser considerado com o universalm ente de confianza (e procedim iento no está autorizado, por ejem plo, a operar sobre otros tipos de objetos) y ese carácu l ter de confianza no debe extenderse a ningún otro procedim iento o segm ento de program a que;í pueda ser ejecutado por un proceso. T#| La am plificación perm ite que los procedim ientos de im plem entación accedan a las variables de representación de un tipo abstracto de datos. Por ejem plo, si un proceso tiene una capacidad so b re ' un objeto tipado A, esta capacidad puede incluir un derecho auxiliar para invocar cierta operación n P pero no incluiría ninguno de los denom inados derechos del kernel, com o por ejem plo leer, escri- . bir o ejecutar el segm ento que representa a A. Dicho tipo de capacidad proporciona a un proceso* una form a de acceso indirecto (a través de la operación P) a la representación de A, pero sólo para : propósitos específicos. Cuando un proceso invoca la operación P sobre un objeto A, sin em bargo, la capacidad para acceder a A puede ser am plificada al pasar el control al cuerpo de código de P. Esta am plificación ; puede ser necesaria para perm itir a P el derecho de acceso al segm ento de alm acenam iento que representa a A, para Ím plem entar la operación que P define sobre el tipo abstracto de datos. El cuerpo de código de P puede ser autorizado para leer o escribir directam ente en el segm ento de A, incluso aunque el proceso que realizó la invocación no pueda. Al volver de P, se restaura a su estado original no am plificado la capacidad sobre A. Este caso representa un ejem plo típico en el que los derechos de acceso que un proceso tiene a un segm ento protegido deben cam biar dinámi-„ cam ente, dependiendo de la tarea que haya que realizar. El ajuste dinám ico de los derechos se realiza para garantizar la coherencia de una abstracción definida por el program ador. La amplifi­ cación de derechos puede enunciarse explícitam ente en la declaración de un tipo abstracto para darla a conocer al sistem a operativo Hydra. Cuando un usuario pasa un objeto com o argum ento a un procedim iento, podem os necesitar garantizar que el procedim iento no pueda m odificar el objeto. Podem os ím plem entar esta restric­ ción fácilm ente pasando un derecho de acceso que no incluya el derecho de m odificación (escri­ tura). Sin ém bargo, si puede tener lugar una am plificación, es posible que se restablezca el derecho de m odificación. De este m odo, el requisito de protección definido por el usuario podría

14.8 Sistemas basados en capacidades

499

ser puenteado. En general, por su puesto, el usuario puede confiar en que un procedim iento rea­ lice su tarea correctam ente. D e todos m odos, esta suposición no siem pre es adecuada, debido a los errores hardw are o softw are. H ydra resuelve este problem a restringiendo las am plificaciones. El m ecanism o de llam ada a procedim ientos de H ydra fue diseñado com o solución directa al problem a de los subsistem as m utuam ente sospechosos. Este problem a se define de la form a siguiente: suponga que se proporciona un program a que puede ser invocado como servicio por varios usuarios distintos (por ejem plo, una rutina de ordenación, un com pilador o un juego). Cuando los usuarios invocan este program a de servicio, asum en el riesgo de que el program a fu n ­ cione incorrectam ente y dañe los datos proporcionados o retenga algunos derechos de acceso a dichos datos para usarlos (sin autorización) posteriorm ente. De form a sim ilar, el programa de ser­ vicio puede tener algunos archivos privados (por ejem plo, para propósitos de contabilización) a los que no debe poder acceder directam ente el program a de usuario que realiza la invocación. H ydra proporciona m ecanism os para tratar directam ente este problema. Los subsistem as de H ydra se construyen por encim a de su kernel de protección y pueden requerir protección de sus propios com ponentes. U n subsistem a interactúa con el kernel a través de una serie de llam adas a un conjunto de prim itivas definidas por el kernel que establecen dere­ chos de acceso a los recursos definidos por el subsistem a. El diseñador del subsistem a puede defi­ nir políticas que regulen el uso de estos recursos por parte de los procesos de usuario, pero las políticas se im ponen utilizando la protección estándar de acceso perm itida por el sistem a de capa­ cidades. U n program ador puede hacer un uso directo del sistem a de protección después de fam iliari­ zarse con sus características m ediante el m anual de referencia apropiado. Hydra proporciona una am plia biblioteca de procedim ientos definidos por el sistem a que pueden ser invocados por los program as de usuario. U n usuario del sistem a H ydra incorporará explícitam ente llamadas a estos procedim ientos del sistem a en el código de sus program as o utilizará un traductor de program as que disponga de una interfaz con Hydra.

14.8.2 Un ejemplo: sistem a CAP de Cam bridge En el sistem a CAP de C am bridge se ha adoptado un enfoque distinto para la im plem entación del m ecanism o de protección basado en capacidades. El sistem a de capacidades de CAP es m ás sim ­ ple y superficialm ente m enos potente que el de Hydra. Sin em bargo, un exam en más atento m ues­ tra que tam bién puede usarse este sistem a para proporcionar una protección segura de los objetos definidos por el usuario. CAP dispone de dos tipos de capacidades. El tipo normal se denom ina capacidad de datos y puede usarse para proporcionar acceso a los objetos, pero los únicos d ere­ chos proporcionados son los derechos norm ales de lectura, escritura y ejecución de los segm entos de alm acenam iento individuales asociados con el objeto. Las capacidades de datos son interpre­ tadas m ediante m icrocódigo incluida en la m áquina CAP. El segundo tipo de capacidades se denom ina capacidad softw are y está protegido, pero no interpretado, por el m icrocódigo de CAP. Para interpretar estas capacidades se utiliza un proced i­ m iento protegido (es decir, privilegiado) que puede ser escrito por un program ador de aplicacio­ nes com o parte de un subsistem a. Con cada procedim iento protegido se asocia un tipo particular de am plificación de derechos. Cuando esté ejecutando el cuerpo de código de dicho tipo de pro­ cedim iento, un proceso adquirirá tem poralm ente el derecho a leer o escribir el contenido de una capacidad softw are. Este tipo específico de am plificación de derechos se corresponde con una im plem entación de las prim itivas s e a l y u n s e a l utilizadas para las capacidades. Por supuesto, este privilegio sigue estando sujeto a un m ecanism o de verificación de tipos para garantizar que sólo se pasen a uno de estos procedim ientos capacidades softw are para un tipo abstracto especi­ ficado. N o se asigna una confianza universal a ningún segm ento de código distinto del propio m icrocódigo de la m áquina CAP (véanse las referencias en las N otas bibliográficas). La interpretación de una capacidad softw are se deja com pletam ente al arbitrio del subsistem a, a través de los procedim ientos protegidos que contenga. Este esquem a perm ite im plem entar diversas políticas de protección. Aunque un program ador puede definir sus propios procedim ien­ tos protegidos (cualquiera de los cuales puede ser incorrecto), la seguridad del sistema global no

500

Capítulo 14 Protección

puede verse com prom etida. El sistem a básico de protección no perm itirá que un procedimiento protegido definido por el usuario y no verificado acceda a ningún segm ento de alm acenam iento (o capacidad) que no pertenezca al entorno de protección en el que respira. La consecuencia más seria de u n procedim iento protegido inseguro será, de este m odo, un fallo de protección del sub­ sistem a del que dicho procedim iento sea responsable. Los diseñadores del sistem a CAP han podido observar que el uso de capacidades softw are les perm itía econom izar considerablem ente a la hora de form ular e im plem entar políticas de protección adecuadas a los requisitos de los recursos abstractos. Sin em bargo, un diseñador de subsiste­ m as que quiera hacer uso de esta funcionalidad no puede sim plem ente estudiar un m anual de referencia, com o en el caso de H ydra. En lugar de ello, deberá aprender los principios y técnicas de protección, ya que el sistem a no proporciona ninguna biblioteca de procedim ientos.

14.9 Protección basada en el lenguaje El grado de protección que se proporciona en los sistem as inform áticos existentes suele conseguir­ se m ediante un kem el del sistem a operativo, que actúa com o agente de seguridad para inspeccio -1 nar y validar cada intento de acceder a un recurso protegido. Puesto que una validación de acceso ^ exhaustiva es potencialm ente una fuente de gasto adicional considerable de recursos de procesa-) m iento, debem os proporcionar a este m ecanism o un soporte hardw are para reducir el coste de cada validación o debem os aceptar que el diseñador del sistem a llegue a ciertos com prom isos en> lo que respecta a los objetivos de la protección. Satisfacer todos esos objetivos es difícil si la flexi-j bilidad para im plem entar las políticas de protección está restringida por los m ecanism os dél soporte proporcionados o si los entornos de protección deben hacerse m ás com plejos de lo nece­ sario para garantizar una m ayor eficiencia de operación. 4 A m edida que ha aum entado la com plejidad de los sistem as operativos, y particularm ente a) m edida que éstos han tratado de proporcionar interfaces de usuario de m ayor nivel, los objetivosde la protección se han hecho m ucho m ás refinados. Los diseñadores de sistem as de protección, han aprovechado al m áxim o una serie de ideas que tienen su origen en los enlaces de program a­ ción y especialm ente en los conceptos de tipos abstractos de datos y objetos. Hoy en día, los siste­ mas de protección no sólo se ocupan de la identidad de un recurso al que se intente acceder, sino tam bién de la naturaleza funcional de dicho acceso. En los sistem as de protección m ás modernos, la preocupación por la función que se está invocando va m ás allá de un conjunto de funciones definidas por el sistem a, com o por ejem plo los m étodos estándar de acceso a archivos, para incluir tam bién las funciones que el usuario pueda haber definido. Las políticas de uso de los recursos tam bién pueden variar, dependiendo de la aplicación, y pueden estar sujetas a cam bios a lo largo del tiempo. P or estas razones, la protección ya no puede ser considerada exclusivam ente com o una preocupación del diseñador del sistem a operativo, sino que tam bién debe estar disponible com o herram ienta para que la use el diseñador de aplicacio­ nes, de m odo que los recursos de un subsistem a de aplicación puedan estar protegidos frente a m odificaciones o frente a la influencia de posibles errores.

14.9.1 Imposición de reglas basadas en com pilador Es aquí donde entran dentro del panoram a los lenguajes de program ación. Especificar el control de acceso deseado a un recurso com partido con un sistem a no es otra cosa que realizar un enun­ ciado declarativo acerca del recurso. Este tipo de enunciado puede integrarse en un lenguaje extendiendo su funcionalidad de definición de tipos. Cuando se declara la protección ju n to con la definición del tipo de datos, el diseñador de cada subsistem a puede especificar sus requisitos de protección, así com o su necesidad de utilizar otros recursos dentro de un sistema. D icha especifi­ cación debe proporcionarse directam ente a m edida que se com pone un program a y en el propio lenguaje en el que el program a esté escrito. Esta técnica tiene varias ventajas significativas.

1 . Las necesidades de protección sim plem ente se declaran, en lugar de program arlas com o una secuencia de llam adas a procedim ientos de un sistem a operativo.’

14.9 Protección basada en el lenguaje

501

2. Los requisitos de protección pueden enunciarse independientem ente de la funcionalidad proporcionada por un sistem a operativo concreto. 3. El diseñador de un subsistem a no tiene por qué proporcionar los m edios para im poner el m ecanism o de protección. 4. La notación declarativa resulta bastante natural, porque los privilegios de acceso están estre­ cham ente relacionados con el concepto lingüístico de tipo de datos. • La im plem entación de u n lenguaje de program ación puede proporcionar diversas técnicas para im poner la protección, pero todas estas técnicas dependen hasta cierto punto del soporte pro­ porcionado por la m áquina subyacente y por su sistem a operativo. P or ejem plo, suponga que se utiliza u n lenguaje para generar un código que deba ejecutarse sobre el sistem a CAP de Cam bridge. En este sistem a, cada referencia al alm acenam iento que se realice sobre el hardware subyacente tiene lugar de m anera indirecta a través de una capacidad. Esta restricción im pide a cualquier proceso acceder a un recurso que esté situado, en un m om ento dado, fuera de su entor­ no de protección. Sin em bargo, un program a puede im poner restricciones arbitrarias en lo que respecta al m odo en que u n recurso puede utilizarse durante la ejecución de u n segm ento de códi­ go concreto. Podem os im plem entar dichas restricciones fácilm ente utilizando las capacidades softw are proporcionadas por CAP. L a im plem entación del lenguaje puede proporcionar procedi­ m ientos protegidos estándar para interpretar las capacidades softw are que lleven a la práctica las políticas de protección que puedan especificarse en el lenguaje. Este esquem a pone la especifica­ ción de políticas a disposición de los program adores, al m ism o tiem po que les libera de tener que im plem entar la im posición de dichas políticas. Incluso si un sistem a no proporciona un kem el de protección tan potente com o los de H ydra o CAP, sigue habiendo m ecanism os disponibles para im plem entar las especificaciones de protección dadas en un lenguaje de program ación. La distinción principal es que la seguridad de esta protec­ ción no será tan grande com o la que podría obtenerse m ediante un kem el de protección, porque el m ecanism o debe confiar en un conjunto m ayor de suposiciones acerca del estado operacional del sistem a. U n com pilador puede separar las referencias para las que pueda certificar que no se va a producir ninguna violación de protección de aquellas para las que una violación podría ser posi­ ble, y puede tratar de m anera diferente am bos tipos de referencias. La seguridad proporcionada por este tipo de protección descansa en la suposición de que el kem el generado por el com pilador no será m odificado antes de su ejecución o durante la misma. Entonces, ¿cuáles son las ventajas relativas de im poner el m ecanism o de protección basándose exclusivam ente en un kernel, por oposición a im poner esos m ecanism os principalm ente mediante un com pilador? • Seguridad. La im posición de los m ecanism os de protección m ediante un kernel proporcio­ na un m ayor grado de seguridad del propio sistem a de protección, si la com param os con el procedim iento de generación de código de com probación de la protección m ediante un com pilador. En un esquem a basado en com pilador, la seguridad descansa en la corrección del traductor, en algún m ecanism o subyacente de gestión del alm acenam iento que proteja los segm entos desde los que se ejecuta el código com pilado y, en últim o térm ino, en la segu­ ridad de los archivos desde los que se carga un program a. A lguna de estas consideraciones se aplica tam bién a un kernel de protección con soporte softw are, pero en m enor m edida, porque el k em el puede residir en segm entos de alm acenam iento físico fijos y puede ser car­ gado exclusivam ente desde un archivo designado. Con un sistem a de capacidades basado en etiquetas, en el que todos los cálculos de direcciones se realizan por hardware o m edian­ te un m icroprogram a fijo, es posible incluso obtener un grado m ayor de seguridad. La pro­ tección basada en hardw are tam bién es relativam ente inm une a las violaciones de protec­ ción que puedan tener lugar com o resultado de fallos de funcionam iento en el hardw are o el softw are del sistem a.

f

• F lexibilid ad . Existen lím ites en lo que respecta a la flexibilidad de un kernel de protección a la hora de im plem entar una política definida por el usuario, aunque el kem el puede suministrar la funcionalidad adecuada para que el sistem a im ponga sus propias políticas. Con

Capítulo 14 Protección 8

un lenguaje de program ación, puede declararse la política de protección y puede imponer­ se la m ism a según sea necesario en cada im plem entación. Si un lenguaje no proporciona la, > suficiente flexibilidad, puede extenderse o sustituirse con un m enor im pacto sobre un siste-. m a que esté en funcionam iento que el que se experim entaría si se m odificara el kernel del sistem a operativo.

• Eficiencia. La m ayor eficiencia se obtiene cuando la im posición de los m ecanism os de pro­ tección está soportada directam ente por el hardw are (o el m icrocódigo). Si se necesitasoporte softw are, la im posición de la protección basada en el lenguaje tiene la ventaja de ” que los accesos de carácter estático pueden verificarse fuera de línea en tiem po de compila­ ción. A sim ism o, puesto que un com pilador inteligente puede ajustar el m ecanism o de im posición para satisfacer cada necesidad específica, a m enudo puede evitarse el gasto fijo adicional de procesam iento im plicado por las llam adas al kernel. En resum en, la especificación de los m ecanism os de la protección en un lenguaje de progra­ m ación perm ite describir a alto nivel las políticas de asignación y uso de los recursos. La implem entación de un lenguaje puede proporcionar softw are para la im posición de los m ecanism os de protección en aquellos casos en que no haya disponible un m ecanism o autom ático de comproba­ ción con soporte hardw are. A dem ás, pueden interpretar las especificaciones de protección para generar llam adas al sistem a de protección proporcionado por el hardw are y el sistem a opera-, tivo. U na form a de hacer que la protección esté disponible para el program a de aplicación es m ediante el uso de una capacidad softw are que pueda utilizarse com o objeto del procesamiento: Inherente a este concepto está la idea de que ciertos com ponentes de program a pueden tener el privilegio de crear o exam inar estas capacidades softw are. Un program a de creación de capacida­ des sería capaz de ejecutar una operación prim itiva que sellara una estructura de datos, haciendo que sus contenidos sean inaccesibles para todos los com ponentes de program a que no dispongan del privilegio de sellar o elim inar ql sello de dicha estructura. Esos program as no privilegiados pueden copiar su estructura de datos o pasar su dirección a otros com ponentes de program a, pero no pueden acceder a su contenido. La razón de introducir tales capacidades softw are es incluir un m ecanism o de protección dentro del lenguaje de program ación. El único problem a con este con­ cepto, tal com o está propuesto, es que el uso de las operaciones s e a l y u n s e a l (definición y eli­ m inación del sello) adoptan una técnica procedim ental para especificar la protección. La notación no procedim ental o declarativa parece preferible a la hora de poner a disposición del programa­ dor de aplicaciones los m ecanism os de protección. Lo que necesitam os es un m ecanism o seguro y dinám ico de control de acceso para distribuir entre los procesos de usuario las capacidades relativas a los recursos del sistema. Para contribuir a la fiabilidad global del sistem a, el m ecanism o de control de acceso debe ser seguro de utilizar. Para ser útil en la práctica, tam bién debe ser razonablem ente eficiente. Este requisito ha conduci­ do al desarrollo de una serie de estructuras de lenguaje que perm iten al program ador declarar diversas restricciones relativas al uso de un recurso específico gestionado (véanse las apropiadas referencias en las N otas bibliográficas). Estas estructuras proporcionan m ecanism os para tres funciones: 1. D istribución de las capacidades de m anera segura y eficiente entre los procesos cliente: en particular, los m ecanism os garantizan que un proceso de usuario sólo pueda usar el recurso gestionado si se le ha concedido una capacidad sobre dicho recurso. 2. Especificar el tipo de operaciones que un proceso concreto pueda invocar sobre un recurso asignado (por ejem plo, un lector de un archivo sólo debe poder leer el archivo, m ientras que un escritor debe poder tanto leer com o escribir el archivo): no debe ser necesario conceder el m ism o conjunto de derechos a todos los procesos de usuario y debe ser im posible que un proceso pueda am pliar su conjunto de derechos de acceso, excepto con la autorización del m ecanism o de control de acceso. 3. Especificar el orden en que un proceso concreto puede invocar las diversas operaciones sobre un recurso (por ejem plo, antes de poder leer un archivo hay que abrirlo). Debe ser posible

14.9 Protección basada en el lenguaje

503

asignar a dos procesos restricciones distintas en lo que respecta al orden en que pueden invo­ car las operaciones relativas al recurso asignado. La incorporación de conceptos de protección en los lenguajes de program ación, como herra­ m ienta práctica para el diseño de sistem as, está todavía en su infancia. La protección constituirá probablem ente una m ayor preocupación para los diseñadores de nuevos sistem as con arquitectu­ ras distribuidas y requisitos cada vez m ás estrictos en lo que respecta a la seguridad de los datos. Es entonces cuando se reconocerá de m anera m ás generalizada la im portancia de notaciones de lenguaje adecuadas m ediante las cuales expresar los requisitos de protección.

14.9.2 Protección en Java Com o Java fue diseñado para ejecutarse en un entorno distribuido, la m áquina virtual de Java (o JVM) tiene m uchos m ecanism os de protección integrados. Los program as Java están com puestos

por clases, cada una de las cuales es una colección de cam pos de datos y funciones (denom inadas m étodos) que operan sobre esos cam pos. La JVM carga una clase en respuesta a una solicitud de creación de instancias (u objetos) de dicha clase. U na de las características m ás novedosas y útiles de Jav a es su soporte para cargar dinám icam ente clases que no sean de confianza a través de una red y para ejecutar clases que desconfían m útuam ente unas de otras dentro de una m ism a JVM. D ebido a estas capacidades de Java, la protección es una de las principales preocupaciones. Las clases que se ejecutan en una m ism a JVM pueden tener diferentes orígenes y pueden no gozar de un grado igual de confianza. Com o resultado, resulta insuficiente garantizar la protección con la granularidad de los procesos JVM. Intuitivam ente, el que u na solicitud de apertura de un archivo deba ser perm itida dependerá, generalm ente, de la clase que haya efectuado 1a-solicitud. El siste­ m a operativo carece de este conocim iento. Por tanto, dichas decisiones de protección se gestionan dentro de la JVM. Cuando la JVM carga una clase, la asigna a u n dom inio de protección que proporciona los perm isos correspondientes a esa clase. El dom inio de protección al que se asigna la clase dependerá de la URL desde la que se cargara la clase y de las firm as digitales que contenga el archivo de clases (hablaremos de las fir­ mas digitales en la Sección 15.4.1.3). U n archivo confígurable de política determ ina los perm isos concedidos al dom inio (y a sus clases). Por ejem plo, las clases cargadas desde un servidor de con ­ fianza pueden colocarse en un dom inio de protección que nos perm ita acceder a archivos situa­ dos en el directorio principal del usuario, m ientras que las clases cargadas desde un servidor que no sea de confianza pueden no tener ningún perm iso de acceso a archivos. Puede ser com plicado para la JVM determ inar qué clase es responsable de una solicitud de acceso a un recurso protegido. Los accesos se realizan a m enudo indirectam ente, m ediante biblio­ tecas del sistem a u otras clases. Por ejem plo, considere una clase que no esté autorizada para abrir conexiones de red y piense qué sucede si esa clase invoca una biblioteca del sistem a para solicitar la carga del contenido de una URL. La JVM debe decidir si abrir o no la conexión de red de acuer­ do con esta solicitud. ¿Pero qué clase debe utilizarse para determ inar si hay que perm itir la cone­ xión, la aplicación o la biblioteca del sistem a? La filosofía adoptada en Java consiste en requerir que la clase de la biblioteca permita explíci­ tam ente la conexión de red para cargar la URL solicitada. D e form a más general, para poder acce­ der a un recurso protegido, alguno de los m étodos en la secuencia de llam adas que dio com o resultado la solicitud deberá perm itir explícitam ente el privilegio de acceder al recurso. Al hacer esto, dicho m étodo se hace responsable de la solicitud y, presum iblem ente, realizará tam bién las com probaciones necesarias para garantizar que dicha solicitud sea segura. Por supuesto, no todos los m étodos están autorizados a establecer un privilegio; un m étodo puede establecer un privile­ gio sólo si su clase se encuentra dentro de un dom inio de protección que a su vez está autorizado a ejercer el privilegio. Esta técnica de im plem entación se denom ina in sp ecció n de la pila. Cada hebra de la JVM tie ­ ne una pila asociada con sus invocaciones actuales a m étodos. Cuando no pueda confiar en aquel que realizó la invocación, un m étodo ejecutará una solicitud de acceso d e n tro de u n bloque d o P r i v i l e g e d para conseguir el acceso a un recurso protegido directa o in d ire cta m e n te . d o P r i v i l e g e d () es un m étodo estático en la clase the A c c e s s C o n t r o l l e r al que se le p a sa

504

Capítulo 14 Protección

una clase con un m étodo ru n () al que haya que invocar. Cuando se entra en el bloql d o P r i v i l e g e d , se inserta la correspondiente anotación en la pila de este m étodo para indicar e hecho. A continuación, se ejecuta el contenido del bloque. Cuando se solicita posteriorm ente r acceso a un recurso protegido, bien por este m étodo o por otro m étodo al que éste haya llamadSL se utiliza una llam ada a c h e c k P e r m i s s i o n s () para invocar la inspección de la pila con el firu §¡ determ inar si la solicitud debe autorizarse. La inspección exam ina el contenido de la pila dejjll hebra, em pezando por la entrada añadida m ás recientem ente y continuando hacia la más antiguflj Si se encuentra prim ero una entrada de la pila que tenga la anotación d o P r i v i l e g e d ( ) , entqf|| ces c h e c k P e r m i s s i o n s () volverá inm ediatam ente y de form a silenciosa, perm itiendo el acce¡ so. Si se encuentra prim ero una entrada de pila para la que el acceso no esté perm itido, basándose* en el dom inio de protección de la clase del m étodo, entonces c h e c k P e r m i s s i o n s () genera un|¡ excepción A c c e s s C o n t r o l E x c e p t i o n . Si se term ina la inspección de la pila sin encontrar nuil guno de estos dos tipos de entradas, entonces el que el acceso se perm ita dependerá de la im p lP m entación (por ejem plo, algunas im plem entaciones de la JVM pueden perm itir el acceso m ientra! que otras pueden denegarlo). i| j El m ecanism o de inspección de la pila se ilustra en la Figura 14.9. Aquí, el m étodo g u i {) d j una clase en el dom inio de protección correspondiente a las untrusted applets (applets no de con¡ fianza) realiza dos operaciones, prim ero una operación g e t () y luego una o p e n (). La prime r ! es una invocación del m étodo g e t () de una clase cLel dom inio de protección URL loader, al q u ese perm ite abrir con o p e n () sesiones en sitios situados en el dom inio l u c e n t . com, en particulal en un servidor proxy denom inado p r o x y . l u c e n t . com para extraer páginas URL. Por esta razón! la invocación a g e t (} de la applet no de confianza será autorizada: la llam ada a c h e c k g P e r m i s s i o n s () en la biblioteca de red encontrará la entrada de pila correspondiente al m é to a l g e t ( ) , que realizó su llam ada a o p en () en un bloque d o P r i v i l e g e d . Sin em bargo, la invoca^ ción a o p e n () por parte de la applet no de confianza generará una excepción, porque la llamada a c h e c k P e r m i s s i o n s O no encontrará ninguna anotación d o P r i v i l e g e d antes de encontrai la entrada de pila correspondiente al m étodo g u i (). ,J§| Por supuesto, para que el m ecanism o de inspección de pila funcione, un program a no defcje poder m odificar las anotaciones de su propia pila ni realizar ningún otro tipo de m anipulación ele la pila. Esta es una de las diferencias m ás im portantes entre Java y m uchos otros lenguajes (incluí yendo C++). U n program a Jav a no puede acceder directam ente a la m emoria. En lugar de elíc| sólo puede m anipular un objeto para el que disponga de una referencia. Las referencias no pue­ den ser im itadas y las m anipulaciones sólo se realizan m ediante interfaces bien definidas. El resj peto de estas reglas se im pone m ediante una sofisticada colección de com probaciones que se llevan a cabo en tiem po de carga y en tiem po de ejecución. Com o resultado, un objeto no puede m anipular su pila de ejecución, porque no puede obtener una referencia a la pila ni a otros com­ ponentes del sistem a de protección. D e m anera m ás general, las com probaciones de tiem po de carga y d e tiem po de ejecución de Java im ponen una seguridad de los tipos de las clases Java. La seguridad de los tipos garantiza

dom iniode protección: perm iso deSocket: ciase:

Figura 14.9 inspección de la pila.

Ejercicios

505

que las clases no puedan tratar los enteros com o punteros, no puedan escribir m ás allá del final de una m atriz ni acceder a la m em oria de ninguna otra m anera arbitraria. M ás bien, un program a sólo puede acceder a un objeto a través de los m étodos definidos para dicho objeto m ediante su clase. En esto es en lo que se basa la protección de Java, ya que perm ite a las clases encapsular de m anera efectiva y proteger sus datos y m étodos frente a otras clases cargadas en la m ism a JVM. Por ejem plo, puede definirse una variable com o p r í v a t e de m odo que sólo pueda acceder a ella la clase que la contiene, o puede definírsela com o p r o t e c t e d para que sólo puedan acceder a ella la clase que la contiene, las subclases de esa clase o las clases contenidas en el m ism o paquete. La seguridad de tipos garantiza que puedan im ponerse estas restricciones.

14.10 Resumen Los sistem as inform áticos contienen m uchos objetos y estos objetos necesitan protegerse frente a posibles m alos usos. Los objetos pueden ser hardw are (como la m em oria, el tiem po de CPU y los dispositivos de E /S ) o softw are (como los archivos, program as y semáforos). U n derecho de acce­ so es el perm iso para realizar una operación sobre un objeto. U n dom inio es un conjunto de dere­ chos de acceso. Los procesos se ejecutan en dom inios y pueden usar cualquiera de los derechos de acceso del dom inio para acceder a los objetos y m anipularlos. D urante su ciclo de vida, un proce­ so puede estar lim itado a un dom inio de protección o se le puede perm itir que conm ute de un dom inio de protección a otro. La m atriz de acceso es un m odelo general de protección que proporciona un m ecanism o que no im pone ninguna política concreta de protección al sistem a ni a sus usuarios. La separación entre política y m ecanism o es una im portante propiedad de diseño. La m atriz de acceso es una m atriz dispersa. N orm alm ente se la im plem enta m ediante listas de acceso asociadas con cada objeto o m ediante listas de capacidades asociadas con cada dom inio. Podemos incluir m ecanism os de protección dinám icos dentro del m odelo de m atriz de acceso considerando los dom inios y la propia m atriz de acceso com o objetos. La reagrupación de dere­ chos de acceso en un m odelo dinám ico de protección es norm alm ente más fácil de im plem entar con un esquem a de listas de acceso que con uno basado en listas de capacidades. Los sistem as reales están m ucho más lim itados que el m odelo general y tienden a proporcio­ nar protección exclusivam ente para los archivos. UNIX es bastante representativo, y proporciona protección de lectura, escritura y ejecución de m anera separada para el propietario, el grupo y el público general de cada archivo. MULTICS utiliza una estructura de anillos adem ás del m ecanism o de protección de acceso a archivos. Hydra, el sistem a CAP de Cam bridge y M ach son sistem as basados en capacidades que am plían la protección a los objetos softw are definidos por el usuario. Solaris 10 im plem enta el principio del m ínim o privilegio m ediante un control de acceso basado en roles, que es una form a de m atriz dé acceso. ~ La protección basada en lenguaje proporciona una capacidad de arbitraje de solicitudes y pri­ vilegios con una granularidad m ás fina de la que el sistem a operativo es capaz de proporcionar. Por ejem plo, una m ism a JVM Java puede ejecutar varias hebras, cada una de ellas en una clase de protección diferente. Java aplica a las solicitudes de recursos un m ecanism o sofisticado de inspec­ ción de la pila y los m ecanism os de seguridad de tipos del lenguaje para im poner los m ecanism os de protección.

Ejercicios 14.1

Considere el esquem a de protección en anillos de MULTICS. Si quisiéram os im plem entar las llamadas al sistem a de un sistema operativo típico y alm acenarlas en un segm ento asocia­ do con el anillo 0, ¿cuáles deberían ser los valores alm acenados en el cam po de anillo del descriptor del segm ento? ¿Qué pasa durante una llam ada al sistem a cuando un proceso que se ejecuta en un anillo de número m ás alto invoca un procedim iento del anillo 0?

14.2

Podría utilizarse la m atriz de control de acceso para determ inar si un proceso puede con ­ m utar de, por ejem plo, el dominio A al dom inio B y disfrutar de los privilegios de acceso

>

506

Capítulo 14 Protección

del dom inio B. ¿Es esta técnica equivalente a incluir los privilegios de acceso del dominio S s en los del dom inio A? =-i|| 14.3

Considere un sistem a inform ático en el que los estudiantes sólo puedan ejecutar progra de ju egos entre las 10 de la noche y las 6 de la m añana, en el que los profesores puedan ejé|¡ cutarlos entre las 5 de la tarde y las 8 de la m añana y en el que el personal del centro de cállí culo pueda ejecutarlos en cualquier momento. Sugiera un esquem a para im plem entar es! política de m anera eficiente.

14.4

¿Q ué características hardw are se necesitan en un sistem a inform ático para poder m anipulé lar de m anera eficiente las capacidades? ¿Pueden utilizarse estas características hardw are^ para la protección de m em oria? - 3Íf

14.5

Explique las fortalezas y debilidades de un sistem a que im plem ente una m atriz de accescfÜÜ utilizando listas de acceso asociadas con los objetos.

14.6

Explique las fortalezas y debilidades de un sistem a qué im plem ente una m atriz de acceáoSf utilizando capacidades asociadas con los dominios.

14.7

Explique pbr.qü é un sistem a basado en capacidades com o H ydra proporciona una mayo? flexibilidad que el esquem a de protección en anillos a la hora de im poner políticas de pro-Sj ; tección. ~ ¿

14.8

Explique la necesidad del m ecanism o de am plificación de derechos de Hydra. Compare^ este m ecanism o con las llam adas inter-anillos en un esquem a de protección en anillos. —

14.9

¿Q ué es el principio de la necesidad de conocer? ¿Por qué es im portante que un sistema deyj protección se ajuste a este principio? -

14.10 Explique cuáles de los siguientes sistem as perm iten a los diseñadores de m ódulos im p o riáli el principio de la necesidad de conocer: 'y l a. El esquem a de protección en anillos de MULTICS.

’^

b. El sistem a de capacidades de Hydra.

r

J

-

-q-Jtd

11

c. El esquem a de inspección de pila d e la JVM. 14.11 D escriba cóm o se vería afectado el modelo de protección de Java si se perm itiera a un pro--gram a Java m odificar directam ente las anotaciones incluidas en su entrada de pila. 14.12 ¿En qué sentido son sim ilares el m odelo de m atriz de acceso y el m odelo de control de acce-' so basado en roles? ¿En qué sentido difieren? 14.13 ¿C óm o ayuda a la creación de sistem as de protección el principio del m ínim o privilegio?

;

14.14 ¿C óm o pueden los sistem as que im plem entan el principio del m ínim o p riv ile g io te n e r fallos , de protección que conduzcan a violaciones de seguridad? sS

Notas bibliográficas El m odelo de protección basado en una m atriz de acceso de dom inios y objetos fue desarrollado por L am pson [1969] y Lam pson [1971], Popek [1974] y Saltzer y Schroeder [1975] proporcionan ' excelentes panorám icas sobre el tem a de la protección. H arrison et al. [1976] utilizó una versión form al de este m odelo para poder dem ostrar m atem áticam ente las propiedades de un sistema de protección. El concepto de capacidad evolucionó a partir de las denom inadas palabras de código de Iliffe y Jodeit, qu e se im plem entaron en la com putadora de Rice U niversity (Iliffe y Jodeit [1962]). El tér­ m ino capacidad fue introducido por Dermis y H om [1966]. El sistem a Hydra fue descrito por Wulf et al. [1981], m ientras que el sistem a CAP lo fue por N eedham y W alker [1977], O rganick [1972] analiza el sistem a de protección en anillos de MULTICS.

Notas bibliográficas

507

El tem a de la revocación se explora en Redell y Fabry [1974], Cohén y Jefferson [1975] y Ekanadham y Bem stein [1979], El principio de la separación entre política y m ecanism o fue defen­ dido por el diseñador de H ydra (Levin et al. [1975]). El problem a de confinam iento fue analizado por prim era vez por Lam pson [1973] y posteriorm ente fue exam inado por Lipner [1975]. El uso de lenguajes de alto nivel para especificar los controles de acceso fue sugerido por pri-rrtera vez por M orris [1973], que propuso el uso de las operaciones s e a l y u n s e a l que se expli­ ca en la Sección 14.9. Kieburtz y Silberschatz [1978], K ieburtz y Silberschatz [1983] y M cGraw y A ndrew s [1979] propusieron varias estructuras de lenguaje para im plem entar esquem as genera­ les de gestión dinám ica de recursos. Jones y Liskov [1978] analizaron cóm o puede incorporarse un esquem a estático de control de acceso en un lenguaje de program ación que soporte tipos abstrac­ tos de datos. El uso de un soporte m ínim o por parte del sistem a operativo para im poner los m eca­ nism os de protección fue defendido por el proyecto Exokernel (Ganger et al. [2002], K aashoek et al. [1997]). Las am pliabilidad del código del sistem a m ediante m ecanism os de protección basados en el lenguaje fue analizada en Bershad et al. [1995b], Otras técnicas para garantizar la protección incluyen la técnica denom inada de cajón de arena (Goldberg et al. [1996]) y la de aislam iento de los fallos softw are (W ahbe et al. [1993b]). Las cuestiones relativas a cóm o reducir la sobrecarga de procesam iento asociada con los m ecanism os de protección y a cómo perm itir el acceso de nivel de usuario a los dispositivos de red fue analizada en M cCanne y Jacobson [1993] y Basu et al. [1995]. Puede encontrar análisis más detallados del m ecanism o de inspección de pila, incluyendo com paraciones con otras técnicas de im plem entación de m ecanism os de seguridad en Java, en W allach et al. [1997] y G ong et al. [1997],

J-

. ■

'

f

\ \

i .!

X

S

Seguridad La protección, com o hemos explicado en el Capítulo 14, es estrictam ente un problem a interno: ¿cóm o proporcionam os un acceso controlado a los program as y a los datos alm acenados en un sis­ tema inform ático? La seguridad, por otro lado, requiere no sólo un adecuado sistem a de protec­ ción, sino tam bién tener en cuenta el entorno externo dentro del que opera el sistem a. U n sistem a de protección no será efectivo si la autenticación de los usuarios se ve com prom etida o si un pro­ gram a es ejecutado por un usuario no autorizado. Los recursos inform áticos deben protegerse frente a los accesos no autorizados, frente a la m odificación o destrucción m aliciosas y frente a la introducción accidental de incoherencias. Entre esos recursos podem os incluir la inform ación alm acenada en el sistem a (tanto datos com o códi­ go), así com o la CPU, la m em oria, los discos, las cintas y los sistem as de interconexión por red que form an la com putadora. En este capítulo, com enzarem os exam inando las form as en que los recur­ sos pueden ser m al utilizados de form a accidental o prem editada. A continuación, explorarem os uno de los factores principales en los que se basa la seguridad: la criptografía. Finalm ente, exam i­ narem os los m ecanism os que existen para defenderse de los ataques y detectarlos.

OBJETIVOS DEL CAPÍTULO • • • •

Analizar las amenazas a la seguridad y los tipos de ataques posibles. Explicar los fundamentos del cifrado, la autenticación y las funciones hash. Examinar los usos de la criptografía en el campo de la Informática. Describir las diversas contramedidas existentes para los ataques a los sistemas de seguridad.

15.1 El problem a de la seguridad En m uchas aplicaciones, m erece la pena dedicar un esfuerzo considerable a garantizar la seguri­ dad del sistem a inform ático. Los sistem as com erciales de gran envergadura que contengan datos de nóm inas u otros datos financieros constituyen objetivos muy codiciados por los delincuentes. A sim ism o, los sistem as que contengan datos relativos a las operaciones de una corporación pue­ den resultar de interés para los com petidores carentes de escrúpulos. A dem ás, la pérdida de tales datos, ya sea accidentalm ente o com o consecuencia del fraude, puede afectar seriam ente a la capa­ cidad de esa corporación para seguir funcionando. En el Capítulo 14 hem os exam inado los m ecanism os que el sistem a operativo puede propor­ cionar (con la adecuada ayuda por parte del hardw are) para perm itir a los usuarios proteger sus recursos, incluyendo los program as y los datos. Estos m ecanism os funcionan adecuadam ente m ientras que los usuarios respeten los usos previstos y el tipo de acceso que se hubiera pensado para esos recursos. Decim os que un sistem a es seguro si sus recursos se utilizan de la form a pre509

Capítulo 15 Seguridad

vista y si se accede a ellos tal com o se pretendía, en todas las circunstancias. D esafortunadam ente, no es posible conseguir una seguridad total; a pesar de ello, debem os prever m ecanism os para hacer que los fallos de seguridad constituyan la excepción, en lugar de la norm a. Las violaciones de seguridad o la m ala utilización de un sistem a pueden clasificarse en dos categorías: intencionadas (m aliciosas) o accidentales. Resulta m ás fácil protegerse frente a una m ala utilización accidental que frente a otra m aliciosa. Principalm ente, los m ecanism os de protec­ ción form an la base de la defensa frente a posibles accidentes. En la siguiente lista indicam os diversas form as de violaciones de seguridad accidentales y m aliciosas. Conviene observar que en nuestras explicaciones acerca de la seguridad utilizam os los térm inos intruso y cracker para desig­ nar a las personas que tratan de rom per los sistem as de seguridad. Asim ism o, una am enaza es la posibilidad de que exista una violación de seguridad, com o por ejem plo el descubrim iento de una vulnerabilidad, m ientras que un ataqu e es un intento de rom per la seguridad. • R uptura de la co n fid en cialid ad . Este tipo de violación im plica la lectura no autorizada de determ inados datos (o el robo de inform ación). Típicam ente, el objetivo de los intrusos es una ruptura de la confidencialidad. La captura de datos secretos en un sistem a o en un flujo de datos, com o por ejem plo inform ación relativa a tarjetas de crédito o inform ación perso­ nal para fingir una identidad ficticia, puede reportar al intruso un beneficio m onetario directo. • R uptura de la integridad. Este tipo de ataque implica la m odificación no autorizada de los datos. Estos ataques pueden, por ejem plo, provocar que se atribuya una cierta responsabi­ lidad a alguien que es inocente o que se m odifique el código fuente de una aplicación com ercial de cierta im portancia. • R uptura de la d isp o n ib ilid ad . Esta violación de seguridad im plica la destrucción n o auto­ rizada de datos. A lgunos atacantes prefieren causar daño y adquirir un cierto renom bre en lugar de obtener beneficios financieros. La sustitución de la página de entrada de un sitio w eb es un ejem plo com ún de este tipo de ruptura de la seguridad. • R obo de servicio. Este tipo de violación de seguridad im plica el uso no autorizado de recursos. Por ejem plo, un intruso (o un program a de intrusión) puede instalar un demonio en un sistem a que actúe com o servidor de archivos. • D en egación de servicio. Esta violación de seguridad im plica im pedir el uso legítim o del sistema. Los ataques de d en egación de servicio (DOS, denial-of-service) son en ocasiones accidentales. U n ejem plo com ún es. el de un programa gusano que atacó Internet hace ya unos cuantos años y que se transform ó en un ataque DOS cuando un error en el propio pro­ grama hizo que no se retardara su rápida disem inación. H ablarem os más en detalle de los ataques D O S en la Sección 15.3.3. Los atacantes utilizan diversos m étodos estándar en sus intentos de rom per la seguridad de los sistem as. El m ás com ún es la m ascarada, en la que un participante en una com unicación preten­ de ser otra persona (u otro host). M ediante la m ascarada, los atacantes rom pen la autenticación, es decir, la corrección de la identificación; com o consecuencia, pueden obtener tipos de acceso que norm alm ente no les estarían perm itidos o escalar sus privilegios, es decir, obtener privilegios de los que norm alm ente no podrían disfrutar. Otro ataque com ún consiste en reproducir un inter­ cam bio de datos previam ente capturado: los ataqu es de reproducción consisten en la repetición m aliciosa o fraudulenta de una transm isión de datos válida. En ocasiones, esa reproducción cons­ tituye el propio ataque, com o por ejem plo cuando se repite una solicitud para transferir dinero, pero frecuentem ente la reproducción se realiza en conjunción con una m od ificació n de m ensaje, que de nuevo suele tener com o objetivo aum entar los privilegios. Considere, por ejem plo, los daños que podrían producirse si se sustituyera la inform ación de un usuario legítim o por la de un usuario no autorizado en una solicitud de autenticación. Otro tipo de ataque es el ataque por in terp osición (m an -in -th e-m id d le), en el cual un atacante se introduce dentro del flujo de datos de una com unicación, haciéndose pasar por el em isor a ojos del receptor y viceversa. En una com unicación por red, un ataque por interposición puede estar precedido por un secuestro de

15.1 El problema de la seguridad

511

Normal

comunicación

S

í emisor

receptor

atacante

Mascarada

emisor

,0'ca co^'

receptor

atacante

atacante

Figura 15.1 Ataques estándar a la seguridad. sesió n (h ija c k in g ), en el que se intercepta una sesión de com unicación activa. La Figura 15.1 ilus­ tra diversos m étodos de ataque. Com o ya hem os com entado, resulta im posible garantizar una protección absoluta del sistema frente a los abusos de carácter m alicioso, pero podem os hacer que el coste para aquel que lo inten­ te sea tan alto com o para disuadir a la m ayoría de los intrusos. En algunos casos, com o por ejem ­ plo con los ataques de denegación de servicio, es preferible prevenir el ataque lo suficiente com o para detectarlo de m odo qu e puedan adoptarse las necesarias contram edidas. Para proteger un sistem a, debem os adoptar las necesarias m edidas de seguridad en cuatro niveles distintos: 1. Físico. El nodo o n odos que contengan los sistem as inform áticos deben dotarse de medidas de seguridad físicas frente a posibles intrusiones arm adas o subrepticias por parte de poten­

12

Capítulo 15 Seguridad

cíales intrusos. H ay que dotar de seguridad tanto a las habitaciones donde las m áquinas resi­ dan com o a los term inales o estaciones de trabajo que tengan acceso a dichas m áquinas. 2. H um ano. La autorización de los usuarios debe llevarse a cabo con cuidado, para garantizar que sólo los usuarios apropiados tengan acceso al sistem a. Sin em bargo, incluso los usuarios autorizados pueden verse “m otivados” para perm itir que otros usen su acceso (por ejemplo, a cam bio de un soborno). Tam bién pueden ser engañados para perm itir el acceso a otros, m ediante técnicas de in g en iería social. U no de los tipos de ataque basado en las técnicas de ingeniería social es el denom inado p h ish in g ; con este tipo de ataque, un correo electrónico o página w eb de aspecto autentico llevan a engaño a un usuario para que introduzca informa­ ción confidencial. Otra técnica com únm ente utilizada es el an álisis de desperdicios, un tér­ m ino general para describir el intento de recopilar inform ación para poder obtener un acceso no autorizado a la com putadora (por ejem plo, exam inando el contenido de las papeleras, localizando listines de teléfonos o encontrando notas con contraseñas). Estos problem as de seguridad son cuestiones relacionadas con la gestión y con el personal, m ás que problemas relativos a los sistem as operativos. 3. S istem a operativo. El sistem a debe autoprotegerse frente a los posibles fallos de seguridad accidentales o prem editados. Un proceso que esté fuera de control podría llegar a constituir un ataque accidental de denegación de servicio. A sim ism o, una cierta consulta a un servicio podría conducir a la revelación de contraseñas o un desbordam iento de la pila podría perm i­ tir que se iniciara un proceso no autorizado. La lista de posibles fallos de seguridad es casi infinita. 4. Red. Son m uchos los datos, en los m odernos sistem as inform áticos que viajan a través de líneas arrendadas privadas, de líneas com partidas com o Internet, de conexiones inalám bri­ cas o de líneas de acceso telefónico. La interceptación de estos datos podría ser tan dañina com o el acceso a una com putadora, y la interrupción de la com unicación podría constituir rm ataque rem oto de denegación de servicio, dism inuyendo la capacidad de uso del sistem a y la confianza en el m ism o por parte de los usuarios. Si querem os poder garantizar la seguridad del sistem a operativo, es necesario garantizar la seguridad en los prim eros dos niveles. C ualquier debilidad en uno de los niveles altos de seguri­ dad (físico o hum ano) perm itirá puentear las m edidas de seguridad que son estrictam ente de bajo nivel (del nivel del sistem a operativo). Así, la frase que afirm a que una cadena es tan fuerte como el más débil de sus eslabones es especialm ente cierta cuando hablam os de la seguridad de los sis­ temas. Para poder m antener la seguridad, debem os contem plar todos estos aspectos. Adem ás, el sistem a debe proporcionar m ecanism os de protección (Capítulo 14) para permitir la im plem entación de las características de seguridad. Sin la capacidad de autorizar a los usuarios y procesos, de controlar su acceso y de registrar sus actividades, sería im posible que un sistema operativo im plem entara m edidas de seguridad o se ejecutara de form a segura. Para soportar un esquem a global de protección hacen falta m ecanism os de protección hardware. Por ejem plo, un sistem a donde la m em oria no esté protegida no puede nunca estar seguro. Las nuevas caracterís­ ticas hardw are perm iten hacer más seguros los sistem as, com o verem os m ás adelante. D esafortunadam ente, casi ninguno de los aspectos relativos a la seguridad resulta sencillo. A m edida que los intrusos aprenden a aprovechar las vulnerabilidades de los sistem as de seguridad, se crean y se im plantan ¡as correspondientes contram edidas, lo cual hace que los intrusos vayan realizando ataques cada vez m ás sofisticados. Por ejem plo, algunos incidentes relativos a la seguridad que se han experim entando en los últim os años incluyen el uso de softw are espía com o con­ ducto para la distribución de spam a través de sistem as inocentes (hablarem os de esta práctica en la Sección 15.2). Este juego del gato y el ratón continuará, probablem ente, en el futuro próximo, haciendo necesario disponef de más herram ientas de seguridad para bloquear las técnicas y acti­ vidades cada vez m ás sofisticadas de los piratas inform áticos. En el resto de este capítulo, vam os analizar el tema de la seguridad en los niveles de red y del sistem a operativo. La seguridad en los niveles físico y hum ano, aunque im portante, cae funda­ m entalm ente fuera del alcance de este texto. La seguridad dentro del sistem a operativo y entre sis-

J-

15.2 Amenzas relacionadas con los programas

513

tem as operativos se im plem enta m ediante diversas técnicas, que van desde la utilización de con­ traseñas para la autenticación a la defensa frente a virus y a la detección de intrusos. Vam os a com enzar explorando la gam a de am enazas a la seguridad.

15.2 Am enazas relacionadas con los program as Los procesos son, junto con el kem el, el único m edio de realizar un trabajo útil en una com puta­ dora. Por tanto, un objetivo com ún de los piratas inform áticos consiste en escribir un program a que cree una brecha de seguridad o que h aga que un proceso norm al cam bie su com portam iento y cree esa brecha de seguridad. De hecho, la m ayoría de las brechas de seguridad no relacionadas con program as tienen por objetivo crear una brecha que sí esté basada en un programa. Por ejem ­ plo, aunque resulta útil iniciar una sesión en u n sistem a sin autorización, norm alm ente es mucho m ás útil dejar un demonio de tipo puerta trasera que proporcione inform ación o que perm ita un fácil acceso incluso aunque se bloquee la brecha de seguridad original. En esta sección, vam os a describir algunos m étodos com unes m ediante los que los program as pueden provocar brechas de seguridad. H ay que resaltar que existe una considerable variación en lo que respecta a los conve­ nios de denom inación de los agujeros de seguridad, y que en este texto utilizam os los térm inos m ás com unes o descriptivos.

15.2.1 Caballo de Troya M uchos sistem as tienen m ecanism os para perm itir que program as escritos por unos usuarios sean ejecutados por otros. Si estos programas se ejecutan en un dom inio que proporcione los derechos de acceso del usuario ejecutante, los otros usuarios podrían u tilizar inapropiadam ente estos dere­ chos. Por ejem plo, un program a editor de texto puede incluir código para buscar ciertas palabras clave en el archivo que hay que editar. Si se encuentra alguna, el archivo com pleto puede copiar­ se en un área especial accesible por el creador del editor de textos. Un segm ento de código que utilice inapropiadam ente su entorno se denom ina cab allo de Troya. Las rutas de búsqueda de gran longitud, com o las que aparecen frecuentem ente en los sistem as U N IX, agravan el problem a de los caballos de Troya. La ruta de búsqueda enum era el conjunto de directorios en el que hay que buscar cuando se proporciona un nom bre de program a am biguo. Lo que se hace es buscar en esa ruta un archivo con dicho nom bre y ejecutar el archivo. Todos los directorios de esa ruta de búsqueda deben ser seguros, porque de lo contrario podría introducirse un caballo de Troya en la ruta de ejecución del usuario y ejecutarse accidentalm ente. Por ejem plo, considere el uso del carácter dentro de una ruta de búsqueda. El le dice a la shell que incluya el directorio actual en la búsqueda. A sí, si un usuario tiene en su ruta de búsqueda, ha configurado el directorio actual para situarse en el directorio de un amigo e intro­ duce el nom bre de un com ando norm al del sistem a, dicho com ando podría ejecutarse desde el directorio de ese amigo. El programa se ejecutaría dentro del dom inio del usuario, perm itiendo que ese program a hiciera cualquier cosa qu e el usuario pu ede hacer, incluyendo por ejem plo borrar los archivos de usuario. Una variante de caballo de Troya es un program a que em ula el típico program a de inicio de sesión. U n usuario que no esté advertido tratará de iniciar la sesión en un terminal y observará que aparentem ente ha escrito mal su contraseña; después, vuelve a intentarlo y esta vez lo hace con éxito. Lo que ha sucedido es que su clave de autenticación y su contraseña han sido robadas por el em ulador de inicio de sesión, que fu e dejado ejecutándose en el term inal por parte del ladrón. El em ulador alm acena la contraseña, im prim e un m ensaje de error de inicio de sesión y sale del program a, después de lo cual se presenta al usuario una verdadera pantalla de inicio de sesión. Este tipo de ataque puede evitarse haciendo que el sistem a operativo im prim a un m ensa­ je de uso al final de una sesión interactiva, exigiendo al u su ario que utilice para iniciar la sesión una secuencia de teclas no capturadle, com o la com binación c o n t r o l - a l t - s u p r usada en todos los sistem as operativos W indow s m odernos. Otra variante del caballo de Troya es el sp y w a r e. Los program as spyivare acom pañan en oca­ siones a ciertos program as que el usuario haya decidido instalar. En la m ayoría de los casos, se

514

Capítulo 15 Seguridad

incluyen con program as de tipo freew are o Shareware, pero en otras ocasiones tam bién se incll yen en softw are de carácter com ercial. El objetivo del spyw are es descargar anuncios para mostrar2* los en el sistem a del usuario, crear ven tanas de explorador em ergentes cuando se visiten cierto sitios o capturar inform ación del sistem a del usuario y enviarla a un sitio central. Este ült m odo es un ejem plo de una categoría general de ataques conocida como canales en cu b ierto s^ través de los cuales tienen lugar com unicaciones subrepticias. Com o ejem plo, la instalación de if program a aparentem ente inocuo en un sistem a W indow s podría provocar la carga de un déml nio spyware. El spyw are podría contactar un sitio central, recibir desde allí un m ensaje y una lisg de direcciones de destino y entregar el m ensaje basura a esos usuarios desde la máquii W indow s. Este proceso continuaría hasta que el usuario descubriera la existencia del spyware. En l m uchísim os casos, ese program a spyw are no llega a ser descubierto. En 2004, las estim aciones inSpI caban que el 80 por ciento del correo basu ra se distribuía a través de este m étodo. ¡Este robo del ¿fl| servicio ni siquiera se considera un delito en la m ayoría de los países! El spyware es un ejem plo a pequeña escala de un problem a a gran escala: la violación del prir¿¡j cipio del m ínim o privilegio. En la m ayoría dé las circunstancias, un usuario de un sistem a opera-1 tivo no necesita instalar dem onios de red. Dichos demonios- llegan a instalarse debido a dos^ errores. En prim er lugar, u n usuario podría estar operando con más privilegios de los necesar io s (por ejem plo, com o adm inistrador), perm itiendo que los program as que ejecute tengan más aerea so al sistem a del necesario; este es un caso de error hum ano, que es una de las vulnerabilidades! de seguridad m ás habituales. En segundo lugar, un sistem a operativo puede perm itir, de m an en ! predeterm inada, m ás privilegios de los que un usuario norm al necesita; este es un ejemplo díS decisiones de diseño del sistem a operativo inadecuadas. U n sistem a operativo (y, en general, cua|| quier tipo de softw are) debe ofrecer una seguridad y un control de acceso de granularidad fin a l pero tam bién debe ser fácil de gestionar y d e com prender. Las m edidas de seguridad incómoda o inadecuadas están condenadas a ser puenteadas, provocando un debilitam iento global del sií tem a de seguridad que en teoría deberían im plém entar.

15.2.2 Puerta trasera El diseñador de u n program a o un sistem a puede dejar detrás suyo un agujero en el softw are qu§¡ sólo él sea capaz de utilizar. Este tipo de brecha de seguridad (o puerta trasera) era el que se ihísg traba en la película Juegos de guerra. Por ejem plo, el código puede tratar de detectar un ID de usua­ rio o una contraseña específicos y, al detectarlo, evitar los procedim ientos de seguridad normales'.] Se han dado casos de program adores que fueron condenados por estafar a los bancos incluyendo; errores de redondeo en su código y haciendo que esas fracciones de céntimo fueran abonadas en, sus cuentas. Estos abonos podían llegar a acum ular grandes sum as de dinero, considerando el gran núm ero de transacciones que un banco ejecuta. Podría incluirse una puerta trasera inteligente dentro del propio com pilador. El compilador: generaría código objeto estándar junto con la puerta trasera, independientem ente de qué códigtfi puente se estuviera com pilando. Esta actividad es particularm ente peligrosa, ya que un análisis; del código fuente del program a no perm itiría revelar ningún problem a. Sólo el código fuente del; com pilador contendría la inform ación necesaria para detectar la puerta trasera. "* Las puertas traseras plantean un difícil problem a porque, para detectarlas, tenem os que anali­ zar todo el código fuente de todos los com ponentes de un sistem a. Puesto que los sistem as soft­ w are pueden estar com puestos por m illones de líneas de código, este análisis no se lleva a cabo frecuentem ente, y en la m ayoría de los casos no se lleva a cabo nunca. J

15.2.3 Bomba lógica Considere un program a capaz de iniciar un incidente de seguridad sólo cuando se dan determi­ nadas circunstancias. Sería difícil de detectar porque, en condiciones norm ales de operación, no existiría ningún agujero de seguridad. Sin em bargo, cuando se satisficiera un conjunto predefini­ do de parám etros, se crearía el agujero de seguridad. Este escenario se conoce con el nom bre de b o m b a lógica. U n program ador, por ejem plo, podría escribir código para detectar si todavía con-

J-

15.2 Amenzas relacionadas con los programas

515

tinúa contratado por la em presa; en caso de que dicha com probación fallara, podría crearse un dem onio para perm itir el acceso rem oto, o podría iniciarse un determ inado fragm ento de código que provocara algún tipo de daño en la instalación.

15.2.4 Desbordamiento de pila y de búfer El ataque por desbordam iento de pila o de búfer es la form a m ás com ún para que un atacante externo al sistem a, a través de una conexión de red o de acceso telefónico, obtenga acceso no auto­ rizado al sistem a objetivo. Los usuarios autorizados del sistem a tam bién pueden utilizar este tipo de ataque para escalar sus privilegios. Esencialm ente, lo que el ataque hace es aprovechar un error de un programa. El error puede deberse a un sim ple caso de m ala práctica de program ación, en el que el program ador se olvidó de incluir en el código com probaciones del límite para un determ inado caso de entrada. En este caso, el atacante envía m ás datos de los que el program a está esperando. Utilizando un m étodo de prueba y error, o exam inando el código fuente del program a atacado, si es que está disponible, el atacante determ ina la vulnerabilidad y escribe un program a para hacer lo siguiente: 1. D esbordar un cam po de entrada, un argum ento de línea de com andos o un búfer de entrada (por ejem plo, en un dem onio de red) hasta escribir en la zona correspondiente a la pila. 2. Sobreescribir la dirección actual de retorno de la pila, sustituyéndola por la dirección de los códigos de ataque cargados en el paso 3. 3. Escribir un fragm ento sim ple de código en el siguiente espacio de la pila, que incluye los com andos que el atacante quiera ejecutar, com o por ejem plo arrancar un program a shell. El resultado de la ejecución de este program a de ataque será una shell raíz o la ejecución de otro com ando privilegiado. Por ejem plo, si un form ulario de página w eb espera que se introduzca un nom bre de usuario en un cam po, el atacante podría enviar el nom bre de usuario m ás una serie de caracteres adicio­ nales con el fin de desbordar el búfer y alcanzar la pila, más una nueva dirección de retorno que cargará en la pila, más el código que el atacante quiera ejecutar. Cuando la subrutina encargada de leer el búfer vuelve de su ejecución, la dirección de retorno será la correspondiente al código de ataque y ese código se ejecutará. A nalicem os un ataque de desbordam iento de búfer con m ás detalle. Considere el program a C sim ple que se m uestra en la Figura 15.2. Este program a crea una m atriz de caracteres de tamaño BUFFER_SIZE y copia el contenido del parám etro proporcionado en la línea de com andos: argv [1]. M ientras que el tam año de este parám etro sea inferior a BUF?FR_SIZE (necesitam os un byte para alm acenar el term inador nulo), este program a funcionará adecuadam ente. Pero considere lo que sucede si el parám etro proporcionado en la línea de comandos tiene una longi­ tud m ayor que BUFFER_SIZE. En este caso, la función strcpy (1) em pezará a copiar desde argvfl] hasta que encuentre un term inador nulo (\ 0) o hasta que le program a sufra un fallo catastrófico. Así, este program a sufre de un problem a potencial de desbordam iento de búfer en el que los datos copiados desbordarán la m atriz buf fer. O bserve que un program ador cuidadoso podría haber realizado una com probación de los lím i­ tes de tam año de argv [ 1 ] utilizando la función strncpy (1) en lugar de strcpy (1), susti­ tuyendo la línea “strcpy ( b u f f e r , argv [ 1 ] ) ; ” por “strncpy (b u f fer , argv [ 1 ] , sizeof (b u f f e r ) -1);”.D esafortunadam ente, las com probaciones adecuadas-de los límites constituyen la excepción, más que la norm a. A dem ás, la falta de com probaciones de lím ites no es la única causa posible del com portam ien­ to del program a de la Figura 15.2. El program a podría haber sido diseñado expresam ente para com prom eter la integridad del sistem a. Vam os a considerar ahora las posibles vulnerabilidades de seguridad derivadas de un desbordam iento de búfer. Cuando se invoca una función en una arquitectura inform ática típica, las variables definidas localm ente a la función (conocidas en ocasiones con el nom bre de variables autom áticas), los parám etros pasados a la función y la dirección a la que volverá el control cuando la función ter-

Capítulo 15 Seguridad

#include #define BUFFER_SIZE 256 int main(int argc, char *argv[]) {

char buffer[BUFFER_SIZE]; if (argc < 2) return -1; eise { strcpy(buffer,argv[l]); return 0; } } Figura 1 5.2

Programa C con una condición de desbordamiento de búfer.

m ine se alm acenan en una entrada de pila. En la Figura 15.3 se m uestra la disposición de una entrada de pila típica. Exam inando la entrada de pila de arriba hacia abajo, vem os prim ero los parám etros pasados a la función, seguidos por las variables autom áticas declaradas en la función. D espués se encuentra el p u ntero de entrada de p ila, que es la dirección del com ienzo de la entra­ da de pila. Finalm ente, tenem os la dirección de retom o, que determ ina a dónde hay que devolver el control una vez que la función term ine. El puntero de entrada de pila debe guardarse en la pila,, ya que el puntero de pila puede variar durante la llam ada a la función; el puntero de entrada de pila perm ite el acceso relativo a los parám etros de las variables autom áticas. D ada esta disposición estándar en m em oria, un pirata inform ático podría ejecutar un ataque por desbordam iento de búfer. Su objetivo sería sustituir la dirección de retom o de la entrada del pila de m odo que ahora apuntara al segm ento de código que contenga el program a atacante. El program ador escribiría prim ero un pequeño segm ento de código com o el siguiente:

#include

"*

int main(int argc, char *argv[]) {

execvp(''\ b i n \ s h ' \bin \sh'', NULL); return 0; 1 U tilizando la llam ada al sistem a e x e c v p ( ) , este segm ento de código crea un proceso shell. Si el program a que se está atacando se ejecuta con perm isos globales del sistem a, esta skell recién

crecim iento

direcciónderetom o punterodeentrada depilaguardado.

punterodeentradadepila

f ü ü ü

variablesautomáticas ' parám etro(s) cim a Figura 15.3 Estructura- de una entrada de pila típica.

15.2 Amenzas relacionadas con los programas

517

creada obtendría un acceso com pleto al sistem a. Por supuesto, el segm ento de código podría hacer cualquier cosa que esté perm itida por los privilegios del proceso atacado. Después, se com pila este segm ento de código para poder m odificar las instrucciones en lenguaje ensam blador. La prin­ cipal m odificación consiste en elim inar todas las partes de código innecesarias, reduciendo el tam año de código para que pueda caber en una entrada de pila. Este fragm ento de código ensam ­ blado será ahora una secuencia binaria que constituirá el corazón del ataque. C onsulte de nuevo el program a m ostrado en la Figura 15.2. Supongam os que cuando se invo­ ca la función m a in () en dicho program a la entrada de pila tiene el aspecto que se m uestra en la Figura 15.4(a). U tilizando un depurador, el program ador averigua la dirección de b u f f e r [ 0 ] dentro de la pila. D icha dirección es la ubicación del código que el atacante quiere ejecutar, por lo que se añade a la secuencia binaria la cantidad necesaria de instrucciones N O -O P (lo que quiere decir N O - O P e r a t io n ) para rellenar la entrada de pila hasta alcanzar la ubicación de la dirección de retom o; a continuación se añade la nueva dirección de retom o, que será la ubicación de b u f f e r [ 0 ] . El ataque estará com pleto cuando el atacante proporcione com o entrada al proceso esta secuencia binaria que ha diseñado. El proceso copiará entonces la secuencia binaria desde a r g v [ 1 ] a la posición b u f f e r [ 0 ] en la entrada de pila. Ahora, cuando el control vuelva desde m a i n ( ) , en lugar de volver a la ubicación especificada por el antiguo valor de la dirección de retom o, volverá al código de shell m odificado, que se ejecutará con los derechos de acceso del pro­ ceso atacado. La Figura 15.4(b) contiene el código shell m odificado. H ay m uchas form as de tratar de aprovechar los problem as potenciales de desbordam iento de búfer. E n este ejem plo, hem os considerado la posibilidad de que el program a que está siendo ata­ cado (el código m ostrado en la Figura 15.2) se estuviera ejecutando con perm isos globales del sis­ tem a. Sin em bargo, el segm ento de código que se ejecute una vez m odificado el valor de la dirección de reto m o podría realizar cualquier tipo de acto m alicioso, com o borrar archivos, abrir puertos de red para realizar ataques ulteriores, etc. Este ataque de ejem plo por desbordam iento de búfer revela que hacen falta unos grandes cono­ cim ientos y habilidades de program ación para poder reconocer el código atacable y diseñar el ata­ que adecuado. Desafortunadam ente, para lanzar ataques de seguridad no hace falta ser un gran program ador: un pirata inform ático podría determ inar el error existente en un cierto program a y escribir un m ódulo de ataque. Cualquiera que tenga unos conocim ientos inform áticos rudim enta­ rios y que se haga con ese código de ataque (los denom inados s c r ip t k id d ie , niños script) podrían tratar de lanzar el ataque contra determ inados sistem as objetivo. El ataque por desbordam iento de búfer resulta especialm ente pernicioso porque pueden lan­ zarse ataques de un sistem a a otro y ese código de ataque puede ser transm itido a través de los

r dirección de código 3, shell modificado

dirección de retorno

• -g *

■s

puntero.de entrada de oiia guardado ' .

buffer(BUFFER_SIZE -1)

■ buffer(1)

y

copiado ^ código shell módificado.

buffer(O)

(a)

(b)

Figura 15.4 Entrada de pila hipotética para la Figura 15.2, (a) antes y (b) después.

Capítulo 15 Seguridad

canales de com unicaciones perm itidos. D ichos ataques pueden realizarse utilizando los protoco- ' los norm ales que se utilicen para com unicarse con la m áquina objetivo, por lo que pueden resul- " tar difíciles de detectar y prevenir. Esos ataques pueden incluso puentear los m ecanism os de seguridad proporcionados por los cortafuegos (Sección 15.7). U na solución a este problem a es que la CPU disponga de una característica que no permita la ejecución de código contenido en una sección de pila de la m em oria. Las versiones recientes del chip SPA R C de Sun incluyen este tipo de m ecanism o de seguridad y las versiones más recientes de Solaris utilizan ese m ecanism o. Puede seguirse m odificando la dirección de retom o de la ruti­ na desbordada, pero cuando la dirección de retorno apunta a una ubicación dentro de la propia pila y se intenta ejecutar el código alm acenado en ella, se genera una excepción y el programa se detiene con un error. Las versiones recientes de los chips A M D e Intel x 86 incluyen la funcionalidad NX para impe- . dir este tipo de ataque. El uso de esta funcionalidad está soportado en varios sistem as operativos para x 86, incluyendo Linux y W indow s XP SP2. La im plem entación hardw are im plica el uso de un nuevo bit dentro de las tablas de páginas de la CPU. Este bit m arca la página asociada com o no eje- . cutable, im pidiendo leer y ejecutar instrucciones desde ella. A m edida que esta característica sea más utilizada, los ataques por desbordam iento de búfer deberían dism inuir significativamente, ¿fe

15.2.5 Virus

^

Otro tipo de am enaza en form a de program a son los virus. Los virus son auto-replicantes y están diseñados para “infectar” otros program as. Pueden causar estragos en un sistem a modificando o destruyendo archivos y provocando funcionam ientos inadecuados de los program as y fallos 4 catastróficos del sistem a. Un virus es el fragm ento de código integrado dentro de un programa • legítim o. Al igual que la m ayoría de los ataques de penetración, los virus son m uy específicos d e las arquitecturas, de los sistem as operativos y de las aplicaciones. Los virus constituyen, un V" problem a especialm ente grave para los usuarios de m áquina de tipo PC. UNIX y otros sistemas ' operativos m ultiusuario no son, generalm ente, susceptibles a los virus, porque los programas •: ejecutables están protegidos contra escritura por el propio sistem a operativo. Incluso si un virus llega a infectar a uno de esos program as, sus poderes están usualm ente lim itados, porque otros aspectos del sistem a están tam bién protegidos. Los virus suelen propagarse a través de correo electrónico, siendo el correo basura el vector más com ún. Tam bién pueden propagarse cuando los usuarios descargan program as infectados desde servicios de com partición de archivos de Internet o cuando intercam bian discos infectados. O tra form a com ún de transm isión de virus utiliza los archivos M icrosoft Office, com o por ejem plo los docum entos de M icrosoft W ord. Estos docum entos pueden contener macros (o progra­ mas V isual Basic) que los program as del paquete O ffice (Word, Pow erPoint y Excel) ejecutarán___ autom áticam ente. Puesto que estos program as se ejecutan bajo la propia cuenta del usuario, las m acros pueden operar de form a bastante poco restringida (por ejem plo, cerrando archivos del usuario a voluntad). Com únm ente, los virus tam bién se envían a sí m ism os por correo electróni­ co a otras personas que se encuentren dentro de la lista de contacto del usuario. He aquí un ejem­ plo de código que m uestra la sim plicidad de escribir una m acro Visual Basic que un virus podría usar para form atear el disco duro de una com putadora W indow s en cuanto se abra el archivo que contenga la macro:

Sub AutoOpen() Dim oFS Set oFS = CreateObject(''Scripting.FileSystemObject'') vs = Shell(''c : command.com /k format c:'',vbHide) End Sub

■’

¿Cóm o funcionan los virus? Una vez que un virus alcance una m áquina objetivu, un programa conocido com o lanzador de virus inserta el virus en el sistem a. El lanzador de virus es usualmen­ te un caballo de Troya, que se ejecuta por otras razones pero cuya principal actividad consiste en

15.2 Amenzas relacionadas con los programas

519

instalar el virus. Una vez instalado, el virus puede hacer una de varias cosas. Existen literalm en­ te m iles de virus.distintos, pero se los puede clasificar en varias categorías generales. O bserve que m uchos virus pertenecen a m ás de una categoría a la vez: • A rchivo. U n virus de archivo estándar infecta un sistem a insertándose a u n archivo y m odi­ ficando el inicio del program a para que la ejecución salte al código del virus. Después de ejecutarse, el virus devuelve el control al program a para que no pueda detectarse que el virus se ha ejecutado. Los virus de archivo se conocen, en ocasiones, con el nom bre de virus parásitos, ya que no dejan ningún archivo com pleto detrás suyo y perm iten que el progra­ m a huésped siga funcionando. • A rranque. Un virus de arranque infecta el sector de arranque del sistem a, ejecutándose cada vez que el sistem a se arranca y antes de que se cargue el sistem a operativo. El virus busca otros soportes de arranque (es decir, disquetes) y tam bién los infecta. Este virus tam ­ bién se conoce con el nom bre de virus de m em oria, porque no aparecen en el sistem a de archivos. La Figura 15.5 m uestra cóm o funciona un virus de arranque. • M acro. La m ayoría de los virus están escritos en un lenguaje de bajo nivel, com o por ejem ­ plo ensam blador o C. Los virus de m acro están escritos en un lenguaje de alto nivel, com o Visual Basic. Estos virus se activan cuando se inicia un program a capaz de ejecutar

en ei arranque del sistema, el virus reduce la memoria física y se oculta en memoria por encima del nuevo límite __________ A1__________

el virus se inserta en la interrupción de lectura-escritura de disco, rnonitorizando toda I a actividad de disco

Figura 15.5 Un virus informático que afecta al sector de arranque.

520

Capítulo 15 Seguridad

la m acro: Por ejem plo, un virus de m acro podría estar contenido en un archivo de hoja de cálculo. • C ód igo fu ente. U n virus de código fuente busca código fuente y lo m odifica para incluir ' el virus y ayudar a su distribución. : • P olim órfico. Este tipo de virus cam bia cada vez que se instala, para evitar su detección p o r ! parte del softw are antivirus. Los cam bios no afectan a la funcionalidad del virus, sino que i sólo m odifican la signatu ra del virus. U na signatura de virus es un patrón que puede usar-* se para identificar un virus, norm alm ente una serie de bytes que form an parte del código de virus. "’ • C ifrado. U n virus cifrado incluye código de descripción junto con el virus cifrado, de nuevo para evitar la detección. El virus se descifra primero y luego se ejecuta. ^ • E n cu bierto. Este insidioso virus trata de evitar la detección m odificando partes del siste­ m a que podrían ser usadas para detectarlo. Por ejem plo, podría m odificar la llam ada al sis­ tem a r e a d para que, si se lee el archivo que el virus ha m odificado, se devuelva el código original en lugar del código infectado. • T ú n el. Este tipo de virus trata de evitar la detección por los program as antivirus instalán­ dose asim ism o en la cadena de rutinas de tratam iento de interrupciones. Otros virus simi­ lares se instalan en los controladores de dispositivo. .ú - >3 • M u ltip arte. Los virus de este tipo son capaces de infectar m últiples partes de un sistema, incluyendo los sectores de arranque, la m em oria y los archivos. Esto hace que sea difícil detectarlos y evitar su propagación. '¡M • A corazado. Los viru s acorazados están codificados de tal m anera que resultan difíciles del desentrañar y de com prender por parte de los investigadores que desarrollan programas antivirus. Tam bién pueden estar com prim idos para evitar la detección y la desinfección^ A dem ás, los lanzadores de virus y otros archivos com plejos que form an parte de un deter­ m inado virus de este tipo suelen frecuentem ente ocultarse utilizando los atributos de archivos o em pleando nom bres de archivo no visualizables. Esta am plia variedad de virus es probable que continúe creciendo. De hecho, en 2004 se detec­ to un nuevo virus de am plia distribución, que aprovechaba tres errores diferentes para operar. El virus com enzó infectando centenares de servidores W indows (incluyendo m uchos sitios de con­ fianza) que ejecutaban M icrosoft Internet Inform ation Server (IIS). Todo explorador web M icrosoft Explorer vulnerable que visitara esos sitios recibía un virus de explorador con cada des­ carga. El virus de explorador instalaba varios program as de puerta trasera, incluyendo un regis­ trador de p u lsacio n es de teclas, que registraba todo lo que se introdujera a través del teclado (incluyendo contraseñas y núm eros de tarjetas de crédito). Tam bién instalaba un dem onio pará perm itir un acceso rem oto no lim itado a los intrusos y otro que permitía al intruso distribu ir’ correo basura a través de la m áquina de escritorio infectada. G eneralm ente, los virus son el tipo de ataque de seguridad más dañino; y com o son bastante efectivos, continuarán desarrollándose y distribuyéndose. Uno de los más activos debates dentro de la com unidad inform ática es si la m onocultura, es decir, esa situación en la que m uchos siste­ mas ejecutan el mismo hardw are, el m ism o sistem a operativo y/o el mismo softw are de aplica­ ción, están increm entando el grado de am enaza y el nivel de daños provocados por las intrusiones de seguridad. Parte de ese debate es, precisam ente, la cuestión de si existe o no en la actualidad una m onocultura (com puesta por productos M icrosoft).

15.3 Amenazas del sistema y de la red Las am enazas basadas en program as utilizan típicam ente un fallo en los m ecanism os de protec­ ción de un sistem a para atacar a los programas. Por contraste, las am enazas del sistem a y de la

15.3 Amenazas del sistema y de la red

521

red im plican el abuso de los servicios y de las conexiones de red. En ocasiones, se utiliza un ata­ que del sistem a y de la red para lanzar un ataque de program a, y viceversa. Las am enazas del sistem a y de la red crean una situación en la que se utilizan inapropiadam en­ te los recursos del sistem a operativo y los archivos del usuario. En esta sección vam os a analizar algunos ejem plos de estas am enazas, incluyendo los gusanos, el escaneo de puertos y los ataques por denegación de servicio. Es im portante destacar que las m ascaradas y los ataques por reproducción tam bién resultan com unes en las redes que interconectan los sistem as. De hecho, estos ataques son m ás efectivos y m ás difíciles de contrarrestar cuando están im plicados m últiples sistem as. Por ejem plo, dentro de una com putadora, el sistem a operativo puede determ inar, usualm ente, el em isor y el receptor de un m ensaje. Incluso si el em isor adopta el ID de alguna otra persona, puede que exista un registro de dicho cam bio de ID. Cuando están im plicados m últiples sistem as, especialm ente sistem as que son controlados por los atacantes, realizar esa labor de traza resulta m ucho m ás difícil. La generalización de este concepto es que el com partir secretos (para dem ostrar la identidad y en form a de claves de cifrado) es una necesidad para la autenticación del cifrado, y que esa com ­ partición resulta m ás sencilla en aquellos entornos (por ejem plo con un único sistem a operativo) en los que existan m étodos seguros de com partición. Estos m étodos incluyen la m em oria com par­ tida y los m ecanism os de com unicación interprocesos. Los tem as de la creación de com unicacio­ nes seguras y de la autenticación se analizan en las Secciones 15.4 y 15.5.

15.3.1 Gusanos Un gusano es un proceso que utiliza un m ecanism o de reproducción para afectar al rendim iento del sistem a. El gusano crea copias de sí m ism o, utilizando recursos del sistem a y en ocasiones im pidiendo operar a todos los dem ás procesos. En las redes inform áticas, los gusanos son parti­ cularm ente potentes, ya que pueden reproducirse de un sistem a a otro y colapsar una red com ­ pleta. Esto fue lo que sucedió en 1988 con los sistem as UNIX de Internet, provocando m illones de dólares de pérdidas en tiem po de detección de los sistem as y en tiem po dedicado por los adm i­ nistradores de los m ism os. Al finalizar la jo m ad a del 2 de noviem bre de 1988, Robert Tappan M orris Jr., un estudiante de segundo ciclo de C om ell, lanzó un program a gusano en una o m ás m áquinas host conectadas en Internet. Teniendo por objetivo a las estaciones de trabajo Sun 3 de Sun M icrosystem s y a las com ­ putadoras VA X que ejecutaban variantes del UNIX BSD versión 4, el gusano se expandió rápida­ m ente, atravesando grandes distancias; en unas pocas horas después de su lanzam iento, había llegado a consum ir los recursos de los sistem as hasta eL punto de provocar el colapso de las m áquinas infectadas. A unque Robert M orris diseñó el program a auto-replicante para su rápida reproducción y dis­ tribución, son algunas de las características del entorno de com unicación por red de UNIX las que p ro p o rcion aro n los m ed ios p ara la propagación del gusano en los distin tos sistem as. Probablem ente, M orris eligió para la infección inicial algún host Internet que hubiera sido dejado abierto para el acceso por parte de usuarios externos. Desde allí, el program a gusano aprovechó una serie de fallos en las rutinas de seguridad del sistem a operativo UNIX y se dedicó a em plear algunas utilidades UNIX que sim plificaban la com partición de recursos en las redes de área local, con el fin de obtener acceso no autorizado a miles de otros sitios conectados a la red. Los m étodos de ataque de M orris son los que a continuación se esbozan. El gusano estaba com puesto de dos programas. U n vector (tam bién denom inado arranque) y el program a principal. D enom inado ll.c , el vector estaba com puesto de 99 líneas de código C com ­ pilado y se ejecutaba en cada m áquina a lasque se accedía. Una vez establecido en el sistem a infor­ m ático objeto del ataque, el vector se conectaba a la m áquina donde se había originado y cargaba una copia del gusano original en el sistem a atacado (Figura 15.6). El program a principal se dedica­ ba entonces a buscar otras m áquinas con las que el sistem a recién infectado pudiera conectarse fácilm ente. Para realizar estas acciones, Nfíorn s a p ro v e c h o la utilidad de red UNIX r s h para la eje­ cución rem ota de tareas. D efiniendo archivos especiales que enum eran parejas de nom bres hostínicio de sesión, los usuarios pueden evitarse introducir una contraseña ¿ad a vez que accedan a

522

Capítulo 15 Seguridad

sistema objetivo

sistema infectado

Figura 15.6 El gusano Internet de Morris. una cuenta rem ota contenida en esa lista de parejas. El gusano analizaba estos archivos especiaieÜ en busca de nom bres de sitios que perm itieran la ejecución rem ota sin una contraseña. Allí donde¿ podía establecerse una shell rem ota, se cargaba el program a gusano y com enzaba a ejecutarse. * El ataque a través del m ecanism o de acceso rem oto era sólo uno de los tres m étodos de infec-| ción incluidos en el gusano. Los otros dos m étodos aprovechaban errores del sistem a operativo énf los program as f inger y sendmail de UNIX. La utilidad f inger funciona com o un listín telefónico electrónico; el com ando ♦1 finger nombre-usuario@nombrehost "*» devuelve el nom bre real de una persona y sus credenciales de inicio de sesión, junto con algunas'2 otras inform aciones que el usuario pueda haber proporcionado, com o por ejem plo la dirección deL trabajo y del dom icilio, el núm ero telefónico, sus intereses de investigación o alguna cita célebre^ Finger se ejecuta com o un proceso de segundo plano (o dem onio) en cada nodo BSD y responde a las consultas a través de Internet. El gusano ejecutaba u n ataque de desbordam iento de búfer sobre finger. El program a consultaba finger con una cadena de 536 bytes diseñada para exce­ der el búfer asignado para la entrada y para sobreescribir la entrada de la pila. En lugar de volver a la rutina principal en la que estuviera antes de la llam ada efectuada por M orris, el dem onio fin­ ger devolvía el control a un procedim iento contenido dentro de la cadena de 536 bytes invasora . que ahora residía en la pila. El nuevo procedim iento ejecutaba /bin/sh, que en caso de iniciarse satisfactoriam ente proporcionaba al gusano una shell rem ota en la m áquina objeto del ataque. El error que se aprovechaba en sendmail tam bién im plicaba la utilización de un proceso dem onio para efectuar úfia entrada de datos m aliciosa, s encima i 1 envía, recibe y encam ina correo. ; electrónico. El código de depuración contenido en esta utilidad perm ite a los desarrolladores veri­ ficar y m ostrar el estado del sistem a de correo. La opción de depuración resultaba m uy útil para los adm inistradores de sistem as, por lo que norm alm ente se la dejaba activada. M orris incluyó en su arsenal de ataques una llam ada a debug (el program a de depuración) que, en lugar de especi­ ficar una dirección de usuario (como se haría norm alm ente durante las pruebas) contenía un con­ junto de com andos que enviaban por correo y ejecutaban una copia del program a vector. U na vez instalado, el gusano principal realizaba una serie de intentos sistem áticos de descu­ brir las contraseñas de los usuarios. C om enzaba probando los casos sim ples de que no se utilice ninguna contraseña o de que las contraseñas estuvieran form adas por com binaciones de los nom­ bres de la cuenta y del usuario. Después, utilizaba com paraciones con un diccionario interno de 432 contraseñas favoritas que m uchos usuarios suelen elegir y luego entraba en una base final en la que se probaba cada una de las palabras del diccionario estándar en línea de UNIX com o posi­ ble contraseña. Este com plejo y eficiente algoritm o de averiguación de contraseñas form ado por tres pasos perm itía al gusano obtener acceso a otras cuentas de usuario del sistem a infectado. El

15.3 Amenazas del sistema y de la red

523

gusano buscaba entonces archivos de datos r s h en esas cuentas recién capturadas y los usaba com o se ha descrito anteriorm ente para tener acceso a cuentas de usuario en sistem as remotos. C on cada nuevo acceso, el program a gusano buscaba copias de sí m ism o que ya pudieran exis­ tir. Si encontraba una, la nueva copia term inaba su ejecución, excepto en uno de cada siete casos. Si el gusano hubiera term inado su ejecución siem pre que se detectaran copias duplicadas, podría haber llegado a no ser detectado nunca. Sin em bargo, al perm itir que uno de cada siete duplica­ dos continuara ejecutándose (posiblem ente para tratar de derrotar los esfuerzos para evitar su disem inación ejecutando falsos gusanos) se creó una infección m asiva en los sistem as Sun y VAX de Internet. Las m ism as características de los entornos de red UNIX que activaron la propagación del gusa­ no sirvieron tam bién para detener su avance. La facilidad de las com unicaciones electrónicas, los m ecanism os para copiar archivos fuente y archivos binarios en m áquinas rem otas y el acceso tanto al código fuente com o a la experiencia hum ana perm itieron un esfuerzo cooperativo para desarrollar soluciones rápidam ente. Al llegar la noche del día siguiente al com ienzo de la infec­ ción, el 3 de noviem bre, una serie de m étodos para detener al program a invasor fueron distribui­ dos a todos los adm inistradores de sistem as a través de Internet. En sólo unos días, ya había disponibles parches softw are específicos para resolver los fallos de seguridad que el gusano apro­ vechaba. ¿Por qué lanzó M orris ese gusano? Se ha atribuido su acción tanto a una brom a inocente que se le fue de las m anos com o a un intento crim inal deliberado. Teniendo en cuenta la com plejidad que requiere iniciar ese ataque, resulta bastante poco probable que el lanzam iento del gusano o su gran distribución no fueran intencionados. El program a gusano llevaba a cabo una serie de pasos m uy elaborados para tratar de no dejar huella y para contrarrestar los esfuerzos dirigidos a dete­ ner su disem inación. Sin em bargo, el program a no contenía ningún código capaz de dañar o des­ truir los sistem as en que se ejecutaba. El autor tenía, claram ente, la experiencia necesaria para haber incluido tales com andos; de hecho, el código de arranque tenía estructuras de datos que podrían haber sido usadas perfectam ente para transferir caballos de Troya o virus inform áticos. El com portam iento del program a nos perm ite realizar diversas observaciones de interés, pero no nos proporciona la suficiente inform ación com o para deducir los m otivos que alentaban al crea­ dor de este gusano. Lo que no deja, de todos m odos, lugar a la especulación es el resultado legal del caso: los jueces consideraron culpable a M orris y le condenaron a tres años de cárcel, a la rea­ lización de 400 horas de servicio a la com unidad y a una m ulta de 10.000 dólares. Los gastos lega­ les del propio M orris probablem ente excedieron de los 100.000 dólares. Los expertos en seguridad continúan elaborando m étodos para reducir o elim inar el riesgo de aparición de gusanos. Sin em bargo, un caso más reciente m uestra que los gusanos siguen proliferando en Internet y tam bién que, a m edida que Internet crece, el daño que incluso los gusanos “inocuos” pueden realizar tam bién crece y puede ser significativo. Este ejem plo tuvo lugar duran­ te agosto de 2003, cuando una serie de personas todavía desconocidas liberaron la quinta versión del gusano “Sobig”, m ás concretam ente conocida con el nom bre de “W 32.Sobig.F@ m m ”. Este ha sido el gusano de m ás rápida distribución que se ha lanzado hasta la fecha, y que infectó en su m om ento de m áxim a actividad a centenares de m iles de com putadoras y a uno de cada 17 m en­ sajes de correo electrónico que se intercam biaron a través de Internet. El gusano colapso las ban­ dejas de entrada de correo electrónico, ralentizó las redes de com unicaciones e hizo que se tuviera que dedicar una enorm e cantidad de horas a tareas de lim pieza. Sobig.F fue lanzado cargándolo en un grupo de noticias pornográfico a través de una cuenta creada con una tarjeta de crédito robada. El gusano estaba oculto en una fotografía. El virus con­ tenido en el gusano tomaba com o objetivo los sistem as M icrosoft W indow s y utilizaba su propio m otor SMTP para enviarse a sí m ismo por correo electrónico a todas las direcciones que se encon­ traran en el sistem a infectado. El gusano utilizaba diversas líneas de tema para evitar su detección, incluyendo “Thank You!”, “Your details” y “Re: A pproved”. Tam bién utilizaba una dirección alea­ toria extraída del host com o dirección de origen del correo electrónico, lo que hacía difícil deter­ m inar a partir del propio m ensaje cuál era la m áquina que estaba actuando com o origen de la infección. Sobig.F incluía un adjunto para que el lector del correo electrónico pulsara en él, de nuevo con una variedad de nom bres. Si se ejecutaba este adjunto, éste alm acenaba un programa

524

Capítulo 15 Seguridad

denom inado W IN PPR32.EX E en el directorio W indow s predeterm inado, junto con un archivo de texto y tam bién m odificaba el registro de W indow s. El código incluido en el adjunto tam bién estaba program ado para tratar periódicam ente del conectarse a uno de un conjunto de veinte servidores y para descargar y ejecutar un programa! desde ellos. A fortunadam ente, esos servidores fueron desactivados antes de que se pudiera des- • cargar el código. Todavía no se ha podido determ inar el contenido del program a que se hubiera descargado de estos servidores. Si dicho código fuera m alintencionado, el resultado podría haber sido un considerable daño en un enorm e núm ero de m áquinas.

15.3.2 Escaneo de puertos

i

El escaneo de puertos no es un ataque, sino m ás bien un m étodo para que los piratas informáti-J eos detecten las vulnerabilidades del sistem a que puedan ser atacadas. El escaneo de puertos se realiza norm alm ente de form a autom atizada, lo que im plica utilizar una herram ienta que trate de crear una conexión TCP/IP a un puerto o rango de puertos específicos. Por ejem plo, suponga que existe una vulnerabilidad (o error) conocida en sendmail. U n pirata inform ático podría ejecutar? un escáner de puertos para tratar de conectarse a, por ejem plo, el puerto 25 de un sistem a o rango? de sistem as concretos. Si la conexión tiene éxito, el pirata (la herram ienta) podría tratar de comu­ nicarse con el servicio que responda para determ inar si se trata de sendmail y, en caso afirmati-" vo, si la versión es la que tiene ese error conocido. A hora, im agínese una herram ienta en la que se hubieran codificado todos los errores conocidos? de todos los servicios de todos los sistemas operativos. Esa herram ienta podría tratar de conectar-! se a todos los puertos de uno o m ás sistem as y, p ara cada servicio que respondiera, podría tratar* de utilizar cada uno de los errores conocidos. Frecuentem ente, esos errores son desbordamientos? de búfer, que perm iten la creación de una shell de com andos privilegiada en el sistema. A partir dé! ahí, por supuesto, el atacante podría instalar caballos de Troya, program as de puerta trasera, etc. | N o existe ninguna herram ienta de ese tipo, pero sí que hay herram ientas que ofrecen un subconjunto de dicha funcionalidad. Por ejem plo, nmap (de http://w w w .insecure.org/nm ap/) es una uti­ lidad de código abierto m uy versátil para la exploración de red y la auditoría de seguridad. Cuando se la apunta a un puerto objetivo, determ ina qué servicios se están ejecutando, incluyen­ do los nom bres y versiones de las aplicaciones. Puede determ inar el sistem a operativo host y tam­ bién puede proporcionar inform ación acerca de las defensas, com o por ejem plo qué cortafuegos están defendiendo ese objetivo. Esta herram ienta no aprovecha ninguno de los errores conocidos. Nessus (de http://w w w .nessus.org/) realiza una función sim ilar, pero tiene tam bién una base de datos de errores y de los m odos de aprovecharlos en un ataque. Perm ite explorar un conjunto de sistem as, determ inar los servicios que se están ejecutando en esos sistem as y tratar de atacar todos los errores apropiados, generando después una serie de inform es acerca de los resultados. La herram ienta no realiza el paso final de explorar los errores encontrados, pero un pirata informá­ tico con los suficientes conocim ientos o uno de los denom inados “scripts kiddie” sí que podrían llevar a cabo ese ataque. Puesto que los escaneos de puertos son detectables (véase la Sección 15.6.3), se suelen realizar desde sistem as zom bi. D ichos sistem as son m áquinas independientes y previam ente com prom e­ tidas que están prestando un servicio norm al a sus propietarios al m ism o tiem po que son utiliza­ das inadvertidam ente para propósitos inconfesables, incluyendo la realización de ataques por denegación de servicio y la retransm isión de correo basura. Los zom bis hacen que resulte particu­ larm ente difícil perseguir a los piratas inform áticos, ya que resulta m uy difícil determ inar el orí-, gen del ataque y la persona que lo ha iniciado. Esta es una de las m uchas razones que aconsejan dotar de seguridad tam bién a los sistem as “no im portantes”, y no sólo a los sistem as que conten­ gan inform ación o servicios “valiosos”.

15.3.3 Denegación de servicio Com o hem os m encionado anteriorm ente, los ataques DOS están dirigidos no a obtener inform a­ ción o a robar recursos, sino a im pedir el uso legítim o de un sistem a o funcionalidad. La m ayoría

15.4 La criptografía como herramienta de seguridad

525

de los ataques de denegación de servicio afectan a sistem as en los que el atacante no ha penetra­ do. De hecho, lanzar un ataque que im pida el uso legítim o de un sistem a resulta, frecuentem en­ te, m ás sencillo que irrum pir en una m áquina o instalación. Los ataques de denegación de servicio se realizan generalm ente a través de la red. Se los puede clasificar en dos categorías. El prim er caso es el de los ataques que consum en tantos recursos de la m áquina atacada que prácticam ente no pu ede realizarse con ella ningún trabajo útil. Por ejem ­ plo, al hacer clic en un sitio w eb podría descargarse una applet Java que consum iera todo el tiem ­ po de CPU disponible o qu e se dedicara a abrir una serie infinita de ventanas em ergentes. El segundo caso de ataque im plica hacer caer la red o la instalación; ha habido num erosos ataques de denegación de servicio de este tipo que se han realizado contra algunos sitios web m uy cono­ cidos. Este tipo de ataque es el resultado de un abuso de algunas de las funciones fundam entales de T C P / IP. Por ejem plo, si el atacante envía la parte del protocolo que dice “Quiero iniciar una conexión TCP” pero luego no sigue con el m ensaje estándar que dice “La conexión está ahora esta­ blecida”, el resultado puede ser un conjunto de sesiones TCP parcialm ente iniciadas. Un número suficiente de estas sesiones puede consum ir todos los recursos de red del sistem a, incluyendo ulteriores intentos legítim os de establecer una conexión TCP. D ichos ataques, que pueden durar horas o días, han provocado en num erosas ocasiones un fallo parcial o total de los intentos de uti­ lizar la instalación objeto del ataque. Estos ataques suelen detenerse en el nivel de red, hasta que pueden actualizarse los sistem as operativos con el fin de redu cir su vulnerabilidad. G eneralm ente, es im posible prevenir los ataques de denegación de servicio. Los ataques uti­ lizan los m ism os m ecanism os que la operación norm al. Todavía m ás difíciles de prevenir y de solucionar son los a ta q u e s d is trib u id o s d e d e n e g a c ió n d e s e r v ic io (DDOS, distributed denial-ofservice attacks). Estos ataques se inician desde m últiples sitios a la vez, dirigidos hacia un objeti­ vo com ún, norm alm ente por parte de program as zombis. En ocasiones, un determ inado sitio puede no ser ni siquiera consciente de que está siendo ata­ cado. Puede resultar difícil determ inar si la ralentización de u n sistem a se debe sim plem ente a un pico de utilización del m ism o o a un ataque. Considere, por ejem plo, el caso de una campaña publicitaria que tuviera un enorm e éxito y que increm entara enorm em ente el tráfico hacia un determ inado sitio web; en ciertas condiciones, podría confundirse esa actividad con un ataque de tipo DDOS. Hay otros aspectos interesantes de los ataques DOS que conviene resaltar. Por ejemplo, los pro­ gram adores y los adm inistradores de sistem as deben tratar de com prender a la perfección los algoritm os y las tecnologías que estén im plantando. Si un algoritm o de autenticación bloquea una cuenta durante un cierto período de tiempo después de varios intentos incorrectos de inicio de sesión, un atacante podría hacer que se bloqueara todo el m ecanism o de autenticación del sistema sim plem ente generando una multitud de intentos incorrectos de sesión para todas las cuentas. De form a sim ilar, un cortafuegos que bloqueara autom áticam ente ciertos tipos de tráfico podría ser inducido a bloquear dicho tráfico en las ocasiones en que no debiera hacerlo. Finalmente, las clases de inform ática son una conocida fuente de ataques DOS accidentales; considere, a este res­ pecto, los prim eros ejercicios de program ación en los que los estudiantes aprenden a crear subprocesos o hebras: uno de los errores más com unes im plica la creación de una serie infinita de subprocesos, que termina por consum ir todos los recursos de la CPU y toda la memoria libre.

.4 La criptografía com o herramienta de seguridad Existen m uchas defensas frente a los ataques inform áticos, que abarcan toda la gama que va desde la m etodología a la tecnología. La herram ienta de carácter m ás general que está a disposición de los usuarios y de los diseñadores de sistem as es la criptografía. En esta sección, vamos a explicar algunos detalles acerca de la criptografía y de su uso en el cam po de la seguridad informática. En una com putadora aislada, el sistem a operativo puede determ inar de m anera fiable quiénes son el em isor y el receptor de todas las com unicaciones interprocesos, ya que el sistema operati­ vo controla todos los canales de com unicaciones de la com putadora. En una red de com putado­ ras, la situación es bastante distinta. Una com putadora conectada a la red recibe bits desde el exterior, y no tiene ninguna form a inm ediata y fiable de determ inar qué m áquina o aplicación ha

Capítulo 15 Seguridad

enviado esos bits. De form a sim ilar, la propia com putadora envía bits hacia la red sin tener n in ll gim a form a de determ inar quién puede llegar a recibirlos. f Com únm ente, se utilizan las direcciones de red para inferir los em isores y receptores potencia-! les de los m ensajes que circulan por la red. Los paquetes de red llegan con una dirección de o n -i gen, com o por ejem plo una dirección IP. Y cuando una com putadora envía un m ensaje, indica! quién es el receptor pretendido del m ism o especificando una dirección de destino. Sin em bargo,! para aquellas aplicaciones,en las que la seguridad tenga im portancia, correríam os el riesgo de! m etem os en problem as si asum iéram os que la dirección de origen o de destino de un paquete per-í m iten determ inar con fiabilidad quién ha enviado o recibido dicho paquete. U na computadora* m aliciosa podría enviar un m ensaje con una dirección de origen falsificada y, asim ism o, otrasj m uchas com putadoras distintas de la especificada por la dirección de destino podrían (y normal­ m ente lo hacen) recibir un paquete. P or ejem plo, todos los encam inadores situados en la ruta hacia! el destino recibirán tam bién el paquete. ¿C óm o puede, entonces, decidir el sistem a operativo si^ debe conceder una solicitud, cuando no puede confiar en el origen especificado en dicha solici­ tud? ¿Y cóm o se supone que debe proporcionar protección para una solicitud o para un conjuntó i de datos, cuando no puede determ inar quién recibirá la respuesta o el contenido del m ensaje que! envíe a través de la red? Jj G eneralm ente, se considera im practicable construir una red (de cualquier tam año) en la que se! pueda “confiar” en este sentido en las direcciones de origen y destino de los paquetes. Por tanto,, la única alternativa es elim inar, de alguna m anera, la necesidad de confiar en la red; este es el tra­ bajo de la criptografía. D esde un punto de vista abstracto, la crip to g rafía se utiliza para restringir! los em isores y/o receptores potenciales de un m ensaje. La criptografía m oderna se basa en unai serie de secretos, denom inados claves, que se distribuyen selectivam ente a las com putadoras de| una red y se utilizan para procesar m ensajes. La criptografía perm ite al receptor de un m en saje verificar que el m ensaje ha sido creado p o r alguna com putadora que posee una cierta clave: esa| clave es el origen del m ensaje. De form a sim ilar, un em isor puede codificar su m ensaje de modoj que sólo una com putadora que disponga de una cierta clave pueda decodificar el m ensaje, del m anera que esa clave se convierte en el destino. S in em bargo, a diferencia de las direcciones de redZa las claves están diseñadas de m odo que no sea com putacionalm ente factible calcularlas a partir d é ­ los m ensajes que se hayan generado con ellas, n i a partir de ninguna otra inform ación pública. Por tanto, las claves proporcionan un m edio m ucho m ás fiable de restringir los em isores y receptores: de los m ensajes. O bserve que la criptografía es un cam po de estudio com pleto por derecho pro­ pio, con una gran com plejidad; aquí, vam os a explorar únicam ente los aspectos m ás importantes de aquellas partes de la criptografía que se relacionan con los sistem as operativos.

15.4.1 Cifrado Puesto que ayuda a resolver una am plia variedad de problem as de seguridad de las com unicacio­ nes, el cifrado se utiliza frecuentem ente en m uchos aspectos de la inform ática m oderna. El cifra­ do es un m edio de restringir los posibles receptores de un m ensaje. U n algoritm o de cifradoperm ite al em isor de un m ensaje garantizar que sólo pueda leer el m ensaje una com putadora que posea una cierta clave. El cifrado de m ensajes es una práctica m uy antigua, por supuesto, y han existido m uchos algoritm os de cifrado, anteriores incluso a la época de César. En esta sección, vam os a describir los algoritm os y principios m odernos m ás im portantes del cifrado. La Figura 15.7 m uestra un ejem plo de dos usuarios que se com unican de m anera segura a tra­ vés de un canal inseguro. A lo largo de toda la sección harem os referencia a esta figura. Observe que el intercam bio de claves puede tener lugar directam ente entre las dos partes o a través de una tercera parte de confianza (es decir, una autoridad de certificación) com o se explica en la Sección 15.4.1.4. U n algoritm o de cifrado consta de los siguientes com ponentes: • Un conjunto K de claves. • Un conjunto M de m ensajes. • U n conjunto C de m ensajes de texto cifrado.

15.4 La criptografía como herramienta de seguridad

527

Figura 15.7 Una comunicación segura a través de un medio inseguro. • U na función E: K —» (M —» Q . Es decir, para cada k e K, E(k) es una función para generar m ensajes de texto cifrado a partir de los m ensajes de texto en claro. Tanto E com o E(k) para cualquier k deben ser funciones com putables de m anera eficiente. • U na función D: K - » (C -» M ). Es decir, para cada k e K, D(k) es una función para generar m ensajes de texto en claro a partir de los m ensajes de texto cifrado. Tanto D com o D(k) para cualquier k deben ser funciones eficientem ente com putables. U n algoritm o de cifrado debe proporcionar esta propiedad esencial: dado un m ensaje de texto cifrado c e C, una com putadora puede calcular m tal que E(k)(m) = c sólo si posee D(k). Así, una com putadora que posea D (k) puede descifrar los m ensajes de texto cifrado para obtener los m en­ sajes de texto en claro que se usaron para producirlos, pero una com putadora que no posea D(k) no puede descifrar esos m ensajes cifrados. Puesto que los m ensajes cifrados están generalm ente expuestos (por ejem plo, enviándolos a través de la red), es im portante que no se pueda deducir D(k) a partir de los m ensajes cifrados. Existen dos tipos principales de algoritm os de cifrado: sim étricos y asim étricos. Vam os a ana­ lizar am bos tipos de algoritm os en las siguientes secciones. 15.4.1.1 C ifrad o sim étrico En un algoritm o de cifrad o sim étrico, se utiliza la m ism a clave para cifrar y para descifrar, es decir, E(k) puede deducirse a partir de D(k) y viceversa. Por tanto, es necesario proteger el secre­ ta de. E(k) con el m ismo grado que el de D(k).

528

Capítulo 15 Seguridad

En los últim os 20 años, el algoritm o de cifrado sim étrico más com únm ente utilizado en los Estados U nidos para aplicaciones civiles ha sido el estándar D E S (data-encryption standard) adoptado por el N IST (N ational Institute of Standards and Technology). DES funciona tomando un valor de 64 bits y una clave de 56 bits y realizando una serie de transform aciones. Estas trans­ form aciones están basadas en operaciones de sustitución y perm utación, com o suele ser general­ m ente el caso para las transform aciones de cifrado sim étricas. A lgunas de las transformaciones son de las denom inadas tran sform acion es de caja negra, en el sentido de que sus algoritm os están ocultos. De hecho, estas denom inadas “cajas S ” son inform ación clasificada por el gobierno de los Estados Unidos. Los m ensajes de más de 64 bits se descom ponen en fragm entos de 64 bits y los bloques que tengan una m enor longitud se rellenan con el fin de com pletar el tam año de bloque requerido. Puesto que D ES opera sobre un conjunto de bits sim ultáneam ente, se denom ina algo­ ritm o de cifrado de blo q u e. Si se utiliza la m ism a clave para cifrar una gran cantidad de datos, esa clave com ienza a ser vulnerable a los ataques. Considere, por ejem plo, que un m ism o bloque fuente generaría el m ism o texto cifrado si se utilizaran la m ism a clave y el m ism o algoritm o de cifrado; en consecuencia, esos fragm entos no sólo se cifran sino que tam bién se hace una opera­ ción XO R con el bloque de texto cifrado anterior antes de proceder al cifrado. Este m ecanism o se conoce con el nom bre de en cad en am iento de b lo q u es cifrados. D ES se considera ahora inseguro para m uchas aplicaciones, porque se puede realizar una exploración exhaustiva de las claves utilizando unos recursos inform áticos no excesivamente grandes. Sin em bargo, en lu gar de abandonar DES, el NIST diseñó una m odificación denomina­ da trip le D E S , en la que el algoritm o D ES se repite tres veces (dos cifrados y un descifrado) sobre un m ism o texto en claro, utilizando dos o tres claves; por ejem plo, c = E(k3)(D(k2)(E(K 1)(tn))). Cuando se utilizan tres claves, la longitud efectiva de clave es de 168 bits. Hoy en día, el algorit­ mo triple D ES se utiliza m uy am pliam ente. En 2001, el N IST adoptó un nuevo algoritm o de cifrado, denom inado A ES (advanced encryption standard), para sustituir a DES. El algoritm o A ES es otro algoritm o de cifrado de bloques sim étricos. Puede utilizar longitudes de clave de 1 2 8 ,1 9 2 y 256 bits y funciona sobre bloques de 128 bits. O pera realizando entre 10 y 14 rondas de transform aciones sobre una m atriz form ada a partir de un cierto bloque de datos. G eneralm ente, el algoritm o es bastante com pacto y eficiente. H ay varios otros algoritm os de cifrado de bloque sim étricos que se utilizan hoy en día y que conviene m encionar. El algoritm o tw ofish es rápido, com pacto y fácil de Ím plementar. Puede uti­ lizar una longitud variable de clave de hasta 256 bits y opera sobre bloques de 128 bits. RC 5 per­ m ite variar la longitud de clave, el núm ero de transform aciones y el tam año de bloque; puesto que sólo usa operaciones de cálculo básicas, puede ejecutarse sobre una am plia variedad de procesa­ dores. RC 4 es, quizás, el algoritm o de cifrado de flujo más com ún. Un algoritm o de cifrado de flujo está diseñado para cifrar y descifrar un flujo de bytes o bits, en lugar de un bloque. Esto resulta útil cuando la longitud de una com unicación pueda hacer que un algoritm o de cifrado de bloques sea dem asiado lento. La clave se introduce en un generador de bits pseudoaleatorio, que es un algoritm o que trata de producir bits aleatorios. La salida del generador, cuando se le alim enta con una clave, es lo que se denom ina flujo de clave. Un flu jo de clave es un conjunto infinito de cla­ ves que pueden usarse para el flujo de texto en claro que se proporcione com o entrada. RC4 se uti­ liza para cifrar flujos de datos, com o por ejem plo en W EP, el protocolo de LAN inalámbrica. Tam bién se lo utiliza en las com unicaciones entre exploradores y servidores web, com o se expli­ ca m ás adelante. Desafortunadam ente, se ha dem ostrado que RC4, tal com o se lo utiliza en WEP (estándar IEEE 802.11) puede rom perse utilizando una cantidad razonable de tiempo de procesa­ miento. De hecho, el propio RC4 tiene vulnerabilidades inherentes. 15.4.1.2 C ifrado asim étrico En un algoritm o de cifrado asim étrico, las claves de cifrado y descifrado son distintas. Aquí, vam os a describir uno de tales algoritm os, conocido con el nom bre RSA debido a las iniciales de los nom bres de sus inventores (Rivest, Sham ir y Adlem an). El algoritm o RSA de cifrado es un algoritm o de cifrado de bloque de clave pública y es el algoritm o asim étrico más am pliam ente uti

J-

15.4 La criptografía como herramienta de seguridad

Figura

529

15.8 Cifrado y descifrado usando criptografía asimétrica RSA.

lizado. Sin em bargo, los algoritm os asim étricos basados en curvas elípticas están ganando cada vez más terreno, porque la longitud de clave de dichos algoritm os puede ser más corta para un grado determ inado de fortaleza criptográfica. Resulta im practicable, desde el punto de vista com putacional, deducir D(kd, N) a partir de E(ke, N), por lo que no es necesario m antener E(ke, N) en secreto y dicha clave puede ser am plia­ m ente disem inada; por tanto, E{ke, N) (o sim plem ente í.;,) es la clave p ú b lica y D(kd, N) (o sim ple­ m ente kd) es la clave privada. :Y es el producto de dos núm eros prim os de gran m agnitud p y q aleatoriam ente seleccionados (por ejem plo, p y q podrían tener 512 bits cada uno). El algoritm o de cifrado es E(ke, N)(m) = mke mod N, donde kc satisface la ecuación kj A). Es decir, para cada k e K, S(k) es una función para generar autenticadores a partir de los m ensajes. Tanto S com o S(k) para cualquier k deben ser fun­ ciones com putacionalm ente eficientes. • U na función V : K —» (M x A —> ( t r u e , f a l s e } ) . Es decir, para cada k e K, V(k) es una fun­ ción para verificar autenticadores de los m ensajes. Tanto V com o V(k) para cualquier k deben ser funciones eficientem ente com putables. La propiedad crítica que u n algoritm o de autenticación debe poseer es esta: para un mensaje m, una com putadora puede generar un autenticador a e A tal que V(k)(m, a) = t r u e sólo si posee S(k). Así, una com putadora que posea S(k) podrá generar autenticadores para los m ensajes de m odo que cualquier otra com putadora que posea V(k) pueda verificarlo. Sin em bargo, una com ­ putadora que no tenga S(k) no podrá generar autenticadores para los m ensajes que puedan veri­ ficarse utilizando V(k). Puesto que los autenticadores están generalm ente expuestos (por ejemplo, cuando se los envía a través de la red con los propios m ensajes), no debe ser factible deducir S(k) a partir de los autenticadores. Al igual que hay dos algoritm os de cifrado, hay tam bién dos variedades principales de algorit­ m os de autenticación. El prim er paso para com prender estos algoritm os consiste en analizar las funciones hash. U na fu n ció n h a s h crea un pequeño bloque de datos de tam año fijo, conocido como resu m en de m e n sa je o v alor h a s h , a partir de un m ensaje dado. Las funciones hash operan tom ando un m ensaje en bloques de n bits y procesando los bloques para generar un valor hash de n bits. H debe ser resistente a las colisiones con respecto a m, es decir, no debe ser factible calcu­ lar un m' * m tal que H(m) = H(m '). En estas condiciones, si H (m ) = H(m') sabem os que m 1 = m2, es decir, que el m ensaje no ha sido m odificado. Entre las funciones m ás com unes de cálculo de j-

15.4 La criptografía como herramienta de seguridad

531

resúmenes de mensajes podemos citar MD5, que produce un valor hash de 128 bits y SHA-1, que genera un valor hash de 160 bits. Los resúmenes de mensajes resultan útiles para detectar los mensajes modificados, pero no sir­ ven como autenticadores. Por ejemplo, podemos enviar H(m) junto con un mensaje; pero si H es conocida, entonces alguien podría modificar m y recalcular H(m) y la modificación del mensaje nos sería detectada. Por tanto; se utiliza un algoritmo de autenticación para tomar el resumen del mensaje y cifrarlo. El primer tipo de algoritmo de autenticación utiliza cifrado simétrico. En un cód igo de au ten ­ tica ció n de m en sajes (MAC, message-authentication code), se genera una suma de comprobación criptográfica a partir del mensaje utilizando una clave secreta. El conocimiento de V(k) y el cono­ cimiento de S(k) son equivalentes: podemos derivar una función a partir de la otra, por lo que es necesario mantener secreto el valor de k. Un ejemplo simple de código MAC define S(k)(m) = f(k, H(m)), donde / es una función de una sola dirección con respecto a su primer argumento es decir, no puede deducirse k a partir de/ (k, H(m)). Debido a la propiedad de resistencia a las coli­ siones de la función hash, podemos estar razonablemente seguros de que ningún otro mensaje permita crear el mismo valor MAC. Un algoritmo de verificación apropiado será entonces V(k) (m, a) s (f(k, m) = a). Observe que se necesita k para calcular tanto S(k) como V(k), por lo que cual­ quiera que sea capaz de calcular esas funciones podrá calcular también la otra. El segundo tipo principal de algoritmo de autenticación es el algoritmo de firma digital, y los autenticadores generados por uno de estos algoritmos se denominan firmas digitales. En un algo­ ritmo de firma digital, no resulta computacionalmente factible deducir S(ks) a partir de V(kv); en particular, V es una función de una sola dirección. Por tanto, kv es la clave pública y ks es la clave privada. Considere como ejemplo el algoritmo de firma digital RSA. Es similar al algoritmo de cifrado RSA, pero la utilización de las claves se invierte. La firma digital de un mensaje se obtiene calcu­ lando S(ks)(m) = H(m)ks mod N. La clave ks es, de nuevo, una pareja (d, N), donde N es el produc­ to de dos números primos de gran magnitud p y q aleatoriamente elegidos. El algoritmo de verificación será entonces V(kv)(m, a) = (akv mod N = H(m)), donde kv satisface la ecuación kJcs mod ( p - l ) f o - l ) = l. Si el cifrado permite demostrar la identidad del emisor de un mensaje, entonces ¿por qué nece­ sitamos algoritmos de autenticación separados? Existen tres razones principales: • Generalmente, los algoritmos de autenticación requieren menos cálculos (con la excepción de las firmas digitales RSA). Con grandes cantidades de texto en claro, esto puede represen­ tar una enorme diferencia en el uso de recursos y en el tiempo necesario para autenticar un mensaje. • Un autenticador de un mensaje casi siempre es más corto que el mensaje y su texto cifrado correspondiente. Esto mejora el uso del espacio y reduce el tiempo de transmisión. • En ocasiones, deseamos disponer de la posibilidad de autenticación, pero no de la confiden­ cialidad. Por ejemplo, una empresa podría proporcionar un parche software y “firmar” dicho parche para demostrar que procede de la empresa y que no ha sido modificado. La autenticación es un componente de muchos aspectos de la seguridad. Por ejemplo, es la base de los mecanismos de no repudio, que proporcionan una demostración de que una determinada entidad ha realizado una cierta acción. Un ejemplo típico de no repudio sería la cumplimentación de formularios electrónicos como alternativa a la firma de contratos en papel. La característica de no repudio asegura que una persona que haya cumplimentado un formulario electrónico no pueda negar que lo ha hecho. 15.4.1.4 Distribución de claves Sin ninguna duda, una gran parte de la batalla entre criptógrafos (aquéllos que inventan los m eca­ nismos de cifrado) y criptoanalistas (aquéllos que intentan romperlos) se encuentra en las claves. Con los algoritmos simétricos, ambas partes necesitan la clave y ninguna otra persona debe ais-

Capítulo 15 Seguridad

poner de ella. La tarea de sum inistrar la clave sim étrica a sus usuarios legítim os constituye un reto im portante. En ocasiones, esa distribución se hace fu era de banda, por ejem plo m ediante un docum ento escrito o una conversación. Sin em bargo, estos m étodos no resultan adecuados para distribución de claves a gran escala y tam bién es necesario considerar el reto de la gestión de esas claves. Supongam os que un usuario desea com unicarse de form a privada con otros N usuarios. D icho usuario necesitaría .V claves y, para m ayor seguridad, tendría que cam biar dichas claves con frecuencia. Estas son las razones por las que se han hecho esfuerzos para crear algoritm os de clave asimé­ trica. N o sólo las claves se pueden intercam biar en público, sino que un determ inado usuario sólo necesita una clave privada, independientem ente de con cuántas personas desee el usuario com u­ nicarse. Queda todavía la cuestión de gestionar u na clave pública por interlocutor con el que se desee establecer com unicación, pero puesto que las claves públicas no necesitan ser seguras, puede utilizarse un m edio de alm acenam iento sim ple para im plem entar dicho an illo de claves. Lam entablem ente, incluso la distribución de claves públicas requiere que se tenga cierto cui­ dado. Considere el ataque por interposición m ostrado en la Figura 15.9. En este caso, la persona que desea recibir un m ensaje cifrado envía su clave pública, pero un atacante tam bién envía su, clave pública “m ala” (que se corresponde con su clave privada). La persona que desea enviar eT m ensaje cifrado desconoce esto y utiliza la clave m ala para cifrar el m ensaje. El atacante entonces lo descifra sin problem as.

escribir

F ig u ra 15,9

u n ataque por interposición en criptografía asim étrica.

15.4 La criptografía como herramienta de seguridad

533

El problema se encuentra en la autenticación; io que necesitam os es dem ostrar quién (o qué) posee una determ inada clave pública. Una form a de resolver este problem a consiste en utilizar certificados digitales. Un c e r tif ic a d o d ig ita l es una clave pública firmada digitalm ente por un organism o de confianza. El organism o de confianza recibe la prueba de identificación de alguna entidad y certifica que la clave pública pertenece a dicha entidad. Pero, ¿cóm o sabemos que el cer­ tificador es seguro? Estas a u to r id a d e s d e c e r tif ic a c ió n incluyen sus claves públicas en explorado­ res web (y otros consum idores de certificados) antes de que éstos sean distribuidos. Estas autoridades de certificación pueden entonces avalar a otras autoridades de certificación (firm an­ do digitalm ente las claves públicas de estas otras autoridades), y así crear una jerarquía de con­ fianza. Los certificados pueden distribuirse en un formato de certificado digital estándar X.509 que puede ser analizado por la com putadora. Este esquem a se em plea para conseguir una com u­ nicación w eb segura, com o se explica en la Sección 15.4.3.

15.4.2 Implementación de los m ecanism os criptográficos Usualm ente, los protocolos de red se organizan en n iv e le s , actuando cada nivel com o un cliente del nivel inferior. Es decir, cuando un protocolo genera un m ensaje para enviarlo a su correspon­ diente protocolo en otra m áquina, pasa su m ensaje al protocolo inferior de la pila de protocolos de red para que éste lo envíe a su correspondiente protocolo en dicha m áquina. Por ejem plo, en una red IP, el protocolo TCP (un protocolo de nivel de transporte) actúa com o un cliente de IP (un protocolo de nivel de red): los paquetes TCP se pasan al nivel IP para entregarlos al protocolo TCP que se encuentra en el otro extrem o de la conexión TCP. IP encapsula el paquete TCP en un paque­ te IP, el cual se pasa de form a sim ilar al nivel de enlace de datos inferior, para ser transm itido a tra­ vés de la red a su correspondiente protocolo IP en la com putadora de destino. Este protocolo IP entrega entonces el paquete TCP al protocolo TCP de dicha m áquina. En conjunto, el m o d e lo d e r e f e r e n c ia IS O , que se ha adoptado casi universalm ente com o m odelo para las redes de datos, define siete niveles de protocolo. En el C apítulo 16 se explica m ás en detalle el m odelo ISO; la Figura 16.6 m uestra un diagram a del m odelo. La criptografía puede incluirse en casi cualquier nivel del m odelo ISO. Por ejem plo, SSL (Sección 15.4.3) proporciona seguridad en el nivel de transporte. G eneralm ente, la seguridad del nivel de red se ha estandarizado en IPSec, que define form atos de los paquetes IP que perm iten la inserción de autenticadores y el cifrado del contenido de los paquetes. Utiliza cifrado sim étrico y el protocolo IKE para el intercam bio de claves. IPSec está em pezando a utilizarse de form a gene­ ralizada com o base de las r e d e s p riv a d a s v ir tu a le s (VPN, virtual prívate netw ork), en las que todo el tráfico entre dos puntos extrem os IPSec se cifra para construir una red privada utilizando una red que de otra m anera sería pública. Tam bién se han desarrollado num erosos protocolos para que los utilicen las.aplicaciones, aunque en este caso las propias aplicaciones deben program arse de modo que im plem enten los m ecanism os de seguridad. ¿E n q u é lu g a r d e la p ila d e p ro to co lo s es m e jo r in clu ir la p ro te c c ió n c rip to g rá fica ? E n g e n e ra l, n o h a y u n a re s p u e s ta d efin itiv a. P o r u n la d o , c u a n d o se in clu y e n las p ro te c cio n e s en la p a rte infe­ rio r d e la pila, h a y un n ú m e ro m a y o r d e p ro to c o lo s q u e p u e d e n b en eficiarse d e ellas. P o r e jem p lo , p u e sto q u e los p a q u e te s IP e n ca p s u la n p a q u e te s TCP, el cifra d o d e p a q u e te s IP (u sa n d o p o r eje m ­ p lo IPSec) tam b ién o cu lta el co n te n id o d e los p a q u e te s TCP e n ca p s u la d o s . D e fo rm a sim ila r, los a u te n tica d o re s d e lo s p a q u e te s IP d e te c ta n la m o d ifica ció n d e la in fo rm a ció n d e c a b e c e ra TCP c o n ­ te n id a en lo s p a q u e te s.

Por otro lado, la protección en los niveles inferiores de la pila de protocolos puede resultar insuficiente para los protocolos de los niveles superiores. Por ejem plo, un servidor de aplicacio­ nes que se ejecute sobre IPSec debe poder autenticar a las com putadoras cliente de las que se re c i­ ban solicitudes. Sin em bargo, para autenticar un usuario en una com putadora cliente, el servidor puede tener que utilizar un protocolo del nivel de aplicación, requiriendo, por ejem plo, que el usuario escriba una contraseña. Tam bién hay que considerar el problem a del correo electrónico. El correo electrónico sum inistrado a través del protocolo estándar SMTP se alm acena y reenvía, frecuentem ente m últiples veces, antes de ser entregado. Cada uno de estos saltos podría llevar a una red segura o a una red no segura. Para que el correo electrónico sea seguro, los m ensajes de

Capítulo 15 Seguridad

correo electrónico tienen que cifrarse de m anera que su seguridad sea independiente de los nive­ les de transporte utilizados para distribuirlos.

15.4.3 Un ejemplo: SSL SSL 3.0 es un protocolo criptográfico que perm ite que dos com putadoras se com uniquen de forma

segura; es decir, cada una de ellas puede establecer lim itaciones que garanticen que el transm isor o receptor de los m ensajes sea la otra com putadora. Es quizá el protocolo criptográfico más com únm ente em pleado actualm ente en Internet, dado que es el protocolo estándar m ediante el que se com unican de form a segura los exploradores w eb con los servidores w eb. H ay que hacer notar que SSL fue diseñado por N etscape y que ha evolucionado transform ándose en el estándar TLS. En esta exposición, em plearem os SSL para referim os tanto a SSL com o a TLS. SSL es un protocolo com plejo con m uchas opciones. A quí sólo vam os a presentar una de las variantes existentes, de form a m uy sim plificada y abstracta, con el fin de centrarnos en la utiliza­ ción de prim itivas criptográficas. Lo que vam os a ver es un com plejo sistem a en el que se usa la criptografía asim étrica de m anera que un cliente y un servidor puedan establecer una clave de sesión segura, que puede em plearse para cifrado sim étrico de la sesión m antenida por esos dos interlocutores, todo ello evitando los ataques por interposición y por repetición. Para aum entar la fortaleza criptográfica, las claves de sesión se olvidan una vez que la sesión se ha com pletado. O tra com unicación entre am bos interlocutores requerirá la generación de nuevas claves de sesión. El protocolo SSL es iniciado por un cliente c para com unicarse de form a segura con un servi­ dor s. A ntes de u tilizar el protocolo, se supone que el servidor s ha obtenido u n certificado, deno­ tado por certs, de una autoridad de certificación CA. Este certificado es una estructura que contiene lo siguiente: • Varios atributos a t t r s del servidor, tal com o su nom bre distintivo unívoco y su nom bre común (DNS). • La identidad de un algoritm o de cifrado público EQ para el servidor. • La clave pública ke de ese servidor. • Un intervalo de validez i n t e r v a l durante el que el certificado debe considerarse válido. • U na firm a digital a para la inform ación anterior, proporcionada por la certificación de auto­ ridad CA, es decir, a = S ( k CA) ( ( a t t r s , E ( k e), interval)) Adem ás, antes de usar el protocolo, se supone que el cliente ha obtenido el algoritm o público de verificación V(kCA) para la autoridad de certificación CA. En el casó de la W eb, el explorador del usuario sum inistrado por su proveedor contendrá los algoritm os de verificación y las claves públicas de determ inadas autoridades de certificación. El usuario puede añadir o elim inar autori­ dades de certificación según desee. Cuando c se conecta a s, envía un valor aleatorio nc de 28 bytes al servidor, el cual responde con un valor aleatorio ns generado por él, m ás su certificado certs. El cliente verifica que V^ca) (( attrs, E ( k e), interval ), a) = true y que el m om ento actual está dentro del intervalo de validez interval. Si am bas condiciones se satisfacen, el servidor ha dem ostrado su identidad. Entonces el cliente genera u n secreto prem aestro pms aleatorio de 46 bytes y envía al servidor cpms = E(ks)( pms). El servidor recupera pms = D (k ¿ (c pms). Ahora, tanto el cliente com o el servi­ dor están en posesión de nc, ns y pms, y cada uno de ellos puede calcular un secreto m aestro de 48 bytes ms = f( n c, n^ pms), donde f e s una función unidireccional resistente a colisiones. Sólo el servidor y el cliente pueden calcular ms, dado que sólo ellos conocen pms. A dem ás, la dependen­ cia de ms con respecto a n c y n s asegura que ms es un valor fresco; es decir, una clave de sesión que no se ha utilizado en ninguna com unicación anterior. En esta situación, el cliente y el servidor cal­ culan las claves siguientes a partir de ms: • Una clave de cifrado sim étrica ?c¿rypt para cifr ar m ensajes del díGnic si servidor. • Una clave de cifrado sim étrica k = J /pz para cifrar m ensajes del servidor al cliente.

15.5 Autenticación de usuario

• U na clave de generación te al servidor. • U na clave de generación vidor al cliente.

MAC MAC k™ c

535

para generar autenticadores para los m ensajes del clien­ para generar autenticadores para los m ensajes del ser­

Para enviar un m ensaje m al servidor, el cliente envía c = E ^ ) ( ( m ,S ( k ™ ) ( m ) ) ) Al recibir c, el servidor recupera ( m , a ) = D ( k ? pt)(c) y acepta m si V(k™K )(m ,a ) — true. De form a sim ilar, para enviar un m ensaje m al cliente, el servi­ dor envía c = E ( k ^ ' ) ( { m ,S ( k r m ) ) y el cliente recupera (m,a) = D (k ^ )(c) y acepta m si = true. Este protocolo perm ite al servidor lim itar los receptores de sus m ensajes al cliente que generó el pms y lim itar tam bién a dicho cliente los em isores de los m ensajes que acepta. De form a sim i­ lar, el cliente puede lim itar los receptores de los m ensajes que envía y el em isor de los m ensajes que acepta al interlocutor que conoce S(kd)(es decir, al interlocutor que puede descifrar cpms). En m uchas aplicaciones, com o por ejem plo las transacciones w eb, el cliente necesita verificar la iden­ tidad del interlocutor que conoce S(kd). Éste es uno de los propósitos del certificado c e r t s; en par­ ticular, el cam po a t t r s contiene inform ación que el cliente puede em plear para determ inar la identidad (por ejem plo, el nom bre de dom inio) del servidor con el que se está com unicando. Para aplicaciones en las que el servidor tam bién necesita inform ación acerca del cliente, SSL proporcio­ na una opción m ediante la que un cliente puede enviar un certificado al servidor. A dem ás de su uso en Internet, SSL se em plea actualm ente en una am plia variedad de tareas. Por ejem plo, ahora las redes privadas virtuales IPSec tienen un com petidor en las redes privadas virtuales SSL. IPSec resulta adecuado para el cifrado de tráfico punto a punto, por ejemplo entre dos oficinas de una em presa. Las VPN SSL son m ás flexibles pero no tan eficientes, por lo que p u e­ den utilizarse, por ejem plo, para la com unicación entre un em pleado concreto que trabaje en m odo rem oto y su oficina.

15.5 Autenticación de usuario La exposición anterior sobre autenticación hacía referencia a m ensajes y sesiones, pero, ¿qué pasa con los usuarios? Si un sistem a no puede autenticar a un usuario, entonces autenticar un m ensa­ je procedente de dicho usuario no sirve de nada. P or tanto, un problem a de seguridad im portan­ te en los sistem as operativos es el de la au tenticación de usuario. El sistem a de protección depende de la capacidad de identificar los program as y procesos que están actualm ente en ejecu­ ción, lo que a su vez depende de la capacidad de identificar a cada usuario del sistema. N orm alm ente, cada usuario se identifica a sí m ism o. ¿Cóm o podem os determ inar si la identidad de un usuario es auténtica? Generalm ente, la autenticación de usuario se basa en una o más de tres cuestiones: la posesión de algo (una clave o tarjeta) por parte del usuario, el conocim iento de algo (un identificador de usuario y una contraseña) por parte del usuario y/o un atributo del usuario (huella digital, patrón retinal o firma).

D JO

c _ a p iiu io

id

oegu nu au

15.5.1 Contraseñas El m étodo m ás habitual para autenticar la identidad de un usuario consiste en usar co n tra se ñ a s. Cuando el usuario se identifica a sí m ism o m ediante un ID de usuario o un nom bre de cuenta, se le pide una co n traseñ a Si la contraseña sum inistrada por el usuario coincide con la contraseña^ alm acenada en el sistem a, el sistem a supone que el propietario de la cuenta está accediendo a la” m ism a. A m enudo, en ausencia de esquem as de protección m ás com pletos, se usan contraseñas para” proteger objetos del sistem a inform ático. Las contraseñas pueden considerarse un caso especial de"' las claves o de las capacidades. Por ejem plo, una contraseña podría estar asociada con un recurso* (por ejem plo, un archivo): si se hace una solicitud para usar el recurso, debe proporcionarse la , contraseña; si ésta es correcta, se concede el acceso. Pueden asociarse diferentes contraseñas con distintos derechos de acceso. Por ejem plo, pueden em plearse diferentes contraseñas para leer archivos, añadir inform ación a archivos y actualizar archivos. En la práctica, la m ayoría de los sistem as sólo requieren una contraseña para que el usuario pueda adquirir todos los derechos. A unque, en teoría, cuantas m ás contraseñas, m ayor será lá* seguridad, tales sistem as no suelen im plem entarse debido al clásico com prom iso entre seguridad y com odidad. Si la seguridad produce incom odidad, entonces frecuentem ente la seguridad se pasa por alto o se evita de alguna m anera. »

15.5.2 Vulnerabilidades de las contraseñas Las contraseñas son extrem adam ente com unes porque son fáciles de com prender y utilizar!" Lam entablem ente, a m enudo pueden adivinarse, ser m ostradas por accidente, ser interceptadas ó"' ser ilegalm ente transferidas por un usuario autorizado a otro que no lo está, com o vam os a ver a* continuación. t» Existen dos form as habituales de adivinar una contraseña. U na form a consiste en que el intru­ so (persona o program a) conoce al usuario o tiene inform ación acerca de él. Con dem asiada fre­ cuencia, las personas em plean com o contraseñas inform aciones obvias, como los nom bres de sus m ascotas o de sus parejas. O tra form a consiste en em plear la fu erza bruta, probando a enumerar todas las posibles com binaciones form adas por caracteres válidos de la contraseña (letras, núme­ ros y algunos sím bolos de puntuación) hasta encontrar la contraseña. Las contraseñas cortas son especialm ente vulnerables a este m étodo. Por ejem plo, una contraseña de cuatro dígitos decima­ les sólo da lugar a 10.000 posibles variaciones. Com o prom edio, probar 5000 posibilidades nos daría la contraseña correcta. U n program a que probara una contraseña por m ilisegundo sólo tar­ daría unos 5 segundos en adivinar una contraseña de cuatro dígitos. Este m étodo de enum eración no tiene tanto éxito en los sistem as que perm iten em plear contraseñas más largas, que incluyan tanto letras m ayúsculas com o m inúsculas, adem ás de núm eros y todos los caracteres de puntua­ ción. Por supuesto, los usuarios deben aprovechar la longitud de la contraseña y no deben, por ejem plo, em plear sólo letras m inúsculas. A dem ás de poder ser adivinadas, las contraseñas pueden averiguarse m ediante mecanism os de m onitorización visual o electrónica. U n intruso puede m irar por encim a del hom bro del usua­ rio cuando el usuario está iniciando una sesión y aprenderse la contraseña fácilm ente mirando el teclado. A lternativam ente, cualquiera con acceso a la red en la que reside la com putadora puede añadir sin problem as un m onitor de red, que le perm ita ver todos los datos que estén siendo trans­ feridos a través de la red, actividad que se conoce con el nom bre de husm ear (sn iffin g ), incluyen­ do los ID de usuario y las contraseñas. El cifrado del flujo de datos que contiene la contraseña resuelve este problem a. Sin em bargo, incluso en un sistem a de este tipo podrían robarse las con­ traseñas. Por ejem plo, si se em plea un archivo para guardar las contraseñas, podría copiarse para llevar a cabo un análisis externo al sistem a. O puede tenerse instalado un caballo de Troya en el sistem a, que capture las pulsaciones de tecla antes de ser enviadas a la aplicación. La exposición de las contraseñas puede ser un problem a im portante si éstas se escriben en un lugar donde puedan ser leídas o donde puedan perderse. Com o verem os, algunos sistem as fuer­ zan a los usuarios a seleccionar contraseñas difíciles de recordar o m uy largas, lo que da lugar a

J-

15.5 Autenticación de usuario

537

que el usuario la apunte o la reutilice. Com o resultado, tales sistem as proporcionan m ucha m enos seguridad que los sistem as que perm iten a los usuarios elegir contraseñas fáciles. El últim o tipo de am enaza relativa a las contraseñas, la transferencia ilegal, es resultado de la propia naturaleza hum ana. La m ayor parte de las instalaciones de com putadoras tienen una regla que prohibe a los usuarios com partir cuentas. En ocasiones, esta regla se im plem enta por razones contables, pero con frecuencia se im pone para m ejorar la seguridad. Por ejem plo, supongam os que varios usuarios com parten un m ism o ID de usuario y que se produce una brecha de seguri­ dad que afecta a dicho ID de usuario. Es im posible saber quién estaba usando el ID en el m om en­ to en que se produjo la brecha e incluso si se trataba de un usuario autorizado. Con un ID para cada usuario, es posible preguntar directam ente a cualquier usuario sobre el uso de la cuenta; ade­ m ás, el usuario puede detectar que algo ocurre en la cuenta y detectar la introm isión. Algunas veces, los usuarios incum plen las reglas de com partición de cuentas para ayudar a sus am igos o para esquivar los m ecanism os contables, y este com portam iento puede dar lugar a accesos al sis­ tem a, posiblem ente dañinos, por parte de usuarios no autorizados. Las contraseñas pueden ser generadas por el sistem a o seleccionadas por el usuario. Las con­ traseñas generadas por el sistem a pueden ser difíciles de recordar, por lo que en consecuencia los usuarios las anotarán. Sin em bargo, com o se ha m encionado anteriorm ente, a m enudo las contra­ señas seleccionadas por los usuarios son fáciles de adivinar (el nom bre del usuario o su coche favorito). Algunos sistem as com probarán una contraseña propuesta antes de aceptarla, para ver si resulta fácil su adivinación. En algunos sitios, los adm inistradores com prueban ocasionalm en­ te las contraseñas de usuario e inform an al usuario de que su contraseña es fácil de adivinar. A lgunos sistem as tam bién controlan la edad de las contraseñas, forzando a los usuarios a cam biar­ las a intervalos regulares de tiem po (por ejem plo, cada tres m eses). Este m étodo no es a toda prue­ ba, ya que los usuarios pueden alternar entre dos contraseñas. La solución, tal y com o se ha im plem entado en algunos sistem as, consiste en registrar un historial de contraseñas para cada usuario. Por ejem plo, el sistem a puede guardar las N últim as contraseñas y no perm itir que se reutilicen. Pueden em plearse diversas variantes de estos sencillos esquem as de contraseñas. Por ejem plo, la contraseña puede cam biarse con una m ayor frecuencia. En el caso extrem o, la contraseña se cam biaría en cada sesión: al final de la sesión, el sistem a o el usuario selecciona una nueva contra­ seña, que se em pleará en la sesión siguiente. En este caso, incluso aunque una contraseña se use mal, sólo se em pleará una vez. Cuando el usuario legítim o intente utilizar una contraseña no váli­ da en la siguiente sesión, descubrirá que ha habido una violación de la seguridad. Entonces, debe­ rá seguir los pasos necesarios para reparar la brecha de seguridad.

15.5.3 Contraseñas cifradas^ Un problem a que plantean todos estos m étodos es la dificultad de m antener en secreto la contra­ seña dentro de la com putadora. ¿Cóm o puede alm acenar el sistem a una contraseña de form a segura para que el m ecanism o de autenticación pueda utilizarla cuando el usuario especifique su contraseña? Los sistem as UNIX utilizan el cifrado para evitar la necesidad de m antener en secreto su lista de contraseñas. C ada usuario tiene una contraseña. El sistem a contiene una función que es extrem adam ente difícil (los diseñadores esperan que im posible) de invertir, pero fácil de calcu ­ lar. Es decir, dado un valor x, es fácil calcular el valor de la función/(x). Sin em bargo, dado un valor de la función /(x), es im posible calcular x. Esta función se em plea para codificar todas las contraseñas y sólo se alm acenan las contraseñas codificadas. Cuando un usuario presenta una contraseña, se codifica y se com para con la contraseña codificada que se tiene alm acenada. Aunque esta contraseña codificada pueda verse, no puede decodificarse, por lo que no es posible determ inar la contraseña real. Por tanto, no es necesario m antener en secreto el archivo de contra­ señas. La función/(x) es, norm alm ente, un algoritm o de cifrado que se ha diseñado y probado de form a rigurosa. El fallo de este m étodo es que el sistem a ya no tiene el control sobre las contraseñas. A unque las contraseñas se cifren, cualquiera que disponga de una copia del archivo de contraseñas puede >

58

Capítulo 15 Seguridad

ejecutar rutinas de cifrado rápido, cifrando cada palabra en un diccionario, por ejem p lo , y com pa­ rando los resultados con las contraseñas alm acenadas. Si el usuario ha seleccio n ad o una contrase­ ña que sea una palabra contenida en el diccionario, este sistem a perm itirá ro m p er la contraseña. En com putadoras lo suficientem ente rápidas o incluso en clusters de co m p u tad oras lentas, talcom paración puede llevar sólo unas pocas horas. A dem ás, dado qu e los sistem as UNIX utilizan un algoritm o de cifrado bien conocido, un cracker puede m antener una caché de.contraseñas que haya roto previam ente. Por estas razones, las nuevas versiones de UNIX alm acenan la s en trad as de con­ traseñas cifradas en un archivo que sólo puede leer el superu su ario. Los p ro g ram as que com pa­ ran una contraseña especificada por el usuario con la contraseña alm acenada ejecu tan s e t u i d con la cuenta root, de m odo qu e pueden leer este archivo, pero otros usuarios no p u ed en. Tam bién incluyen un aleatorizador, o núm ero aleatorio grabado, en el algoritm o de cifrad o. E l aleatorizador se añade a la contraseña para asegurar que, si dos contraseñas son iguales sin cifrar, darán lugar a contraseñas cifradas diferentes. O tra debilidad de los m étodos de contraseñas de UNIX es que m uchos sistem as UNIX sólo tra­ tan los ocho prim eros caracteres com o significativos. Por tanto, es extrem ad am ente im portante para los usuarios aprovecharse del espacio de contraseñas disponible. P ara ev ita r el m étodo d e; análisis basado en diccionario, algunos sistem as no perm iten el uso de p alabras del diccionario^ com o contraseñas. U na bu ena técnica consiste en generar la contraseña usando la prim era letra de cada palabra de una frase q u e sea fácil de recordar, usando tanto letras m ayú scu las com o m inús- ; culas, adem ás de u n núm ero o u n signo de puntuación. Por ejem plo, la frase “E l nom bre de mi-, m adre es C atalina” podría dar la contraseña “Endm m .esC ”. L a contraseña es d ifícil de romper,® pero el usuario puede recordarla rápidam ente. a

15.5.4 Contraseñas de un solo uso

-

,

-;'

16.3 Estructura de una red

563

La otra técnica consiste en perm itir (o exigir) al usuario que especifique explícitam ente cómo debe m igrar el proceso. Este m étodo suele em plearse cuando es necesario m over el proceso para satisfacer unas preferencias hardw are o softw are. Probablem ente se haya dado cuenta el lector de que la W eb presenta m uchos de los aspectos de un entorno inform ático distribuido. Ciertam ente, proporciona m ecanism os de m igración de datos (entre un servidor w eb y un cliente web) y tam bién de m igración de los cálculos. Por ejem ­ plo, un cliente w eb puede hacer que se ejecute una operación de base de datos en un servidor web. Por últim o, gracias a Java, proporciona una form a de m igración de procesos. Las applets Java se envían desde el servidor al cliente, donde se las ejecuta. U n sistem a operativo de red proporciona la m ayoría de estas funciones, pero un sistem a operativo distribuido hace que esas funciones sean transparentes y fácilm ente utilizables. El resultado es un conjunto de funcionalidades potente y fácil de usar, lo que constituye una de las razones para el enorm e crecim iento de la W orld W ide W eb.

16.3 Estructura de una red Existen básicam ente dos tipos de redes: red es de área lo cal (LAN, local-area network) y redes de área exten sa (WAN, w ide-area netw ork). La principal diferencia entre los dos tipos es la form a en que están distribuidas geográficam ente. Las redes de área local están com puestas de procesado­ res distribuidos en un área pequeña (como por ejem plo un único edificio o un conjunto de edifi­ cios adyacentes), m ientras que las redes de área extensa están com puestas de una serie de procesadores autónom os distribuidos en una área de gran tam año (com o por ejem plo todo un país). Estas diferencias im plican variaciones im portantes en la velocidad y la fiabilidad de la red de com unicaciones y están reflejadas en el diseño del propio sistem a operativo distribuido.

16.3.1 Redes de área local Las redes de área local surgieron a principios de la década de 1970 com o sustituto de los grandes sistem as inform áticos basados en mainframe. Para m uchas em presas, resulta m ás económ ico dis­ poner de una serie de pequeñas com putadoras, cada una con sus propias aplicaciones autocontenidas, que adquirir un único sistem a de gran tam año. Puesto que resulta probable que cada pequeña com putadora necesite un conjunto com pleto de dispositivos periféricos (como por ejem ­ plos discos e im presoras) y com o tam bién es probable que tenga lugar algún tipo de com partición de datos en toda organización, resulta un paso natural conectar estos sistem as de pequeño tam a­ ño m ediante una red. Las redes LAN, com o y a hem os m encionado, están usualm ente diseñadas para cubrir un área geográfica pequeña (com o por ejem plo un edificio o un conjunto de edificios adyacentes) y se uti­ lizan generalm ente en u n entorno de oficina. Todos los nodos en dicho tipo de sistemas están pró­ ximos entre sí, por lo que los enlaces de com unicaciones tienden a tener u na m ayor velocidad y una m enor tasa de errores que sus equivalentes en la redes de área extensa. Se necesitan cables de alta calidad (costosos) para obtener esta alta velocidad y fiabilidad. Tam bién es posible utilizar el cable exclusivam ente para el tráfico de la red de datos. Para distancias m ayores el coste de utili­ zar cable de alta calidad es enorm e y el uso exclusivo del cable tiende a ser prohibitivo. Los enlaces m ás com unes en una red de área local son los de par trenzado y de fibra óptica. Las configuraciones m ás com unes son el bus m ultiacceso y las redes en anillo y en estrella. Las velocidades de com unicación van desde 1 m egabit por segundo, para redes tales como AppleTalk, infrarrojos y la nueva red de radio local Bluetooth, hasta 1 gigabit por segundo para gigabit Ethernet. La velocidad m ás com ún es de 10 m egabits por segundo y esa es la que se em plea en lO B aseT Ethernet. lOOBaseT Ethernet requiere un cable de m ayor calidad, pero trabaja a 100 m egabits por segundo y está siendo cada vez más com ún. Tam bién está creciendo el uso de redes FDDI basada en fibrp óptica. La red RDDí utiliza un m ecanism o de paso de testigo y trabaja a más de 100 m egabits por segundo. Una LAN típica puede estar com puesta por varias com putadoras de diferentes tipo (desde com ­ putadoras de tipo m ainfram e a portátiles o dispositivos PDA), diversos dispositivos periféricos

Capítulo 16 Estructuras de los sistemas distribuidos

Servidor de aplicaciones

Estación de trabajo

Estación de trabajo

s»;

Impresora

Estación de trabajo

Pasarela

Portátil

Servidor de archivos

Figura 16.2 Red de área local. com partidos (com o im presoras láser y unidades de cinta m agnética) y una o m ás pasarelas (pro­ cesadores especializados) qu e proporcionan acceso a otras redes (Figura 16.2). Para construir redes LAN se utiliza com únm ente un esquem a Ethernet. U na red Ethernet no tiene ningún contro­ lador central, porque se trata de un bus m ultiacceso, por lo que pueden añadirse fácilm ente nue­ vos hosts a la red. El protocolo Ethernet está definido por el estándar IEEE 802.3.

16.3.2 Redes de área extensa Las redes de área extensa surgieron a finales de la década de 1960, fundam entalm ente com o un proyecto académ ico de investigación destinado a proporcionar un m ecanism o eficiente de com u­ nicación entre sitios, perm itiendo que una am plia com unidad de usuarios com partiera el hardwa­ re y el softw are de form a cóm oda y económ ica. La prim era red WAN que se diseñó y desarrolló fue A rpanet. Iniciada en 1968, A rpanet ha crecido enorm em ente, pasando dé ser una red experi­ m ental com puesta de cuatro nodos a una red m undial de redes, Internet, com puesta por millones de sistem as inform áticos. Puesto que los nodos de una WAN están físicam ente distribuidos en un área geográfica de gran tam año, los enlaces de com unicaciones son, de form a predeterm inada, relativam ente lentos y poco fiables. Los enlaces m ás típicos son las líneas telefónicas, las líneas arrendadas (líneas de datos dedicadas), los enlaces de m icroondas y los canales de com unicación vía satélite. Estos enla­ ces de com unicaciones están controlados por procesadores de com un icacion es especiales (Figura 16.3), que se encargan de definir la interfaz m ediante la cual se com unicarán los diversos sitios a través de la red, asi com o de transferir la inform ación entre los diversos sitios. Por ejem plo, la red WAN Internet perm ite que una serie de hosts geográficam ente separados se com uniquen entre sí. Las com putadoras host suelen diferir entre sí en lo que respecta a su tipo, velocidad, longitud de palabra, sistem a operativo, etc. Los hosts se encuentran.norm alm ente situa­ dos en redes LAN que están conectadas a su vez a Internet a través de redes regionales o naciona­ les. Las redes regionales, com o NSFnet en el noreste de los EE. UU., están entrelazadas mediante en cam in ad ores (ro u ters) (Sección 16.5.2) para form ar una única red m undial. Las conexiones entre las redes utilizan frecuentem ente un servicio del sistem a telefónico denom inado T I, que proporciona una tasa de transferencia de 1,544 m egabits por segundo a través de una línea arren-

16.4 Topología de red

565

H Figura 16.3 Procesadores de comunicaciones en una red de área extensa. dada. Para aquellos sitios que requieran un acceso m ás rápido a Internet, las líneas T I se agrupan en unidades que trabajan en paralelo para proporcionar una m ayor tasa de transferencia. Por ejem plo, una línea T3 está com puesta de 28 conexiones T I y tiene una tasa de transferencia de 45 m egabits por segundo. Los encam inadores controlan la ruta que cada m ensaje sigue a través de la red. Este proceso de encam inam iento puede ser dinám ico, para increm entar la eficiencia de las com unicaciones, o estático, para reducir los riesgos de seguridad o para perm itir que se calculen los costes de las com unicaciones. Otras redes WAN utilizan líneas telefónicas estándar com o m edio principal de com unicación. Un m ód em es un dispositivo.que acepta datos digitales desde el lado de conexión con la com pu­ tadora y los convierte a las señales analógicas em pleadas en el sistem a telefónico. O tro módem situado en el nodo de destino convierte de nuevo la señal analógica a form a digital, con lo que el destino puede recibir los datos. La red de noticias UNIX, UUCP perm ite que en los sistem as se com uniquen unos con otros en m om entos predeterm inados, a través de m ódem, para intercam ­ biar m ensajes. Los m ensajes se encam inan a continuación a otros sistem as cercanos y, de esta form a, o bien se propagan a todos los hosts de la red (m ensajes públicos) o se term inan transfirien­ do a su destino (m ensajes privados). Las redes WAN son, generalm ente, más lentas que las redes LAN; sus velocidades de transm isión ven de 1.200 bits por segundo a m ás de 1 m egabit por segun­ do. UUCP se ha visto sustituido por PPP, el protocolo punto a punto. PPP funciona sobre conexio­ nes por m ódem , perm itiendo que las com putadoras dom ésticas se conecten a Internet.

16.4 Topología de red Los nodos de un sistem a distribuido pueden conectarse físicam ente de diversas m aneras y cada configuración tiene sus ventajas y desventajas. Podem os com parar las distintas configuraciones usando los siguientes criterios: • C oste de in stalació n . El coste de enlazar físicam ente los nodos que form an el sistema.

566

Capítulo 16 Estructuras de los sistemas distribuidos

red con estructura en árbol

red en estrella

red en anillo

Figura 16.4 Topología de red. • C oste de com un icacion es. nodo A al nodo B.

El coste en tiem po y en dinero para en viar un m ensaje desde el

• D isp o n ib ilid ad . El grado hasta el que p u ed e acced erse a los datos a pesar del fallo de algu­ nos enlaces o nodos. Las diversas topologías se m uestran en la Figura 16.4 en form a de grafos cuyos nodos se corres­ ponden con los sitios del sistem a. U na arista desde el nodo A al nodo B se corresponde con un enlace de com unicaciones directo entre los dos sitios. E n una red com pletam ente conectada, cada sitio está conectado directam ente con todos los dem ás sitios. Sin em bargo, el núm ero de enlaces crece según el cuadrado del núm ero de sitios, lo qu e representa u n coste de instalación enorme. Como consecuencia, las redes com pletam ente con ectad as no resultan prácticas en ningún sistema de gran tamaño. En una red p arcialm en te conectada, existen en laces directos entre algunas parejas de sitios, pero no entre todas. De este m odo, el coste de instalación de una configuración com o ésta es menor que para una red com pletam ente conectada. Sin em bargo, si dos sitios A y B no están conectados directam ente, los m ensajes del uno al otro deben en cam in arse a través de una secuen­ cia de enlaces de com unicaciones. Este requisito h ace que el coste de com unicaciones sea más alto. Si falla un enlace de com unicaciones, los m ensajes que habrían sido transm itidos a través de ese enlace deberán ser reencam inados. En algunos casos, puede encontrarse otra ruta a través de la red, de m odo que los m ensajes seráíi capaces de alcanzar su destino. En otros casos, un fallo

16.5 Estructura de comunicaciones

567

puede im plicar que deje de existir una conexión entre algunas parejas de sitios. Cuando un siste­ m a queda dividido en dos (o más) subsistem as que carecen de conexiones entre ellos, se dice que está particionado. Usando esta definición, u n subsistem a (o partición) puede estar com puesto por un único nodo. Entre los diversos tipos de redes parcialm ente conectadas se incluyen las redes con estructura de árbol, las redes en anillo y las redes en estrella, com o se m uestra en la Figura 16.4. Cada uno de estos tipos de redes tiene diferentes características de fallo y diferentes costes de instalación de y de com unicaciones. Los costes de instalación y de com unicaciones son relativam ente bajos para las redes con estructura de árbol; sin em bargo, el fallo de un único enlace en una red de este tipo puede provocar que la red quede particionada. En una red en anillo, deben fallar al m enos dos enlaces para que se produzca una partición, por lo que la red en anillo tiene un grado m ás alto de disponibilidad que una red con estructura de árbol; sin em bargo, el coste de com unicaciones es alto, ya que u n m ensaje puede tener que atravesar un gran núm ero de enlaces. En una red en estrella, el fallo de un único enlace provoca una partición de la red, pero una de las particiones está com puesta por un único sitio; dicha partición puede tratarse com o si fuera un fallo de un único nodo. La red en estrella tiene tam bién u n bajo coste de com unicaciones, ya que cada sitio está a una distancia de com o m ucho dos enlaces de cualquier otro sitio. Sin em bargo, si falla el sitio central, todos los sitios del sistem a quedan desconectados.

16.5 Estructura de com unicaciones Ahora qu e hem os explorado los aspectos físicos de las redes, vam os a volver nuestra atención a su funcionam iento interno. El diseñador de una red de com unicaciones debe contem plar cinco cuestiones básicas; • N om brado y reso lu ció n de n om bres. ¿Cóm o se localizan m utuam ente dos procesos para poder com unicarse? • Estrategias de encam inam iento. ¿Cóm o se envían los m ensajes a través de la red? • Estrategias de paquetes. ¿Los paquetes se envían individualm ente o com o una secuencia? • Estrategias de conexión. ¿Cómo envían dos procesos una secuencia de mensajes? • C ontienda. ¿Cóm o resolvem os las dem andas conflictivas de uso de la red, dado que se trata de un recurso com partido? En las siguientes secciones, vam os a analizar cada una de estas cuestiones.

16.5.1 Nom brado y resolución de nombres El prim er com ponente de una red de com unicaciones es el m ecanism o de nom brado de los siste­ mas de la red. Para que un proceso en el sitio A intercam bie inform ación en el sitio B, cada uno de ellos d ebe ser capaz de especificar al otro. Dentro de un sistem a inform ático autónomo, cada proceso tiene un identificador de proceso y la dirección de los m ensajes puede especificarse utili­ zando dicho identificador. Pero, puesto que los sistem as en red no com parten memoria, un host del sistem a no tiene ningún conocim iento inicial acerca de los procesos existentes en otros hosts. Para resolver este problem a, los procesos de los sistem as rem otos se identifican generalm ente m ediante la pareja

Sistemas de archivos distribuidos

JZ

\ q # ¡j6 lo / t í ^

^>J

E n el capítulo anterior, hem os analizado el tem a de la construcción de redes y de los protocolos de bajo nivel necesarios para poder transferir m ensajes entre sistem as. A hora vam os a exam inar uno de los posibles usos de esta infraestructura. Un sistem a de archivos d istribu id o (DFS, distributed file system ) es una im plem entación distribuida del m odelo clásico de com partición de tiem ­ po de un sistem a de archivos, en el que m últiples usuarios com parten archivos y recursos de alm acenam iento (Capítulo 11). El propósito de un sistem a DFS es em plear el m ism o tipo de com ­ partición cuando los archivos están físicam ente dispersos entre los sitios que com ponen un siste­ m a distribuido. En este capítulo, vam os a describir com o puede diseñarse e im plem entarse un sistem a distri­ buido. En prim er lugar, analizarem os algunos conceptos com unes en los que se basan los sistem as DFS. A continuación, ilustrarem os dichos conceptos exam inando un sistem a DFS bastante relevan­ te: el sistem a de archivos A ndrew (AFS).

íiÓ B J E T IV O S D E L ^

.

-

•

Explicar el mecanism o de nombrado que proporciona la independencia y la transparencia de ubi­ cación. t v ; . .

•

Describir los diversos métodos para acceder a archivos distribuidos.

•

Com parar los servidores de archivos distribuidos con o sin memoria del estado.

• ,

Mostrar cóm o la replicación de archivos en diferentes máquinas constituye un útil mecanismo de redundancia para mejorar la disponibilidad.

V.

Presentar el sistem a de archivos Andrew (AFS, Andrew file system ) como ejemplo de sistem a eje ’ N '’ :

:h: • archivos distribuido.. :

17.1 Conceptos esenciales C om o hem os indicado en el capítulo anterior, un sistema distribuido es una colección de com pu­ tadoras débilm ente acopladas interconectadas por una red de com unicaciones. Estas com putado­ ras pued en com partir archivos físicam ente dispersos utilizando un sistem a de archivos distribuido (DFS, distributed file system). En este capítulo utilizam os el térm ino DFS para referir­ nos a los sistem as de archivos distribuidos en general, no al producto com ercial Transare DFS. A este últim o le denom inarem os Transare DFS. Asimism o, NFS hace referencia a NFS versión 3, a m enos que se indique lo contrario. Para explicar la estructura de un sistem a DFS, necesitam os definir los térm inos servicio, servidor y cliente. U n servicio es una entidad softw are que se ejecuta en una o m ás m áquinas y que pro­ porciona un tipo particular de función a los clientes. Un servidor es el softw are de servicio que se ejecuta en una única m áquina. Un clien te es un proceso que puede invocar un servicio utilizando

585

Capítulo 17 Sistemas de archivos distribuidos

un conjunto de operaciones que form an su interfaz de cliente. En ocasiones, se define una ínter-~ faz de m enor nivel para la propia interacción entre unas m áquinas y otras; se trata de la interfaz/

intermáquinas.

I

U tilizando esta term inología, decim os que un sistem a de archivos proporciona servicios de l archivos a los clientes. Una interfaz de cliente para un servicio de archivos está form ada por un 4 conjunto de operaciones prim itivas de archivos, com o la de creación de un archivo, la de borrado^ de un archivo, la de lectura de un archivo y la de escritura en un archivo. El com ponente h ard w a -j re principal que un servidor de archivos controla es un conjunto de dispositivos de almacena-"! m iento secundario locales (usualm ente, discos m agnéticos) en los que se alm acenan y de los que * se extraen los archivos de acuerdo con las solicitudes de los clientes. *í U n DFS es u n sistem a de archivos cuyos clientes, servidores y dispositivos de alm acenam iento^ están dispersos entre las m áquinas de un sistem a distribuido. Correspondiente, la actividád d e f servicio tiene que ser llevada a cabo a través de la red. En lugar de existir un único repositorio de£j datos centralizado, el sistem a tiene frecuentem ente dispositivos de alm acenam iento múltiples e5? independientes. Como verem os en este texto, la configuración e im plem entación concretas de u n 'l DFS pueden variar de un sistem a a otro. En algunas configuraciones, los servidores se ejecutan?! "sobre m áqu inas dedicadas; en otras, una m áquina puede actuar a la vez com o servidor y como= cliente. U n DFS se puede im plem entar com o parte de un sistem a distribuido o, alternativamente m ediante un nivel softw are cuya tarea consiste en gestionar la com unicación entre sistem as op rativos convencionales y sistem as de archivos. Las características distintivas de un DFS son la mi tiplicidad y la autonom ía de los clientes y servidores del sistem a. Idealm ente, un DFS debe aparecer a ojos de sus clientes com o si fuera un sistem a de archivi centralizado convencional. La m ultiplicidad y la dispersión de sus servidores y de sus disposii vos de alm acenam iento deben ser invisibles para los usuarios. En otras palabras, la interfaz c cliente de un DFS no debe distinguir entre los archivos locales y rem otos. Es responsabilidad di DFS localizar los archivos y organizar el transporte de los datos. U n DFS transparente facilita^ m ovilidad de los usuarios trasladando el entorno del usuario (es decir, el directorio principal) lugar donde el usuario haya iniciado la sesión. La m ed ida m ás im portante de rendim iento de un DFS es la cantidad de tiempo necesaria p satisfacer solicitudes de servicio. En los sistem as convencionales, este tiem po está compuesto poi el tiem po de acceso a disco y por una pequeña cantidad de tiempo de procesam iento invertido por/ la CPU. Sin em bargo, en un DFS, cada acceso rem oto tiene un coste adicional, debido a la estructu-' i ra distribuida. Este coste incluye el tiem po para entregar la solicitud a un servidor, asi como el-^ tiem po para que el cliente obtenga la respuesta a través de la red. Para cada una de las direccio-^ nes de com unicación, adem ás de la transferencia de la inform ación, tenemos el coste de CPU-?! requerido para ejecutar el softw are del protocolo de com unicaciones. El rendim iento de un DFS j puede considerarse com o otra dim ensión de la transparencia del sistem a DFS. En otras palabras; 5 el rendim iento de un DFS ideal debería ser com parable al de un sistem a de archivos convencional.-'! El hecho que un DFS gestione un conjunto de dispositivos dispersos de alm acenam iento cons^J tituye la característica distintiva m ás im portante de los sistem as DFS. El espacio de almacenamien~éj to total gestionado por un DFS está com puesto de espacios de almacenamiento más pequeños-^ que están separados y que se ubican de form a rem ota. Usualm ente, estos espacios de alm acen a-J m iento constituyentes se corresponden con conjuntos de archivos. Una unidad componente es el | conjunto de archivos más pequeño que puede alm acenarse en una sola máquina, independiente- , m ente de otras unidades. Todos los archivos que pertenezcan a la misma unidad componente ^ deben resid ir en la m ism a ubicación. *

.2 N om brado y transparencia El nom brad o es una correspondencia entre los objetos lógicos y físicos. Por ejemplo, los usuarios tratan con objetos lógicos de datos representados por nom bres de archivos, mientras que el siste- s m a m anipula bloques físicos de datos alm acenados en las pistas de los discos. Usualmente, 1°S..L usuarios hacen referencia a los archivos m ediante un nom bre textual. El nombre textual se hace~ corresponder con un identificador num érico de m enor nivel que a su vez se hace corresponder

17.2 Nombrado y transparencia

587

con los bloques de disco. Esta correspondencia m ultinivel proporciona a los usuarios una abstrac­ ción de un archivo que oculta los detalles de cóm o y en qué lugar del disco está alm acenado el archivo. En un DFS transparente, se añade una nueva dim ensión a esta abstracción: la de ocultar en qué lugar de la red reside el archivo. En un sistem a de archivos convencional, el rango de esa corres­ pondencia de nom brado son las direcciones dentro de un disco. En un DFS, este rango se expan­ de para incluir la m áquina específica en cuyo disco está alm acenado el archivo. Si vam os un paso m ás allá con el concepto de tratar los archivos com o abstracciones, nos encontram os con la posi­ bilidad de la rep licació n de archivos. Dado un nom bre de archivo, la correspondencia de nom ­ brado devuelve un conjunto de ubicaciones correspondientes a las réplicas del archivo. Según esta abstracción, tanto la existencia de m últiples copias com o sus ubicaciones están ocultas.

17.2.1 Estructuras de nom brado N ecesitam os diferenciar dos ideas relacionadas en lo que respecta a las correspondencias de n o m ­ bres en un DFS: 1. T ran sp arencia de u b icació n . El nom bre de un archivo no revela ninguna inform ación acer­ ca de la ubicación física de alm acenam iento del archivo. 2. In d ep en d en cia de u bicació n . No es necesario m odificar el nom bre de un archivo cuando varía la ubicación física de alm acenam iento del archivo. A m bas definiciones son relativas al nivel de nom brado del que hem os hablado anteriorm ente, dado que los archivos tienen nom bres diferentes en los distintos niveles (es decir, nom bres textua­ les de nivel de usuario e identificadores num éricos de nivel del sistem a). U n esquema de nom bra­ do independiente de la ubicación constituye una correspondencia dinám ica, ya que puede hacer corresponder el m ism o nom bre con ubicaciones diferentes en dos instantes distintos. Por tanto, la independencia de la ubicación es una propiedad m ás estricta que la de la transparencia de ubica­ ción. En la práctica, la m ayoría de los sistem as DFS actuales proporcionan una correspondencia está­ tica de los nom bres de nivel de usuario, que es transparente respecto a la ubicación. Sin em bargo, estos sistem as no soportan la m igración de archivos; es decir, resulta im posible cam biar autom á­ ticam ente la ubicación de un archivo. Por tanto, la noción de independencia de la ubicación es irrelevante para estos sistem as. Los archivos están asociados perm anentem ente con un conjunto específico de bloques de disco. Los archivos y los discos pueden desplazarse de unas m áquinas a otras m anualm ente, pero la m igración de archivos im plica una acción autom ática iniciada por el SO, Sólo AFS y unos cuantos sistem as de archivos experim entales perm iten la independencia de ubicación y la m ovilidad de archivos. AFS soporta la m ovilidad de archivos principalm ente con propósitos adm inistrativos. U n protocolo proporciona el m ecanism o de m igración de las unida­ des com ponentes de AFS para satisfacer las solicitudes de alto nivel de los usuarios, sin cam biar ni los nom bres de nivel de usuario ni los nom bres de bajo nivel de los correspondientes archivos. U nos cuantos aspectos nos perm iten diferenciar aún m ejor los conceptos de independencia de ubicación y de transparencia estática de ubicación: • La separación entre datos y ubicación, tal com o se im plem enta m ediante la independencia de ubicación, proporciona una m ejor abstracción para los archivos. Cada nom bre de archi­ vo debe denotar los atributos más significativos del archivo, que son sus contenidos y no la ubicación. Los archivos independientes de la ubicación pueden contem plarse com o conte­ nedores lógicos de datos que no están asociados con ninguna ubicación de alm acenam ien­ to específica. Si sólo se soporta la transparencia estática de ubicación, el nom bre de archivo seguirá denotando un conjunto específico, aunque oculto, de bloques físicos de disco. • La transparencia estática de ubicación proporciona a los usuarios una forma cóm oda de com partir datos. Los usuarios pueden com partir archivos rem otos sim plem ente nom bran­ do los archivos en una form a transparente con respecto a la ubicación, como si los archivos fueran locales. Sin em bargo, resulta bastante engorroso com partir el espacio de alm acena>

Capítulo 17 Sistemas de archivos distribuidos

m iento, porque los nom bres lógicos siguen estando asociados estáticam ente a los dispositi vos físicos de alm acenam iento. La independencia de ubicación prom ueva la compartid, del propio espacio de alm acenam iento, adem ás de la com partición de los objetos de dati C uando los archivos pueden ser m ovilizados, el espacio de alm acenam iento total del sisl m a parece un único recurso virtual. U na de las posibles ventajas de este m ecanism o es? capacidad de equilibrar la utilización de los discos en todo el sistema. La independencia de ubicación separa la jerarqu ía de nom bres de la jerarquía dé disposü tivos de alm acenam iento y de la estructura de interconexión de las com putadoras. Por® contraste, si se em plea una transparencia estática de ubicación (aunque los nom bres seaÜÜ transparentes), podem os determ inar fácilm ente la correspondencia entre las unidades coi ponentes y las m áquinas. Las m áquinas están configuradas según un patrón sim ilar al de estructura de nom bres. Esta configuración puede restringir la arquitectura del sistem a irme cesariam ente y entrar en conflicto con otras consideraciones. Un servidor a cargo de directorio raíz constituye un ejem plo de estructura que está dictada por la jerarquía de noi bres y que contradice las directrices de descentralización. U na vez com pletada la separación entre nom bres y ubicaciones, los clientes pueden accede los archivos que residen en sistem as servidores rem otos. D e hecho, estos clientes pueden ser l u disco y depender de los servidores para que estos les proporcionen todos los archivos, incluye do el k em el del sistem a operativo. Sin em bargo, harán falta protocolos especiales para la secüé cia de arranque. Considere el problem a de enviar el k em el a una estación de trabajo sin disco ! estación de trabajo sin disco no tiene n ing ú n kem el, por lo que no puede utilizar el código DFS pá extraer el kem el. En lugar de ello, se invoca un protocolo de arranque especial, que está almace do en la m em oria de sólo lectura (ROM, read-only m em ory) del cliente. Este protocolo pemúte>| conexión por red y extrae únicam ente u n archivo especial (el kem el o el código de arranque) de una ubicación fija. U na vez que se ha copiado el k em el desde la red y que se ha cargado, su t)| hace que todos los dem ás archivos del sistem a operativo estén disponibles. Son n um erosa^ ventajas de los clientes sin disco, incluyendo un m enor coste (porque las m áquinas cliente~ño necesitan ningún disco) y una m ayor com odidad (cuando tiene lugar una actualización del síffe m a operativo, sólo es necesario m odificar el servidor). Las desventajas son la m ayor com plejidl¡ de los protocolos de arranque y el m enor rendim iento com o consecuencia de utilizar una red ép|j lugar de un disco local. "p z M La tendencia actual es que los clientes utilicen tanto discos locales com o servidores remotos dé~|j| archivos. Los sistem as operativos y el softw are de interconexión de red se alm acenan localmentegjgj los sistem as de archivos que contienen datos del usuario (y posiblem ente aplicaciones) se alm aq P lg nan en sistem as de archivos rem otos. A lgunos sistem as cliente pueden alm acenar tam bién apÜcalllfc ciones com únm ente utilizadas, com o por ejem plo procesadores de texto y exploradores web; e el sistem a de archivos local. Otras aplicaciones m enos com únm ente utilizadas pueden ser extraía das desde el servidor de archivos rem oto y cargados en el cliente según sea necesario. La princi­ pal razón para proporcionar a los clientes sistem as de archivos locales en lugar de sistem as pi sin disco es que las unidades de disco están aum entando rápidam ente de capacidad y disüuñi|g yendo de coste, apareciendo nuevas generaciones de unidades de disco, aproxim adam ente cada año. No se puede decir lo m ism o de las redes, que evolucionan cada varios años. En conjunto, lo sistem as están creciendo m ás rápidam ente que las redes, por lo que hace falta un esfuerzo adicioyl nal para lim itar el acceso a la red con el fin de aum entar la tasa de procesam iento del sistema. ^

17.2.2 Esquemas de nom brado Existen tres técnicas principales para construir esquem as de nom brado en un DFS. C on el enfoque j g más sim ple, cada archivo se identifica m ediante una com binación de su nom bre de host y de sttgif nom bre local, lo que garantiza un nom bre único en todo el sistema. En Ibis, por ejem plo, cal^ M archivo se identifica unívocam ente m ediante el nom bre host .nombre-local, donde nombre-local egj| una ruta estilo UNIX. Este esquem a de nom brado no es ni transparente con respecto a la ubicaciónj ni independiente con respecto a la ubicación; de todos m odos, pueden utilizarse las mismas <

17.2 Nombrado y transparencia

589

raciones de archivos, tanto para los archivos rem otos com o para los locales. El DFS está estructu­ rado com o una colección de unidades com ponentes aisladas, cada una de las cuales es un sistem a de archivos convencional com pleto. C on esta prim era técnica, las unidades com ponentes perm a­ necen aisladas, aunque proporcionan m ecanism os para hacer referencia a los archivos rem otos. A lo largo dé este texto no analizarem os con m ás detalle este esquem a. La segunda técnica fue popularizada por el sistem a de archivos de red (NFS, netw ork file system ) de Sun. NFS es el com ponente del sistem a de archivos de O NC+, un paquete de interco­ nexión por red soportado p o r m uchos fabricantes de UNIX. NFS proporciona un m edio para aso­ ciar directorios rem otos a los directorios locales, proporcionando así la apariencia de un árbol de directorios coherente. Las prim eras versiones de NFS sólo perm itían acceder transparentem ente a los directorios rem otos previam ente m ontados. Con la aparición de la característica de a u to m o n ta je , el m ontaje se realiza según es necesario, basándose en una tabla de puntos de m ontaje y nom ­ bres de estructura de archivos. Los com ponentes se integran para soportar una com partición transparente, aunque esta integración está lim itada y no es uniform e, porque cada m áquina puede asociar directorios rem otos distintos a su árbol. La estructura resultante es bastante versátil. Podem os conseguir una total integración de los sistem as de archivos com ponentes utilizando la tercera de las técnicas. C on ella, hay una única estructura global de nom bres que abarca a todos los archivos del sistem a. Idealm ente, la estructura de sistem as de archivos com puesta es isom orfa a la estructura de un sistem a de archivos convencional. Sin em bargo, en la práctica, los num e­ rosos archivos especiales (por ejem plo, los archivos de dispositivos UNIX y los directorios binarios específicos de la m áquina) hacen que este objetivo sea difícil de alcanzar. Para evaluar las estructuras de nom brado, tenem os que analizar su co m p le jid a d a d m in is tr a ­ tiv a . L a estructura m ás com pleja y m ás difícil de m antener es la estructura NFS. Puesto que puede asociarse cualquier directorio rem oto en cualquier lugar del árbol de directorios local, la jerarquía resultante puede ser altam ente no estructurada. Si un servidor deja de estar disponible, dejará tam bién de estar disponible algún conjunto arbitrario de directorios en diferentes m áquinas. A dem ás, hay un m ecanism o de acreditación separado que controla qué m áquinas están autoriza­ das a asociar determ inados directorios a su árbol. Por tanto, un usuario puede ser capaz de acce­ der a un árbol de directorios rem oto en un cliente, pero denegársele el acceso en otro cliente.

17.2.3 Técnicas de im plem entación La im plem entación de un convenio transparente de nom brado requiere algún tipo de m ecanism o para establecer la correspondencia entre el nom bre de un archivo y la ubicación asociada. Para que este m ecanism o de correspondencia sea m anejable, debem os agregar conjuntos de archivos en unidades com ponentes y realizar la correspondencia basándonos en las unidades com ponen­ tes, en lugar de realizarla por separado para cada archivo. Este proceso de agregación tam bién sim plifica las tareas adm inistrativas. Los sistem as de tipo UNIX utilizan el árbol de directorios jerárquico para proporcionar esta correspondencia entre nom bres y ubicaciones y para agregar los archivos recursivam ente en directorios. Para m ejorar la disponibilidad de esta inform ación crucial de correspondencia, podem os utili­ zar m ecanism os de replicación, de caché local o am bos. Com o hem os indicado anteriorm ente, el concepto de independencia de la ubicación im plica que esas correspondencias cam bian a lo largo del tiem po; por tanto, si replicam os esas correspondencias, se vuelve im posible la actualización de esta inform ación de una m anera sim ple y coherente. U na técnica para elim inar este obstáculo consiste en introducir i d e n tif ic a d o r e s d e a rc h iv o in d e p e n d ie n te s d e la u b ic a c ió n de bajo nivel. Los nom bres de archivo textuales se asignan a identificadores de archivo de bajo nivel que indi­ can a qué unidad com ponente pertenece el archivo. Estos identificadores siguen siendo indepen­ dientes de la ubicación. Se los puede replicar y alm acenar en caché librem ente sin que se vean invalidados por la m igración de unidades com ponentes. El precio que hay que pagar de m anera inevitable es la necesidad de un segundo nivel de correspondencias, que haga corresponder a cada unidad com ponente una ubicación determ inada y que necesita un m ecanism o de actualiza­ ción sim ple y coherente. Si im plem entam os los árboles de directorio de tipo UNIX utilizando estos identificadores de bajo nivel independientes de la ubicación, toda la jerarquía será invariante con

>0

Capítulo 17 Sistemas de archivos distribuidos

respecto a la m igración de las unidades com ponentes. El único aspecto que cam bia es la corres-^ pondencia entre las unidades com ponentes y las ubicaciones. U na form a com ún de im plem entar identificadores de bajo nivel consiste en utilizar nombres ■ estructurados. Estos nom bres son cadenas de bits que están form adas, usualm ente, por dos partes. La prim era parte identifica la unidad com ponente a la que pertenece el archivo. La segunda ™ parte identifica el archivo concreto dentro de esa unidad. Tam bién son posibles algunas otras1' variantes con m ás partes. Sin em bargo, la invarianza dé los nom bres estructurados es que todas las partes individuales del nom bre son unívocas en todo m om ento sólo dentro del contexto de las 4 partes. Podem os conseguir la unicidad en todo m om ento teniendo cuidado de no reutilizar u n í nom bre que esté siendo usado todavía, añadiendo un núm ero suficiente de bits adicionales (este m étodo se utiliza en AFS) o em pleando una m arca tem poral com o otra parte del nom bre (como se , hace en A pollo Dom ain). O tra form a de ver este proceso es que estam os tom ando un sistema transparente con respecto a la ubicación, tal com o Ibis y añadiendo otro nivel de abstracción para® producir un esquem a de nom brado independiente con respecto a la ubicación. ^ La agregación de archivos en unidades com ponentes y la identificación de identificadores de : archivo de bajo nivel independientes respecto a la ubicación son técnicas ejem plificadas en AFS. “

17.3 Acceso rem oto a archivos

%

Supongam os que un usuario solicita acceder a un archivo rem oto. El servidor donde se almacena^ el archivo ha sido localizado por el esquem a de nom brado y con eso puede tener lugar la p rop ia; transferencia de datos. 'i| U na form a de llevar a cabo esta transferencia es m ediante un m ecanism o de servicio remoto)3: m ediante el cual las solicitudes de acceso se entregan al servidor, la m áquina servidora realiza los| accesos y los resultados se devuelven al usuario. Una de las form as m ás com unes de im plem en-f tar un servicio rem oto es el paradigm a de llam adas a procedim ientos rem otos (RPC, rem óte p r ó j cedure cali), del que hem os hablado en el Capítulo 3. Existe una analogía directa entre los m étodos: de acceso a disco en los sistem as de archivos convencionales y el m étodo se servicio rem oto en u n í DFS. U tilizar el m étodo de servicio rem oto es análogo a realizar un acceso a disco por cada solici- • tud de acceso. 1 Para garantizar un rendim iento razonable del m ecanism o de servicio rem oto, podem os utili­ zar algún tipo de caché. En los sistem as de archivos convencionales, la razón de utilizar el alma­ cenam iento en caché es reducir la E/S de disco (increm entando así la velocidad), m ientras que en un DFS, el objetivo es reducir tanto el tráfico red com o el de E/S de disco. En el siguiente análisis, vam os a d escribir la im plem entación del m ecanism o de caché en un DFS y a com pararla con el paradigm a básico de servicio rem oto.

17.3.1 Esquema básico de caché El concepto de alm acenam iento en caché es simple. Si los datos necesarios para satisfacer la soli­ citud de acceso no se encuentran ya en la caché, entonces se trae una copia de dichos datos desde el servidor hasta el sistem a cliente. Los accesos se realizan sobre la copia alm acenada en caché. La idea es retener en la caché los bloques de disco a los que se ha accedido recientem ente, de modo que los accesos repetidos a la m ism a inform ación puedan gestionarse localm ente, sin necesidad de tráfico red adicional. La im plem entación de algún tipo de sustitución (por ejem plo, la de los datos m enos recientem ente utilizados) hace que el tam año de la caché se m antenga acotado. No existe correspondencia directa entre los accesos y el tráfico dirigido al servidor. Los archivos pue­ den seguir identificándose con una copia m aestra que reside en la m áquina servidora, pero una serie de copias del archivo (o de partes del m ismo) estarán dispersas en las diferentes cachés. C uando se m odifica una copia alm acenada en caché, será necesario reflejar los cam bios en la copia m aestra, con el fin de preservar la correspondiente sem ántica de coherencia. El problem a de man­ tener las copias de caché coherentes con el archivo m aestro se denom ina p roblem a de la coheren­ cia de caché, y hablarem os de dicho problem a en la Sección 17.3.4. Los m ecanism os de caché de 1 un DFS tam bién podrían denom inarse m em oria virtu al de red, ya que actúan de form a similar a :

17.3 Acceso remoto a archivos

591

la fo rm a v irtu a l d e p a g in a c ió n bajo d e m a n d a , s a lv o p o rq u e el a lm a c e n a m ie n to d e re s p a ld o n o es, u su a lm e n te , u n d is co lo ca l sin o u n s e r v id o r re m o to . NFS p e rm ite m o n ta r re m o ta m e n te el e sp a cio d e in te rc a m b io , d e m o d o q u e p u e d e v e rd a d e r a m e n te im p le m e n ta r u n a m e m o ria v irtu a l a tra v é s d e la re d , a u n q u e p o r su p u e s to c o n u n co n sid e ra b le im p a c to so b re las p re sta cio n e s.

La granularidad de los datos almacenados en caché en un DFS puede variar, pudiendo defi­ nirse esa granularidad en el nivel de bloque de archivo o en el de un archivo completo. Usualmente, se almacenan en caché más datos de los necesarios para satisfacer un único acceso, de modo que se pueda dar servicio a muchos accesos mediante los datos almacenados en caché. Este procedimiento se parece bastante al mecanismo de lectura anticipada de disco (Sección 11.6.2). AFS almacena en caché los archivos utilizando fragmentos de gran tamaño (64 KB). Los otros sistemas analizados en este capítulo permiten almacenar en caché bloques individuales, a medida que sean demandados por los clientes. Incrementar el tamaño de la unidad de caché per­ mite aumentar la tasa de aciertos, pero también incrementa la penalización correspondiente a los fallos, porque cada fallo requerirá transferir más datos. También incrementa la posibilidad de que aparezcan problemas de coherencia. Para seleccionar la unidad de almacenamiento en caché, debemos tener en cuenta parámetros tales como la unidad de transferencia de red y la unidad de servicio del protocolo RPC (si se utiliza un protocolo RPC). La unidad de transferencia de red (para Ethernet, un paquete) es de aproximadamente 1,5 KB, por lo que las unidades de datos de caché que tengan un mayor tamaño necesitarán ser desensambladas para poder entregarlas y re-ensambladas después de recibirlas. El tamaño de bloque y el tamaño total de la caché resultan evidentemente importantes para los esquemas de almacenamiento de bloques en caché. En los sistemas tipo UNIX, los tamaños de blo­ que más comunes son 4 KB y 8 KB. Para las memorias caché de gran tamaño (más de 1 MB), resul­ ta ventajoso utilizar tamaños de bloque grandes (por encima de 8 KB). Para las memorias caché más pequeñas, los tamaños de bloque grande son menos ventajosos, porque hacen que se alma­ cenen menos bloques en la caché y, por tanto, que se consiga una menor tasa de aciertos.

17.3.2 Ubicación de la caché ¿Dónde deben almacenarse los datos de caché, en el disco o en la memoria principal? Las cachés. de disco tienen una clara ventaja sobre las cachés de memoria principal: son bastante más fiables. Las modificaciones efectuadas en los datos almacenados en caché se perderán cuando se sufra un fallo catastrófico de la máquina, si la caché se almacena en memoria volátil. Además, si los datos de caché se almacenan en disco, seguirán estando allí durante la recuperación, y no será necesa­ rio volver a extraerlos. Las cachés de memoria principal tienen, de todos modos, varias ventajas: • Las cachés de memoria principales permiten que las estaciones de trabajo no utilicen disco. • Resulta más rápido acceder a los datos almacenados en una caché de memoria principal que a los de una caché de disco. • La tecnología está evolucionando para dar memorias de mayor tamaño y menor coste. Las previsiones son que las ventajas de velocidad que se podrán conseguir de esta manera com­ pensarán con creces las ventajas de la caché de disco. • Las cachés de servidor (utilizadas para acelerar la E/S de disco) residirán en memoria prin­ cipal, independientemente de dónde residan las cachés de usuario; si utilizamos también cachés de memoria principal en las máquinas de usuario, podemos definir un único meca­ nismo de caché para utilizarlo tanto en los servidores como en los clientes. Hay muchas implementaciones de los mecanismos de acceso remoto que pueden considerarse como híbridos de los mecanismos de caché y de los de servicio remoto. En NFS, por ejemplo, la implementación está basada en un servicio remoto, pero complementado con cachés de memoria del lado del cliente y del lado del servidor para mejorar la velocidad. De forma similar, la implementación de Sprite está basada en mecanismos de caché, pero en ciertas circunstancias se adop­ ta un método basado en servicio remoto. Por tanto, para evaluar los dos métodos, debemos primero determinar hasta qué punto se pone el énfasis en uno u otro de los métodos. J-

Capítulo 17 Sistemas de archivos distribuidos

El protocolo NFS y la mayoría de las implementadones no proporcionan ninguna caché de disco. Las implementadones redentes de NFS en Solaris (Solaris 2.6 y superior) incluyen una opción de caché de disco del lado del cliente, el sistema de archivos cachéis. Una vez que el clien­ te NFS lee bloques de un archivo desde el servidor, los almacena en la caché de memoria y tam­ bién en la caché de disco. Si se vacía la copia de memoria, o sí se produce un re-arranque del sistema, se consulta la caché de disco. Si un bloque necesario no sé'encueritra ni en la memoria ni en la caché de disco cachéis, se realiza una llamada RPC al servidor con el fin de extraer el bloque, y dicho se bloque se almacena tanto en la caché de disco como en la caché de memoria, para que lo utilice el cliente.

,

17.3.3 Política de actualización de la caché La política que se utilice para escribir los bloques de datos modificados en la copia maestra del servidor tiene un efecto crítico sobre la fiabilidad y las prestaciones del sistema. La política más simple consiste en escribir los datos en disco en cuanto se los coloca en cualquier caché. La venta­ ja de esta política de escritura directa es la fiabilidad: es muy poca la información que se pierde f ! cuando un sistema cliente sufre un fallo catastrófico. Sin embargo, esta política requiere que cada^;* acceso de escritura espere hasta que se envíe la información al servidor, por lo que la velocidad de escritura es muy baja. El almacenamiento en caché con un mecanismo de escritura directa es' equivalente a utilizar un servicio remoto para los accesos de escritura y aprovechar la caché úni-_~. camente para los accesos de lectura. Una alternativa es la política de escritura diferida, también denominada caché de escriturá?Jjl.. diferida; con este tipo de política, lo que hacemos es retardar las actualizaciones de la copia maestra. Las modificaciones se escriben en la caché y luego se envían al servidor en un momento pos-3f terior. Esta política tiene dos ventajas sobre la de escritura directa. En primer lugar, puesto que las^S, escrituras se realizan en la caché, los accesos de escritura se completan mucho más rápidamentéíí§® En segundo lugar, los datos pueden ser sobrescritos antes de enviarlos al servidor, en cuyo caso ¿ sólo será necesario escribir en el servidor la última actualización. Lamentablemente, los esquemas SE de escritura diferida introducen problemas de fiabilidad, ya que los datos no escritos se perderán -% si una máquina de usuario sufre un fallo catastrófico. " íÉ Las diversas variantes de la política de escritura diferida se diferencian en lo que respecta al momento en que se vuelcan en el servidor los bloques de datos modificados. Una alternativa con­ siste en volcar un bloque cuando esté a punto de ser expulsado de la caché de cliente. Esta opción puede proporcionar unas buenas prestaciones, pero algunos bloques pueden permanecer en la caché de cliente durante mucho tiempo antes de escribirlos en el servidor. Un compromiso entre esta alternativa y la política de escritura directa consiste en explorar la caché a intervalos regula- _ res y volcar aquellos bloques que hayan sido modificados desdé la última exploración, utilizando . el mismo método que UNIX emplea para explorar su caché local. Sprite utiliza esta política, con un: i?? intervalo de 30 segundos. NFS emplea también esta política para los datos de archivo, pero una,,^ vez que se realiza una escritura en el servidor durante un volcado de caché, es necesario esperar jg a que esa escritura se realice de forma efectiva en el disco del servidor antes de poder considerar- j la completa. NFS trata los metadatos (datos de directorio y datos de atributos de los archivos) de O forma diferente. Los cambios en los metadatos se envían de manera síncrona al servidor. De este modo, se evita la pérdida de información sobre la estructura de archivos y la corrupción de la ^ estructura de directorios cuando se produce un fallo catastrófico en el cliente o en el servidor. Para NFS con cachéis, las escrituras también se realizan en caché de disco local en el momento de llevarlas a cabo en el servidor, con el fin de mantener la coherencia entre todas las copias. Por » tanto, NFS con cachéis mejora las prestaciones con respecto al sistema NFS estándar en la solicitudes de lectura para las que haya un acierto de caché cachéis pero reduce las prestaciones para las J?;. solicitudes de lectura o de escritura en las que se produzca un fallo de caché. Al igual que con p, todos los mecanismos de caché, resulta fundamental tener una alta tasa de aciertos de caché, con el fin de mejorar la velocidad. En la Figura 17.1 se ilustra el sistema cachéis y su uso de los meca- p nismos de caché con escritura directa y escritura diferida. . Otra variante de la escritura diferida consiste en escribir los datos en el servidor en el momen- to de cerrar el archivo. Esta política de escritura durante el cierre se utiliza en AFS. En el caso de £ : J-

'

17.3 Acceso remoto a archivos

593

servidor NFS

c(e acsh deram ria) créitu deirm eo cta

Figura 17.1

Utilización de los mecanismos de caché en cachefs.

los arch iv o s que se ab ran d u ran te cortos p eríod os de tiem p o o qu e se m od ifiq u en m uy ra ra m en ­ te, esta política no red u ce sig n ificativ am en te el tráfico de red. A d em ás, la política de escritu ra d u ra n te el cierre req u iere qu e el p roceso q u e realiza el cierre se qued e a la espera m ientras q u e se está escrib ien d o el arch iv o, lo qu e red u ce la ventaja d e p restacion es ofrecid a por las escritu ras d iferid as. Sin em b arg o, para los arch iv os q u e están ab iertos d u rante largos períodos de tiem po o q u e se m od ifiq u en frecu en tem en te, las v en tajas de v elocid ad de esta política con respecto a la escritu ra d iferid a con un v o lcad o m ás frecu en te resu ltan b astante ev id en tes.

17.3.4 Coherencia Las m áq u in as clien te se en fren tan al problem a de d ecid ir si una copia de los datos alm acen ad a en la ca ch é local es co h eren te o no con la copia m aestra (y pu ede por tanto ser u tilizada). Si la m áq u i­ na clien te d eterm in a que los d atos de su cach é están d esactu alizad o s, no podrá va darse serv icio a las so licitu d es de acceso utilizan d o d ich os d atos de la caché. Será n ecesario alm acen ar en la ca ch é una cop ia actu alizad a de los datos. Existen dos técn icas para v e rific a rla validez de los datos a lm a cen a d o s en la cach é.

1. Inicio por parte cliente. El clien te inicia una com p ro b ació n de validez en la que con tacta con el serv id or y com p ru eb a si los d atos locales son coh eren tes con la copia m aestra. La fre­ cu en cia de esta co m p ro b a ció n de v alid ez es el asp ecto fu n d am en tal de esta técnica y d eter­ m ina la sem án tica de coh eren cia resu ltan te. Esa frecu en cia puede variar, pudiendo realizarse la co m p ro b a ció n para cada acceso o sólo en el prim er acceso a un archivo (b ásicam en te d u ran te la ap ertu ra de un arch iv o); tam b ién pu ed e utilizarse cu alq u ier otra frecu en cia en tre estos dos extrem os. T o d os los acceso s q u e llev en -ap arejad a una com p ro bació n de valid ez su frirán un cierto retard ó, co m p arad o s con los acceso s a los que se dé servicio in m ed iatam en ­ te u tilizan d o los d atos de la caché. A ltern ativ am en te, esas com p ro b acio n es pueden in iciarse a in terv alos de tiem po fijos. D ep en d ien d o de su frecu en cia, las com p ro bacio n es de valid ez pu ed en im p o n er una gran carga tanto a la red com o al servid or. 2. In ic io por p arte d el serv id o r. El serv id o r registra, para cada cliente, los arch ivos (o partes de los m ism os) q u e estos tienen alm acen ad o s en caché. C uando el servid or detecta una in co ­ h eren cia p oten cial, d ebe reaccio n ar a la m ism a. Una posibilid ad de incoherencia se p rod u ce cu an d o dos clien tes d istin tos que op eran con m odos con flictiv o s alm acen an dn cach é un

594

Capítulo 17 Sistemas de archivos distribuidos

m ism o archivo. Si se im p lem en ta la sem án tica d e UNIX (Sección 1 0.5.3), p od em os resolv er la in coh eren cia p o ten cial h acien d o q u e el serv id o r ju e g u e un p ap el activ o. El serv id or deberá ser n otificad o cad a vez qu e se ab ra un arch iv o, y d eb erá in d icarse el m odo d esead o (lectura o escritu ra) para cad a ap ertu ra arch iv o. El se rv id o r p u ed e en to n ces actu ar cu an d o detecte que el archivo ha sid o ab ierto sim u ltá n ea m en te en m od os co n flictiv o s, d esactiv an d o en ese caso el m ecan ism o de cach é p ara ese arch iv o co n creto . En la p ráctica, la d esactiv ació n del m ecan ism o de ca ch é p ro vo ca la co n m u ta ció n a u n m o d o de o p e ra ció n basad o en el p arad ig­ m a de servicio rem oto.

17.3.5 Comparación entre el m ecanism o de caché y el de servicio remoto E sen cialm en te, ¡a elección en tre el m ecan ism o de ca c h é y el de servicio rem o to rep resen ta un com ­ prom iso en tre las m ejoras p oten ciales de p re stacio n es y la m ayor sim p licid ad de im plem en tación . V am os a ev alu ar este co m p ro m iso in d ican d o las v en tajas y d esv en tajas d e los dos m étod os. • C u an d o se u tiliza un m ecan ism o de cach é, la cach é lo cal p u ed e g estio n ar de m an era eficien ­ te un núm ero su stan cial de los a cceso s rem o to s. Si ap ro v ech am o s las características de loca­ lidad de los p atron es de acceso a los a rch iv o s, el m ecan ism o de ca ch é resulta tod av ía m ás atractivo. De este m od o, la m ay o ría de los a cceso s rem otos p o d rán servir tan ráp id o com o los accesos locales. A d em ás, só lo es n ecesario co n ta cta r con los serv id ores ocasion alm en te, en lu gar de h acerlo para cad a acceso . En co n secu en cia , se red u ce tan to la carga d el servidor co m o el tráfico d e red, y se au m en ta la e sca la b ilid a d del sistem a. P o r con traste, cu an d o se usa el m étod o de serv icio rem o to , tod o acceso rem o to req u iere u n a co m u n icació n a través de la red. Las d esv en tajas en lo q u e resp ecta a tráfico de red, ca rg a d e servid or y p restacio­ nes resu ltan obvias. •

La carga total a d m in istrativ a de red es m en o r cu a n d o se tran sm iten grandes fragm en tos de d atos (com o se h ace en el caso de los m ecan ism o s de caché) q u e cu an d o se tran sm ite una serie de resp u estas a so licitu d es esp ecíficas (co m o su ced e con el m étod o de serv icio rem o­ to). A d em ás, las ru tin as de acceso a d isco en el serv id or p u ed en op tim izarse en m ayor m edida si se sabe de an tem an o que las so licitu d es siem p re estarán d irigid as a extraer gran­ d es seg m en tos co n tin u o s de d atos, en lu g ar de b lo q u es de d isco aleatorios.

•

El problem a de la coh eren cia de cach é es la p rin cip al d esv en taja del m ecan ism o de alm ace­ n am ien to en cach é. C u an d o los p atron es de a cceso m uestran p o cas escritu ras, los m ecanis­ m os de caché resu ltan claram en te m ejores. Sin em b arg o, cu an d o las escritu ras son frecu en­ tes, los m ecan ism o s u tilizad o s para reso lv er el pro blem a de la coh eren cia im p lican un so b reco ste b astan te su stan cial en térm in os de p restacio n es, de tráfico de red y de carga del servid or.

• Para q u e el m ecan ism o de cach e p u ed a resu lta r v en tajo so , d eb e u tilizarse en m áq u in as que tengan un d isco local o una gran can tid ad d e m em o ria p rincip al. Los accesos rem otos en las m áq u in as sin d isco y con una p eq u eñ a can tid ad d e m em oria d eb en realizarse utilizando el m étod o del serv icio rem oto. •

C on los m ecan ism o s de cach é, p u esto q u e los d ato s se tran sfieren en m asa en tre el servidor y el clien te, en lu gar de en resp u esta a las n ecesid a d es esp ecíficas de una op eración de archi­ vo, la in terfaz in term áq u in a de bajo n ivel es d istin ta d e la in terfaz d e usuario q u e se utiliza a un nivel su p erior. Por co n traste, el p ara d ig m a del servicio rem o to es sim p lem en te una exten sió n a través de la red de la in terfaz con el sistem a de arch iv o s local. Por tanto, la inter­ faz in term áq u in a se co rresp o n d e co n la in terfaz de usuario.

17.4 Servicios con y sin m em oria del estado Existen dos técnicas para a lm acen ar la in fo rm ació n del lado del serv id o r cuan d o un clien te acce­ de a arch iv os rem otos. O bien el se rv id o r lleva la cu e n ta de cada arch iv o al que esté accediendo -

J-

17.4 Servicios con y sin memoria del estado

595

cad a clien te , o sim p lem en te se lim ita a p ro p orcio n ar b lo q u es a m ed id a que los clien tes los so lici­ tan, sin n in g ú n tipo de co n o cim ien to d e có m o se u tilizan esos bloqu es. En el p rim ero de los casos, el serv icio p ro p o rcio n a d o tiene m em oria del estado, en el segu n d o caso, no tiene m em oria del estado. El esce n a rio típico d e u n se rv ic io d e a rch iv o s con m em o ria d el estad o sería el sigu ien te: un clien te d eb e realizar u n a o p era ció n o p e n () sobre un arch iv o antes de acced er a d ich o arch iv o. El serv id o r ex tra e la in fo rm a ció n acerca del arch iv o desde su disco, la alm acen a en la m em o ria y p ro­ p orcion a al clien te un id en tifica d o r d e co n ex ió n que es exclu siv o de ese clien te y de ese arch iv o co n creto q u e se ha ab ierto. En térm in os UNIX, el servid or extrae el in od o y p ro p o rcio n a al clien te un d escrip to r de arch iv o q u e sirve co m o índ ice para u n a tabla in tern a de in od o s. E ste id e n tifica­ dor se em p lea para los a cceso s su b sig u ien tes hasta q u e term in a la sesión . U n servicio con m em o ­ ria d el e sta d o está ca ra cteriz a d o com o u n a con exió n en tre el clien te y el serv id o r d u ran te la sesión . D u ran te el cierre del arch iv o , o m ed ian te un m ecan ism o de recolecció n de m em oria, el serv id or d eb erá en un m om en to u otro re d a m a r el espacio de m em oria p rin cip al u tilizad o por los clien tes que ya no estén activos. E l pu nto clav e en lo que resp ecta a la toleran cia a fallos en un serv icio con m em oria d el estad o es q u e el servid or m an tien e in form ación en m em oria p rin cip al acerca de sus clien tes. AFS es un se rv icio de arch iv os con m em oria d el estado. U n se rv ic io de a rc h iv o s sin m em o ria d e l estad o ev ita la in fo rm ació n de estad o h acien d o que cad a so licitu d sea au to co n ten id a. En otras palabras, cad a so licitu d id en tifica el arch iv o y la p o si­ ción d en tro del arch iv o (para los acceso s de lectura y escritu ra) de m od o com p leto. El serv id or no n ecesita m an ten er u na tabla de a rch iv os abiertos en m em oria p rin cip al, au n q u e u su alm en te lo hace p or razon es de eficien cia . A d em ás, no h ay n ecesid ad de estab lecer y term in ar u na con exió n m ed ia n te op eracion es o p e n () y c i ó s e (). Estas op eracio n es son to talm en te red u n d an tes, ya que cad a o p e ra ció n de a rch iv o es totalm en te au tónom a y n o se con sid era p arte de una sesión . El p ro ­ ceso clien te abriría el a rch iv o y d icha ap ertu ra no p ro v o caría el en v ío de m en sajes rem otos. Las lectu ras y escritu ras ten d rían lugar co m o m en sajes rem o to s (o b ú sq u ed as en cach é). El cierre final por p arte del clien te im p licaría ú n icam en te, de nuevo, u na op eración local. NFS es un servicio de arch iv os sin m em oria d el estad o La v en taja de un se rv icio con m em oria del estado fren te a otro qu e no lo ten ga es el in crem en ­ to en las p restacion es. L a in form ación acerca de los arch iv o s se alm acen a en cach é d en tro de la m em oria principal, con lo que se pu ed e acced er fácilm en te a la m ism a u tilizan d o el id en tificad or de co n ex ió n , ev itán d o se así accesos a disco. A dem ás, u n servid or con m em oria del estad o sabe si un a rch iv o está abierto para acceso secu en cial v p u ed e, p or tanto, leer de m an era an ticip ad a los b lo q u es sigu ien tes. L os servid ores sin m em oria del estad o no p u ed en h acer esto, ya qu e no tienen nin gú n co n o cim ien to d e cuál es el p ro p ósito de las so licitu d es de los clien tes. La d istin ción en tre u n servicio con m em oria del estad o y otro qu e no lo tenga resulta m ás e v i­ dente cu a n d o co n sid era m o s los efectos de un fallo catastró ñ co qu e tenga lu gar d u rante la activ i­ dad de servicio. Un se rv id o r con m em oria del estado p erderá todos sus d atos de estad o v olátiles d u ran te el fallo. Para p o d e r efectu ar u n a recu p eració n grácil del serv id o r será n ecesario restau rar su estad o , u su alm en te m ed ian te un p ro to co lo de recu p eració n b asad o en un d iálogo con los c lien ­ tes. O tra s form as de recu p era ció n m en os gráciles req u ieren que se ab o rd en las op eracio n es que estu v ieran teniendo lu g a r en el m om en to de p ro d u cirse el fallo. En el caso de qu e lo q u e fallen sean lo s clien tes, el p ro b lem a es d istin to. El servid or n ecesitará d arse cu en ta de que se ha pro d u ­ cid o ese fallo para p o d er reclam ar el esp acio asign ad o p ara registrar el estad o de los p ro cesos del clien te que ha fallad o. E ste fen óm en o se d en om in a en ocasion es d e te cc ió n y e lim in a c ió n de h u é r­ fa n o s. L os serv id o res sin m em oria del estad o no p resen tan estos p ro blem as, ya q u e el serv id or puede, d esp u és del arran q u e, resp on d er a cu alq u ier so licitu d au to co n ten id a sin n in gu na d ificu ltad . Por tanto, los efectos de los fallos de serv id o r y de los m ecan ism o s co rresp o n d ien tes de recu peración son p rácticam en te in ap reciab les. N o existe ningu na d iferen cia en tre un serv id or lento y un se rv i­ dor qu e esté efectu an d o una recu p eración desde el p u n to de vista del clien te. El clien te co n tin u a­ rá retran sm itien d o su so licitu d en caso de no recibir n in gu na respuesta. La d esv en taja de u tiliz a r el robu sto servicio de una m áquina sin m em oria del estad o es qu e los m en sajes de solicitu d so n m ás largos y el p ro cesam ien to de las so licitu d es m ás lento, ya que no se d isp o n e de nin gu na in form ación in tern a para acelerar el p ro cesam ien to. A d em ás, el servicio sin

596

Capítulo 17 Sistemas de archivos distribuidos

m em o ria del esta d o im p o n e restriccio n es ad icion ales al d iseñ o del DFS. En p rim er lu gar, pu esto q u e ca d a de so licitu d id e n tifica el arch iv o dé destino, es n ecesario u tilizar u n esqu em a de n om ­ b ra d o de bajo n iv el q u e sea global y u n ifo rm e para todo el sistem a. T rad u cir los n om b res rem o­ tos en n o m b res lo cales p a ra ca d a so licitu d h a ce que el p ro cesam ien to de las so licitu d es sea todavía m ás lento. E n seg u n d o lu g a r, pu esto q u e lo s clien tes retran sm iten las so licitu d es relativas a ope­ ra cio n e s de arch iv o s, esta s op eracion es d eb en ser id em p o ten tes; es d ecir, cad a o p eració n debe ten er el m ism o efecto y d ev o lv er la m ism a salid a si se eje cu ta v arias veces co n secu tiv am en te. Los a cceso s de lectu ra y escritu ra a u to co n ten id o s son id em p oten tes, siem p re y cu a n d o u tilicen u n con ­ tad o r a b so lu to de b y tes p a ra in d icar la p o sició n dentro del arch iv o a la que q u ieren acced er, y que n o d ep en d a n d e u n d esp la z a m ie n to in crem en tal (com o se h ace en las llam ad as al sistem a r e a d () y w r i t e () d e UNIX). S in em b arg o , d eb em o s ten er cu id ad o a la hora de im p lem en tar las op eracio­ n es d estru ctiv a s (com o p o r ejem p lo el b o rrad o de un arch iv o) con el fin de h acerlas tam bién idem ­ p oten tes. En a lg u n o s en to rn o s, es ab so lu tam en te n ecesario u tilizar u n servicio co n m em oria del estado. Si el serv id o r em p lea el m éto d o de v alid ació n de caché con in icio por p arte d el servid or, no puede p ro p o rcio n a r un se rv icio sin m em oria del estad o, va q u e m an tien e un reg istro de q u é archivos tiene cad a clien te a lm a cen a d o s en su cach é.

NFS V4 •' -

T

p ■'*■•*

-

*■»

4 i*

, -•

.■

.-i---i 7:-.*.

^ Tvluestro;,tratam iento d e, NFS h a co n sid erad o h asta el m o m en to ú n icam en te Ia/yersii &'/d é O T ^ ^ ^ ^ e )^ ^ y E f• l¿t^ Jd ^ í,' NFS m ás r e q e n t e ^ í a ^ e m i i ^ ^ ( V ^ /y dicK a^fe^iór^

- J¿de:m á n ^ ^ p p r t a n t e 'd e ^ veisioñes’añteribres: Eícam fíom ás sighiffcafm) e sju é e ' ■' tocólo^s áRdra con moñona del estado,Toqúe significaJuéWservidor mantiene ePesta< la sesión dé cliente desde el momento que se abre el archivo remoto hasta que se cierran tanto, el protocolo NFS-.propbrciona ahora operaíáonés o p en () y cToseTfyíiúéntf; ' las versiones anteriores'de NFS (que no tenían-memoria del estado) ñó'proporcio: -^dichas opérádones. iAdéinás,-las*versiones ¡mtenóres -especi6cabaniprotocolpsl:separaí para montar sistemas de archivos remotos y para bloquear archivos remotos. V4 proporciof^ i na todas estas car'acfénsticas con üh único protocolo. En particular, el protocolo mount ha/; ■' sidó eliminado, permitiendo a NFS trabajar con cortafuegos de red. El protocoló mount er a ;jl un conocido agujero de seguridad en las implementaciones de NFS. Además, V4 ha mejorado la capacidad délos clientes para almacenar datos de archivos -I en la caché local. Esta característicamejora las prestaciones del sistema de archivos distri- * buido, ya que los clientes pueden resolver más accesos ¿ archivos desde la caché local en •;! í lugar detener qüe acutiiral servidor. ¥ 4 permite a los clientes solicitar también a los servi-,V-á * dores' que bloqueen archivos. Si el servidor concede la solicitud, el cliente mantiene elJilo- , j queo hastaliberarloo hasta'que caduque la concesion jtambién se permite a los clientes W renovar las concesiones existentes). Tradiciónalmente, los sistemas basados en UNIX propor-, donan un bloqueo de archivos sugerido, mientras que los sistemas operativos Windows uti­ lizan un bloqueo obligatorio. Para permitir que NFS fundone adecuadamente con sistemas no UNIX, V4 proporciona ahora también unmecanismo de bloqueo obligatorio. Los nuevos mecanismos de bloqueo y de almacenamiento en caché están basados en el concepto de | delegacióh, por el qué el servidor delega las responsabilidades sobre el contenido y el blo- 1 queo dé un archivo en‘el diente que ha solidtado el bloqueo. Ese cliente delegado mañtie- | ne en caché esa versión del archivo, y otros dientes pueden solidtar a ese cliente delegado . un acceso al contenido del archivo, hasta que el cliente.delegado renuncie al bloqueo y a la delegación. J Por último, mientras que las versiones anteriores de NFS estaban basadas en el pro toco- \ lo de red UDP, V4 está basada en TCP, lo que le permite ajustarse mejor a las cargas de i rá- i fico variables experimentadas por la red. La delegación de responsabilidades en los clientes -a reduce la carga en el servidor y mejora la coherencia de caché. %~4 J -

17.5 Replicación de archivos

597

La forma en que UNIX utiliza los descriptores de archivo y los desplazamientos implícitos es, inherentemente, un mecanismo con memoria del estado. Los servidores deben mantener tablas para establecer la correspondencia entre los descriptores de archivo y los inodos y deben almace­ nar el desplazamiento actual dentro de cada archivo. Este requisito es la razón por la que NFS, que emplea un servicio sin memoria del estado, no emplea descriptores de archivo e incluye un des­ plazamiento explícito en cada acceso.

17.5 Replicación de archivos

J~

La replicación de archivos en diferentes máquinas dentro de un sistema de archivos distribuido constituye un útil mecanismo de redundancia para mejorar la disponibilidad. La replicación multimáquina puede aumentar también las prestaciones: seleccionar una réplica cercana para dar ser­ vicio a una solicitud de acceso da como resultado un tiempo de servicio más corto. El requisito básico de un esquema de replicación es que las diferentes réplicas del mismo archi­ vo residan en máquinas que sean independientes en lo respecta a los fallos, es decir, que la dispo­ nibilidad de una réplica no se vea afectada por la disponibilidad del resto de las réplicas. Este requisito obvio implica que la gestión de la replicación es, inherentemente, una actividad opaca en lo que respecta a la ubicación. Será necesario proporcionar mecanismos para poder colocar una réplica en una máquina concreta. Resulta deseable ocultar los detalles de la replicación a ojos de los usuarios. El establecimiento de la correspondencia entre un nombre de archivo replicado y una réplica concreta es tarea del esquema de nombrado. La existencia de réplicas debe ser invisible para los niveles superiores. Sin embargo, en los niveles inferiores, es necesario distinguir unas réplicas de otras utilizando nom­ bres de bajo nivel distintos. Otro requisito de transparencia es que se debe proporcionar mecanis­ mos de control de la replicación en los niveles superiores. Esos mecanismos de control de la replicación incluyen poder determinar el grado de replicación y la colocación de las réplicas. En determinadas circunstancias, puede que convenga proporcionar estos detalles a los usuarios. Locus, por ejemplo, proporciona a los usuarios y a los administradores del sistema mecanismos para control del esquema de replicación. El problema principal asociado con las réplicas es su actualización. Desde el punto de vista de un usuario, todas las réplicas de un archivo denotan la misma entidad lógica, por lo que cualquier actualización en una réplica debe reflejarse en todas las réplicas restantes. De manera más precisa, será necesario preservar la semántica de coherencia relevante cuando los accesos a las réplicas se contemplen como accesos virtuales a los archivos lógicos de las réplicas. Si la coherencia no tiene una importancia fundamental, puede sacrificarse en aras de la disponibilidad y de las prestaciones. En este compromiso fundamental dentro del área de la tolerancia a fallos, la elección que hay que hacer es entre preservar la coherencia a toda costa, creando así el potencial de un bloqueo indefinido, o sacrificar la coherencia en algunas (en teoría, pocas) circunstancias de fallo catastrófico, para poder garantizar que las operaciones pro­ gresen de manera continua. Locus, por ejemplo, emplea de manera intensiva los mecanismos de replicación y sacrifica la coherencia en caso de que se produzca una partición de la red, con el fin de garantizar la disponibilidad de los accesos de lectura y escritura. Ibis utiliza una variante de la técnica de copia principal. El dominio de las correspondencias de nombres es una pareja . Si no existe ninguna réplica local, se uti­ liza un valor especial. Por tanto, estas correspondencias son relativas a cada máquina concreta. Si la réplica local es la principal, la pareja contendrá dos identificadores idénticos. Ibis soporta un mecanismo de replicación bajo demanda, que es una política de control de replicación auto­ mático similar a los mecanismos de almacenamiento en caché de archivos completos. Con una replicación bajo demanda, la lectura de una réplica no local, hace que esa réplica se almacene localmente en la caché, generando así una nueva réplica no principal. Las actualizaciones se rea­ lizan únicamente en la réplica principal y hacen que las demás réplicas queden invalidadas, enviándose los oportunos mensajes. No se garantiza la invalidación atómica y serializada de todas las réplicas no principales. Por ello, puede darse el caso de que una réplica obsoleta se con­ sidere válida. Para satisfacer los accesos de escritura remotos, lo que se hace es migrar la copia principal hasta la máquina solicitante.

598

Capítulo 17 Sistemas de archivos distribuidos

17.6 Un ejemplo: AFS Andrew es un entorno informático distribuido diseñado e implementado en la Universidad ^ Camegie Mellon. El sistema de archivos Andrew (AFS) constituye el mecanismo subyacente ~ compartición de información entre los clientes del entorno. Transare Corporation asumió el de arrollo de AFS y luego fue adquirida por IBM. Desde entonces, IBM ha producido varias implemerP taciones comerciales de AFS. El sistema AFS fue posteriormente elegido como sistema DFS por ímSlff determinada coalición de empresas del sector, el resultado fue Transare DFS, que forma parte délj¡¡| entorno informático distribuido (DCE, distributed computing environment) de la organización,' OSF. En el año 2000, el laboratorio Transare Lab de IBM anunció que AFS iba a pasar a ser un p n ífll ducto de código abierto (denominado Open AFS), disponible bajo la licencia pública de IBM, p ó j i l f ' lo que Transare DFS fue cancelado como producto comercial. Open AFS está disponible para la mayor parte de las versiones comerciales de UNIX, así com o3J para los sistemas Linux y Microsoft Windows. Muchos fabricantes de UNIX, además de Microsoft,;® soportan el sistema DCE y su sistema de archivos DFS, que está basado en AFS, y el trabajo conti-SF núa para hacer que DCE sea un DFS interplataforma universalmente aceptado. Puesto que AFS Ygg|| Transare DFS son muy similares, vamos a describir AFS en esta sección; cuando hagamos referen f S f cia a Transare DFS lo indicaremos de forma explícita. -Tai AFS trata de resolver muchos de los problemas de los sistemas DFS más simples, como NFS^p§|l es el DFS no experimental más rico en funcionalidad. Incluye un espacio de nombres uniformepiL mecanismos de compartición de archivos independientes de la ubicación, cachés del lado cliente con coherencia de caché y un sistema de autenticación segura basado en KerberosS También incluye mecanismos de caché del lado del servidor en la forma de réplicas, con carácter*, rísticas de alta disponibilidad gracias a la conmutación automática a una réplica en caso de qúaefil servidor de origen deje de estar disponible. Uno de las características más formidables de A FSjsll la escalabilidad. El sistema Andrew permite interconectar más de 5000 estaciones de trabajo. Entri** AFS y Transare DFS, hay ya centenares de implementaciones de este sistema en todo el m undo.5§Í ..

17.6.1 Introducción

*^"5Sw555S

TI r m

AFS distingue entre máquinas cliente (en ocasiones se denominan estaciones de trabajo) y máquinas

servidoras dedicadas. Los servidores y clientes ejecutaron originalmente únicamente el sistema UNIX BSD 4.2, pero AFS ha sido portado a muchos sistemas operativos. Los clientes y servidores se interconectan mediante una red de redes LAN o WAN. A los clientes se les presenta un espacio dividido de nombres de archivo: un espacio de nom­ bres local y un espacio de nombres compartido. Los servidores dedicados, que se denominan Vice por el nombre del software que ejecutan, presentan el espacio de nombres compartido á los clientes en forma de una jerarquía de archivos homogénea, idéntica y transparente a la ubicación. El espacio de nombres local es el sistema de archivos raíz de cada estación de trabajo, del que des­ ciende el espacio de nombres compartido. Las estaciones de trabajo ejecutan el protocolo Virtue'z-~. para comunicarse con Vice y cada una de ellas debe tener un disco local en el que almacenan su espacio de nombres local. Los servidores son, colectivamente, responsables del almacenamiento y la gestión del espacio de nombres compartido. El espacio de nombres local es pequeño, distinto para cada estación de trabajo y contiene programas del sistema esenciales para la operación autó­ noma de las máquinas y para mejorar las correspondientes prestaciones. También son locales los¿ archivos temporales y los archivos que el propietario de la estación de trabajo, por razones de con­ fidencialidad, quiera explícitamente almacenar de modo local. Contemplados con una granularidad más fina, clientes y servidores están estructurados en clusters e interconectados mediante una WAN. Cada cluster consta de una colección de estaciones de trabajo en una LAN y por un representante de Vice denominado servidor de cluster, y cada cluster se conecta a la WAN mediante un encaminador. La descomposición en clusters se lleva a cabo prin­ cipalmente para resolver el problema del aumento de escala. Para optimizar las prestaciones, las estaciones de trabajo deben utilizar el servidor de su propio cluster la mayor parte del tiempo, con el fin de hacer que las referencias a archivos entre cluster sean relativamente infrecuentes. >

17.6 Un ejemplo: AFS

599

L a arq u itectu ra del sistem a de arch ivos tam bién está basada en consideraciones de escala. El p roced im ien to heu rístico b ásico consiste en d escarg ar trabajo de los servidores a los clientes, a la v ista de la exp erien cia que indica que la v elocid ad d e la CPU del servid or es el cuello de botella del sistem a. D e acu erd o co n este principio heurístico, el m ecanism o fundam ental seleccionado p ara las op eracio n es rem o ta s con arch ivos consiste en alm acenar archivos en caché en grandes fragm én tos (64 KB). E sta característica red u ce la latencia de ap ertu ra de los archivos y perm ite que las lectu ras y escritu ras se dirijan a la cop ia alm acen ad a en caché, sin im plicar frecuentem ente a los servid ores.

Brevem ente, he aquí algunas características adicionales del diseño de

APS:

• M o v ilid ad de los clien tes. Los clientes pueden acceder a cualquier archivo del espacio de nom bres com partido desde cualquier estación de trabajo. El cliente puede percibir una cier­ ta degradación inicial de las prestaciones debido al alm acenam iento en caché de los archi­ vos cuando esté accediendo a esos archivos desde una estación de trabajo distinta de la usual. • Segu rid ad . La interfaz Vice se considera la frontera de confianza, porque ningún progra­ m a cliente se ejecuta en las m áquinas Vice. Las funciones de autenticación y de transm isión segura se proporcionan com o parte de un paquete de com unicaciones basado en conexión que utiliza el paradigm a RPC. D espués de la autenticación m utua, un servidor Vice y un cliente se com unican m ediante m ensajes cifrados. El cifrado se realiza m ediante dispositi­ vos hardw are o (m ás lentam ente) por softw are. La inform ación de los clientes y de los gru­ pos está alm acenada en una base de datos de protección replicada en cada servidor. • P rotección . AFS proporciona listas de acceso para proteger los directorios, adem ás de los bits norm ales de UNIX para protección de archivos. La lista de acceso puede contener infor­ m ación sobre aquellos usuarios que están autorizados a acceder a un directorio, adem ás de inform ación acerca de aquellos usuarios que no están autorizados a acceder a él. De este m odo, resulta m uy sencillo especificar que todo el m undo excepto una determ inada perso­ na puede acceder a un directorio. AFS soporta los tipos de acceso de lectura, escritura, bús­ queda, inserción, adm inistración, bloqueo y borrado. • H eterogeneidad . La definición de una interfaz clara con Vice resulta clave para la integra­ ción de diversos sistem as operativos y estaciones de trabajo con distinto hardware. Para facilitar la heterogeneidad, algunos archivos del directorio bin local son enlaces sim bólicos que apuntan a archivos ejecutables específicos de la m áquina que residen en Vice.

17.6.2 Espacio de nom bres com partido El espacio de nom bres com partido de AFS está form ado por unidades com ponentes denom inada volú m enes. Los volúm enes son unidades com ponentes inusualm ente pequeñas. Típicam ente, están asociados con los archivos de u n único cliente. En cada partición de disco residen unos cuan­ tos volúm enes y estos pueden crecer (hasta una determ inada cuota) y reducirse de tamaño. Conceptualm ente, los volúm enes se com binan m ediante un m ecanism o sim ilar al m ecanism o de m ontaje de UNIX. Sin em bargo, la diferencia de granularidad es significativa, ya que en UNIX sólo se puede m ontar una partición de disco com pleta (que contiene un sistem a de archivo). Los volú­ m enes son una unidad adm inistrativa fundam ental y juegan un papel vital en la identificación y localización de los archivos individuales. U n archivo o directorio Vice está identificado por un identificador de bajo nivel denom inado fid . C ada entrada de directorio AFS establece la correspondencia entre un com ponente de nom bre de ruta y un identificador fid . U n fid tiene 96 bits de longitud y tres com ponentes de igual longi­ tud: un núm ero de volumen, un núm ero de vnodo y un unificador. El núm ero de vnodo se utiliza com o índice en una m atriz qu e contiene los inodos de los archivos de un único volum en. El u nificad or perm ite reutilizar los núm eros de vnodo, m anteniendo com pactas de este modo ciertas estructu­ ras de datos. Los identificadores fid son transparentes con respecto a la ubicación; por tanto, los desplazam ientos de archivos de un servidor a otro no invalidan los contenidos de los directorios alm acenados en caché.

600

Capítulo 17 Sistemas de archivos distribuidos

La inform ación de u bicación se m antiene independientem ente para cada volum en en una ba de datos de u b icació n de vo lu m en replicada en cada servidor. Los clientes pueden identificar ll ubicación de todos los volúm enes del sistem a consultando esta base de datos. La agregación di archivos en volúm enes h ace que sea posible m antener la base de datos de ubicación con un 1 ño m anejable. Para equilibrar el espacio de disco disponible y el grado de utilización de los servidores,’^ necesario m igrar los volúm enes entre particiones de disco y servidores. Cuando se envía un volt m en a su nueva ubicación, se deja en su servidor original una inform ación de re-envío temporal para que la base de datos de ubicación n o tenga que actualizarse de m anera síncrona. M ientras s ü está transfiriendo el volum en, el servidor original puede continuar gestionando las actualizacíc nes, que se envían posteriorm ente al nuevo servidor. En un determ inado m om ento, el volum en! desactiva brevem ente para poder procesar las m odificaciones recientes; a continuación, el nueve volum en pasa a estar disponible otra vez en el nuevo sitio. La operación de m ovim iento del volii m en es atóm ica; si alguno de los dos servidores sufre un fallo catastrófico, se aborta la operador com pleta. El sistem a soporta la replicación de sólo lectura con un nivel de granularidad equivalente al d| un volum en com pleto p ara los archivos ejecutables por el sistem a y para los archivos raram en f actualizados en los niveles superiores del espacio de nom bres Vice. La base de datos de u b icad ! de los volúm enes especifica el servidor que contiene la única copia de lectura-escritura de u volum en y una lista de los sitios de replicación de sólo lectura.

17.6.3 Operaciones con archivos y sem ánticas de coherencia El principio fundam ental de arquitectura en AFS es el alm acenam iento en caché de archivos coi pletos extraídos de los servidores. Correspondientem ente, una estad ón de trabajo clien te interác túa con los servidores V ice sólo durante la apertura y el cierre de los archivos, e incluso ésf interacción no siem pre es necesaria. La lectura y escritura de archivos no provoca una interacd B.

'Tsm 2. Si A es el suceso correspondiente al envío de un m ensaje por un proceso y B es el suceso? correspondiente a la recepción de dicho m ensaje por parte de otro proceso, entonces A->

B|

3. S i A - > B y B - > C entonces A -> C. Puesto que un suceso no puede ocurrir antes que sí m ism o, la relación —» es una ordenación pa cial no reflexiva. Si dos sucesos, A y B, no están relacionados por la relación —» (es decir, A no sucedió antes qd B, y B no sucedió antes que A), entonces decim os que estos dos sucesos se ejecutaron concurre tem ente. En este caso, ninguno de los sucesos puede afectar causalm ente al otro. Sin embargo, s A —> B, entonces es posible que el suceso A afecte causalm ente al suceso B. La m ejor m anera de ilustrar las definiciones de concurrencia y de la relación ha sucedido ant es un diagram a espacio-tem poral com o el de la Figura 18.1, La dirección horizontal representa él espacio (es decir, diferentes procesos), y la dirección vertical representa el tiempo. Las líneas ve ticales etiquetadas denotan procesos (o procesadores). Los puntos etiquetados denotan suce U na línea ondulada denota un m ensaje enviado de un proceso a otro. Los sucesos son concurren­ tes si y sólo si no existe ninguna ruta entre los m ismos. ^ Por ejem plo, he aquí algunos de los sucesos relacionados por la relación ha sucedido antes de las Figura 18.1: p 1 - » q2 ro Rt

‘i -j

R3

^

U Pi -> R \ (ya que Pi

fc y t e t e ) 1

H e aquí algunos de los sucesos concurrentes del sistem a %ypi

#

ro Y % ro Y Ps

J

RsYPs

;;

No podem os conocer cuál de dos sucesos concurrentes, com o qQy p 2, ha tenido lugar primero. Sin; em bargo, puesto que ninguno de los dos sucesos puede afectar al otro (no hay ninguna forma queuno de ellos sepa si el otro ya ha ocurrido), no es im portante cuál de ellos haya tenido lugar pri­ m ero. Sólo es im portante que cualesquiera procesos que se preocupen acerca del orden de cuales-; quiera dos sucesos acuerden un cierto orden arbitrario. r;

18.1.2 Implementación Para determ inar que un suceso A ha tenido lugar antes que un suceso B, necesitam os un reloj: com ún o un conjunto de relojes perfectam ente sincronizado. Puesto que un sistem a distribuido no está disponible ninguna de estas dos opciones, tenemos que definir la relación ha sucedido antes sin utilizar relojes físicos. í Con cada suceso del sistem a asociem os una m arca tem poral. Podem os entonces definir eF requisito de ord enación g lobal: para cada pareja de sucesos A y B, si A —» B, entonces la marca tem poral de A es inferior a la marca tem poral de B (m ás adelante verem os que el enunciado inver­ so no tiene porqué ser cierto). ¿C óm o im ponem os el requisito de ordenación global en un entorno distribuido? Definimos dentro de cada proceso P¿ un relo j lógico, LC,. El reloj lógico puede im plem entarse com o un sim­ ple contador que se increm enta cada dos sucesos sucesivos que se ejecuten dentro de un proceso. Puesto que el reloj lógico tiene un valor m onótonam ente creciente, asignará un núm ero unívoco a cada suceso, y si un suceso A tiene lugar antes que el suceso B en el proceso P,, entonces LC¡(A)

18.2 Exclusión mutua

P

P4



P2 P1 — " " Po 1>

Figura

Q

R

3 x m + 1. .

p¡ :i| ¡ -'18

2. El retardo de caso peor para alcanzar un acuerdo es proporcional a m + 1 retardos de trans-|| ferencia de mensaje. 3.

El núm ero de m ensajes requeridos para alcanzar el acuerdo es grande. N inguno de los pro- ; cesos es totalm ente de confianza, por lo que todos los procesos deben recopilar toda la infor- ! m ación y tom ar sus propias decisiones.

En lugar de presentar una solución general, que sería com plicada, vam os a presentar un algo­ ritm o para el caso más sim ple, en el que m = 1 y n = 4. EFalgoritm o requiere dos tu m os de inter- . cam bio de inform ación: 1. Cada proceso envía su valor privado a los otros tres procesos.

J

2. C ada proceso envía la inform ación que ha obtenido en la prim era ronda a todos los demás ' procesos. Un proceso fallido puede, obviam ente, negarse a enviar m ensajes. En este caso, un proceso no ¿ fallido puede seleccionar un valor arbitrario y pretender que dicho valor ha sido enviado por el J proceso fallido. j U na vez que se han com pletado estas dos rondas, un proceso no fallido P, puede construir su J vector X¡ = (A; i , A i 2, Ai 3, Ai 4) del siguiente m odo: 1. A y = V ,

'

2. Para j * i, si al m enos dos de los tres valores inform ados para el proceso Py (en las dos rondas ; de intercam bio) concuerdan, entonces se usa el valor m ayoritario para asignar un valor a A¿¿. En caso contrario, se utiliza un valor predeterm inado (por ejem plo, nil) para asignar el valor a A,%y >

Ejercicios

627

18.8 Resumen E n un sistem a distribuido sin m em oria com ú n y sin un reloj com ún, a veces es im posible deter­ m inar el orden exacto en que se producen lo s sucesos. L a relación ha sucedido antes es sólo una ordenación parcial de los sucesos en un sistem a distribuido. Pueden utilizarse m arcas tem porales para proporcionar una ordenación de sucesos coherente. P uede im plem entarse la exclusión m utua en un entorno distribuido de diversas m aneras. Con el enfoque centralizado, se elige uno de los procesos del sistem a para coordinar la entrada en la sección crítica. C on el enfoque com pletam ente distribuido, la tom a de decisiones se distribuye por todo el sistem a. U n posible algoritm o distribuido, que es aplicable a las redes con estructura de anillo es la técnica de paso de testigo. Para garantizar la atom icidad, todos los sitios en los que una transacción T se haya ejecutado deben acordar cuál es el resultado final de la ejecución. T debe confirm arse en todos los sitios o abortarse en todos los sitios. Para garantizar esta propiedad, el coordinador de la transacción T debe ejecutar un protocolo de confirm ación. El protocolo de confirm ación m ás am pliam ente uti­ lizado es el protocolo 2PC. Podem os m odificar los diversos esquem as de control de concurrencia utilizados en los siste­ m as centralizados para em plearlos en un entorno distribuido. En el caso de los protocolos de b lo ­ queo, sólo necesitam os m odificar la form a en que se im plem enta el gestor de bloqueos. En el caso de los esquem as de m arcas tem porales y de validación, el único cam bio necesario es el desarrollo de u n m ecanism o para generar marcas tem porales unívocas globales. El m ecanism o puede lim i­ tarse a concatenar una m arca tem poral local con el identificador del sitio, o puede hacer avanzar los relojes locales cada vez que se reciba u n m ensaje que tenga una m arca tem poral mayor. El m étodo principal para tratar con los interbloqueos en un entorno distribuido es la detección de interbloqueos. El problem a fundam ental es el de cóm o m antener el grafo de espera. Entre los - m étodos existentes para organizar el grafo de espera se incluyen la técnica centralizada y la técni­ ca com pletam ente distribuida. A lgunos algoritm os distribuidos requieren el uso de un coordinador. Si el coordinador falla debido a un fallo del sitio en el que reside, el sistem a sólo podrá continuar operando si reinicia una nueva copia del coordinador en algún otro sitio. Puede hacer esto m anteniendo un coordina­ dor de reserva que esté listo para asum ir la responsabilidad si el coordinador falla. O tra posible técnica consiste en elegir el nuevo coordinador después de que el antiguo haya fallado. Los algo­ ritm os que determ inan dónde debe reiniciarse una copia del coordinador se denom inan algorit­ m os de elección. Pueden usarse dos algoritm os: el algoritm o de im posición y el algoritm o del anillo, para elegir un nuevo coordinador en el caso de que se produzca un fallo.

Ejercicios

J-'

18.1

Explique las ventajas y desventajas de los dos m étodos que hem os presentado para la gene­ ración de m arcas tem porales globalm ente unívocas.

18.2

El esquem a de m arcas tem porales basadas en reloj lógico que se ha presentado en este capí­ tulo proporciona la siguiente garantía: Si el suceso A ocurre antes que el suceso B, entonces la m arca tem poral de A será m enor que la m arca tem poral de B. Sin em bargo, observe que no podem os ordenar dos sucesos basándonos únicam ente en sus m arcas tem porales. El hecho de que un suceso C tenga una m arca tem poral inferior a la m arca tem poral del suce­ so D no quiere decir necesariam ente que el suceso C haya tenido lugar antes que el suceso D; C y D podrían ser sucesos concurrentes en el sistem a. Proponga diversas form as en las que podría am pliarse el esquem a de m arcas tem porales basado en reloj lógico para distin­ guir entre sucesos concurrentes y sucesos que puedan ordenarse m ediante la relación lia sucedido antes.

18.3

Im agine que nuestra em presa está construyendo una red inform ática y que se nos pide que escribam os un algoritm o para conseguir la exclusión m utua distribuida. ¿Qué esquem a pro­ pondría? Razone su respuesta.

28

Capítulo 18 Coordinación distribuida

18.4 18.5

¿Por qué la detección de interbloqueos es m ucho m ás costosa en un entorno distribuido que en un entorno centralizado? n sw y Im agine que nuestra em presa está construyendo una red inform ática y que se nos pide queSSlS escribam os un esquem a para tratar con el problem a de los interbloqueos.

dl|jj¡||

a.

¿U tilizaría u n esquem a de detección de interbloqueos o un esquem a de prevención interbloqu eos?' ' .9 K

b.

Si fuera a u tilizar un esquem a de prevención de interbloqueos, ¿cuál u tiliz a ría ? !!!! Razone su respuesta.

c. Si fuera a utilizar un esquem a de detección de interbloqueos, ¿cuál utilizaría? Razoneí su respuesta. 18.6

¿En qué circunstancias se com porta m ejor el esquem a espera-m uere que el esquem a h erid o-ISll espera, a la hora de conceder recursos a una serie de transacciones que se estén ejecutando*^® de m anera concurrente? “iSSll

18.7

Considere las técnicas centralizada y com pletam ente distribuida de detección de interblo­ queos. C om pare los dos algoritm os en térm inos de la com plejidad de los m ensajes.

18.8

C onsidere el siguiente algoritm o jerárqu ico de detección de interbloqueos, en el que él grafól de espera global está distribuido entre una serie de controladores diferentes, que están orga-á nizado en form a de árbol. Cada controlador que nó sea una hoja del árbol, m antiene i grafo de espera que contiene inform ación relevante correspondiente a los grafos de los con-J troladores contenidos en el subárbol que se encuentra por debajo suyo. En particular, seangi SA, SB y S c una serie de controladores tales que S c es el ancestro com ún m ás bajo de SAy S¿| ¡ (Sc debe ser único, ya que estam os considerando el caso de un árbol). Suponga que el nodc T, aparece en el grafo de espera local de los controladores SA y SB. Entonces T, tam bién debe! aparecer en el grafo de espera local de Jj a. el controlador Sc b. todos los controladores situados en la trayectoria que va desde Sc a SA

4 >-5

c. todos los controladores situados en la trayectoria que va desde Sc aSB A dem ás, si T, y 7) aparecen en el grafo de espera del controlador SD y existe una trayecto­ ria desde T, a 7) en el grafo de espera de uno de los hijos de SD, entonces deberá existir una arista T¡ —» T;- en el grafo de espera de SD. D em uestre que, si existe un ciclo en cualquiera de los grafos de espera, entonces el sistema está interbloqueado. ------18.9

D iseñe un algoritm o de elección para anillos bidireccionales que sea más eficiente que el que hem os presentado en este capítulo. ¿C uántos m ensajes se necesitan para n procesos?

18.10 C onsidere una configuración en la que los procesadores no estén asociados con identifica­ dores unívocos, pero en la que el núm ero total de procesadores sea conocido y los procesa­ dores estén organizados en form a de un anillo bidireccional. ¿Resulta posible diseñar un algoritm o de elección para esta configuración? 18.11 Considere un fallo que tenga lugar durante el algoritm o 2PC para una transacción. Para cada posible fallo, explique de qué m anera garantiza el algoritm o 2PC la atom icidad de transacción a pesar del fallo. 18.12 Considere el siguiente m odelo de fallo para una serie de procesadores fallidos. Los proce­ sadores siguen el protocolo pero pueden fallar en instantes inesperados de tiempo. Cuando los procesadores fallan, sim plem ente dejan de funcionar y no continúan participando en el sistem a distribuido. D ado este m odelo de fallo, diseñe un algoritm o para alcanzar un acuer­ do entre un conjunto de procesadores. A nalice las condiciones bajo las que podrá alcanzar­ se dicho acuerdo.

>

Notas bibliográficas

629

Notas bibliográficas El algoritm o distribuido para extender la relación ha sucedido antes y transform arla en una orde­ nación total coherente de todos los sucesos del sistem a fue desarrollada por Lam port [1978]. Puede encontrar análisis adicionales relativos a la utilización del tiem po lógico para caracterizar un com portam iento de los sistem as distribuidos en Fidge [1991], Raynal y Singhal [1996], Babaoglu y M arzullo [1993], Schw arz y M attern [1994], y M attem [1988]. El prim er algoritm o general para la im plem entación de la exclusión m utua en un entorno dis­ tribuido tam bién fue desarrollado por Lam port [1978a], El esquem a de Lam port requiere 3 x (n 1) m ensajes por cada entrada en una sección crítica. Subsiguientem ente, Ricart y Agraw ala [1981] propusieron un algoritm o distribuido que sólo requiere 2 x (n - 1) m ensajes. Su algoritm o se pre­ senta en la Sección 18.2.2. U n algoritm o proporcional a la raíz cuadrada para la exclusión m utua en sistem as distribuidos es el descrito por M aekaw a [1985], El algoritm o de paso de testigo para sistem as con estructura de anillo presentado en la Sección 18.2.3 fue desarrollado por Lelann [1977], Carvalho y Roucairol [1983] expusieron la exclusión m utua en las redes inform áticas y A graw al y A bbadi [1991] describen una solución eficiente y tolerante a fallos para la exclusión m utua distribuida. Raynal [1991] presenta una taxonom ía sim ple de los archivos distribuidos de exclusión m utua. La cuestión de la sincronización distribuida fue analizada en Reed y Kanodia [1979] (entorno de m em oria com partida), Lam port [1978a], Lam port [1978b] y Schneider [1982] (procesos com ple­ tam ente disjuntos). Una solución distribuida al problem a de la cena de los filósofos es la presen­ tada por C hang [1980], El protocolo 2PC fue desarrollado por Lam pson y Sturgis [1976] y Gray [1978]. M ohán [1983] analizó dos versiones m odificadas de 2PC, denom inadas “presuposición de la confirm ación” y “presuposición del aborto”, que reducen la sobrecarga de 2P C por el procedim iento de definir suposiciones predeterm inadas en lo que respecta al destino de las transacciones. Algunos artículos que tratan los problem as de im plem entar el concepto de transacción en una base de datos distribuida fueron presentados por G ray [1981], Traiger et al. [1982] y Spector y Schw arz [1983]. Puede encontrar análisis detallados sobre el tem a del control de concurrencia en sistem as distribuidos en B em stein et al. [1987]. En Rosenkrantz et al. [1978] analizan el algoritm o de prevención de interbloqueos distribuido basado en m arcas tem porales. El esquem a de detec­ ción de interbloqueos com pletam ente distribuido presentado en la Sección 18.5.2 fue desarrolla­ do por O berm arck [1982], El esquem a jerárquico de detección de interbloqueos del Ejercicio 18.4 apareció en M enasce y M untz [1979], Knapp [1987] y Singhal [1989] incluyen un repaso del tema de la detección de interbloqueos en sistem as distribuidos. Los interbloqueos tam bién pueden detectarse tom ando instantáneas de un sistem a distribuido, com o se explica en Chandy [1985]. El problem a de los generales bizantinos se expone en Lam port et al. [1982] y Pease et al. [1980]. El algoritm o de im posición fue presentado por G arcía-M olina [1982] y el algoritm o de elección para un sistem a con estructura de anillo fue escrito por Lelann [1977].

Parte Siete

Sistemasde propósito especial Nuestro tratam iento de los-tem as de sistemas operativos se ha centrado hasta ahora principalm ente en los sistemas informáticos de propósito general. Existen, sin em bargo, sistemas de propósito especial cuyos requisitos son dis­ tintos de los de m uchos de los sistemas que hemos descrito hasta ahora. Un sistem a d e tie m p o real es un sistema informático que no sólo requiere que los resultados calculados sean “correctos” , sino tam bién que esos resulta­ dos se produzcan dentro de un periodo de tiem po especificado. Los resultados producidos después de finalizar ese periodo pueden no tener (incluso aunque sean correctos) ningún valor útil. Para dichos sistemas, es necesario m odificar m uchos algoritm os de planificación de ios sistem as operativos tradicionales, con el fin de cum plir con los estrictos requisitos de tem porización. Un sistem a m u ltim e d ia debe ser capaz de m anejar no sólo datos convencio­ nales, com o archivos de texto, programas y docum entos de procesadores de texto, sino tam bién datos multimedia. Los datos m ultim edia están com puestos por datos de flujo continuo (audio y vídeo) adem ás de por datos convenciona­ les. Los datos de flujo continuo (como las imágenes de un vídeo) deben sum i­ nistrarse respetando ciertas restricciones de tiem po (por ejemplo, 25 im ágenes por segundo). Las dem andas relativas a la gestión de datos de flujo continuo requieren realizar cam bios significativos en la estructura de los sistem as ope­ rativos, especialm ente en lo que respecta a la gestión de la m em oria, del disco y de la red.

J-

1

i

Sistemas de tiempo rea/

v.

.

¡x(->

■A V v ■ v " " - “j f ^

- " V

- J

\

\

'

N uestro tratam iento de los tem as relativos a los sistem as operativos se ha centrado principalm en­ te en los sistem as inform áticos de propósito general (por ejem plo, los sistem as de sobrem esa y sis­ tem as servidores). En este capítulo, vam os a volver nuestra atención a los sistem as inform áticos de tiem po real. Los requisitos de los sistem as de tiem po de real difieren de los de m uchos de los sistem as que hem os descrito hasta el m om ento, principalm ente porque los sistem as de tiempo real deben producir los resultados dentro de ciertos lím ites de tiem po. En este capítulo, vam os a pro­ porcionar una panorám ica de los sistem as inform áticos en tiem po real y a describir cóm o deben construirse para satisfacer los estrictos requisitos de tiem po de estos sistem as.

. ,-QBJEHVOS DEL^GAPtoLO

t

'„

. -

• Explicar los requisitos de Jemporización de los sistemas de tiempo reab.'-. •

"

V

A

x / . . .

' Distiñguif^ntrft^stémasíd€tiéfb|w:reaIfe^rictÓs^a‘6stridos.'5H p l^ ^ ^ ^ J ru

19.6 VxW orks 5.x

645

Plazos

i

I t- lP2~

iA

1

1

_L

J

10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Figura 19.10 Planificación por prioridad en finalización de plazo. El algoritm o de planificación con cuota proporcional debe trabajar en conjunción con una polí­ tica de control de adm isión, para garantizar que cada aplicación reciba su cuota de tiem po asig­ nada. La política de control de adm isión sólo adm itirá a un cliente que solicite un núm ero concreto de cuotas si hay suficientes cuotas disponibles. E n nuestro ejem plo, hem os asignado 50 + 15 + 20 = 75 cuotas del total de 100. Si un nuevo proceso D solicitará 30 cuotas, el controlador de adm isión denegaría a D la entrada en el sistema.

19.5.4 Planificación en Pthread El estándar POSIX tam bién proporciona extensiones para inform ática en tiem po real: P O SIX .lb . En esta sección, vam os a analizar parte de la API Pthread de POSIX relacionada con la planificación de hebras en tiem po real. Pthreads define dos clases de planificación para las hebras en tiempo real:

• SCHED_FIFO • SCHED_RR SCHEDJFIFO planifica las hebras de acuerdo con una política en que el prim ero en llegar es el prim ero en ser servido, usando una cola FIFO, com o se indica en la Sección 5.3.1. Sin em bargo, no existe ningún reparto de franjas tem porales entre las hebras de igual prioridad. Por tanto, la hebra de tiem po real de prioridad m ás alta situada al principio de la cola FIFO recibirá la CPU y conti­ nuará ejecutándose hasta term inar, o hasta quedar bloqueada. SCHED_RR (donde RR quiere decir round-robin, es decir, planificación por tum os) es sim ilar a SCHED_FIFO salvo porque incluye una distribución de franjas tem porales entre hebras de igual prioridad. Pthreads proporciona una clase adicional de planificación (SCHED_OTHER) pero su im plem entación no está definida y es específica del sistem a, pudiendo por tanto com portarse de m anera diferente en distintos sistem as. La API Pthread especifica las siguientes dos funciones para consultar y establecer la política de planificación:

• pthread_attr_getsched_policy(pthread_attr_t *attr,

int *policy)

• pthread_attr_getsched_policy(pthread_attr_t *attr,

int policy)

El prim er parám etro de am bas funciones es un puntero al conjunto de atributos de la hebra. El segundo parám etro puede ser un puntero a un entero que defina la política de planificación actual [para pthread_attr_getsched_policy () ] o un valor entero (SCHED_FIFO, SCHED_RR o SCHED_OTHER) para la fu nción pthread_attr_getsched_policy (). A m bas funciones devuelven valores distintos de cero en caso de que se produzca un error. En la Figura 19.11 se m uestra un programa Pthread que usa esta API. Este program a determ i­ na en prim er lugar la política de planificación actual y después selecciona el algoritm o de planifi­ cación SCHED OTHER.

19.6 VxW orks 5.x En esta sección, vam os a describir VxW orks, un popular sistem a operativo de tiem po real que pro­ porciona soporte de tiem po real estricto. VxW orks, desarrollado com ercialm ente por W ind River System s, se utiliza am pliam ente en vehículos, dispositivos de consum o e industriales y en equi­ pos de red com o conm utadores y encam inadores. VxW orks tam bién se em plea para controlar los dos robots, Spirit y O pportunity, que com enzaron a explorar el planeta M arte en 2004.

646

Capítulo 19 Sistemas de tiempo real

#include #include #define NUM_THREADS 5 int main(int argc, char *argv[]) { int i, policy; pthread_t tid[NUM_THREADS]; pthread_attr_t attr; /* obtener atributos predeterminados */ pthread_attr_init(iattr); /* obtener la política de planificación actual */ if (pthread_attr_getschedpolicy(&attr, kpolicy) != 0) fprintf(stderr, "Imposible obtener política.\n"), else { if (policy == SCHED_OTHER) printf("SCHED_OTHER\n"); else if (policy == SCHED_RR) printf("SCHED_RR\n"); else if (policy == SCHED_FIFO) printf("SCHED_FIFO\n"); }

/* establecer la política de planificación - FIFO, RR, u OTHER */ if (pthread_attr_setschedpolicy(&attr, SCHED_OTHER) != 0) fprintf(stderr, "Imposible establecer política.\n”); /* crear las hebras */ for (i = 0; i < NUM_THREADS; i++) pthread_create(&tid[i],&attr,runner,NULL); /* terminar cada una de las hebras */ for (i = 0; i < NUM_THREADS; i++) pthread_join(tid[i], NULL); ~

}

/* Cada hebra tomará el control en esta función */ void *runner(void *param) {

/* realizar alguna tarea ... */ pthread exit(0); } Figura 1 9 .1 1

API de planificación de Pthread.

La organización de VxW orks se m uestra en la Figura 19.12. VxW orks está centrado en torno al • m icrokernel W ind. Recuerde de nuestras explicaciones en la Sección 2.7.3, que los m icrokem els están diseñados de m odo que el kem el del sistem a operativo proporcione un núm ero m ínim o de carac­ terísticas; las utilidades adicionales, com o la conexión por red, los sistem as de archivos y los grá- ;. ficos, se proporcionan en bibliotecas situadas fuera del kem el. Esta técnica ofrece m uchas ventajas

19.6 VxWorks 5.x

647

aplicación de tiempo real integrada

Figura 19.12 La organización de VxWorks. incluyendo la m inim ización del tam año del kem el, que constituye una característica deseable para todo sistem a integrado que requiera una huella de m em oria pequeña. El m icrokernel W ind soporta las siguientes características básicas: • Procesos. El m icrokernel W ind proporciona soporte para procesos individuales y hebras (utilizando la API Pthread). Sin em bargo, de form a sim ilar a Linux, VxW orks no distingue entre procesos y hebras haciendo referencia a am bos con el nom bre dé tareas. • P lan ificación . W ind proporciona dos m odelos separados de planificación: planificación por tum os apropiativa y no apropiativa con 256 niveles diferentes de prioridad. El planifi­ cador tam bién soporta la API POSIX para hebras de tiem po real que se analiza en la Sección 19.5.4. • In terrupciones. El microkernel W ind tam bién gestiona interrupciones. Para cum plir con los requisitos de tiempo real estrictos, los tiem pos de latencia de despacho y de interrupción están acotados. • C om u nicación interprocesos. El m icrokernel W ind proporciona m ecanism os tanto de m em oria com partida com o de paso de m ensajes para la com unicación entre las distintas tareas. W ind tam bién perm ite que las tareas se com uniquen utilizando una técnica denom i­ nada p ip e s , que son un m ecanism o que se com porta del m ism o m odo que una cola FIFO, pero perm ite a las tareas com unicarse en un archivo especial, el pipe. Para proteger los datos com partidos por las distintas tareas, VxW orks proporciona sem áforos y cerrojos m útex, con un protocolo de herencia de prioridades con el fin de. evitar el fenóm eno de inversión de prioridad. Fuera del microkernel, VxW orks incluye varias bibliótecás de com ponentes que proporcionan soporte para POSIX, Java, redes TCP/IP, etc. Todos los com ponentes son opcionáles, perm itiendo al diseñador de un sistem a integrado personalizar el sistem a de acuerdo con sus necesidades específicas. Por ejem plo, si no se requiere la conexión por red, puede excluirse la biblioteca TCP/IP de la im agen del sistem a operativo. Esta estrategia perm ite al diseñador del sistem a operativo incluir sólo las características requeridas, m inim izando así el tam año (o huella de m emoria) del sistem a operativo.

648

Capítulo 19 Sistemas de tiempo real

VxW orks adopta un enfoque interesante en lo que respecta a la gestión de m em oria, permitieng do dos niveles de m em oria virtual. El prim er nivel, que es bastante sim ple, perm ite controla® caché por separado para cada página. Esta política hace que las aplicaciones puedan espec ciertas páginas com o no alm acenables en caché. C uando hay una serie de datos que están siendo com partidos por distintas tareas que se ejecutan en una arquitectura m ultiprocesador, resultaj posible alm acenar los datos com partidos en cachés separadas que sean locales a cada procesado® individual. A m enos que una arquitectura soporte una política de coherencia de caché para garan­ tizar que los m ism os datos que residan en dos cachés no puedan ser distintos, dichos datos com-% partidos no deben alm acenarse en caché y deben residir, en su lugar, únicam ente en memoria principal, para que todas las tareas puedan m antener una vista coherente de los datos. El segundo nivel de m em oria virtual requiere el com ponente opcional de m em oria virtual; VxVM I (Figura 19.12), ju n to con un soporte de una unidad de gestión de m em oria (MMU) por! parte del procesador. Cargando este com ponente opcional en los sistem as con una MMU, V xW orks perm ite a las tareas m arcar ciertas áreas de datos com o privadas. Un área de datos mar­ cada com o privada sólo podrá ser accedida por la tarea a la que pertenezca. A dem ás, VxWorks perm ite declarar com o de sólo lectura las páginas que contienen el código del kem el ju n to con el . vector de interrupción. Esta característica resulta m uy útil, ya que VxW orks no distingue entre los m odos de usuario y de k em el; todas las aplicaciones se ejecutan en m odo kem el, lo que proporcio-j?na a la aplicación acceso al espacio de direcciones com pleto del sistem a. J5 ;

19.7 Resumen U n sistem a de tiem po real es un sistem a inform ático que requiere que se obtengan los resultados rantes de un cierto plazo; los resultados obtenidos después cum plirse el plazo son completamente inútiles. En los dispositivos de consum o e industriales están integrados m uchos sistem as de tiem­ po real. Existen dos' tipos de sistem a de tiem po real: estrictos y no estrictos. Los sistem as de tiem po real no estrictos son los m enos restrictivos, lim itándose a asignar a las tareas de tiemp0 >

Ejercicios

649

real una prioridad de planificación m ayor que a las otras tareas. Los sistem as de tiem po real estric­ tos deben garantizar que se preste servicio a las tareas de tiem po real dentro de los plazos defini­ dos. A dem ás de por los requisitos de tem porización estrictos, los sistem as de tiem po pueden caracterizarse tam bién por e l hecho de que se utilizan para un único propósito y se ejecutan sobre dispositivos de pequeño tam año y.bajo coste. Para cum plir con los requisitos de tem porización, los sistem as operativos de tiem po real deben em plear diversas técnicas. E l planificador para u n sistem a de tiem po real debe poder trabajar con un algoritm o basado en prioridades con apropiación. A dem ás, el sistem a operativo debe perm itir que las tareas que se ejecutan en el kernel sean desalojadas en favor de las tareas de tiem po real con m ayor prioridad. Los sistem as operativos de tiem po real tam bién tratan de resolver los pro­ blem as específicos de tem porización m inim izando la latencia de interrupción com o la de des­ pacho. Entre los algoritm os de planificación de tiem po real podem os citar el algoritm o de planifica­ ción p or prioridad m onótona en tasa y el algoritm o por prioridad en finalización de plazo. La pla­ nificación por prioridad m onótona en tasa asigna una m ayor prioridad a las tareas que requieren la CPU m ás a m enudo, asignando la prioridad m ás baja a aquellas que hacen un uso m ás in fre­ cuente de la CPU. La planificación por prioridad en finalización de plazo asigna la prioridad de acuerdo con los plazos previstos: cuanto m ás próxim o esté un plazo, m ayor será la prioridad del proceso correspondiente. L a planificación con cuota proporcional utiliza la técnica de dividir el tiem po de procesador en u na serie cuotas y asignar un núm ero de cuotas a cada proceso, garan­ tizando así a cada proceso su cuota proporcional de tiem po de CPU. La API Pthread proporciona tam bién diversas funciones para la planificación de hebras en tiem po real.

Ejercicios 19.1

Indique si resulta m ás apropiada la planificación de tiem po real estricta o no estricta en los siguientes entornos: a. Term ostato en una vivienda. b. Sistem a de control para una central de energía nuclear. c. Sistem a de ahorro en un vehículo. d. Sistem a de aterrizaje en un avión com ercial.

19.2

In d iqu e de qué m anera se podría resolver el .problem a de inversión de prioridades en un sistem a de tiempo real. Indique tam bién si las soluciones podrían im plem entarse dentro del contexto de un planificador con cuota proporcional.

19.3

El kernel de Linux 2.6 puede construirse sin sistem a de m em oria virtual. Explique por qué esta característica pu ede resultar atractiva para los diseñadores de sistem as en tiem po real.

19.4

¿En qué circunstancias es la planificación por prioridad m onótona en tasa peor que la pla­ nificación por prioridad de finalización de plazo, a la hora de satisfacer los plazos asociados con cada proceso?

19.5

Considere dos procesos, P2 y P 2, donde p x = 50, ía = 25, p 2 = 75 y t2 = 30. a. ¿Pueden planificarse estos dos procesos utilizando un algoritm o de planificación m onótona en tasa? Ilustre su respuesta utilizando un diagram a de Gantt. b. Ilustre la planificación de estos dos procesos utilizando el algoritm o EDF de planifica­ ción por prioridad en finalización de plazo.

19.6

¿C uáles son los diversos com ponentes de las latencias de interrupción y de despacho?

19.7 ¿

Explique por qué las latencias de interrupción y de despacho deben estar acotadas en un sistem a de tiempo real estricto.

650

Capítulo 19 Sistemas de tiempo real

Notas bibliográficas Los algoritm os de planificación para los sistem as de tiem po real estrictos, com o la planificacióm onótona en tasa y la planificación por prioridad en finalización de plazo, fueron presentados etí Liu y Layland [1973], O tros algoritm os de planificación, asi com o una serie de extensiones a lo algoritm os anteriores se presentan en Jensen et al. [1985], Lehoczky et al. [1989], A udsley et: [1991], M ok [1983] y Stoica et al. [1996]. M ok [1983] describía u n algoritm o de asignación dinám ca de prioridades denom inado planificación con prioridad de la m enor laxitud. Stoica et al [199 analiza el algoritm o de cuota proporcional. Puede encontrar inform ación útil relativa a diverso! sistem as operativos populares que se u tilizan en sistem as integrados en http://rtlinux.oir" http://w indriver.com y http://qnx.com . El tem a de las líneas futuras de investigación y los problem" m ás im portantes abordados por esas investigaciones en el cam po de los sistem as integrados . analiza en un artículo de Stankovic [1996].

Sistemas multim edia

X ' 'í

i, \ ’^ ' i A~

I '

J /

En los capítulos anteriores, nos hem os centrado generalm ente en la form a en la que los sistem as operativos gestionan los datos convencionales, com o archivos de texto, program as, archivos bina­ rios, docum entos de procesadores de textos y hojas de cálculo. Sin em bargo, los sistem as operati­ vos pueden tener que m anejar tam bién otros tipos de datos. U n a tendencia reciente dentro del ám bito tecnológico es la de la incorporación de datos m u ltim ed ia en los sistem as inform áticos. Los datos m ultim edia están com puestos de flujos continuos de datos (audio y vídeo), adem ás de archivos convencionales. Los datos de flujo continuo difieren de los datos convencionales en que los prim eros (por ejem plo, las im ágenes de vídeo) deben sum inistrarse de acuerdo con ciertas res­ tricciones de tiem po (por ejem plo, 24 im ágenes por segundo). E n este capítulo, vam os a analizar los requisitos de los datos de flujo continuo. Tam bién verem os con m ás detalle en qué sentido difieren esos datos de los datos convencionales y cóm o afectan esas diferencias en el diseño de los sistem as operativos que se utilizan en los sistem as m ultim edia.

OBJETIVOS DEL CAPITULO

^

.

•

Identificar las características de ios datos multimedia.

•

Examinar varios algoritmos que s e utilizan para comprimir los datos multimedia. _

•

Explorar los requisitos que los datos multimedia imponen a los sistem as operativos, incluyendo los tem as de planificación de la CPU y del disco, y de gestión d e red.

20.1 ¿Qué es la m ultimedia? El térm ino m ultim edia describe un amplio rango de aplicaciones que se utilizan hoy en día de m odo bastante popular. Entre éstas se incluyen los archivos de audio y vídeo, com o por ejem plo los archivos de audio MP3, las películas de DVD y videoclips de corta duración correspondientes a anuncios de películas o noticias de interés inform ativo que pueden descargarse a través de Internet. Las aplicaciones m ultim edia tam bién incluyen las difusiones en vivo (webcasts, que son difusiones realizada a través de la W orld W ide W eb) de discursos o de eventos deportivos e inclu­ so las cám aras w eb en vivo que perm iten a un espectador de una determ inada ciudad observar a los clientes de un café de París. Las aplicaciones m ultim edia no tienen por qué ser sólo audio o sólo vídeo; en lugar de ello, una aplicación m ultim edia suele incluir una com binación de am bos tipos de datos. Por ejem plo, una película puede estar com puesta por pistas separadas de audio y de vídeo. A sim ism o, las aplicaciones m ultim edia no sólo se distribuyen a com putadoras persona­ les de sobrem esa. Cada vez m ás, tam bién se distribuyen estos datos a dispositivos de m enor tam a­ ño, incluyendo los asistentes digitales personales (PDA, personal digital assistant) y teléfonos J-

651

652

Capítulo 20 Sistemas multimedia

m óviles. Por ejem plo, un agente de bolsa puede hacer que se le envíen las cotizaciones en tiempo’*2 real a su PDA. E n esta sección, vam os a explorar diversas características de los sistem as m ultim edia y a i m inar cóm o pueden enviarse archivos m ultim edia desde un servidor a un sistem a clienfc T am bién vecem os determ inados estándares com unes para la representación de archivos multú dia de audio y vídeo.

20.1.1 Suministro de datos '-'-SU?

Los datos m ultim edia se alm acenan en el sistem a de archivos al igual que cualquier otro tipo de datos. La principal diferencia entre un archivo norm al y un archivo m ultim edia es que al ardSycSg m ultim edia hay que acceder con una tasa específica, m ientras que el acceso a u n archivo hor no requiere ninguna tem porización especial. U tilicem os un vídeo com o ejem plo de lo que quered m os decir con “tasa”. El vídeo está representado por una serie de im ágenes, que se muestran en í rápida sucesión. Cuanto m ás rápido se m uestran las im ágenes, m ás suaves parecen los movirmeníl tos del vídeo. En general, es necesaria una tasa de entre 24 y 30 im ágenes por segundo para qc los m ovim ientos reflejados en el vídeo parezcan suaves a ojos de un espectador hum ano (el ojc retiene cada im agen durante un corto tiem po después de presentarla, conociéndose esta caracte rística con el nom bre de p ersisten cia de la v isió n . U na tasa de entre 24 y 30 im ágenes por segun~fSf do es lo suficientem ente rápida com o para que parezca un m ovim iento continuo). Una inferior a 24 im ágenes por segundo hará que los m ovim ientos parezcan dar saltos. Es necesán¡ que se acceda al archivo de vídeo del sistem a de archivos a una tasa que sea coherente con aqiie lia a la que se está m ostrando el vídeo. Para referim os a los datos que tienen este tipo de reqn is i - j^ S tos de tasa asociados, utilizam os el térm ino de datos de flu jo continuo. Los datos m ultim edia pueden sum inistrarse a u n cliente bien desde el sistem a de archivos loca bien desde un servidor rem oto. Cuando los datos se sum inistran desde el sistem a de archivó local, denom inam os a ese sum inistro reprodu cción lo cal. Com o ejem plos tendríam os la visua||||gg| zación de un DVD en una com putadora de sobrem esa o la audición de un archivo MP3 en un r e p n P S lS r ductor MP3 de m ano. En estos casos, los datos están contenidos en un archivo norm al alm a cen a d o ^ g r , en el sistem a de archivos local y que se reproduce (es decir, se visualiza o se escucha) desde dichorSBF sistem a. Los archivos m ultim edia pueden estar tam bién alm acenados en un servidor rem oto y ser entregados a un cliente a través de una red utilizando una técnica conocida con el nombre d e” 1Z" tran sm isió n de flu jo s (stream ing). El cliente puede ser una com putadora personal o algún otro ^ dispositivo de m enor tam año, com o una com putadora de m ando, un PDA o un teléfono móvil. Los datos correspondientes a contenidos en vivo de tipo continuo (como por ejem plo, cám aras web en vivo) tam bién se envían desde un servidor a uno o m ás clientes. Existen dos tipos de técnicas de transm isión de flujos: descarga progresiva y flujos en tiempo^'Sfe: real. C on una descarga progresiva, se descarga un archivo m ultim edia que contenga audio o - '

íí

r

T-h

El prim er k em el de Linux presentado al público fue la versión 0.01 el 14 de m ayo de 1991. No disponía de capacidad de interconexión por red, sólo se ejecutaba sobre procesadores Intel compatibles con el 80386 y hardw are PC, y tenía un soporte para controladores de dispositivos k fl extrem adam ente limitado. El subsistem a de m em oria virtual era tam bién bastante básico y no j t e incluía ningún soporte para archivos m apeados en m em oria; sin em bargo, incluso esta versión ini- ^ cial soportaba la utilización de páginas com partidas con un m ecanism o de copia durante la e s c r i - , tura. El único sistem a de archivos perm itido era el sistem a de archivos Minix, los prim eros kem els ® de Linux se desarrollaron utilizando una plataform a M inix. Sin em bargo, el kem el sí que implem entaba adecuadam ente los procesos UNIX con espacios de direcciones protegidos. , La siguiente versión im portante, Linux 1.0, fue lanzada el 14 de m arzo de 1994. Esta versión culm inó tres años de rápido desarrollo del kernel de Linux. Q uizá la novedad más im portante era la conexión por red: la versión 1.0 incluía soporte para los protocolos de red estándar TCP/IP de UNIX, así com o una interfaz socket com patible con BSD para la program ación de red. Se añadió soporte de controladores de dispositivo para ejecuta! IP sobre una red Ethernet o (utilizando los protocolos PPP o SLIP) sobre líneas de com unicación serie o vía m ódeiti. El kernel 1.0 tam bién incluía un nuevo sistem a de archivos m uy m ejorado, sin las limitaciones del sistem a de archivos M inix original, y soportaba diversos controladores SCSI para el acceso a discos a alta velocidad. Los desarrolladores am pliaron el subsistem a de m em oria virtual para per­ m itir la paginación sobre los archivos de intercam bio y el m apeo de m em oria de archivos arbitra­ rios (pero en la versión 1.0 sólo se im plem entaba m apeo en m em oria de sólo lectura). Tam bién se incluyó en esta versión una gam a com pleta de soporte hardw are adicional. Aunque todavía restringido a la plataforma PC de Intel, el soporte hardw are había crecido para incluir unidades de disquete y dispositivos CD-ROM, así com o tarjetas de sonido, diversos ratones y teclados internacionales. El kernel proporcionaba em ulación de coma flotante para aquellos usuarios del procesadores 80386 que no dispusieran de coprocesador m atem ático 80387; el siste­ ma im plem entaba asim ism o, m ecanism os de com u n icación interprocesos (IPC) estilo UNIX System V, incluyendo m em oria com partida, sem áforos y colas de m ensajes. Tam bién se propor­ cionaba un soporte sim ple para cargar y descargar dinám icam ente m ódulos del kernel. En este punto, dio com ienzo el desarrollo de la versión 1.1 del kernel, pero posteriorm ente se publicaron num erosos parches cié la versión LO para corregir diversos errores. Fue en este punto cuando se adoptó el patrón estándar de la num eración de las versiones del kem el de Linux. Los kem els con un número de versión secundaria impar, com o 1 .1 ,1 .3 y 2.1 son k e m e ls de desarrollo; los núm eros de versión secundaria pares hacen referencia a k e m e ls de producción estables. Las actualizaciones de los kem els estables sólo buscan solventar errores detectados m ientras que los

21.1 Historia de Linux

673

kernels

de desarrollo pueden incluir funcionalidad m ás reciente que todavía no haya sido suficien­ tem ente probada. En m arzo de 1995, se publicó la versión 1.2 del kernel. Esta versión no ofrecía tantas m ejoras de funcionalidad como la versión 1.0, pero soportaba una variedad m ucho más am plia de dispositi­ vos hardw are, incluyendo la nueva arquitectura de bus hardw are PCI. Los desarrolladores añadie­ ron tam bién otra característica típica de las m áquinas tipo PC (el soporte para eEmodo 8086 virtual de la CPU 80386), con el fin de perm itir la em ulación del sistem a operativo DOS en las com putado­ ras de tipo PC. Tam bién actualizaron la pila de protocolos para proporcionar soporte para el pro­ tocolo IPX y com pletaron la im plem entación IP incluyendo herram ientas de gestión de cuentas y funcionalidad de tipo cortafuegos. La versión 1. 2 del kernel fue el últim o de los kernels Linux sólo para PC. La distribución fuente para Linux 1.2 incluía soporte parcialm ente im plem entado para procesadores SPARC, Alpha y MIPS, pero la integración com pleta de estas otras arquitectura no com enzó hasta después de que se publicara el kernel 1.2 estable. La versión Linux 1.2 se concentró en proporcionar un m ás am plio soporte hardw are y una im plem entación más com pleta de la funcionalidad existente. En aquel mom ento se estaban des­ arrollando m uchas nuevas funcionalidades, pero la integración del nuevo código dentro del códi­ go fuente principal del kernel había sido diferida hasta después de que se publicara el kernel estable 1.2. Com o resultado, el equipo de desarrollo de la versión 1.3 añadió una gran cantidad de fun­ cionalidades nuevas al kernel. Este trabajo culm inó con el lanzam iento de Linux 2.0 en ju nio de 1996. Con este lanzam iento se increm entó el núm ero de versión principal para reflejar dos nuevas capacidades: el soporte para m últiples arquitecturas, incluyendo una versión A lpha nativa com pletam ente de 64 bits, y el soporte para arquitecturas m ultiprocesador. H ay tam bién distribuciones Linux basadas en la ver­ sión 2.0 disponibles para los procesadores de la serie M otorola 68000 y para los sistem as SPARC de Sun. H ay tam bién una versión derivada de Linux que se ejecuta sobre el m icrokernel M ach y que funciona en sistem as PC y Pow erM ac. Los cam bios en la versión 2.0 no se detuvieron ahí. El código de gestión de m em oria fue m ejo­ rado sustancialm ente con el fin de proporcionar una caché unificada para los datos del sistem a de archivos, independientem ente del m ecanism o de caché de los dispositivos de bloque. Com o resul­ tado de este cam bio, el kernel ofrecía unas prestaciones de m em oria virtual y del sistem a de archi­ vos m ucho m ayores. Por prim era vez, el m ecanism o de caché del sistem a de archivos se extendió a los sistem as de archivos en red, y se añadió tam bién soporte para regiones mapeadas en m em o­ ria en las que se pudiera escribir. El kernel 2.0 tam bién m ejoraba significativam ente las prestaciones de las com unicaciones TCP/IP, y se añadieron asim ism o diversos nuevos protocolos de red, incluyendo AppleTalk, AX.25 para la com unicación a través de redes de radioaficionados y soporte RDSI. Se añadió la capacidad de m ontar softw are de red rem oto y volúm enes SMB (M icrosoft LanM anager). O tras m ejoras im portantes de la versión 2.0 fueron el soporte para las hebras internas del ker­ nel, para gestionar dependencias entre m ódulos cargables y para la carga automática de m ódulos a la carta. Se m ejoró en buena m edida la configuración dinám ica del kernel en tiempo de ejecución, utilizando una nueva interfaz de configuración estandarizada. Entre las características añadidas se incluían las cuotas del sistem a de archivos y las clases para planificación de procesos en tiem ­ po real com patibles con POSIX. Las m ejoras con tin u aron co n el lanzam iento de Linux 2.2 en en ero de 1999. Se añadió una v e r­ sión p a ra sistem as UltraSPARC y se m ejoraron las cap acid ad es de com unicación por red, añadien ­ do un sistem a de cortafu egos m ás flexible, unos m ejores m ecan ism os de encam inam iento y de gestión de tráfico y sop orte p ara ventanas de transm isión TCP d e gran tam año y m ecanism os de confirm ación selectiva. C on esta versión podían leerse discos A corn , A pple v NT, y se m ejoró el sistem a de archivo NFS, añ ad ien d o un dem onio NFS en m odo kernel. Los m ecanism os de bloqueo p ara tratam iento de señales, interrupciones y ciertas interrupciones de E/S se rediseñaron utili­ zan d o una granularidad m ás fina que antes, con el fin de m ejorar la velocidad en el m ultiprocesam iento sim étrico (SMP). Las m ejoras en las versiones 2.4 y 2.6 del kernel incluyen un m ay o r soporte para los sistem as SMP, sistem as de archivos con registro diario y m ejoras en el sistem a de gestión de m em oria. El

674

Capítulo 21 El sistema Linux

planificador de procesos ha sido m odificado en la versión 2.6, proporcionando un eficiente algo­ ritm o de planificación con com plejidad 0 (1 ). El kernel Linux 2.6 es ahora apropiativo, permitien­ do desalojar un proceso m ientras se está ejecutando en modo kernel.

21.1.2 El sistem a Linux En m uchos aspectos, el kernel de Linux form a la base del proyecto Linux, pero hay tam bién otros com ponentes que intervienen en la construcción de un sistem a operativo Linux completo. M ientras que el kernel de Linux está com puesto com pletam ente de código escrito partiendo de cero específicam ente para el proyecto Linux, buena parte del softw are de soporte que form a un sistem a Linux no es exclusivo de Linux, sino com ún a diversos sistem as operativos de tipo UNIX. En particular, Linux utiliza m uchas herram ientas desarrolladas com o parte del sistem a operativo BSD de Berkeley, del sistem a X W indow del MIT y del proyecto GNU de la organización Free Softw are Foundation. Esta com p artició n de h erram ien tas ha tenido lu gar en am bas direcciones. L as principales bibliotecas del sistem a de L in u x tiene su origen en el proyecto GNU, pero la com u n id ad Linux ha m ejorado en orm em en te esas bibliotecas resolviendo las om isiones, ineficiencias y errores detecta­ dos. O tros com p on en tes, co m o el co m p ila d o r C de GNU (gcc), ya tenían una calidad lo suficien­ tem ente alta co m o p ara p o d er u sarlos directam ente en Linux. Las herram ientas de adm inistración de red utilizadas en Lin u x d eriv an de código que fue desarrollado para el sistem a BSD 4.3, pero a cam bio otros d erivad os m ás recien tes de BSD, com o FreeBSD, han tom ado prestad o código de Linux. C o m o ejem plos, p o d ríam o s citar la biblioteca m atem ática de em ulación de co m a flotante p ara Intel y los co n trolad ores de d ispositivos h ard w are de sonido p ara PC.

El sistem a Linux, en su conjunto, es m antenido por una red poco estructurada de desarrolladores que colaboran a través de Internet, existiendo pequeños grupos de personas individuales que son responsables de m antener la integridad de determ inados com ponentes específicos. Hay un pequeño núm ero de sitios públicos de archivos ftp (file-transfer-protocol, protocolo de trans­ ferencia de archivos) en Internet que actúan com o repositorio com únm ente aceptado para dichos com ponentes. La com unidad Linux m antiene tam bién el docum ento File Sy stem Hierarchy Standard (estándar de jerarquía del sistem a de archivos) como m edio de m antener la compatibi­ lidad entre los diversos com ponentes del sistema. Este estándar especifica la disposición global de un sistem a de archivos estándar de Linux; determ ina los nom bres de los directorios en los que deben alm acenarse los archivos de configuración, las bibliotecas, los ejecutables del sistem a y los archivos de datos de tiem po de ejecución.

21.1.3 Distribuciones de Linux En teoría, cualquiera puede instalar un sistem a Linux descargando de los sitios ftp las últimas revisiones de los com ponentes del sistem a necesarios y com pilándolas. En los prim eros días de Linux, esto era precisam ente lo que un usuario de Linux tenía que hacer. Sin em bargo, a medida que Linux ha ido m adurando, diversas personas y grupos han tratado de hacer más sencillo este trabajo proporcionando un conjunto de paquetes estándar precom pilado para realizar una insta­ lación de m anera sencilla. Estas colecciones, o distribuciones, incluyen m uchas más cosas que el sistem a Linux básico. N orm alm ente, incluyen tam bién utilidades adicionales de gestión e instalación del sistem a, así com o paquetes precom pilados y listos para instalar m uchas de las herram ientas com unes UNIX, com o servidores de noticias, exploradores web, herram ientas de edición y procesam iento de tex­ tos e incluso juegos. Las prim eras distribuciones gestionaban estos paquetes sim plem ente proporcionando un m ecanism o para desem paquetar todos los archivos en los lugares apropiados. Sin em bargo, una de las contribuciones m ás im portantes de las distribuciones más m odernas es un m ecanism o de gestión avanzada de paquetes. Las distribuciones actuales de Linux incluyen una base de datos de control de los paquetes que perm ite instalar, actualizar o elim inar paquetes de m anera sen­ cilla. J-

21.2 Principios de diseño

675

La distribución SLS, que se rem onta a los prim eros días de Linux, fue la prim era colección de paquetes Linux reconocible com o una distribución com pleta. Sin em bargo, aunque podía instalar­ se com o una sola entidad, SLS carecía de las herram ientas de gestión de paquetes que ahora se incluyen en todas las distribuciones Linux. La distribución S lack w are representó una gran mejo­ ra en lo que respecta a la calidad global, aun cuando su sistem a de gestión de paquetes seguía siendo un tanto pobre; continúa siendo una de las distribuciones m ás am pliam ente instaladas dentro de la com unidad Linux. Desde el lanzam iento de Slackw are, han surgido m uchas distribuciones com erciales y no com erciales de Linux. R ed H a t y D e b ían son distribuciones bastante populares; la prim era ha sido creada por una em presa com ercial de soporte Linux, m ientras que la segunda es de la com u­ nidad de softw are libre Linux. O tras versiones de Linux con soporte com ercial son las distribucio­ nes de C ald era, C raftw o rk s y W o rk G ro u p S olu tion s. El gran seguim iento que Linux ha tenido en A lem ania ha hecho que existan varias distribuciones dedicadas en alem án, incluyendo las ver­ siones de S uSE y U n ifix. Existen dem asiadas distribuciones Linux en circulación com o para enu­ m erarlas todas aquí. Sin em bargo, esa diversidad de distribuciones no im pide la com patibilidad entre unas distribuciones de Linux y otras. La m ayoría de las distribuciones utilizan, o al menos entienden, el form ato de archivo de paquete RPM, y los paquetes com erciales distribuidos en este form ato pueden instalarse y ejecutarse sobre cualquier distribución que acepte archivos RPM.

21.1.4 Licencias Linux El kem el de Linux se distribuye de acuerdo con la licencia pública general de GNU (GPL, general public license), cuyos térm inos establece la organización Free Softw are Foundation. Linux no es un softw are de dom inio público. El térm ino d o m in io p ú b lico im plica que los autores han renun­ ciado a los derechos de propiedad intelectual sobre el softw are, pero los derechos de propiedad intelectual del código de Linux siguen estando en las m anos de los diversos autores del código. Sin em bargo, Linux es softw are lib re, en ¿I sentido de que cualquiera puede copiarlo, m odificar­ lo, utilizarlo en la form a que desee y proporcionar a otros sus propias copias sin ningún tipo de restricción. Las principales consecuencias de las condiciones de licencia de Linux son que nadie que utili­ ce Linux, o que cree su propio derivado de Linux (lo que puede perfectam ente hacerse), puede hacer que el producto derivado sea propietario. El softw are distribuido de acuerdo con la licencia GPL no puede redistribuirse com o producto exclusivam ente binario. Si alguien distribuye algún softw are que incluya cualquier com ponente cubierto por la licencia GPL, entonces, bajo los térm i­ nos de la licencia GPL, debe distribuirse tam bién el código fuente ju n to con la distribución ejecu­ table. (Esta restricción no prohibe la creación ni la venta de distribuciones softw are en código exclusivam ente binario, siem pre y cuando cualquiera que reciba ese código binario tenga también la oportunidad de obtener el código fuente, por un precio de distribución razonable.)

21.2 Principios de diseño En su diseño global, Linux se asem eja a cualquier otra im plem entación tradicional de UNIX no basada en microkernel. Es un sistem a m ultiusuario y m ultítarea con un conjunto com pleto de herram ientas com patibles con UNIX. El sistem a de archivos de Linux respeta la sem ántica UNIX tradicional y en lo que respecta al m odelo de red estándar de UNIX, éste se ha im plem entado en su totalidad. Los detalles internos del diseño de Linux se han visto m uy influidos por la historia del desarrollo de este sistem a operativo. Aunque Linux se ejecuta sobre una am plia variedad de plataform as, fue desarrollado exclusi­ vam ente sobre una arquitectura PC. Una buena parte de aquellos prim eros desarrollados fue aco­ metida por personas entusiastas, en lugar de por organizaciones de investigación o em presas com erciales bien dotadas de fondos, por lo que desde el principio Linux trató de obtener la m áxi­ ma funcionalidad posible a partir de unos recursos lim itados. Hoy en día, Linux puede ejecutar­ se holgadam ente sobre una m áquina iñ u! t i p rocesa do ra con cientos de m egabytes de memoria

676

Capítulo 21 El sistema Linux

principal y m u ch o s gigab ytes de espacio de disco, pero tam bién sigue siendo cap az de op erar de m an era útil en m en os de 4 MB de RAM.

A m edida que los PC se fueron haciendo más potentes y a m edida que fue dism inuyendo el coste de la m em oria y de los discos duros, los kernels Linux originales, de carácter m inim alista, fue­ ron creciendo para im plem entar m ás funcionalidades de UN IX. La velocidad y la eficiencia siguen siendo objetivos de diseño im portantes, pero buena parte del trabajo actual y reciente realizado en Linux se ha concentrado en el tercero de los principales objetivos de diseño: la estandarización. U no de los precios que hay que pagar por la diversidad de las im plem entaciones UN IX actualmen­ te disponibles es que el código fuente escrito para una de las versiones puede o no compilarse o ejecutarse correctam ente en otra. Incluso cuando están presentes las m ism as llam adas al sistema en dos sistem as U N IX diferentes, esas llam adas no se com portan necesariam ente de la misma form a exacta. El estándar PO SIX com prende un conjunto de especificaciones de diferentes aspec­ tos de com portam iento del sistem a operativo. Existen docum entos PO SIX para la funcionalidad m ás com ún del sistem a operativo y para extensiones tales com o hebras de proceso y operaciones en tiem po real. Linux está diseñado para ser com patible con los docum entos POSIX relevantes; hay al m enos dos distribuciones Linux que han conseguido la certificación POSIX oficial. Puesto que presenta interfaces estándar tanto al program ador com o al usuario, Linux no ofre­ ce m uchas sorpresas a cualquiera que esté fam iliarizado con UNIX. N o vam os a detallar esas inter­ faces aquí; las secciones dedicadas a la interfaz del program ador (Sección A.3) y a la interfaz de usuario (Sección A.4) de BSD se aplican tam bién a Linux. Sin em bargo, de m anera predeterm ina­ da, la interfaz de program ación de Linux se adhiere a la sem ántica de UNIX SVR4, en lugar de ajus­ tarse al com portam iento de BSD. Hay disponibles conjuntos separados de bibliotecas para im plem entar la sem ántica de BSD en aquellas situaciones en las que los com portam ientos son sig­ nificativam ente distintos. Existen otros m uchos estándares en el m undo U N IX, pero la certificación com pleta de Linux de acuerdo con esos estándares va algo lenta, porque a m enudo esa certificación sólo puede obtenerse pagando una determ inada licencia, y los gastos necesarios para certificar el cum plim iento de la m ayoría de los estándares por parte de un sistem a operativo resulta sustancial. Sin embargo, soportar una am plia base de aplicaciones es im portante para cualquier sistem a operativo, por lo que la im plem entación de estándares es uno de los objetivos principales del desarrollo de Linux, incluso aunque esa im plem entación no esté certificada form alm ente. A dem ás del estándar POSIX básico, Linux soporta actualm ente las extensiones para hebras de POSIX (Pthreads) y un subconjunto de las extensiones PO SIX para el control de procesos en tiem po real.

21.2.1 Componentes de un sistema Linux El sistem a Linux está form ado por tres cuerpos principales de código, en línea con la m ayoría de las im plem entaciones U N IX más tradicionales: 1. K ern el. El kernel es responsable de m antener todas las abstracciones im portantes del sistema operativo, incluyendo elem entos tales como la m em oria virtual y los procesos. 2. B ib lio te ca s del sistem a. Las bibliotecas del sistem a definen un conjunto estándar de funcio­ nes m ediante las que las aplicaciones pueden interactuar con el kem el. Estas funciones imple­ m entan buena parte de la funcionalidad del sistem a operativo que no necesita los privilegios com pletos del código del kem el. 3.

Utilidades del sistema.

Las utilidades del sistem a son p ro g ram as que realizan tareas indi­ vid u ales y esp ecializad as de gestión. A lgunas utilidades del sistem a pueden ser invocadas p ara inicializar y con figu rar algunos aspectos del sistem a; otras (conocidas com o demonios en la term inología UNIX) pueden ejecutarse de m anera p erm an en te, gestionando tareas tales co m o resp on d er a las conexiones entrantes de red, acep tar solicitudes de inicio d e sesión por p arte de los term inales y actu alizar los archivos de registro.

La Figura 21.1 ilustra los diversos com ponentes que form an un sistem a Linux com pleto. La dis­ tinción m ás im portante aquí es entre el kem el y todo lo dem ás. Todo el código del kem el se ejecu-

21.2 Principios de diseño

677

m ódulos del kernel carg ab les

Figura 21.1 Componentes del sistema Linux. ta en el m odo privilegiado del procesador con acceso com pleto a todos los recursos físicos de la com putadora. Linux se refiere a este modo privilegiado con el térm ino m odo k e rn e l. En Linux, no hay ningún código en modo usuario incluido dentro del kernel. Todo el código de soporte del sis­ tema operativo que no necesite ejecutarse en m odo kernel se coloca en las bibliotecas del sistem a. Aunque varios sistem as operativos m odernos han adoptado una arquitectura de paso de m en­ sajes para el funcionam iento interno de su kernel, Linux m antiene el m odelo histórico de UNIX: El kernel está construido com o un código binario m onolítico. La principal razón es m ejorar las pres­ taciones: puesto que todo el código y las estructuras de datos del kernel ocupan un único espacio de direcciones, no es necesario ningún cam bio de contexto cuando un proceso invoca una función del sistem a operativo o cuando se produce una interrupción hardware. N o es sólo el código prin­ cipal de planificación y de m em oria virtual el que ocupa este espacio de direcciones, todo el códi­ go del kernel, incluyendo todos los controladores de dispositivos, los sistem as de archivos y el código de interconexión de red está presente en el m ismo espacio de direcciones unificado. Incluso aunque todos los com ponentes del kernel com parten esta m ism a área, sigue existiendo espacio para la m odularidad. D e la misma form a que las aplicaciones de usuario pueden cargar bibliotecas com partidas en tiem po de ejecución para integrar una parte de código necesaria, tam ­ bién el kernel de Linux puede cargar (y descargar) módulos dinám icam ente en tiem po de ejecu­ ción. El kem el no necesita conocer de antemano qué módulos pueden ser cargados: esos m ódulos son, verdaderam ente, com ponentes cargables independientes. El kernel de Linux form a la base del sistem a operativo Linux. Proporciona toda la funcionali­ dad necesaria para ejecutar procesos y tam bién proporciona servicios del sistem a para que las aplicaciones dispongan de un acceso arbitrado y protegido a los recursos hardware. El kem el im plem enta todas las características requeridas para poder calificarlo com o un verdadero sistem a operativo. Sin em bargo, visto en sí mismo, el sistem a operativo proporcionado por el kernel de Linux no se parece en nada a un sistem a UNIX. Le faltan m uchas de las características adicionales de UNIX, y la funcionalidad que proporcionan no está necesariam ente en el form ato en el que apli­ cación UNIX la esperaría. El kem el no m antiene directamente la interfaz con el sistem a operativo que es visible para las aplicaciones que se están ejecutando. En lugar de ello, las aplicaciones rea­ lizan llam adas a las bibliotecas del sistema, que a su vez invocan según sea necesario a los servi­ cios del sistem a operativo. Las bibliotecas del sistem a proporcionan m uchos tipos de funcionalidad. En el nivel más sim ­ ple, perm iten a las aplicaciones realizar solicitudes de servicio al sistem a del kernel. Realizar una llam ada al sistem a im plica transferir el control desde el modo de usuario no privilegiado al modo de kernel privilegiado; los detalles de esta transferencia varían de una arquitectura a otra. Las bibliotecas se encargan de recopilar los argum entos de la llamada al sistem a y, en caso necesario, ordenar esos argum entos en la form a especial necesaria para poder hacer la llam ada al sistema. Las bibliotecas tam bién pueden proporcionar versiones más com plejas de las llam adas al sis­ tema básicas. Por ejem plo, las funciones de gestión de archivo con búfer del lenguaje C están im plem entadas en las bibliotecas del sistema, proporcionando un control más avanzado de la E/S de archivo que perm iten las llam adas al sistema básicas del kernel. Las bibliotecas tam bién propor­ cionan rutinas que no se corresponden en absoluto con ninguna llamada al sistem a, com o por

J-

678

Capítulo 21 El sistema Linux

ejem plo algoritm os de ordenación, funciones m atem áticas y rutinas de m anipulación de cadenas de caracteres. Todas las funciones necesarias para perm itir la ejecución de aplicaciones UNIX o POSIX están im plem entadas aquí en las bibliotecas del sistem a. El sistem a Linux incluye una am plia variedad de program as en m odo usuario, tanto utilidades del sistem a com o utilidades de usuario. Las utilidades del sistem a incluyen todos los programas necesarios para inicializar el sistem a, com o por ejem plo los que se usan para configurar dispositi­ vos de red y para cargar m ódulos del kem el. Los program as de servidor que se ejecutan de modo continuo tam bién se consideran utilidades del sistem a; dichos program as gestionan solicitudes de inicio de sesión del usuario, conexiones de red entrantes y las colas de impresión. N o todas las utilidades estándar im plem entan funciones clave de adm inistración del sistema. El entorno de usuario de UNIX contiene un gran núm ero de utilidades estándar para llevar a cabo sim plem ente tareas cotidianas, com o listar el contenido de los directorios, m over y borrar archi­ vos y visualizar el contenido de un archivo. Otras utilidades m ás com plejas pueden realizar fun­ ciones de procesam iento de textos, com o ordenar datos textuales y buscar patrones en el texto de entrada. Juntas, estas utilidades form an un conjunto de herram ientas estándar que los usuarios esperarán encontrar en cualquier sistem a UNIX; aunque no realizan ninguna función del sistema operativo, son una parte im portante del sistem a Linux básico.

21.3 Módulos del kernel El kem el de Linux tiene la capacidad de cargar y descargar secciones arbitrarias del código del ker­ nel bajo dem anda. Estos m ódulos cargables kem el se ejecutan en m odo kem el privilegiado y como consecuencia disponen de acceso com pleto a todas las capacidades hardw are de la m áquina sobre la que se ejecutan. En teoría, no hay ninguna restricción en cuanto a lo que se perm ite hacer a un m ódulo del kem el; típicam ente, un m ódulo puede im plem entar un controlador de dispositivo, un sistem a de archivos o un protocolo de red. Los m ódulos del k em el resultan útiles por varias razones. El código fuente de Linux es gratui­ to, por lo que cualquier persona que quiera escribir código del kem el, puede com pilar un kem el m odificar y rearrancar el sistem a para cargar la nueva funcionalidad; sin em bargo, recompilar, rem ontar y recargar el código com pleto constituye un ciclo de desarrollo bastante engorroso si lo que estam os desarrollando es un nuevo controlador. Si utilizam os m ódulos del kem el no es nece­ sario construir un nuevo kem el para probar un nuevo controlador: el controlador puede compilar­ se por separado y cargarse sobre el kem el que se esté ejecutando. Por supuesto, una vez que se ha escrito.un nuevo controlador, se puede distribuir en form a de m ódulo, de modo que otros usua­ rios puedan beneficiarse del m ism o sin tener que reconstruir sus kem els. Este últim o punto tiene otra im plicación im portante. Puesto que está cubierto por la licencia GPL, el kem el de Linux no puede distribuirse con com ponentes propietarios añadidos, a menos que dichos nuevo com ponentes tam bién se distribuyan según la licencia GPL y se ponga el códi­ go fuente a disposición de aquellos usuarios que los soliciten. La interfaz de m ódulos del kem el perm ite que otras personas u organizaciones interesadas escriban y distribuyan, de acuerdo con sus propios térm inos, controladores de dispositivos o sistem as de archivos que no podrían distri­ buirse de acuerdo con los térm inos de licencia de GPL. Los m ódulos del kem el perm iten construir un sistem a Linux con un kem el estándar mínimo, sin incorporar ningún controlador de dispositivo adicional. C ualquier controlador de dispositivo que el usuario necesite puede ser cargado explícitam ente por el sistem a en el arranque o ser cargado autom áticam ente por el sistem a bajo dem anda, siendo descargado después cuando no se esté uti­ lizando. Por ejem plo, un controlador de CD-ROM podría cargarse cuando se m onte un CD y des­ cargarse de m em oria cuando se desm onte el CD del sistem a de archivos. El soporte de m ódulos en Linux tiene tres com ponentes: 1. El com ponente de g estió n de m ódulos perm ite cargar m ódulos en m em oria y que estos se com uniquen con el resto del kem el. 2. El m ódulo de registros de controladores perm ite a los m ódulos informar al resto de! kem el de que hay disponible un nuevo controlador. >

21.3 Módulos del kernel

679

3. El m ecanism o de resolu ció n de co n flicto s perm ite a los diferentes controladores de disposi­ tivo reservar recursos hardw are y proteger dichos recursos del uso accidental por parte de otro controlador.

21.3.1 Gestión de m ódulos C argar un módulo requiere algo más que cargar su contenido binario en la m emoria del kem el. El sistem a debe también asegurarse de que todas las referencias que el m ódulo realice a los puntos de entrada o sím bolos del kernel se actualicen para apuntar a las ubicaciones correctas dentro del espacio de direcciones del kem el. Linux lleva a cabo esta actualización de referencias dividiendo el trabajo de cargar un m ódulo en dos secciones separadas: la gestión de secciones de código de los m ódulos en m em oria del kem el y la gestión de los sím bolos que se perm ite a los m ódulos que referencien. Linux m antiene una tabla interna de sím bolos en el kem el. Esta tabla de sím bolos no contiene el conjunto com pleto de sím bolos definido en el k em el durante la com pilación de éste; en lugar de ello, cada sím bolo debe ser exportado explícitam ente por el kem el. El conjunto de sím bolos expor­ tado constituye una interfaz bien definida m ediante la que un m ódulo puede interactuar con el kernel. A unque exportar de sím bolos desde una función del k em el requiere una solicitud explícita por parte del programador, no se necesita hacer ningún esfuerzo especial para im portar dichos sím ­ bolos en un módulo. El desarrollador de un m ódulo sim plem ente utiliza el m ecanism o estándar de m ontaje externo del lenguaje C. Todos los sím bolos externos a los que haga referencia el m ódu­ lo y que no estén declarados en el m ism o se m arcan sim plem ente com o no resueltos en el código binario final del m ódulo generado por el com pilador. Cuando hay que cargar un m ódulo en el ker­ nel, una utilidad del sistem a analiza prim ero el m ódulo en busca de estas referencias no resueltas. Todos los símbolos que sea necesario resolver se buscan en la tabla de sím bolos del kem el, intro­ duciéndose en el código del m ódulo las direcciones correctas de dichos sím bolos dentro del ker­ nel que se esté actualm ente ejecutando. Sólo después de esto se pasa el m ódulo al kernel para cargarlo. Si esta utilidad del sistem a no puede resolver alguna referencia contenida en el módulo buscándola en la tabla de sím bolos del kem el, se rechaza la carga del módulo. La carga del módulo se realiza en dos etapas. En prim er lugar, la utilidad cargadora de m ódu­ los pide al kernel que reserve un área continua de la m em oria virtual del kernel para el m ódulo. El kernel devuelve la dirección de la m em oria asignada y la utilidad cargadora puede utilizar esta dirección para reubicar el código m áquina del m ódulo de acuerdo con la dirección de carga correcta. Una segunda llam ada al sistem a pasa entonces el m ódulo, junto con cualquier tabla de sím bolos que el nuevo m ódulo quiera exportar al kernel. El propio módulo se copiará ahora tal cual en el espacio previam ente asignado, actualizándose la tabla de sím bolos del kernel con los nuevos sím bolos, con el fin de perm itir que sean utilizados por otros módulos que todavía no se hayan cargado. El com ponente final de gestión de m ódulos es el solicitante de módulos. El kernel define una interfaz de com unicaciones a la que puede conectarse cualquier program a de gestión de módulos. Una vez establecida esta conexión, el kernel inform ará al proceso de gestión cada vez que un pro­ ceso solicite un controlador de dispositivo, un sistem a de archivos o un servicio de red que no esté actualm ente cargado, dando a ese gestor la oportunidad de cargar dicho servicio. La solicitud ori­ ginal de servicio se com pletará una vez que el m ódulo haya sido cargado. El proceso gestor con­ sulta regularm ente al kem el para ver si se siguen utilizando cada uno de los módulos dinám icam ente cargados, y ¡os descarga cuando ya no están siendo activam ente utilizados.

21.3.2 Registro de controladores Una vez cargado un m ódulo, pasa a ser una sim ple región aislada de memoria hasta que da a conocer al resto del kernel la nueva funcionalidad que ese m ódulo proporciona. El kem el m antie­ ne una serie de tablas dinám icas de todos los controladores conocidos y proporciona un conjunto de rutinas mediante las que se pueden añadir o elim inar controladores de esas tablas en cualquier

680

Capítulo 21 El sistema Linux

instante. El kernel invoca la rutina de arranque de un m ódulo en el m om ento de cargar de ese m ódulo e invoca tam bién la rutina de lim pieza antes de descargarlo: estas rutinas son las respon­ sables de registrar la funcionalidad del m ódulo ante el sistem a. Un m ódulo puede registrar m uchos tipos de controladores y puede registrar m ás de un con­ trolador si así lo desea. Por ejem plo, un controlador de dispositivo podría querer registrar dos m ecanism os separados para acceder a ese dispositivo. Las tablas de registro incluyen los elemen­ tos siguientes:

• Controladores de dispositivos. Estos controladores incluyen dispositivos de caracteres (com o im presoras, term inales y ratones), dispositivos de bloques (incluyendo todas las uni­ dades de disco) y dispositivos de interfaz de red.

• Sistemas de archivo. El sistem a de archivos puede ser cualquier cosa que im plem ente las rutinas de llam ada al sistem a de archivos virtual de Linux. Puede im plem entar un formato para alm acenar archivos en disco, pero tam bién podría ser perfectam ente un sistema de archivos en red, com o NFS, o un sistem a de archivos virtual cuyo contenido se genere bajo dem anda, com o el sistem a de archivos / p ro c de Linux.

• Protocolos de red. U n m ódulo puede im plem entar un protocolo com pleto de comunica­ ción por red com o IPX, o sim plem ente un nuevo conjunto de reglas de filtrado de paquetes para un cortafuegos de red.

• Formato binario. Este form ato especifica una form a de reconocer y cargar un nuevo tipo de archivo ejecutable. A dem ás, un m ódulo puede registrar un nuevo conjunto de entradas en las tablas sysctl y proc, para perm itir configurar dinám icam ente dicho m ódulo (Sección 21.7.4).

21.3.3 Resolución de conflictos Las im plem entaciones de UNIX com erciales suelen venderse para ejecutarlas sobre el propio hard­ ware del fabricante. U na ventaja de las soluciones de un solo fabricante es que el fabricante del softw are tiene una idea bastante correcta acerca de las configuraciones hardw are que son posibles. Sin em bargo, el hardw are IBM PC se presenta en un am plísim o núm ero de configuraciones con una gran cantidad de posibles controladores para dispositivos como tarjetas de red, controladoras SCSI y adaptadoras de pantalla de vídeo. El problem a de gestionar la configuración hardware se com plica cuando se soportan los controladores de dispositivos m odulares, ya que el conjunto actualm ente activo de dispositivos pasa a variar dinám icam ente. Linux proporciona un m ecanism o centralizado de resolución de conflictos com o ayuda para arbitrar en el acceso a ciertos recursos hardw are. Sus objetivos son los siguientes: • Evitar que los m ódulos entren en conflicto a la hora de acceder á los recursos hardware. • Evitar que las autocomprobaciones (las pruebas que un controlador de dispositivo hace para autodetectar la configuración del dispositivo) interfieran con los controladores de dis­ positivo existentes. • Resolver los conflictos entre m últiples controladores que están tratando de acceder al m ism o hardw are; por ejem plo, cuando el controlador de la im presora paralelo y el contro­ lador de red de línea paralelo IP (PLIP, parallel-line IP) tratan de com unicarse con el puerto de im presora paralelo. P ara co n seg u ir e sto s o b jetiv o s, el kernel m an tien e listas de los recu rsos h ard w are asign ados. El

PC tien e un n ú m ero lim ita d o d e p u erto s de E/S p o sib les (d ireccion es d en tro d e su esp acio de d ireccio n es h a rd w a re d e E/S), lín eas d e in terru p ció n y can ales DMA; cu an d o algú n co n tro lad o r de d isp o sitiv o q u iere a c c e d e r a uno d e eso s recu rso s, lo q u e se espera es q u e reserv e p rim ero el recur­ so, so licitá n d o lo a la b a se de d atos d el kernel. E ste req u isito perm ite ad em ás al a d m in istrad o r del sistem a d eterm in a r e x a cta m en te q u é recu rso s h a n sid o asig n ad o s a cad a co n tro lad o r en cualquier in stan te d eterm in a d o .

21.4 Gestión de procesos

681

Los m ódulos deben em plear este m ecanism o para reservar de antem ano los recursos hardw a­ re que esperen utilizar. Si se rechaza la solicitud de reserva porque el recurso no está presente o porque ya está en uso, es responsabilidad del m ódulo decidir qué hacer. El m ódulo puede dar por cancelada la inicialización y solicitar que se le descargue si no puede continuar, o puede seguir adelante em pleando recursos hardw are alternativos.

21.4 Gestión de procesos U n proceso es el contexto básico en el que se da servicio a todas las actividades solicitadas por el usuario dentro del sistem a operativo. Para ser com patible con otros sistem as UN IX, Linux debe uti­ lizar un m odelo de proceso sim ilar a los de las otras versiones de UNIX. Sin em bargo, Linux opera de m anera diferente a UNIX en algunos aspectos clave. En esta sección, vam os a repasar el m ode­ lo tradicional de procesos de UN IX descrito de la Sección A.3.2 y vam os a presentar el propio m odelo de hebras de Linux.

21.4.1 El m odelo de procesos forkO y execO El principio básico de la gestión de procesos UNIX consiste en separar dos operaciones: la creación de un proceso y la ejecución de un nuevo program a. U n nuevo proceso se crea con la llam ada al sistem a f o r k () y un nuevo program a se ejecuta después de una llam ada a e x e c (). Se trata de dos funciones separadas netam ente distintas. Puede crearse un nuevo proceso con f o r k () sin que se ejecute un nuevo program a y el nuevo subproceso sim plem ente continuará ejecutando exacta­ m ente el m ism o program a que el proceso padre estaba ejecutando. De la m ism a forma, para eje­ cutar un program a no se requiere que se cree prim ero un nuevo proceso. Cualquier proceso puede invocar e x e c () en cualquier m om ento. El program a que se esté actualm ente ejecutando se term i­ nará inm ediatam ente y el nuevo program a com enzará a ejecutarse en el contexto del proceso exis­ tente. Este m odelo presenta la ventaja de su gran sim plicidad. En lugar de tener que especificar cada detalle de un nuevo program a en la llam ada al sistem a que ejecuta dicho program a, los nuevos program as se ejecutan en su entorno ya existente. Si un proceso padre quiere m odificar el entor­ no en el que hay que ejecutar un nuevo program a, puede crear un nuevo proceso, y luego, m ien­ tras se sigue ejecutando el program a original en el proceso hijo, realizar las llam adas al sistem a que requiera para m odificar ese proceso hijo antes de ejecutar finalm ente el nuevo programa. En UNIX, por tanto, un proceso abarca toda la inform ación que el sistem a operativo tiene que m antener para controlar el contexto de una sola ejecución de un único program a. En Linux, pode­ m os descom poner este contexto en una serie de secciones específicas. Las propiedades de los pro­ cesos pueden clasificarse en tres grupos: identidad del proceso, entorno y contexto. 21.4.1.1 Id en tid ad del proceso La identidad del proceso está com puesta principalm ente de los siguientes elementos: •

ID de proceso (PID ). Cada proceso tiene un identificador unívoco. Los identificadores PID se utilizan para especificar procesos al sistema operativo cuando una aplicación realiza una llam ada al sistem a para señalizar, m odificar o esperar a otro proceso. Una serie de identifi­ cadores adicionales asocian el proceso con un grupo de procesos (norm alm ente com o un árbol de procesos que se han creado m ediante un único com ando de usuario f o rk ) y con un inicio de sesión concreto.

• C red enciales. Cada proceso debe tener un ID de usuario asociado y uno o más identifica­ dores de grupo (los grupos de usuarios se explican en la Sección 10.6.2) que determ inan los derechos de un proceso para acceder a archivos y recursos del sistema. • Personalidad. Las personalidades de los procesos no se encuentran tradicionalm ente en los sistem as UNIX, pero en Linux cada proceso tiene un identificador de personalidad asoJ-

682

Capítulo 21 El sistema Linux

c ia d o q u e p u e d e m o d ifica r lig e ra m e n te la s e m á n tic a d e cie rta s lla m a d a s al sistem a. Las b ib lio tecas d e e m u la c ió n e m p le a n las p e rso n a lid a d e s p rin cip a lm e n te p a ra so licita r que las lla m a d a s al sis te m a se a n co m p a tib le s co n c ie rta s v a ria n te s d e UNIX.

La m ayor parte de estos identificadores están bajo el control lim itado del propio proceso. Los identificadores de grupo de procesos y de sesión pueden cam biarse si el proceso quiere iniciar un nuévo grupo o sesión. Sus credenciales pueden m odificarse realizando las comprobaciones de seguridad apropiadas. Sin em bargo, el PID principal de un proceso no puede cam biar e identifica unívocam ente al proceso hasta que éste termina.

;

21.4.1.2 Entorno de u n proceso El entorno de un proceso se hereda de su proceso padre y está com puesto por dos vectores con term inación nula: el vector de argum entos y el vector de entorno. El vector de argum entos sim­ plem ente enum era los argum entos de línea de com andos para invocar al program a en ejecución; norm alm ente com ienza con el nom bre del propio program a. El vector de entorno es una lista de parejas “NOMBRE = VALOR” que asocia una serie de variables de entorno con nom bre con sus correspondientes valores textuales arbitrarios. El entorno no se alm acena en la m em oria del ker­ nel, sino en el espacio de direcciones en m odo usuario del propio proceso con el prim er dato en la parte superior de la pila del proceso. Los vectores de argum entos y de entorno no se m odifican cuando se crea un nuevo proceso: el nuevo proceso hijo heredará el entorno que su padre posea. Sin em bargo, cuando se invoca un nuevo program a se establece un entorno com pletam ente nuevo. Al invocar a e x e c ( ) , un proce- ' so debe sum inistrar el entorno para el nuevo program a. El kernel pasa estas variables de entorno al siguiente program a, sustituyendo al entorno actual del proceso. Por lo dem ás, el kem el no inter­ fiere con los vectores de entorno y de línea de com andos, su interpretación se deja completamen- “ • te al arbitrio de las aplicaciones y bibliotecas del m odo usuario. El paso de las variables de entorno de un proceso al siguiente y la herencia de dichas variables por parte de los hijos de un proceso proporciona m aneras flexibles de pasar inform ación a los com ponentes del softw are del sistem a m odo usuario. H ay diversas variables de entorno impor­ tantes que tienen significados convencionales para determ inadas partes de softw are del sistema. Por ejem plo, la variable TERM se configura para nom brar el tipo de term inal conectado a una sesión de usuario; m uchos program as utilizan esta variable para determ inar cóm o realizar opera­ ciones en la pantalla del usuario, por ejem plo, desplazar el cursor o m over una región de texto por la pantalla. Los program as de soporte m ultiiingüe utilizar, la variable LANG para determinar en qué idiom a hay que m ostrar los m ensajes del sistema. El m ecanism o de variables de entorno permite personalizar el sistema operativo para cada pro­ ceso, en lugar de para todo el sistem a en su conjunto. Los usuarios pueden seleccionar su propio idiom a o sus propios editores independientem ente unos de otros. 21.4.1.3 C ontexto de u n proceso La identidad del proceso y las propiedades del entorno se suelen configurar en el momento de crear un proceso y no cam bian hasta que el proceso term ina. Un proceso puede decidir algunos aspectos de su identidad si necesita hacerlo, o puede tam bién alterar su entorno. Por contraste, el contexto de un proceso es el estado del programa en ejecución en un m om ento determ inado, así que está variando constantem ente. El contexto de un proceso incluye las siguientes partes: • C ontexto de p lan ificació n . La parte más im portante del contexto de un proceso es su con­ texto de planificación: la inform ación que necesita el planificador para suspender y reiniciar el proceso. Esta inform ación incluye las copias guardadas de todos los registros procesos. Los registros en com a flotante se alm acenan por separado y se restauran sólo cuando es necesario, de m odo que los procesos que no utilizan aritm ética de com a flotante no tienen que pagar el coste de guardar dicho estado. El contexto de planificación tam bién incluye inform ación acerca de la prioridad de planificación y de las señales pendientes de ser súmi>

21.4 Gestión de procesos

683

nistradas a! proceso. U na parte clave del contexto de planificación es la pila del kernel del proceso, un áre?, separada de la m em oria del kernel reservada para uso exclusivo del códi­ go en m odo kernel. Tanto las llam adas al sistem a com o las interrupciones que se produzcan m ientras el procese se está ejecutando utilizarán esta pila. El kem el m antiene inform ación acerca de los recursos que estén actualm ente siendo consum idos por cada proceso y acerca de los recursos totales consum i­ dos por el procese hasta ahora, desde que fue iniciado.

• C o n ta b ilid a d d e re cu rso s.

La tabla de archivos es una m atriz de punteros a estructuras de archi­ vos del kem el. Cuando se realizan llam adas al sistem a para E/S de archivos, los procesos hacen referencia a los archivos utilizando su índice correspondiente dentro de esta tabla.

• T a b la de arch iv os.

• C o n texto del sistem a de arch ivo s. M ientras que la tabla de archivos enum era los archivos

abiertos existentes, el contexto de sistem a de archivos se aplica a las solicitudes para abrir nuevos archivos. A quí se alm acenan el directorio raíz inicial y los directorios predeterm ina­ dos que haya que utilizar para las nuevas búsquedas archivos. • T a b la de ru tin a de tra ta m ie n to de señ ales. Los sistem as UNIX pueden sum inistrar señales

asincronas a un proceso en respuesta a diversos sucesos externos. La tabla de rutinas de tra­ tam iento de señales define las rutinas dentro del espacio de direcciones del proceso, que hay que invocar cuando lleguen determ inadas señales específicas. El contexto de m em oria virtual describe el contenido com ­ pleto del espacio de direcciones privado de un proceso; hablarem os de él en la Sección 21.6.

• C o n texto de m em o ria v irtu al.

21.4.2 Procesos y hebras Linux proporciona la llam ada al sistem a f o r k () con la funcionalidad tradicional de duplicar un proceso. Linux tam bién proporciona la capacidad de crear hebras usando la llamada al sistem a c l o n e ( ) . Sin em bargo, Linux no distingue entre procesos y hebras. De hecho, Linux utiliza gene­ ralm ente el térm ino tarea (en lugar de proceso o hebra) para referirse a un flujo de control dentro de un programa. Cuando se invoca c l o n e ( ) , se le pasa un conjunto de indicadores para determ inar el grado de com partición que debe haber entre las tareas padre e hija. Algunos de estos indicado­ res son los que a continuación se enum eran:

Por tanto, si se pasa a c l o n e () los indicadores CLONE_FS, CLONE_VM, CLONE_SIGHAND y CLONE_FILES, las tareas padre e hija com partirán la m ism a inform ación del sistem a de archivos (como por ejem plo el directorio de trabajo actual), el m ism o espacio de m em oria, las m ism as ruti­ nas de tratam iento de señales y el m ism o conjunto de archivos abiertos. U tilizar c l o n e () de esta "manera es equivalente a crear una hebra en otros sistem as, ya que la tarea padre com parte la m ayor parte de sus recursos con la tarea hija. Sin em bargo, si no está activado ninguno de estos indicadores en el m om ento de invocar c l o n e (), no tendrá lugar ninguna com partición, con lo que la funcionalidad es sim ilar a la de la llamada al sistem a f o r k (). La falta de distinción entre procesos y hebras es posible porque Linux no alm acena el contex­ to com pleto de un proceso dentro de la estructura principal de datos del proceso; en lugar de ello, alm acena el contexto dentro de subcontextos independientes. Por tanto, el contexto del sistem a de archivos, la tabla de descriptores de archivos, la tabla de rutinas de tratam iento de señales y el contexto de m emoria de un próceso se alm acenan en estructuras de datos separadas. La estructu-

J-

684

Capítulo 21 El sistema Linux

ra de datos del proceso sim plem ente contiene punteros a estas otras estructuras, por lo que cual­ quier núm ero de procesos puede com partir fácilm ente un subcontexto apuntando al mismo subcontexto según sea necesario. Los argum entos de la llam ada al sistem a c l o n e () le dicen a ésta qué subcontextos hay que copiar y cuáles hay que com partir, cuando se crea un nuevo proceso. A l nuevo proceso siempre se le proporciona una nueva identidad y un nuevo contexto' de planificación; sin em bargo, según los argum entos que se le pasen, puede crear nuevas estructuras de datos de subcontexto que se inicialicen com o copias de las del padre, o puede configurar el nuevo proceso para que utilice las m ism as estructuras de datos de subcontexto que el padre esté utilizando. La llam ada al sistema f o r k () no es otra cosa que un caso especial de c l o n e () en el que se copian todos los subcontex­ tos no com partiéndose ninguno de ellos.

21.5 Planificación La planificación es el acto de asignar el tiem po de CPU a las diferentes tareas dentro de un siste­ m a operativo. N orm alm ente, pensam os en la planificación com o si fuera el acto de ejecutar e inte­ rrum pir procesos, pero hay otro aspecto de la planificación que tam bién resulta im portante en Linux; la ejecución de las diversas tareas del kem el. Las tareas del kem el com prenden tanto tareas solicitadas por un proceso en ejecución, com o tareas que se ejecuten internam ente por cuenta de un controlador de dispositivo.

21.5.1 Planificación de procesos Linux tiene dos algoritm os separados de planificación de procesos. U no de ellos es un algoritmo de tiem po com partido para la planificación apropiativa y equitativa entre m últiples procesos; el otro está diseñado para tareas de tiempo real, en la que las prioridades absolutas son más impor­ tantes que la equidad. El algoritm o de planificación utilizado para las tareas norm ales de tiem po com partido fue enorm em ente m ejorado en la versión 2.5 del kem el. A ntes de la versión 2.5, el kem el de Linux eje­ cutaba una variante del algoritm o tradicional de UNIX. Entre otros, los principales problem as del planificador tradicional de UNIX son que no proporciona un adecuado soporte para los sistemas SMP y que no puede escalarse bien a m edida que crece el núm ero de tareas en el sistema. La mejo­ ra realizada en el planificador en la versión 2.5 del kernel proporciona ahora un algoritm o de pla­ nificación que se ejecuta en tiempo constante [lo que se conoce com o 0 (1 )], independientemente del núm ero de tareas que haya en el sistem a. El nuevo planificador tam bién proporciona un soporte m ejorado para SMP, incluyendo m ecanism os de afinidad de procesador y de equilibrado de carga, adem ás de m antener la equidad y de proporcionar soporte para tareas interactivas. El planificador de Linux es un algoritm o apropiativo basado en prioridades, con dos rangos de prioridad separados: un ran go de tiem po real, que va de O hasta 99, y un rango de valores nice, que va de 100 a 140. Estos dos rangos se ponen en correspondencia con un esquem a de priorida­ des global en el que los valores num éricam ente inferiores indican las prioridades más altas. A diferencia de los planificadores de m uchos otros sistem as, Linux asigna a las tareas de mayor prioridad unos cuantos de tiem po más largos, y viceversa. Debido a la naturaleza original del pla­ nificador, esto resulta apropiado para Linux, com o pronto veremos. En la Figura 21.2 se ilustra la relación entre las prioridades y los tamaños de los cuantos de tiem po utilizados. Una tarea se considera elegible para ejecución en la CPU siem pre que todavía le quede tiempo en su cuanto de tiempo. Cuando una tarea ha agotado su cuanto de tiempo, se la considera cadu­ cada y no es elegible de nuevo para ejecución hasta que todas las restantes tareas hayan agotado tam bién su cuanto de tiem po. El kernel m antiene una lista de todas las tareas ejecutables en una estructura de datos denom inada cola de ejecu ció n (runqueue). Debido a su soporte para SMP, cada procesador m antiene su propia cola de ejecución y se planifica de m anera independiente. Cada cola de ejecución contiene dos m atrices de prioridad: m atriz de tareas activas y m atriz de tareas caducadas. La matriz de tareas activas contiene todas las tareas que todavía les queda tiempo en su cuanto de tiempo, m ientras que la m atriz de tareas caducadas contiene todas las tareas cadu>

21.5 Planificación

prioridad numérica

prioridad relativa

cuanto de tiempo

más alta

200 ms

más baja

10 ms

685

99

100

140 Figura

21.2 Relación entre prioridades y tamaño de los cuantos de tiempo.

cadas. Cada una de estas m atrices de prioridad incluye una lista de tareas indexada de acuerdo con la prioridad de cada una (Figura 21.3). El planificador selecciona, para ejecución en la CPU, la tarea con prioridad más alta dentro de la m atriz de tareas activas. En las m áquinas de tipo m ulti­ procesador, esto quiere decir que cada procesador planifica para ejecución la tarea de prioridad m ás alta de su propia cola de ejecución. Cuando todas las tareas han agotado sus cuantos de tiem ­ po (cuando la m atriz activa está vacía), se intercam bian las dos m atrices de prioridad, con lo que la m atriz de tareas caducadas pasa a ser la m atriz de tareas activa, y viceversa. A las tareas se les asignan prioridades dinám icas basadas en el valor nice más o m enos un cier­ to valor m enor o igual a 5, dependiendo de la interactividad de la tarea. El que se sum e o se reste ese valor adicional del valor nice de la tarea dependerá de la interactividad de la misma. La inter­ actividad de una tarea se determ ina basándose en el tiem po que haya estado durm iendo m ientras esperaba a que se realizaran operaciones de E/S. Las tareas m ás interactivas tienen, norm alm en­ te, tiem pos de inactividad m ás largos y es, por tanto, más probable que el valor de ajuste esté m ás próxim o a - 5 , ya que el planificador favorece dichas tareas interactivas. A la inversa, las tareas con tiem pos de inactividad m ás cortos suelen estar lim itadas por el tiempo de procesam iento, de m odo que su prioridad se ajustará a la baja. El recálculo de la prioridad dinám ica de cada tarea tiene lugar cuando esa tarea ha agotado su cuanto de tiem po y es preciso m overla a la m atriz de tareas caducadas. Así, cuando se intercam ­ bian las dos m atrices, todas las tareas de la nueva m atriz de tareas activas tendrán asignadas las nuevas prioridades y sus correspondientes cuantos de tiempo. La planificación en tiem po real de Linux es todavía más sim ple. Linux im plem enta las dos cla­ ses de planificación de tiem po real requeridas por POSDClb: la planificación FCFS (first-come, firstserved) y la planificación por turnos (Secciones 5.3.1 y 5.3.4, respectivam ente). En am bos casos, cada proceso tiene una prioridad, adem ás de pertenecer a una cierta clase de planificación. Los procesos con prioridades diferentes pueden com petir entre sí hasta un cierto punto cuando se uti­ liza una planificación de tiem po com partido; sin em bargo, en la planificación de tiem po real, el planificador siem pre ejecuta el proceso que tenga la mayor prioridad. Entre los procesos de igual prioridad, el planificador ejecuta aquel proceso que haya estado esperando más tiempo. La única matriz de tarea s activas

prioridad listas de tareas

prioridad listas de tareas [0]

[0]

[ 1] [140]

matriz de tareas cad u cad as

[1]

O

©—©—®

©

[140]

Figura 2.13 Lista de tareas indexada de acuerdo con la prioridad. J-

686

Capítulo 21 El sistema Linux

diferencia entre la planificación FCFS y la planificación por turnos es que los procesos FCFS conti­ núan ejecutándose hasta que term inan o se bloquean, m ientras que un proceso en la planificación por turnos será desalojado después de u n cierto tiem po y pasará al final de la cola de planifica­ ción, por lo que los procesos de igual prioridad con planificación por tu m os estarán, en la prácti­ ca, com partiendo el tiem po disponible. A diferencia de lo que sucede con las tareas normales de tiempo com partido, a las tareas de tiem po real se les asigna prioridades estáticas. La planificación de tiem po de real de Linux es un m ecanism o de tiem po real no estricto. El pla­ nificador ofrece unas garantías estrictas acerca de las prioridades relativas de los procesos de tiem po real, pero el kem el no ofrece ninguna garantía sobre la rapidez con que un proceso de tiem­ po real será planificado para ejecución una vez que ese proceso pase a ser ejecutable.

21.5.2 Sincronización del kernel La form a en que el k em el planifica sus propias operaciones es fundam entalm ente distinta de la form a en que planifica los procesos. U na solicitud para ejecución en m odo k em el puede producir­ se de dos form as. U n program a en ejecución puede solicitar un servicio del sistem a operativo, bien explícitam ente m ediante una llam ada al sistem a, o bien im plícitam ente (por ejem plo, cuando se produce un fallo de página). A lternativam ente, un controlador de dispositivo puede generar una interrupción hardware que haga que la CPU com ience a ejecutar una rutina de tratam iento defini­ da por el kem el para dicha interrupción. El problem a que se le plantea al kem el es que todas estas tareas pueden tratar de acceder a las m ismas estructuras internas de datos. Si una tarea del kem el está accediendo a alguna estructura de datos en el m om ento en que se ejecuta una rutina de servicio de interrupción, entonces dicha rutina de servicio no puede acceder a esos m ism os datos ni m odificarlos sin que se corra el riesgo de que los datos se corrom pan. Este hecho se relaciona con la idea de secciones críticas, es decir, partes de código que acceden a datos com partidos y a las que no se les debe perm itir que se eje­ cuten de m anera concurrente. Com o resultado, la sincronización del kernel im plica mucho más que sim plem ente planificar los procesos. Se requiere un m arco de trabajo que perm ita a las tare­ as del kem el ejecutarse sin violar la integridad de los datos com partidos. Antes de la versión 2.6, Linux era un kem el no apropiativo, lo que quiere decir que un proceso que se estuviera ejecutando en m odo kem el no podía ser desalojado, ni siquiera si pasaba a estar disponible para ejecución otro proceso de m ayor prioridad. Con la versión 2.6, el kem el de Linux se ha hecho com pletam ente apropiativo, de modo que ahora una tarea puede ser desalojada cuan­ do se está ejecutando en el kem el. El kem el de Linux proporciona cerrojos de bucle sin fin (spinlock) y sem áforos (así com o versio­ nes lector-escritor de estos dos tipos de bloqueo), para los bloqueos en el kem el. En las máquinas SMP, el m ecanism o de bloqueo fundam ental es un cerrojo de bucle sin fin, el kernel está diseñado de form a que el cerrojo sólo se m antiene durante períodos m uy cortos. En las m aquinas de un solo procesador, éstos cerrojos resultan inapropiados y se sustituyen por un sistem a de activación y desactivación del m ecanism o de apropiación del kem el. En otras palabras, en las m áquinas monoprocesador, en lugar de m antener un cerrojo de bucle sin fin, la tarea desactiva el m ecanism o de apropiación del kem el. C uando ha finalizado con el bloqueo, en lugar de liberar un cerrojo, lo que hace la tarea es volver a activar el m ecanism o de apropiación en el kernel. Este com portam iento se resum e en la siguiente tabla:

monoprocesador

multiprocesador

Linux utiliza una técnica interesante para activar y desactivar el m ecanism o de apropiación -'del kem el. Proporciona dos llam adas al sistem a sim ples, p r e e r r .p t _ d is a b le () y p r e e m p t _ e n a b l e ( ) , para desactivar y activar el m ecanism o de apropiación del kem el. Sin em bargo, ade­ >

21.5 Planificación

687

más de esto, el kem el no es apropiativo si hay una tarea en m odo kem el que esté m anteniendo un bloqueo. Para im poner esta regla, cada tarea tiene una estructura t h r e a d - i n f o que incluye el cam po p r e e m p t_ c o u n t , que es un contador que indica el núm ero de cerrojos que m antiene la tarea. Cuando se adquiere un cerrojo, se increm enta p r e e m p t _ c o u n t. De la m ism a form a, el con­ tador se decrem enta cuando se libera un cerrojo. Si el valor de p r e e m p t_ c o u n t para la tarea que se está actualm ente ejecutando es m ayor que cero, no resulta seguro desalojar a la tarea ya que esa tarea m antiene al m enos un cerrojo. Si el contador tiene un valor igual a cero, puede in­ terrum pirse al kem el sin problem as, suponiendo que no haya ninguna llam ada pendiente a p r e e m p t _ d i s a b l e (). Los cerrojos de bucle sin fin (junto con el sistem a de activación y desactivación del m ecanism o de apropiación del kem el) se utilizan en el kem el sólo cuando el cerrojo se m antiene durante un tiem po m uy corto. Cuando es necesario m antener un cerrojo durante períodos m ás largos se uti­ lizan sem áforos. La segunda técnica de protección que utiliza Linux se aplica a las secciones críticas contenidas en las rutinas de servicio de interrupciones. La herram ienta básica es el hardw are de control de interrupciones del procesador. Desactivando las interrupciones (o utilizando cerrojos de bucle sin fin) durante una sección crítica, el kem el garantiza que se pueda continuar operando sin correr el riesgo de un acceso concurrente a las estructuras de datos com partidas. Sin em bargo, existe un precio a pagar por la desactivación de las interrupciones. En la m ayo­ ría de las arquitecturas hardw are, las instrucciones de activación y desactivación de las interrup­ ciones son costosas. A dem ás, m ientras las interru pciones perm anezcan desactivadas, se interrum pen todas las operaciones de E/S y cualquier dispositivo que esté esperando a ser servi­ do tendrá que esperar hasta que se vuelvan a activar las interrupciones; en consecuencia, las pres­ taciones se degradan. El k em el de Linux utiliza una arquitectura de sincronización que perm ite ejecutar largas secciones críticas por com pleto, sin tener que desactivar las interrupciones. Esta capacidad resulta especialm ente útil en el código de com unicación por red: una interrupción en un controlador de dispositivo de red puede señalar la llegada de un paquete de red com pleto, lo que puede dar com o resultado que se ejecute una gran cantidad de código para desensam blar, encam inar y re-enviar ese paquete dentro de la rutina de servicio de la interrupción. Linux im plem enta esta arquitectura separando en dos secciones las rutinas de servicio de inte­ rrupciones: la mitad superior y la m itad inferior. La m itad superior es una rutina norm al de ser­ vicio de interrupción y se ejecuta teniendo desactivadas las interrupciones recursivas; otras interrupciones de m ayor prioridad pueden interrum pir a la rutina, pero no estarán perm itidas las interrupciones de la m ism a prioridad o de una prioridad m enor. La m itad in ferio r de una rutina de servicio se ejecuta con todas las interrupciones activadas, em pleándose un planificador en m iniatura que garantiza que esas m itades inferiores no se interrum pan nunca a sí m ismas. El pla­ nificador de mitades inferiores se invoca autom áticam ente en el m om ento de salir de una rutina de servicio de interrupción. Esta separación im plica que el kem el puede com pletar cualquier procesam iento com plejo que haya que realizar en respuesta a una interrupción sin preocuparse de que pudiera darse el caso de que se interrum piera a sí mismo. Si se produce otra interrupción m ientras se está ejecutando una mitad inferior, entonces esa interrupción puede solicitar que se ejecute esa m ism a m itad inferior pero la ejecución será diferida hasta que se com plete la m itad inferior que se esté ejecutando actualm ente. Cada ejecución de la mitad inferior puede ser interrum pida por una m itad superior pero nunca por otra m itad inferior similar. La arquitectura basada en esa distinción mitad superior/m itad inferior se com pleta m ediante un m ecanism o para desactivar una serie de m itades inferiores seleccionadas m ientras se ejecuta el código norm al de prim er plano del kem el. D e este m odo, pueden incluirse fácilm ente secciones críticas de código en el kem el. Las rutinas de tratam iento de interrupciones pueden incluir el códi­ go de sus secciones críticas en las secciones inferiores; y cuando el cuerpo principal del kem el quie­ ra entrar en una sección crítica, puede desactivar las m itades inferiores relevantes para evitar que otras secciones críticas le interrum pan. Al final de la sección crítica, el kem el puede volver a acti­ var las m itades inferiores y ejecutar aquellas mitades inferiores que hayan sido puestas en cola por las m itades superiores de las rutinas de servicio de interrupciones durante la sección crítica. J-

688

Capítulo 21 El sistema Linux

I WsaorvK'Rutinas de servicio del sistema del kemel (no desalojables) Programas de modo usuario (desalojables)

■'§ o ■O S o Q.

Figura 21.4 Niveles de protección de interrupción. La Figura 21.4 resum e los diversos niveles de protección de interrupciones dentro del kemel. Cada nivel puede ser interrum pido por código que se esté ejecutando en un nivel superior, pero nunca será interrum pido por código que se ejecute en el m ism o nivel o en un nivel inferior; salvo por lo que respecta al código en m odo usuario, los procesos de usuario siem pre pueden ser des­ alojados por otro proceso cuando se produce una interrupción de planificación de tiem po com­ partido.

21.5.3 Multiprocesamiento simétrico El kem el de Linux 2.0 fue el prim er kernel de Linux estable en soportar hardw are de m u ltip ro c e s a m ie n to s im é tric o (SMP), lo que perm ite que una serie de procesos separados se ejecuten en paralelo en diferentes procesadores. O riginalm ente, la im plem entación de SMP im ponía la restricción de que sólo un procesador podía estar ejecutando código en m odo kem el en cada instante. En la versión 2.2 del kem el, se creó un único cerrojo de bucle sin fin del kem el (en ocasiones denom inado BKL, big k em el lock) para perm itir que estuvieran activos concurrentem ente en el ker­ nel m últiples procesos (ejecutándose en diferentes procesadores). Sin em bargo, el BKL proporcio­ naba un nivel muy grueso de granularidad de bloqueo. Las posteriores versiones del kemel hicieron que la im plem entación SMP fuera m ás escalable, dividiendo este único cerrojo de bucle sin fin en m últiples cerrojos, cada uno de los cuales protege únicam ente un pequeño subconjunto de las estructuras de datos del kem el. D ichos cerrojos de bucle sin fin se describen en la Sección 21.5.2. El kernel 2.6 proporcionaba m ejoras adicionales en el cam po SMP, incluyendo mecanismos de afinidad de procesador y algoritm os de equilibrado de carga.

21.6 Gestión de m em oria La gestión de m em oria en Linux tiene dos com ponentes. El prim ero se encarga de la asignación y de la liberación de la m em oria física: páginas, grupos de página y pequeños bloques de memoria. El segundo gestiona la m em oria virtual, que es la m em oria m apeada sobre el espacio de direccio­ nes de los procesos que se está ejecutando. En esta sección, vam os a describir estos dos compo­ nentes y a exam inar después los m ecanism os m ediante los que los com ponentes cargables de un nuevo program a se cargan dentro de la m em oria virtual de un proceso en respuesta a una llama­ da al sistem a e x e c { ) .

21.6.1 Gestión de m em oria física Debido a características hardw are específicas, Linux separa la m em oria física en tres z o n a s distin­ tas, que identifican diferentes regiones de m emoria. Las zonas se identifican como:

• ZONE_DMA •

ZONE_NORMAL

• ZONE HIGKMEM >

21.6 Gestión de memoria

689

Figura 21.5 Relaciones entre zonas y direcciones físicas en el Intel 80x86. Estas zonas son específicas de la arquitectura. Por ejem plo, en la arquitectura Intel 8 0x86, cier­ tos dispositivos ISA (industry standard architecture) sólo pueden acceder a los 16 MB m ás bajos de la m em oria física utilizando DMA. En estos sistem as, los prim eros 16 MB de la m em oria física for­ m an la zona ZONE_DMA. ZONE_NORMAL identifica la m em oria física que se m apea sobre el espa­ cio de direcciones de la CPU. Esta zona se utiliza para la m ayoría de las solicitudes de m em oria norm ales. Para las arquitecturas que no im pongan un lím ite a la zona de m em oria a la que se puede acceder m ediante DMA, ZONE_DMA no está presente, utilizándose ZONE_NORMAL. Final­ m ente, Z0NE_HIGHMEM (“high m em ory”) hace referencia a la m em oria física que no está m apea­ da sobre el espacio de direcciones del kem el. Por ejem plo, en la arquitectura de 32 bits de Intel (en la que 232 proporciona 4 GB de espacio de direcciones), el kernel se m apea sobre los prim eros 896 MB del espacio de direcciones; la m em oria restante se denom ina m e m o r ia a lta y se asigna a par­ tir de ZONE_HIGHMEM. En la Figura 21.5 se m uestra la relación entre las zonas y las direcciones físicas en la arquitectura Intel 8 0x86. El kem el m antiene una lista de páginas libres para cada zona. Cuando llega una solicitud de m em oria física, el kem el satisface la solicitud usando la zona apro­ piada. El gestor principal de m em oria física en el kem el de Linux es el a s ig n a d o r d e p á g in a s . Cada zona tiene su propio asignador que es responsable de asignar y liberar todas las páginas físicas de la zona, y es capaz de asignar rangos de páginas físicam ente contiguas según se vaya solicitando. El asignador utiliza un s is te m a d e d e s c o m p o s ic ió n b in a r ia (Sección 9.8.1), para controlar las pági­ nas físicas disponibles. Según este esquem a, se agrupan las unidades adyacentes de m em oria asig­ nable. C ada región de m em oria asignable tiene una región adyacente asociada. Cuando se liberan dos regiones asociadas adyacentes, se las com bina para form ar una región más grande. Dicha región tiene tam bién otra región asociada con la que se puede com binar para form ar una región todavía m ayor. A la inversa, si no se puede satisfacer una solicitud de m em oria de pequeño tam a­ ño, asignando una región libre pequeña ya existente, se subdividirá una región libre de mayor tam año en dos regiones asociadas con el fin de satisfacer la solicitud. Se utilizan listas enlazadas separadas para llevar la cuenta de las regiones libres de m em oria de cada uno de los tam años per­ m itidos; en Linux, el tam año asignable más pequeño con este m ecanism o es una única página físi­ ca. La Figura 2 1 .6 m uestra un ejem plo de asignación por descom posición binaria. Se quiere asignar una región de 4 KB, pero la región m ás pequeña disponible es una de 16 KB. En consecuen­ cia, esta región se descom pone recursivam ente hasta obtener un fragm ento del tam año deseado.

Figura 21.6 División de la memoria en el sistema de descomposición binaria.

690

Capítulo 21 El sistema Linux

En últim o térm ino, todas las asignaciones de m em oria dentro del kernel de Linux se realizan estáticam ente (por controladores que reservan un área continua de m em oria durante el arranque del sistem a) o dinám icam ente (por parte del asignador de página). Sin em bargo, las funciones del kernel no tienen que usar obligatoriam ente el asignador básico para reservar m emoria. Varios sub­ sistem as especializados de gestión de m em oria em plean el asignador de páginas subyacentes para gestionar sus propias secciones de m em oria. Los m ás im portantes son el sistem a de memoria vir­ tual, descrito en la Sección 21.6.2, el asignador de tam año variable k m a l lo c (); el asignador de franjas utilizado para asignar m em oria para las estructuras de datos del k em el y la caché de pági­ nas, utilizada para alm acenar en caché las páginas pertenecientes a los archivos. M uchos com ponentes del sistem a operativo Linux necesitan asignar páginas com pletas de acuerdo con las solicitudes recibidas, pero a m enudo se necesitan bloques de m em oria más peque­ ños. El kernel proporciona un asignador adicional para solicitudes de tam año arbitrario, en las que el tam año de la solicitud no se conoce de antem ano y puede ser de sólo unos pocos bytes, en lugar de una página com pleta. D e form a análoga, a la función m al l o e () del lenguaje C, este servicio k m a l lo c () asigna páginas com pleta bajo dem anda, pero luego las descom pone en fragmentos m ás pequeños. El kem el m antiene un conjunto de listas de páginas que estén siendo utilizadas por el servicio k m a l lo c (). La asignación de m em oria im plica utilizar la lista apropiada y extraer de ella el fragm ento disponible o asignar una nueva página y dividirla, Las regiones de memoria reservadas por el sistem a k m a l lo c O se asignan perm anentem ente hasta que se las libera de form a explícita; el sistem a k m a l lo c () no puede reubicar ni reclam ar estas regiones en respuesta a las situaciones de falta de memoria. O tra estrategia adoptada por Linux para asignar m em oria del kem el se conoce con el nombre de asignación de franjas. U na fra n ja se utiliza para asignar m em oria para las estructuras de datos del kem el y está com puesta de una o más páginas físicam ente contiguas. C ada caché está com­ puesta de una o m ás franjas y existe una sola caché por cada estructura de datos del kem el distin­ ta: por ejem plo, una caché para la estructura de datos que representa los descriptores de procesos, otra caché para los objetos de archivos, una caché para los sem áforos, etc. Cada caché se rellena con o b jeto s, que son instancias de las estructuras de datos del kernel que esa caché representa. Por ejem plo, la caché que representa los sem áforos alm acena instancias de objetos sem áforo, la caché que representa descriptores de procesos alm acena instancias de objetos descriptor de proceso, etc. En la Figura 21.7 se m uestra la relación entre franjas, cachés y objetos. La figura m uestra dos obje­ tos del kernel de 3 KB de tam año y tres objetos de 7 KB de tam año. Estos objetos están almacena­ dos en las cachés respectivas para los objetos de 3 KB y 7 KB. El algoritm o de asignación de franjas utiliza cachés para alm acenar objetos del kernel. Cuando se crea una caché, se la asigna una serie de objetos, que están inicialm ente m arcados com o libres.

objetos del kernel

cachés

franjas

páginas físicamente contiguas

Figura 21.7 Asignador de franjas en Linux.

21.6 Gestión de memoria

691

El núm ero de objetos en la caché dependerá del tam año de la franja asociada. Por ejem plo, una franja de 12 KB (com puesta de tres páginas de 4 KB contiguas) podría alm acenar 6 objetos de 2 KB. Inicialm ente, todos los objetos de la caché están m arcados com o libres. Cuando se necesita u n nuevo objeto para una estructura de datos del kernel, el asignador puede asignar cualquier objeto libre de la caché para satisfacer la solicitud. El objeto asignado de la caché se m arca como usado. C onsiderem os un escenario en el que el kem el solicita m em oria al asignador de franjas para un objeto que representa al descriptor de un proceso. En los sistem as Linux, un descriptor de proce­ so tiene el tipo s t r u c t t a s k _ s t r u c t , que requiere aproxim adam ente 1,7 KB de memoria. Cuando el kem el de Linux crea una nueva tarea, solicita la m em oria necesaria para el objeto s t r u c t t a s k _ s t r u c t a la caché correspondiente. La caché satisfará la solicitud utilizando un objeto s t r u c t t a s k _ s t r u c t que ya haya sido asignado en una franja y que esté m arcado como libre. En Linux, una franja p u ed e estar en uno de tres posibles estados: 1. Llena. Todos los objetos de la franja están m arcados com o utilizados. 2. V acía. Todos los objetos de la franja están m arcados com o libres. 3. Parcial. La franja está com puesta de objetos tanto libres com o utilizados. El asignador de franjas prim ero intenta satisfacer la solicitud con un objeto libre de una franja parcial. Si no existe ninguno, se asigna un objeto libre de una franja vacía. Si no hay disponible ninguna franja vacía, se d efine una nueva franja form ada por una serie de páginas físicam ente contiguas y se la asigna a una caché; la m em oria para el objeto se asigna a partir de esta franja. Los otros dos subsistem as principales de Linux que realizan su propia gestión de páginas físi­ cas están estrecham ente relacionados entre sí. Se trata de la caché de páginas y del sistem a de m em oria virtual. La caché de páginas es la caché principal del kem el para los dispositivos orien­ tados a bloques y para los archivos m apeados en m em oria, y constituye el m ecanism o principal m ediante el que se llevan a cabo las operaciones de E/S con estos dispositivos. Tanto los sistem as de archivo nativos de Linux, basados en disco, como el sistem a de archivos en red NFS utilizan la caché de páginas. La caché de páginas alm acena páginas com pletas de los archivos y no está lim i­ tada a los dispositivos de bloques; tam bién pueden alm acenarse en caché datos relacionados con la com unicación por red. El sistem a de m em oria virtual gestiona el contenido del espacio de direc­ ciones virtual de cada proceso. Estos dos sistem as interactúan estrecham ente, porque leer una página d e datos para cargarla en la caché de páginas requiere m apear las páginas sobre la caché de páginas em pleando el sistem a de m em oria virtual. En las secciones siguientes, vam os a exam i­ nar el sistem a de m em oria virtual con m ayor detalle.

21.6.2 Memoria virtual El sistem a de m em oria virtual de Linux es responsable de m antener el espacio de direcciones visi­ ble para cada proceso. Este sistem a crea páginas de m em oria virtual bajo dem anda y gestiona la carga de dichas páginas desde el disco o la escritura de esas páginas en el espacio de intercam bio del disco, según sea necesario. En Linux, el gestor de m em oria virtual m antiene dos vistas sepa­ radas del espacio de direcciones de un proceso: una com o conjunto de regiones separadas y otra com o conjunto de páginas. La prim era vista de un espacio de direcciones es la vista lógica, que describe las instrucciones que el sistem a de m em oria virtual ha recibido en lo que respecta a ala disposición del espacio de direcciones. En esta vista, el espacio de direcciones consta de un conjunto de regiones no sola­ padas, donde cada región representa un subconjunto continuo del espacio de direcciones con alineación de página. Cada región se describe internam ente m ediante una única estructura v m _ a r e a _ s t r u c t que define las propiedades de la región, incluyendo los perm isos de lectura, escritura y ejecución del proceso para dicha región e inform ación acerca de cualesquiera archivos que estén asociados con esa región. Las regiones de cada espacio de direcciones están enlazadas

692

Capítulo 21 El sistema Linux

en un árbol binario equilibrado, con el fin de perm itir la búsqueda rápida de la región correspon­ diente a cualquier dirección virtual. El kem el tam bién m antiene una segunda vista, de carácter físico, de cada espacio de direccio­ nes. Esta vista está alm acenada en las tablas de páginas hardw are del proceso. Las entradas de la tabla de páginas determ inan la ubicación actual exacta de cada página de m em oria virtual, inde­ pendientem ente de si se encuentra en disco o-en la m em oria física. La vista física está gestionada por un conjunto de rutinas que se invocan desde las rutinas de servicio de interrupciones softwa­ re del kem el cada vez que u n proceso trata de acceder a una página que no se encuentra actual­ m ente en las tablas de páginas. Cada estructura v m _ a r e a _ s t r u c t de la descripción del espacio de direcciones contiene un cam po que apunta a una tabla de funciones que im plem enta las fun­ ciones clave de gestión de páginas para cualquier región de m em oria virtual dada. Todas las soli­ citudes de leer o escribir una página no disponible term inan por ser despachadas a la rutina de tratam iento apropiada en la tabla de funciones de la estructura v m _ a r e a _ s t r u c t , de modo que las rutinas centrales de gestión de m em oria no necesitan conocer los detalles relativos a cómo ges­ tionar cada uno de los tipos posibles de regiones de m em oria. 21.6.2.1 R eg io n es de m em oria virtu al Linux im plem enta varios tipos de regiones de m em oria virtual. La prim era propiedad que carac­ teriza a un tipo de m em oria virtual es el alm acenam iento de respaldo utilizado para la región, que describe el lugar del que proceden las páginas de esa región. La m ayoría de las regiones de memo­ ria utilizan com o origen un archivo o nada en absoluto. U na región que no tenga nada como ori­ gen es el tipo m ás sim ple de m em oria virtual. Dicha región representa lo que se denom ina una m em oria dem andada con ceros. C uando u n proceso trata de leer una página en una de esas regio­ nes, sim plem ente se le devuelve una página de m em oria rellenada con ceros. U na región que tenga com o origen un archivo actúa com o una especie de visor de una sección de ese archivo. Cuando el proceso intenta acceder a una página dentro de esa región, la tabla de páginas se llena con la dirección de una página dentro de la caché del kem el que se corresponde con el desplazam iento apropiado dentro del archivo. La caché de páginas y las tablas de páginas del proceso utilizan la m ism a página de m em oria física, por lo que cualquier cam bio hecho en el archivo por el sistem a de archivos será inm ediatam ente visible para cualquier proceso que haya m apeado dicho archivo en su espacio de direcciones. Cualquier núm ero de procesos puede mapear la m ism a región del m ism o archivo, y todos ellos term inarán usando la misma página de m em oria física. U na región de m em oria virtual tam bién queda definida por su reacción frente a las escrituras. El m apeado de una región sobre el espacio de direcciones de un proceso puede ser privado o com­ partido. Si un proceso escribe sobre una región m apeada de m ánéra privada, el paginador detec­ tará que es necesario realizar una copia durante la escritura con el fin de que los cambios continúen siendo locales al proceso. Por contraste, las escrituras en una región com partida provo­ can que se actualice el objeto m apeado sobre dicha región, de m odo que el cam bio será inmedia­ tam ente visible para cualquier proceso que esté m apeando el objeto. 21.6.2.2 D u ración de u n espacio de d irecciones virtual El kem el creará un nuevo espacio de direcciones virtual en dos situaciones distintas: cuando un proceso ejecute un nuevo program a m ediante la llam ada al sistem a e x e c () y al crear un nuevo proceso m ediante la llam ada al sistem a f o r k (). El prim er caso resulta sencillo: cuando se ejecu­ ta un nuevo proceso, al proceso se le asigna un espacio de direcciones virtual nuevo com pleta­ m ente vacío. Es responsabilidad de las rutinas que cargan el program a rellenar el espacio de direcciones con regiones de m em oria virtual. El segundo caso, el de creación de un nuevo proceso m ediante f o r k (), implica crear una copia com pleta del espacio de direcciones virtual del proceso existente. El kem el copia los descriptores v m _ a r e a _ s t r u c t del proceso padre y luego crea un nuevo conjunto de tablas de páginas para el hijo. Las tablas de páginas del padre se copian directam ente en las del hijo, y el contador de refe-

i

21.6 Gestión de memoria

693

ren d as de cada página se increm enta; así, después de la creación del proceso hijo, el hijo y el padre com parten las m ism as páginas físicas de m em oria en sus espacios de direcciones. Un caso especial es el que se produce cuando la operación de copia alcanza una región de m em oria virtual que está m apeada de form a privada. Todas las páginas en las que haya escrito el proceso padre dentro de dicha región serán privadas, por lo que los subsiguientes cam bios hechos en esas páginas por parte del padre o del hijo no deben actualizar la página en el espacio de direc­ ciones del otro proceso. C uando se copian las entradas de la tabla de páginas para dichas regio­ nes, se las configura com o de sólo lectura y se las m arca para aplicar la operación de copia durante la escritura. M ientras que ninguno de los procesos m odifique estas páginas, los dos procesos com ­ partirán la m ism a página de m em oria física. Sin em bargo, si algunos de los procesos trata de m odificar una página de copia durante la escritura, se com prueba el contador de referencias de la página. Si la página sigue estando com partida, entonces el proceso copia el contenido de la pági­ na en una nueva página de m em oria física y utiliza, en su lugar, esa copia recién creada. Este m ecanism o garantiza que se com partan entre los procesos, siem pre que sea posible, las páginas de datos privados y que sólo se realizan copias cuando sea absolutam ente necesario. 21.6.2.3 In tercam bio y p agin ación U na tarea im portante que debe llevar a cabo cualquier sistem a de m em oria virtual es la de reubicar las páginas de m em oria, extrayéndolas de la m em oria física y alm acenándolas en el disco cuando esa m em oria sea necesaria para otras cosas. Los sistem as UNIX m ás antiguos realizaban esta reubicación intercam biando todo el contenido de un proceso com pleto, pero las versiones m odernas de UNIX utilizan m ás el m ecanism o de paginación: el m ovim iento de páginas indivi­ duales de m em oria virtual entre m em oria física y disco. Linux no im plem enta el m ecanism o de intercam bio de procesos com pletos, sino que utiliza exclusivam ente el m ecanism o m ás reciente de paginación. El sistem a de paginación puede dividirse en dos secciones. En prim er lugar, el algoritm o de p o lítica decide qué paginas escribir en el disco y cuándo escribirlas. En segundo lugar, el m eca­ n ism o de paginación lleva a cabo la transferencia y vuelve a cargar los datos en m em oria física cuando son necesarios de nuevo. La po lítica de descarga de págin as de Linux utiliza una versión m odificada del algoritm o estándar del reloj (o de segunda oportunidad) descrito en la Sección 9.4.5.2. En Linux, se utiliza un reloj con m últiples pasadas y cada página tiene una edad que se ajusta en cada pasada del reloj. Esa edad es, para ser m ás precisos, una m edida de la “juventud” de una página, o de cuánta acti­ vidad se ha realizado recientem ente con esa página. Las páginas a las que se acceda frecuentem en­ te tendrán un valor de edad más alto, pero la edad de las páginas a las que se acceda de m anera infrecuente caerá hacia cero con cada pasada. Estos valores de edad perm iten al paginador selec­ cionar las páginas que hay que descargar, basándose en una política del tipo LFU (least frequently used, menos frecuentem ente utilizada). El m ecanism o de paginación soporta la paginación tanto con particiones y dispositivos de intercam bio dedicados, com o con archivos norm ales, aunque el intercam bio con un archivo es sig­ nificativam ente más lento, debido al procesam iento adicional que debe realizar el sistem a de archivos. Los bloques se asignan a partir de los dispositivos de intercam bio de acuerdo con un m apa de bits de bloques utilizados, que se m antiene en m em oria física en todo instante. El asig­ nador utiliza un algoritm o de siguiente ajuste con el fin de tratar de escribir las páginas en seccio­ nes continuas de bloques de disco, para m ejorar la velocidad. El asignador registra el hecho de que se ha descargado una página en disco, em pleando una característica de las tablas de páginas de los procesadores m odernos: se activa el bit de “página no presente” de la entrad de la tabla de páginas, perm itiendo rellenar el resto de esa entrada de la tabla de páginas con un índice que identifique dónde se ha escrito la página. 21.6.2.4 M em oria virtual del k e m e l Linux reserva para su propio uso interno una región constante, dependiente de la arquitectura, del espacio de direcciones virtual de cada proceso. Las entradas de la tabla de páginas que se

694

Capítulo 21 El sistema Linux

corresponden con estas páginas del kem el se m arcan com o protegidas, para que esas páginas no sean visibles ni m odificables cuando el procesador esté operando en m odo usuario. Esta área de m em oria virtual del kernel contiene dos regiones. La prim era es un área estática que contiene refe­ rencias de la tabla de páginas a cada una de las páginas físicas de m em oria disponibles en el sis­ tema, para poder realizar una traducción sim ple entre direcciones físicas y virtuales cuando se esté ejecutando código del kernel. La parte fundam ental del kem el junto con todas las páginas asig­ nadas por el asignador de páginas norm al reside en esta región. El resto de la sección del espacio de direcciones reservada por el kem el no está reservado para ningún proceso específico. Las entradas de la tabla de páginas dentro de este rango de direccio­ nes pueden ser m odificadas por el kem el con el fin de que apunten a otras áreas de memoria. El kem el proporciona un par de funciones que perm iten a los procesos usar esta m em oria virtual. La función v m a ll o c () asigna un núm ero arbitrario de páginas de m em oria física que pueden no estar físicam ente contiguas en una única región de m em oria virtual contigua del kem el. La función v rem ap () hace corresponder una secuencia de direcciones virtuales con un área de memoria usada por un controlador de dispositivo para las operaciones de E/S m apeadas en m em oria.

21.6.3 Ejecución y carga de program as de usuario La ejecución de program as de usuario por parte del kem el de Linux se inicia m ediante una invo­ cación a la llam ada al sistem a e x e c ( ) . Esta llam ada hace que el kem el ejecute un nuevo progra­ m a dentro del proceso actual, sobreescribiendo com pletam ente el contexto actual de ejecución con el contexto inicial del nuevo program a. El prim er com etido de este servicio del sistem a consiste en verificar que el proceso que realiza la invocación tiene los perm isos correctos sobre el archivo que se va a ejecutar. U na vez efectuada esta com probación, el kem el invoca una rutina de carga para com enzar a ejecutar el program a. El cargador no carga necesariam ente el contenido del archi­ vo de program a en m em oria física, pero al m enos prepara el m apeo del program a sobre memoria virtüal. No existe ninguna ru tina diferenciada en Linux para cargar un nuevo program a. En su lugar, Linux m antiene una tabla, de posibles funciones cargadoras, y da a cada una de esas funciones la oportunidad de que intente cargar el archivo especificado cuando se realice una llam ada al siste­ ma e x e c ( ) . La razón inicial para la existencia esta tabla de rutinas cargadoras era que, entre las versiones de los kem els 1.0 y 1.2, se m odificó el form ato estándar de los archivos binarios de Linux. Los kem els más antiguos de Linux sólo com prendían el form ato a . o u t de archivos binarios, que es un form ato relativam ente sim ple bastante com ún en los sistem as UNIX más antiguos. Los siste­ m as Linux m ás recientes utilizan el form ato más m oderno ELF, que ahora está soportado por la m ayoría de las im plem entaciones UNIX actuales. ELF tiene una serie de ventajas sobre a.o u t, incluyendo una m ayor flexibilidad y am pliabilidad. Pueden añadirse nuevas secciones a un bina­ rio ELF (por ejem plo, para añadir inform ación de depuración adicional) sin que las rutinas de carga se confundan. Al perm itir registrar m últiples rutinas de carga, Linux puede soportar fácil­ m ente los form atos binarios ELF y a . o u t dentro de un m ism o sistema. En las Secciones 21.6.3 y 21.6.3.2, vam os a concentram os exclusivam ente en los procesos de carga y de ejecución de los archivos binarios con form ato ELF. El procedim iento para cargar archi­ vos binarios a . o u t es m ás sim ple, pero su operación resulta similar. 21.6.3.1

Carga de program as en m em oria

En Linux, el cargador binario no carga un archivo binario en m em oria física. En lugar de ello, se m apean las páginas del archivo binario sobre regiones de m em oria virtual. Sólo cuando el progra­ ma trate de acceder a una página determ inada, el correspondiente fallo de página provocará la carga de dicha página en m em oria física, utilizando el m ecanism o de paginación bajo demanda. Es responsabilidad del cargador binario del kernel configurar el m apeo de m em oria inicial. Un archivo binario en form ato ELF está com puesto por una cabecera, seguida de varias secciones con alineación de página. El cargador ELF funciona leyendo la cabecera y m apeando las secciones del archivo sobre regiones separadas de m em oria virtual. J-

21.6 Gestión de memoria

695

m em oriainvisibleparacódigodelm ododeusuario

región mapeada en memoria región mapeada en memoria región mapeada en memoria datos de tiempo de ejecución datos no inicializados datos inicializados ■ stexto del programa

puntero‘brk’

regiónprohibida Figura 21.8 Disposición de memoria para los programas ELF. La Figura 21.8 m uestra la disposición típica de regiones de m em oria inicializada por el carga­ dor ELF. En una región reservada en uno de los extrem os del espacio de direcciones, se sitúa el ker­ nel en su propia región privilegiada de m em oria virtual a la que no pueden acceder los programas norm ales en m odo usuario. El resto de la m em oria virtual está disponible para aplicaciones, que pueden utilizar las funciones de m apeo de m em oria del kem el para crear regiones que m apeen una parte de un archivo o qu e estén disponibles para alm acenar los datos de la aplicación. El trabajo del cargador consiste en preparar el m apeo inicial de m em oria con el fin de que dé com ienzo la ejecución del program a. Entre las regiones que hay que inicializar se encuentran la pila y las regiones de texto y de datos del programa. La pila se crea en la parte superior de la m em oria virtual de m odo usuario; la pila crece hacia abajo, en el sentido decreciente de direcciones de m em oria. Incluye copias de los argum entos y de las variables de entorno proporcionadas al program a en la llam ada al sistema e x e c (). El resto de regiones se crean cerca de la parte inferior de la memoria virtual. Las secciones del archivo bin a­ rio que contienen texto del program a o datos de sólo lectura se m apean en m em oria como región protegida contra escritura. A continuación se m apean los datos inicializados sobre los que se puede escribir, después, se m apean todos los datos no inicializados, como una región privada con ceros bajo dem anda. D irectam ente a continuación de estas regiones de tamaño fijo hay una región de tam año varia­ ble que los program as pueden am pliar según sea necesario con el fin de alm acenar los datos asig­ nados en tiem po de ejecución. C ada proceso tiene un puntero, b r k , que apunta al lím ite actual de esta región de datos, y los procesos pueden am pliar o reducir su región b r k con una única llam a­ da al sistem a: s b r k {). U na vez configuradas estas correspondencias de regiones de m emoria, el cargador inicializa el registro contador de program a del proceso, cargando en él el punto inicial indicado en la cabece­ ra del ELF, después de lo cual se puede planificar la ejecución del proceso.

21.6.3.2 Montaje estático y dinámico Una vez que el program a se ha cargado y ha com enzado a ejecutarse, todo contenido necesario del archivo binario habrá sido cargado en el espacio de direcciones virtual del proceso. Sin em bar­ go, la m ayoría de los program as también necesitan ejecutar funciones de las bibliotecas del siste­ ma, por lo que será necesario, asim ism o, cargar dichas funciones de biblioteca. En el caso más sim ple, las funciones de biblioteca necesarias estarán integradas directam ente dentro del archivo J-

696

Capítulo 21 El sistema Linux

binario ejecutable del program a. U n program a de este tipo está m ontado estáticam ente con sus bibliotecas, y los ejecutables con m ontaje estático pueden com enzar a ejecutarse inmediatamente después de que term ine su carga. La principal desventaja del m ontaje estático es que cada program a que se genere deberá con­ tener copias de las m ism as funciones com unes exactas de la biblioteca del sistem a. Resulta mucho m ás eficiente, tanto en térm inos de m em oria física com o del uso del espacio de disco, cargar una única vez en m em oria las bibliotecas del sistem a. La técnica de m ontaje dinám ico perm ite que se realice esta única operación de carga. Linux im plem enta el m ontaje dinám ico en m odo usuario a través de una biblioteca especial de m ontador. Cada program a dinám icam ente m ontado contiene una pequeña función de montaje estático que se invoca en el m om ento de arrancar el program a. Esta función estática simplemente m apea la biblioteca de m ontaje en m em oria y ejecuta el código que contiene la función. La biblio­ teca de m ontaje determ ina las bibliotecas dinám icas requeridas por el program a y los nombres de las variables y funciones que se necesitan de dichas bibliotecas, leyendo para ello la información contenida en una serie de secciones del archivo binario ELF. A continuación, m apea las bibliotecas en la m em oria virtual y resuelve las referencias a los sím bolos contenidos en dichas bibliotecas. N o im porta en qué punto exacto de la m em oria se m apeen estas bibliotecas com partidas, porque se com pilan en un c ó d ig o in d e p e n d ie n te d e la p o s ic ió n (PIC, position-independent code), que puede ejecutarse en cualquier dirección de la m em oria.

21.7 Sistemas de archivos Linux m antiene el m odelo estándar de sistem as de archivos de UNIX. En UNIX, un archivo no tiene porque ser un objeto alm acenado en disco o descargado a través de la red desde un servidor de archivos rem oto. En lugar de ello, los archivos UNIX pueden ser cualquier cosa capaz de procesar la entrada o la salida de un flujo de datos. Los controladores de dispositivos pueden aparecer com o archivos y los canales de com unicación interprocesos o las conexiones de red tam bién pare­ cen archivos a ojos del usuario. El kem el de Linux gestiona todos estos tipos de archivos ocultando los detalles de implemen­ tación de cada tipo de archivo concreto por debajo de una cap a de softw are, el sistem a de archi­ vos virtual (VFS, virtual file system). Aquí, vam os a presentar prim ero el sistem a de archivos virtual y luego nos ocuparem os del sistem a de archivos estándar de Linux, ext2fs.

21.7.1 El sistema de archivos virtual El VFS de Linux está diseñado basándose en principios de orientación a objetos. Tiene dos compo­ nentes: un conjunto de definiciones q u é especifican cuál es el aspecto que están autorizados a tener los objetos del sistem a de archivos y una capa de softw are para m anipular los objetos. El sis­ tem a VFS define cuatro tipos principales de objetos: • U n o b je to in o d o representa un archivo individual. • U n o b jeto archivo representa un archivo abierto. • U n o b jeto su p erb loq u e representa el sistem a de archivos com pleto. • U n o b jeto entrada de directorio (dentry) representa una entrada de directorio individual. Para cada uno de estos cuatro tipos de objeto, VFS define un conjunto de operaciones. Cada objeto de uno de estos tipos contiene un puntero a una tabla de funciones. La tabla de funciones enum era las direcciones de las funciones reales que im plem entan las operaciones definidas para ese objeto. Por ejem plo, una API abreviada para algunas de las operaciones que pueden realizar­ se sobre el objeto archivo incluiría: •

in t

o p en { .

• s s iz e _ t

.

re a d (.

.) — Abre un archivo. .

.) — Leer de ün archivo.

21.7 Sistemas de archivos

• s s i z e _ t w r ite (. • in t

mmap ( .

.

.

697

. ) — Escribir en un archivo.

. ) — M apear en m em oria un archivo.

La definición com pleta del objeto archivo se especifica en la estructura s t r u c t f i l e _ o p e r a t i o n s , que está ubicada en el archivo / u s r / i n c l u d e / l i n u x / f s .h . Cada im plem entación del objeto archivo (para un tipo de archivo específico) debe obligatoriam ente im plem entar todas las funciones especificadas en la definición del objetó archivo. L a c a p a d e so ftw a re VFS p u e d e re a liz a r u n a o p e r a c ió n so b re u n o d e lo s o b jeto s d el siste m a d e a rc h iv o s in v o c a n d o la fu n ció n a p ro p ia d a d e la ta b la d e fu n cio n e s d el objeto, sin te n e r q u e c o n o ­ c e r d e a n te m a n o e x a c ta m e n te el tip o d e o b jeto c o n el q u e e s tá tra ta n d o . E l VFS n o sab e, ni ta m p o ­ c o le p re o c u p a , si u n in o d o re p re s e n ta u n a rc h iv o d e re d , u n a rc h iv o d e d is co , u n socket d e re d o u n a rc h iv o d e d ire cto rio . L a fu n ció n a p ro p ia d a p a r a la o p e r a c ió n r e a d () d e d ich o a rch iv o sie m ­ p re se e n c o n tra r á en el m is m o lu g a r d e n tro d e su tab la d e fu n cio n e s, y la c a p a d e so ftw a re VFS in v o c a rá d ic h a fu n ció n sin p re o c u p a rs e d e la f o rm a e n q u e los d a to s se a n leíd o s re a lm e n te .

Los objetos inodo y archivo son los m ecanism os utilizados para acceder a los archivos. Un obje­ to inodo es una estructura de datos que contiene punteros a los bloques de disco donde están los propios contenidos del archivo, y un objeto archivo representa un punto de acceso a los datos de un archivo abierto. Un proceso no puede acceder al contenido de un inodo sin prim ero obtener el objeto archivo que apunta al inodo. El objeto archivo controla en qué lugar del archivo está leyen­ do o escribiendo actualm ente el proceso, con el fin de controlar las operaciones de E /S de archivo secuenciales. Tam bién recuerda si el proceso solicitó perm isos de escritura al abrir el archivo y controla la actividad del proceso en caso necesario para realizar lecturas anticipadas adaptativas, cargando los datos del archivo en m em oria antes de que el proceso los solicite, con el fin de m ejo­ rar la velocidad. Los objetos archivo pertenecen norm alm ente a un único proceso, pero los objetos inodo no. A ún cuando un archivo ya no esté siendo utilizado por ningún proceso, su objeto inodo puede continuar siendo alm acenado en la caché por el VFS, con el fin de m ejorar la velocidad por si acaso, a corto plazo, se utiliza de nuevo el archivo. Todos los datos del archivo alm acenados en caché están enlazados en una lista dentro del objeto inodo del archivo. El inodo tam bién m antiene infor­ m ación estándar acerca de cada archivo, com o por ejem plo su propietario, su tam año y el instan­ te en que ha sido m odificado más recientem ente. El tratam iento que se da a los archivos de directorio es ligeram ente distinto del de los demás archivos. La interfaz de program ación de UNIX define una serie de operaciones con los directorios, com o por ejem plo la de creación, borrado y renom brado de un archivo dentro de un directorio. Las llam adas al sistem a para estas operaciones de directorio no requieren que el usuario abra los correspondientes archivos, a diferencia de lo que ocurre con la lectura o la escritura de datos. Por tanto, el VFS define estas operaciones de directorio en el objeto inodo e n lugar de en el objeto archivo. El objeto superbloque representa un conjunto conectado de archivos que form an un sistem a de archivos autocontenido. El kem el del sistem a operativo m antiene un único objeto superbloque por cada dispositivo de disco m ontado como sistem a de archivos y por cada sistem a de archivos de red que esté actualm ente conectado. La responsabilidad principal del objeto superbloque consis­ te en proporcionar acceso a los inodos. El VFS identifica cada inodo m ediante una pareja unívoca (sistem a-archivo/núm ero inodo) y localiza el inodo que corresponde a un núm ero de inodo con­ creto pidiendo al objeto superbloque que le devuelva el inodo que tiene dicho número. Por últim o, un objeto entrada de directorio representa una entrada de directorio que puede incluir el nom bre de un directorio dentro del nom bre de ruta de un archivo (como / u s r ) o el propio archivo (como s t d i o .h ). Por ejem plo, el archivo / u s r / i n c l u d e / s t d i o .h contiene las entradas de directorio (1) /, (2) u s r , (3) i n c l u d e y (4) s t d i o . h . Cada uno de estos valores está representado por su propio objeto entrada de directorio. Com o ejem plo del modo en que se utilizan los objetos entrada de directorio, considere el caso en que un proceso quisiera abrir el archivo con el nom bre de ruta / u s r / i n c l u d e / s t d i o . h, uti­ lizando un editor. Puesto que Linux trata los nom bres de directorio com o archivos, traducir esta ruta requiere obtener en primer lugar el inodo de la raíz, /. El sistem a operativo debe entonces

698

Capítulo 21 El sistema Linux

leer este archivo para obtener el inodo del archivo i n c l u d e y continuar con este proceso hasta obtener el inodo del archivo s t d i o . h . Puesto que la traducción de los nom bres de ruta puede ser una tarea que consum a m ucho tiem po, Linux m antiene una caché de objetos de entrada de directorio, que consulta durante la traducción de los nom bres de ruta. Obtener el inodo a partir de la caché de entradas de directorio es considerablem ente m ás rápido que leer el archivo alma­ cenado en disco.

21.7.2 El sistema de archivos ext2fs de Linux Por razones históricas, el sistem a de archivos estándar en disco estándar utilizado por Linux se denom ina ext2fs. O riginalm ente, Linux fue program ado con un sistem a de archivos compatible con M inix, para facilitar el intercam bio de datos con el sistem a de desarrollo M inix, pero dicho sis­ tema de archivos estaba enorm em ente restringido, ya que los nom bres de archivo tenían un lími­ te de 14 caracteres y el tam año m áxim o del sistem a de archivos era de 64 MB. El sistem a de archivos M inix fue sustituido por otro nuevo sistem a de archivos que se denom inó sistem a de archivos extendido (EFS, extended file system ). U n posterior rediseño de este sistem a de archivos para m ejorar la velocidad y la escalabilidad y añadir unas cuantas características que se echaban de m enos condujo al denom inado segundo sistem a de archivos extendido (ext2fs, second exten­ ded file system ). El sistem a de archivos ext2fs de Linux tiene m uchas características en com ún con el sistem a (Fast File System ) de (Sección U tiliza un m ecanism o sim ilar para localizar los bloques de datos que pertenecen a un archivo específico, alm acenando punteros a los bloques de datos en bloques indirectos por todo el sistem a de archivos con hasta tres niveles de indirección. Como en los archivos de directorio están alm acenados en disco al igual que los archivos norm ales, aun­ que su contenido se interpreta de m anera diferente. Cada bloque en un archivo de directorio está com puesto por una lista enlazada de entradas; cada entrada contiene la longitud de la entrada, el nom bre de un archivo y el núm ero del inodo al que esa entrada hace referencia. Las principales diferencias entre ext2fs radican en sus respectivas políticas de asignación de disco. En el disco se asigna a los archivos en bloques de 8 KB. Estos bloques se subdividen en fragm entos de 1 KB para el alm acenam iento de pequeños archivos o de bloques parcialmente llenos situados al final de los archivos. Por contraste, ext2fs no utiliza fragm entos, sino que reali­ za todas las tareas de asignación em pleando unidades más pequeñas. El tamaño de bloque prede­ term inado en ext2fs es de KB, aunque tam bién se perm iten bloques de 2 KB. Para obtener unas altas prestaciones, el sistem a operativo debe tratar de realizar las operacio­ nes de en grandes fragm entos siem pre que sea posible, agrupando las solicitudes de que sean físicam ente adyacentes. Este agrupam iento reduce el gasto prom edio adicional por cada soli­ citud debido a los controladores de dispositivos, los discos y el hardw are de la controladora de disco. Un tam año de solicitud de de es dem asiado pequeño como para poder obtener unas buenas prestaciones, por lo que ext2fs utiliza políticas de asignación diseñadas para situar los bloques de un archivo que sean adyacentes desde el punto de vista lógico en bloques física­ m ente adyacentes en el disco, con el fin de poder solicitar en una única operación de varios bloqueos de disco sucesivos. La política de asignación de ext2fs tiene dos partes. Com o en un sistema de archivos ext2fs está particionado en m últiples grupos de blo q u es. em plea el concepto sim ilar de grupos de cilin d ros, donde cada grupo se corresponde con un único cilindro de un disco físico. Sin embar­ go, la tecnología m oderna de las unidades de disco em paquetan los sectores en el disco con dife­ rentes densidades, y por tanto con diferentes tam años de cilindro, dependiendo de lo lejos que esté el cabezal del disco con respecto al centro del disco. Por tanto, los grupos de cilindros de tam año fijo no se corresponden necesariam ente con la geom etría del disco. Cuando se asigna un archivo, ext2fs debe seleccionar en prim er lugar el grupo de bloques de dicho archivo. Para los bloques de datos, trata de asignar el archivo al grupo de bloques al que se haya asignado el inodo del archivo. Para asignaciones de inodos, selecciona el grupo de bloques en el que resida el directorio padre del archivo (en el caso de archivos que no sean de directorio). Los archivos del directorio no se m antienen juntos, sino que se dispersan entre todos los grupos

BSD

FFS

A .7.7).

FFS,

y FFS

FFS,

1

KB y 4

E/S

E/S

E/S

1 KB

E/S

FFS

FFS,

21.7 Sistemas de archivos

699

de bloques disponibles. Estas políticas están diseñadas no sólo para m antener toda la inform ación relacionada dentro del m ism o grupo de bloques, sino tam bién distribuir la carga del disco entre los distintos grupos de bloques del m ism o, con el fin de reducir la fragm entación de cada una de las áreas del disco. Dentro de un grupo de bloques, ext2fs trata de realizar las asignaciones de m anera que sean físicam ente contiguas, siem pre que sea posible, reduciendo la fragm entación si puede. El sistem a m antiene un m apa de bits de todos los bloques libres de cada grupo de bloques. C uando se asig­ nan los prim eros bloques para un nuevo archivo, el sistem a com ienza a buscar un bloque libre a partir del principio del grupo de bloques, cuando se trata de am pliar un archivo, continúa la bús­ queda a partir del bloque asignado m ás recientem ente al archivo. Esa búsqueda se realizada en dos etapas. En prim er lugar, ext2fs busca un byte libre com pleto dentro del m apa de bits, si no encuentra ninguno, se conform ará con cualquier bit libre. La búsqueda de bytes libres pretende asignar el espacio de disco en secciones de al m enos ocho bloques, siem pre que sea posible. Una vez que se ha identificado un bloque libre, se extiende hacia atrás la búsqueda hasta encontrar un bloque asignado. C uando se encuentra un byte libre en el m apa de bits, esta búsque­ da hacia atrás evita que ext2fs deje un hueco entre el bloque asignado m ás recientem ente dentro del byte anterior distinto de cero y el byte igual a cero encontrado anteriorm ente. U na vez locali­ zado el siguiente bloque que hay que asignar, m ediante la búsqueda de un byte o un bit, ext2fs extiende la asignación hacia adelante hasta un m áxim o de 8 bloques y preasigna estos bloques adicionales al archivo. Esta preasignación ayuda a reducir la fragm entación durante las escrituras entrelazadas entre archivos separados y tam bién reduce el coste de CPU de la asignación de disco, al asignar m últiples bloques sim ultáneam ente. Los bloques preasignados se devuelven al m apa de bits de espacio libre en el m om ento de cerrar el archivo. La Figura 21.9 ilustra las políticas de asignación. Cada fila representa una secuencia de bits activado/ desactivado dentro de un m apa de bits de asignación, indicando los bloques utilizados y libres que hay en el disco. En el prim er caso, si podem os encontrar algún bloque libre lo sufi­ cientem ente cerca del com ienzo de la búsqueda, asignarem os esos bloques independientem ente de lo fragm entados que puedan estar. La fragm entación se com pensa parcialm ente por el hecho de que los bloques están próxim os entre sí y probablem ente pueden ser leídos todos ellos sin efectuar ningún reposicionam iento del cabezal del disco; además, asignarlos todos a un mismo asignación de bloques libres dispersos

asignación de bloques libres contiguos

bloque en uso

bloque libre

bloque seleccionado por el asignador

------ ► búsqueda en el mapa de bits

frontera de bit

frontera de byte

Figura 21.9 Políticas de asignación de bloques de ext2fs.

700

Capítulo 21 El sistema Linux

archivo es m ejor, a largo plazo, que asignar bloques aislados a distintos archivos una vez que em piezan a escasear las áreas libres de gran tam año dentro del disco. En el segundo caso, no se ha encontrado inm ediatam ente un bloque libre cercano, por lo que se busca hacia adelante hasta encontrar un byte libre com pleto dentro del m apa de bits. Si asignáram os dicho byte como una unidad, term inaríam os creando un área fragm entada de espacio libre antes de ese byte, de modo que antes de realizar la asignación volvem os hacia atrás para situar la asignación a continuación de la asignación precedente, y asignam os un conjunto de bloques a partir de ese punto con el fin de satisfacer el tam año predeterm inado de asignación que es de ocho bloques.

21.7.3 Diario Hay disponibles m uchos tipos diferentes de sistem as de archivos para los sistem as Linux. Una característica popular de los sistem as de archivos es la de llevar un diario, m ediante el cual se escriben secuencialm ente en un registro las m odificaciones efectuadas en el sistem a de archivos. U n conjunto de operaciones que realice una tarea específica recibe el nom bre de transacción. Una vez escrita una transacción en el diario, se la considera confirm ada y la llam ada al sistem a que ha m odificado el sistem a de archivos (por ejem plo, w r i t e ( ) ) , puede devolver el control al proceso de usuario, perm itiéndole continuar con su ejecución. M ientras tanto, las entradas del diario rela­ cionadas con la transacción se reaplican en las propias estructuras del sistem a de archivos. A m edida que se realizan los cam bios, se actualiza un puntero para indicar qué acciones se han com­ pletado y cuáles están todavía incom pletas. Una vez com pletada una transacción confirmada entera se la elim ina del diario. Este diario, que es en la práctica un búfer circular, puede encon­ trarse en una sección separada del sistem a de archivos, o incluso en una sección separada del disco. Resulta m ás eficiente, .aunque tam bién m ás com plejo, utilizar cabezas de lectura-escritura distintas, porque así se reducen tanto la contienda por la utilización de los cabezales como los tiem pos de búsqueda. Si el sistem a sufre un fallo catastrófico, en el diario estarán alm acenadas cero o m ás transaccio­ nes. Esas transacciones nunca llegaron a ser com pletam ente aplicadas al sistem a de archivos, aun cuando hubieran sido confirm adas por el sistem a operativo, así que será necesario completarlas. Las transacciones pueden ejecutarse a partir del puntero hasta que se term ine con todas las tare­ as pendientes y las estructuras del sistem a de archivos queden en un estado coherente. El único problem a aparece cuando se ha abortado una transacción, es decir, cuando hay una transacción que no había sido confirm ada antes de que el sistem a sufriera el fallo catastrófico. Todos los cam­ bios correspondientes a dichas transacciones que hubieran sido aplicados al sistem a de archivos deben ser deshechos, de nuevo para poder preservar la coherencia del sistem a de archivos. Este proceso de recuperación es lo único que hay que hacer después de un fallo catastrófico, eliminan­ do así todos los problem as asociados con las com probaciones de coherencia. Los sistem as de archivos con registro de diario tam bién suelen ser m ás rápidos que los que carecen de esta característica, ya que las actualizaciones se realizan m ucho m ás rápidam ente cuan­ do se aplican al diario que se conserva en m em oria en lugar de aplicarlas a las estructuras de datos alm acenadas en el disco. La razón de esta m ejora es que resulta m ucho m ás rápida la E/ S secuencial que la E/S aleatoria. Las costosas escrituras aleatorias síncronas en el sistem a de archivos se transform an en unas escrituras secuenciales síncronas m ucho m enos costosas en el registro de dia­ rio del sistem a de archivos. Esos cam bios, a su vez, se vuelven a aplicar asincronam ente, median­ te escrituras aleatorias, en las estructuras de datos apropiadas. El resultado global es una ganancia significativa en la velocidad de las operaciones realizadas con los m etadatos del sistem a de ¿rchivos, com o por ejem plo la creación y el borrado de archivos. El sistem a ext2fs no tiene un registro de diario. Sin em bargo, quien sí lo tiene es otro sistema de archivos com ún disponible para los sistem as Linux, ext3, que está basado en ext2fs.

21.7.4 El sistema de archivos proc de Linux La flexibilidad del VFS de Linux nos perm ite im plem entar un sistem a de archivos que no almace­ ne ningún dato de m anera persistente, sino que sim plem ente proporcione una interfaz para otro

21.7 Sistemas de archivos

701

tipo de funcionalidad. El sistem a de archivos de proceso de Linux, denom inado sistem a de archi­ vos / p r o c , es un ejem plo de un sistem a de archivos cuyo contenido no está alm acenado en nin­ guna parte sino que se calcula bajo dem anda de acuerdo con las solicitudes de E/S de archivos del usuario. Los sistem as de archivos / p r o c no son exclusivos de Linux. SVR4 UNIX ya introdujo un siste­ m a de archivos / p ro c com o interfaz de gran eficiencia para los m ecanism os de soporte de depu­ ración de procesos del kernel: cada subdirectorio del sistem a de archivos no se corresponde con un directorio de cualquier disco, sino con un proceso activo en el sistem a actual. U n listado del siste­ m a de archivos nos da un directorio por cada proceso, siendo el nom bre del directorio la repre­ sentación decim al ASCII del identificador de proceso (PID) unívoco de cada proceso. Linux im plem enta ese m ism o sistem a de archivos / p r o c , pero lo am plía en gran m edida, aña­ diendo diversos directorios adicionales y archivos de texto en el directorio raíz del sistem a de archivos. Esas nuevas entradas se corresponden con diversas estadísticas acerca del kem el y con­ troladores cargados asociados. El sistem a de archivos / p r o c proporciona una m anera para que los program as accedan a esta inform ación en form a de archivos de texto, que pueden ser proce­ sados por las potentes herram ientas que el entorno de usuario de UNIX estándar proporciona. Por ejem plo, en el pasado, el com ando tradicional p s de UNIX para obtener un listado del estado de todos los procesos en ejecución se im plem entaba com o un proceso privilegiado que leía el estado del proceso directam ente de la m em oria virtual del kem el. En Linux, este com ando se im plem en­ ta com o un program a com pletam ente no privilegiado que sim plem ente analiza y form atea la inform ación obtenida de / p ro c . El sistem a de archivos / p r o c debe im plem entar dos cosas: una estructura de directorios y el contenido de los archivos alm acenados en ella. Puesto que un sistem a de archivos UNIX se define com o un conjunto de inodos de archivo y de directorio identificados por sus núm eros de inodo, el sistem a de archivos / p ró ó debe definir un núm ero de inodo unívoco y persistente para cada directorio y para los archivos asociados. Una vez establecida esa correspondencia puede utilizar ese núm ero de inodo para identificar la operación requerida cada vez que un usuario trata de leer del inodo de un archivo concreto o trata de realizar una búsqueda en el inodo de un directorio concreto. Cuando se leen los datos de uno de estos archivos, el sistem a de arch iv o s/ p ro c recopi­ la la inform ación apropiada, la da form ato textual y la coloca en el búfer de lectura del proceso solicitante. La correspondencia entre núm ero de inodo y el tipo de inform ación se basa en dividir el núm e­ ro de inodo en dos cam pos distintos. En Linux, un identificador PID tiene 16 bits de longitud, pero un núm ero de inodo tiene 32 bits. Los 16 bits m ás altos del núm ero de inodo se interpretan com o un PID y los restantes bits definen el tipo de inform ación que se está solicitando acerca de dicho proceso. Un identificador PID igual a cero no es válido, por lo que si el cam po PID en un núm ero de inodo es igual a cero, se asum e que ese inodo contiene inform ación global en lugar de contener inform ación específica de un proceso. Hay diferentes archivos globales en / p r o c para proporcio­ nar inform ación tal com o la versión del kem el, la m em oria libre, las estadísticas de rendim iento y los controladores que se estén actualm ente ejecutando. No todos los núm eros de inodo de este rango están reservados. El k em el puede asignar nuevas correspondencias de inodo en / p r o c dinám icam ente, m anteniendo un m apa de bits de los núm e­ ros de inodo asignados. Tam bién m antiene una estructura de datos en árbol con las entradas glo­ bales registradas del sistem a de archivos / p ro c . Cada entrada contiene el núm ero de inodo del archivo, el nom bre del archivo y los perm isos de acceso, ju n to con las funciones especiales utili­ zadas para generar'el contenido del archivo. Los controladores pueden registrar y desregistrar entradas en este árbol en cualquier m om ento, y hay una sección especial del árbol (que aparece el directorio /proc/sys) reservada para las variables del kem el. Los archivos situados bajo este árbol son gestionados m ediante un conjunto de descriptores com unes que perm iten tanto leer com o escribir estas variables, por lo que un adm inistrador del sistem a puede optim izar los parám etros del k em el sim plem ente escribiendo los nuevos valores deseados en form ato ASCII decimal en el archivo apropiado. Para perm itir un acceso eficiente a estas variables desde las aplicaciones puede accederse al subárbol /pro c/sy s m ediante una llam ada al sisterhá especial, s y s c t l ( ) , que lee y escribe las m is-

J-

702

Capítulo 21 El sistema Linux

m as variables en form ato binario, en lugar de en form ato de texto, sin tener incurrir en el coste adicional exigido por el sistem a de archivos, s y s c t l O no es una funcionalidad adicional; sim­ plem ente lee el árbol de entradas dinám icas de / p r o c para decidir a qué variables dinámicas está haciendo referencia la aplicación.

21.8 Entrada y salida Para el usuario, el sistem a de E/S en Linux se parece bastante al de cualquier otro sistema UNIX. Es decir, en la m edida de lo posible, todos los controladores de dispositivos aparecen como archi­ vos norm ales. U n usuario puede abrir un canal de acceso a un dispositivo de la m isma forma en que abre cualquier otro archivo, los dispositivos pueden aparecer com o objetos dentro del siste­ m a de archivos. El adm inistrador del sistem a puede crear archivos especiales dentro de un siste­ m a de archivos que contengan referencias a un controlador de dispositivo específico, y un usuario que abra dicho archivos será capaz de leer y escribir en el dispositivo refereríciado. Utilizando el sistem a norm al de protección de archivos, que determ ina quién puede acceder a cada archivo, el adm inistrador puede establecer los perm isos de acceso para cada dispositivo. Linux divide todos los dispositivos en tres clases: dispositivos de bloque, dispositivos de carac­ teres y dispositivos de red. La Figura 21.10 ilustra la estructura global del sistem a de controladores de dispositivo. Los d isp o sitiv o s de b lo q u e incluyen todos los dispositivos que perm iten el acceso aleatorio a bloques de datos com pletam ente independientes y de tam año fijo, incluyendo los discos duros y disquetes, los discos CD-ROM y la m em oria flash. Los dispositivos de bloques se utilizan normal­ m ente para alm acenar sistem as de archivos, pero tam bién está perm itido el acceso directo a un dispositivo de bloque, para que los program as puedan crear y reparar el sistem a de archivos que ü el dispositivo contiene. Las aplicaciones tam bién pueden acceder a los dispositivos de bloque1'; directam ente si lo desean; por ejem plo, una aplicación de base de datos puede preferir revisar su propia disposición optim izada de los datos en el disco en lugar de em plear el sistem a de archivos de propósito general. Los d isp o sitiv o s de caracteres incluyen la m ayoría de los restantes dispositivos, como por ejem plo ratones y teclados. La diferencia fundam ental entre dispositivos de bloque y de caracte­ res es el acceso aleatorio: a los dispositivos de bloques se puede acceder de form a aleatoria, mien­ tras que a los dispositivos de caracteres sólo se puede acceder en modo serie. Por ejemplo, la operación de situarse en una cierta posición de un archivo puede estar soportada para un DVD, pero no tiene ningún sentido si de lo que hablam os es de un dispositivo de señalización como un ratón. Los d isp o sitiv o s de red se tratan de m anera distinta que los dispositivos de bloques y de carac­ teres. Los usuarios no pueden transferir datos directam ente a los dispositivos de red; en lugar de ello, deben com unicarse indirectam ente abriendo una conexión con el subsistema de red del ker­ nel. En la Sección 21.10 nos ocuparem os de la interfaz con los dispositivos de red. aplicación de usuario

Figura 21.10 Estructura de bloques de los controladores de dispositivos.

21.8 Entrada y salida

703

21.8.1 Dispositivos de bloque Los dispositivos de bloque proporcionan la interfaz principal para todos los dispositivos de disco del sistem a. Las prestaciones son especialm ente im portantes para los discos, y el sistem a de dis­ positivos de bloque debe proporcionar la funcionalidad necesaria para garantizar que el acceso a disco sea lo m ás rápido posible. Esta funcionalidad se consigue a través de la planificación de las operaciones de E/S. En el contexto de los dispositivos de bloque, un b lo q u e representa la unidad con la que el kernel realiza las operaciones de E/S. Cuando se lee un bloque en m em oria, se alm acena en un bú fer. El gestor de solicitu d es es la capa de softw are que gestiona la lectura y escritura del contenido del búfer desde y en el controlador de dispositivo de bloque. Para cada controlador de dispositivo de bloque se m antiene una lista separada de solicitudes. Tradicionalm ente, estas solicitudes se planificaban de acuerdo con un algoritm o de tipo ascensor unidireccional (C-SCAN) que aprovecha el orden en que se insertan y elim inan las solicitudes en la lista de cada dispositivo. Las listas de solicitudes se m antienen ordenadas según el orden cre­ ciente del núm ero de sector inicial. C uando se acepta una solicitud para su procesam iento por parte de un controlador de dispositivo de bloque, no se le elim ina de la lista. Sólo se le elim ina después de com pletada la operación de E /S , en cuyo m om ento el controlador continúa con el siguiente controlador de la lista, incluso si se han insertado nuevas solicitudes en la lista antes que la solicitud activa. A m edida que se realizan nuevas solicitudes de E /S , el gestor de solicitudes trata de com binar las solicitudes existentes en la lista de cada dispositivo. La planificación de las operaciones de E /S cam bió en cierta m edida con la versión 2.6 del kernel. El problem a fundam ental con el algoritm o del ascensor es que las operaciones de E /S concen­ tradas en una región específica del disco podían provocar la m uerte por inanición de las solicitudes dirigidas a otras regiones del disco. El p lan ificad o r de 'E/S con lím ite de tem poriza­ ció n utilizado en la versión 2.6 funciona de form a sim ilar al algoritm o del ascensor salvo porque tam bién asocia un plazo con cada solicitud resolviendo así el problem a de m uerte por inanición. D e m anera predeterm inada, el plazo para solicitudes de lectura es de 0,5 segundos y para las dé escritura de 5 segundos. El planificador con lím ite de tem porización m antiene una cola ordena­ da de operaciones de E /S pendientes ordenadas por núm ero de sector. Sin em bargo, tam bién m antiene otras dos colas: una cola de lectura para las operaciones de lectura y una cola de escri­ tura para las operaciones de escritura. Estas dos colas están ordenadas de acuerdo con los plazos. Cada solicitud de E /S se coloca tanto en la cola ordenada com o en la cola de lectura o de escritu­ ra, según sea apropiado. N orm alm ente, las operaciones de E /S van realizándose de acuerdo con la cola ordenada. Sin em bargo, si vence el plazo de una solicitud en la cola de lectura o de escri­ tura, se planifican las operaciones de E /S de la cola que contiene esa solicitud caducada. Esta polí­ tica garantiza que ninguna operación de E /S tengan que esperar más tiempo que el plazo marcado.

21.8.2 Dispositivos de caracteres Un controlador de dispositivo de caracteres puede ser casi cualquier controlador de dispositivo que no ofrezca un acceso aleatorio a bloques fijos de datos. Todos los controladores de dispositi­ vo de caracteres registrados antes el kem el de Linux deben tam bién registrar un conjunto de fun­ ciones que im plem enten las operaciones de E /S de archivo que el controlador soporte. El kem el no realiza casi ningún preprocesam iento de las solicitudes de lectura o escritura de archivo realiza­ das en un dispositivo de caracteres, sim plem ente pasa la solicitud al dispositivo en cuestión y deja que el dispositivo la trate. La excepción principal a esta regla es el subconjunto especial de controladores de dispositivo de caracteres que im plem enta dispositivos de term inal. El kem el m antiene una interfaz estándar con estos controladores m ediante un conjunto de estructuras t t y _ s t r u c t . Cada una de estas estructuras proporciona búferes y un m ecanism o de control de flujo para los datos procedentes del dispositivo term inal, y entrega dichos datos a una disciplina de línea. Una d iscip lin a de lín ea es un intérprete de la inform ación procedente de un dispositivo de ter­ minal. La disciplina de línea m ás com ún es la disciplina t t y , que dirige el flujo de datos vdel

704

Capítulo 21 El sistema Linux

term inal a los flujos estándar de entrada y de salida de los procesos que el usuario esté ejecutan­ do, perm itiendo a dichos procesos com unicarse directam ente con el term inal de usuario. Esta tarea se com plica por el hecho de que puede haber varios de dichos procesos ejecutándose simul- & táneam ente, y la disciplina de línea t t y es responsable de conectar y desconectar la entrada y sali- “ da del term inal a los distintos procesos conectados, a m edida que el usuario suspende o despierta dichos procesos. * H ay tam bién otras disciplinas de línea im plem entadas que no tienen nada que ver con la E/s a un proceso de usuario. Los protocolos de red PPP y SLIP representan form as de codificar una conexión de red a través de un dispositivo term inal tal com o una línea serie. Estos protocolos se im plem entan en Linux com o controladores que, en uno de los extrem os, aparecen ante el sistema • term inal com o disciplinas de línea, m ientras que en el otro extrem o aparecen ante el sistema d e ' ' red com o controladores de dispositivo de red. U na vez que se ha activado una de estas discipliL l í ñas de línea en un dispositivo term inal, los datos que aparezcan en dicho dispositivo terminal se encam inarán directam ente al controlador de dispositivo de red apropiado.

21.9 Comunicación interprocesos UNIX proporciona un entorno m uy rico para que los procesos se com uniquen entre sí. La comuni- gi cación puede ser sim plem ente una cuestión de hacer que el otro proceso sepa que se ha produci­ do un determ inado suceso, o puede im plicar la transferencia de datos de un proceso a otro.

21.9.1 Sincronización y señales El m ecanism o estándar de UNIX para inform ar a un proceso de que ha tenido lugar un cierto suce- U so es una señal. Las señales pueden ser enviadas por un proceso a cualquier otro proceso, e x is -lí, tiendo una serie de restricciones que afectan a las señales enviadas a los procesos que sean ' propiedad de otro usuario. Sin em bargo, el núm ero de señales disponibles es lim itado, y esas.— señales no pueden transportar inform ación: lo único que está disponible para el proceso es el hecho de que se ha producido una señal. Las señales no son sólo generadas por los procesos. El kem el también genera señales internam ente; por ejem plo, puede enviar una señal a un proceso ser­ vidor cuando llegan datos a través de un canal de red, a un proceso padre cuando un proceso hijo term ina o a un proceso en espera cuando term ina un tem porizador. Internam ente, el kem el de Linux no utiliza señales para com unicarse con los procesos que se están ejecutando en m odo kem el. Si un proceso en m odo kem el está esperando a que ocurra un suceso, norm alm ente no utilizará señales para recibir la notificación de dicho suceso. En lugar de ello, la com unicación con el kem el a c e rc a de los sucesos asincronos entrantes se realiza mediante el uso de estados de planificación y de w a it_ q u e u e . Estos m ecanism os perm iten a los procesos en m odo kem el inform arse entre sí acerca de los sucesos relevantes, y tam bién perm iten que los sucesos sean generados por los controladores de dispositivos o por el sistem a de com unicación por red. Cada vez que un proceso quiere esperar a que se com plete un determ inado suceso, se coloca a sí m ism o en una cola de espera asociada con dicho suceso y le dice al planificador que ya no es elegible para ejecución. Una vez que el suceso se ha com pletado, despertará a todos los pro­ cesos que se encuentren en la cola de espera. Este procedim iento perm ite que m últiples procesos esperen a que se produzca un m ism o suceso. Por ejem plo, si hay m uchos procesos tratando de leer un archivo del disco, entonces todos ellos serán despertados una vez que los datos hayan sido car­ gados en m em oria. Aunque las señales han sido siem pre el m ecanism o principal de com unicación de sucesos asin­ cronos entre procesos, Linux tam bién im plem enta el m ecanism o de semáforos, de UNIX System V . Un proceso puede esperar en un sem áforo con la m ism a sencillez con que puede esperar a una señal, pero los sem áforos tienen dos ventajas: se pueden com partir m últiples sem áforos entre m últiples procesos independientes y las operaciones sobre m últiples sem áforos pueden realizar­ se atóm icam ente. Internam ente, el m ecanism o estándar de colas de espera de Linux sincroniza los procesos que se estén com unicando m ediante sem áforos. J-

21.10 Estructura de red

705

21.9.2 Transferencia de datos entre procesos Linux ofrece varios m ecanism os para la transferencia de datos entre procesos. El m ecanism o p ip e (canalización) estándar de UNIX perm ite que un proceso hijo herede el canal de com unicación de su padre; los datos escritos en un extrem o del pipe pueden leerse en el otro. En Linux, los pipes apa­ recen com o otro tipo más de inodo en e l softw are del sistem a de archivos virtual. Cada pipe tiene un par de colas de espera para sincronizar al lector y al escritor. UNIX tam bién define un conjun­ to de funcionalidades de red que perm iten enviar flujos de datos a procesos tanto locales com o rem otos. En la Sección 21.10 se cubre el tem a de la com unicación por red. H ay disponibles otros dos m étodos para com partir datos entre procesos. En prim er lugar, la m em oria com partida ofrece una form a extrem adam ente rápida de transferir grandes o pequeñas cantidades de datos. Los datos escritos por un proceso en una región de m em oria com partida pue­ den ser leídos inm ediatam ente por cualquier otro proceso que haya m apeado dicha región en su espacio de direcciones. La desventaja principal de la m em oria com partida es que, en sí m ism a, no ofrece ninguna sincronización. U n proceso ni puede preguntar al sistem a operativo si se ha escri­ to en una sección de la m em oria com partida ni tam poco puede suspender su propia ejecución hasta que dicha escritura se produzca. La m em oria com partida resulta particularm ente potente cuando se la utiliza en conjunción con otro m ecanism o de com unicación interprocesos que pro­ porcione ese m ecanism o de sincronización que a la m em oria com partida le falta. U na región de m em oria com partida en Linux es un objeto persistente que puede ser creado o elim inado por los procesos. D icho objeto se trata com o si fuera un pequeño espacio de direccio­ nes independiente. Los algoritm os de paginación de Linux pueden decidir descargar en disco las páginas de m em oria com partida, de la m ism a form a que pueden descargar las páginas de datos de un proceso. El objeto de m em oria com partida actúa com o alm acén de respaldo para las regio­ nes de m em oria com partida, de la m ism a m anera que un archivo puede actuar de respaldo para una región m apeada en m em oria. Cuando se m apea un archivo en una región del espacio de direcciones virtual, cualquier fallo de página que se produzca hará que se m apee en la m em oria virtual la página apropiada del archivo. De la m ism a form a, los m apeos de m em oria com partida hacen que los fallos de página m apeen las páginas de un objeto de m em oria com partida persis­ tente. Tam bién al igual que con los archivos, los objetos de m em oria com partida recuerdan su con­ tenido incluso aunque que no haya ningún proceso que los esté m apeando actualm ente en m em oria virtual.

21.10 Estructura de red La com unicación por red es una de las áreas clave de funcionalidad en Linux. Linux no sólo sopor­ ta los protocolos Internet estándar utilizados en la m ayoría de las com unicaciones UNIX-UNIX, sino que tam bién im plem enta diversos protocolos nativos de otros sistem as operativos distintos de UNIX. En particular, puesto que Linux fue originalm ente im plem entado principalm ente en m áqui­ nas de tipo PC, en lugar de grandes estaciones de trabajo o sistem as de tipo servidor, adm ite m uchos de los protocolos usados norm alm ente en redes de tipo PC, com o A ppleTalk e IPX. Internam ente, la com unicación por red en el kem el de Linux se im plem enta m ediante tres capas de software; 1. La interfaz socket 2. C ontroladores de protocolo 3. Controladores de dispositivos de red. Las aplicaciones de usuario realizan todas las solicitudes de com unicación por red a través de la interfaz socket. Esta interfaz está diseñada para asem ejarse a la capa socket de BSD 4.3, de m odo que cualquier program a diseñado para hacer uso de los socktes de Berkeley se podrá ejecutar en Linux sin efectuar ningún cam bio en el código fuente. Esta interfaz se describe en la Sección A .9.1. La interfaz socket BSD es suficientem ente general com o para representar las direcciones de red para un am plio rango de protocolos de com unicación por red. Esta misma interfaz se em plea en Linux

Capítulo 21 El sistema Linux

n o só lo p a ra a c c e d e r a a q u e llo s p ro to c o lo s im p le m e n ta d o s en los sis te m a s BSD e s tá n d a r, sin o tam ­ b ién a to d o s los p ro to co lo s s o p o r ta d o s p o r el sistem a.

La siguiente capa de softw are es la pila de protocolos, que es sim ilar en organización a la uti­ lizada en BSD. C ada vez que llegan nuevos datos por red a esta capa, bien procedente de un Soc­ ket de aplicación o a través un controlador de dispositivo de red, se espera que los datos hayan sido etiquetados con un identificador que especifique el protocolo de red que contienen. Los pro­ tocolos pueden com unicarse entre sí, si asi lo desean; por ejem plo, dentro del conjunto de proto­ colos Internet, hay una serie de protocolos separados que gestionan el encam inam iento, los inform es de errores y la retransm isión fiable de los datos perdidos. La capa de protocolos puede reescribir paquetes, crear nuevos paquetes, dividir o re-ensam­ blar paquetes en fragm entos o sim plem ente descartar los datos entrantes. En últim o extremo, una vez que ha finalizado de procesar un conjunto de paquetes los pasa a la siguiente capa, es decir, a la interfaz socket si los datos están destinados a una conexión local o al controlador de dispositi­ vo si el paquete tiene que retransm itirse rem otam ente. La capa de protocolos decide el socket o dis­ positivo al cual hay que enviar el paquete. Todas las com unicaciones entre las capas de la pila de com unicación por red se realizan pasan­ do estructuras s k b u f f . U n estructura s k b u f f contiene un conjunto de punteros a un área conti­ nua de m em oria, que representa un búfer dentro del cual pueden construirse los paquetes de red. Los datos válidos de una estructura s k b u f f no necesitan com enzar al principio del búfer, y tam­ poco necesitan continuar hasta el final. El código de com unicación por red puede añadir o elimi­ nar datos de cualquiera de los dos extrem os del paquete, siem pre y cuando el resultado continúe cabiendo dentro de la estructura s k b u f f . Esta capacidad resulta especialm ente im portante en los m icroprocesadores m odernos, en los que las m ejoras en la velocidad de la CPU han sido mucho más significativas que las de la velocidad de la m em oria principal. La arquitectura s k b u f f pro­ porciona una gran flexibilidad a la hora de m anipular las cabeceras de paquetes y las sumas de com probación, evitando operaciones innecesarias de copia de los datos. El conjunto de protocolos m ás im portante dentro del sistem a de com unicación por red de Linux es el conjunto de protocolos TCP/IP. Este conjunto com prende diversos protocolos separa­ dos. El protocolo IP im plem enta el encam inam iento entre distintos hosts situados en cualquier lugar de la red. Por encim a del protocolo de encam inam iento están construidos los protocolos UDP, TCP e ICMP. El protocolo UDP transporta datagram as individuales arbitrarios entre hosts. El protocolo TCP im plem enta conexiones fiables entre hosts con una entrega ordenada y garantiza­ da de los paquetes y con un m ecanism o de retransm isión autom ática de los datos perdidos. El protocolo ICMP se utiliza para com unicar diversos m ensajes de error y de estado entre un host y otro. Los paquetes (estructuras s k b u f f ) que llegan a la capa de protocolos de la pila red deben estar etiquetados con un identificador interno que indique el protocolo para el cual es relevante dicho paquete. D iferentes controladores de dispositivos de red codifican el tipo de protocolo de distin­ tas m aneras en el m edio de com unicación; por tanto, el protocolo para los datos entrantes debe identificarse en el controlador de dispositivo. El controlador de dispositivos utiliza una tabla hash de identificadores conocidos de protocolos de red para localiza el protocolo apropiado y pasa el paquete a dicho protocolo. Pueden añadirse nuevos protocolos a la tabla hash en form a de módu­ los cargables por el kemel. Los paquetes IP entrantes se entregan al controlador IP. El trabajo de esta capa de softw are con­ siste en realizar el encam inam iento. Después de decidir a dónde está destinado el paquete, esta capa re-eñvía el paquete al controlador de protocolo interno que resulte apropiado, con el fin de sum inistrarlo localm ente, o vuelve a inyectarlo en la cola de un controlador de dispositivo de red seleccionado, con el fin re-enviarlo a otro host. Esa decisión de encam inam iento se tom a utilizan­ do dos tablas: la denom inada base de inform ación de re-envío persistente (FIB, forw arding inform ation base) y una caché en la que se alm acenan las decisiones de encam inam iento recientemente tom adas. La base FIB alm acena inform ación de configuración del encam inam iento y puede espe­ cificar rutas basándose en una dirección de destino específica o en un carácter com odín que repre­ sente m últiples destinos. La base FIB está organizada com o un conjunto de tablas hash indexadas según la dirección de destino; las tablas que representan las rutas m ás específicas son las que se J-

21.11 Seguridad

707

exploran prim ero. Las búsquedas que tengan éxito en esta tabla se añaden a la tabla de caché de rutas, donde se alm acenan las rutas únicam ente según su destino específico, en la caché no se alm acena ningún carácter com odín, de m odo que las búsquedas en la caché puedan llevarse a cabo rápidam ente. Las entradas de la caché de rutas caducan después de un período fijo durante el cual no se haya producido ningún acierto de caché para esa entrada. E n diversas etapas del proceso, el softw are IP pasa los paquetes a una sección de código sepa­ rada con el fin de realizar la g estió n de cortafuegos, es decir, el filtrado selectivo de los'paquetes de acuerdo con una serie de criterios arbitrarios, norm alm ente por razones de seguridad. El ges­ tor de cortafuegos m antiene una serie de cadenas de cortafu egos y perm ite com parar cada s k b u f f con cualquiera de las cadenas. Las distintas cadenas se reservan para diferentes propósi­ tos: una se usa para los paquetes re-enviados, otra para los paquetes que constituyen una entrada para este host y otras para los datos generados en este host. Cada cadena se alm acena en form a de una lista ordenada de reglas, en la que cada regla especifica una función de entre una serie de posibles funciones que regulan la decisión de cortafuegos; cada regla se com plem enta con una serie de datos arbitrarios que son con los que hay que ver si el paquete se corresponde. El controlador IP realiza otras dos funciones: el desensam blado y el re-ensam blado de paque­ tes de gran tam año. Si un paquete saliente es dem asiado grande com o para poder ponerlo en la cola de un dispositivo, sim plem ente se divide en una serie de fragm entos más pequeños, todos los cuales se ponen en la cola del controlador. En el host receptor, esos fragm entos deberán ser re­ ensam blados. El controlador IP m antiene un objeto i p f r a g por cada fragm ento que esté a la espe­ ra de ser re-ensam bldo y un objeto i p q por cada datagram a que esté siendo ensam blado. Los fragm entos entrantes se com paran con cada ip q conocido. Si se encuentra una correspondencia, se le añade el fragm ento; en caso contrario, se crea un nuevo ip q . U na vez que ha llegado el frag­ m ento final de un ip q , se construye un estructura s k b u f f com pletam ente nueva para alm acenar el nuevo paquete y este paquete se pasa al controlador IP. Los paquetes identificados por la capa IP com o destinados a este host se pasa a alguno de los otros controladores de protocolo. Los protocolos UDP y TCP com parten un m ismo medio de aso­ ciar los paquetes con los sockets de origen y de destino: cada pareja de sockets conectados queda identificada unívocam ente m ediante sus direcciones de origen y de destino y m ediante los núm e­ ros de puerto de origen y de destino. Las listas de sockets están enlazadas en tablas hash que utili­ zan com o clave estos cuatro valores de dirección-puerto, con el fin de poder buscar fácilm ente el socket correspondiente a los paquetes entrantes. El protocolo TCP tiene que tratar con conexiones no fiables, asi que m antiene listas ordenadas de paquetes salientes no confirm ados, con el fin de retransm itirlos después de un cierto período de tem porización, y de paquetes entrantes que han entrado desordenadam ente con el fin de entregárselos al socket una vez que lleguen los datos que faltan.

21.11 Seguridad El m o d e lo d e s e g u rid a d d e L in u x e stá b a sta n te re la c io n a d o c o n los m e c a n is m o s típ ico s d e s e g u ri­ d a d d e UNIX. L o s p ro b le m a s re la tiv o s a la s e g u rid a d p u e d e n cla sifica rse e n d o s g ru p o s:

1. A u ten ticación. A segurarse de que nadie pueda acceder al sistem a sin dem ostrar primero que tiene los correspondientes derechos de entrada. 2. C on trol de acceso. . Proporcionar un m ecanism o para controlar si un usuario tiene derecho de acceso a un cierto objeto e im pedir el acceso a los objetos según sea necesario.

21.11.1 Autenticación L a a u te n tica ció n en UNIX se realiz a b a tra d ic io n a lm e n te u tiliz a n d o u n a rch iv o d e co n tra se ñ a s p ú b lica m e n te legib le. L a c o n tr a s e ñ a d e u n u su a rio se co m b in a c o n u n v a lo r aleatorizador y el re s u lta d o se co d ific a m e d ia n te u n a fu n ció n d e tra n sfo rm a c ió n u n id ire ccio n a l y se a lm a ce n a en el a rc h iv o d e c o n tra s e ñ a s . E l u so d e la fu n ció n u n id ire ccio n a l im p lica q u e la c o n tra se ñ a o rig in a l no p u e d e d e d u c irs e a p a rtir d el a rc h iv o d e c o n tra s e ñ a s s a lv o p o r u n m é to d o d e p ru e b a y e rro r.

708

Capítulo 21 El sistema Linux

Cuando un usuario presenta una contraseña al sistem a, la contraseña se recom bina con el aleatorizador alm acenado en el archivo de contraseñas y se pasa a través de la m ism a función unidirec­ cional. Si el resultado se corresponde con el contenido del archivo de contraseñas, entonces la contraseña se acepta. H istóricam ente, las im plem entaciones UNIX de este m ecanism o presentaban diversos proble­ mas. Las contraseñas estaban lim itadas a m enudo a ocho caracteres y el núm ero de posibles valo­ res aleatorizadores era tan bajo que un atacante podía fácilm ente com binar un diccionario de contraseñas com únm ente utilizadas con todos los valores aleatorizadores y tener una buena pro­ babilidad de encontrar una correspondencia con una o más de las contraseñas del archivo de con­ traseñas, obteniendo com o resultado un acceso no autorizado a las cuentas que hubieran quedado com prom etidas. Se han introducido diversas extensiones del m ecanism o de contraseñas que man­ tienen en secreto la contraseña cifrada en un archivo que no es públicam ente legible. Otras varian­ tes perm iten utilizar contraseñas de m ayor tam año o em plean m étodos más seguros para codificar la contraseña. Tam bién se han introducido otros m ecanism os de autenticación que limitan el núm ero de veces que un usuario está autorizado a conectarse al sistem a o que distribuyen infor­ m ación de autenticación a todos los sistem as relacionados de una red. Los distribuidores de UNIX han desarrollado u n nuevo m ecanism o de seguridad para resolver los problem as de autenticación. El sistem a de m ó d u lo s d e a u te n tic a c ió n c o n e c ta b le s (PAM, pluggable authentication m odules) está basado en una biblioteca com partida que puede ser utilizada por cualquier com ponente del sistem a que necesite autenticar a los usuarios. En Linux hay dispo­ nible una im plem entación de este sistem a. PAM perm ite cargar m ódulos de autenticación bajo dem anda, según se especifique en un archivo de configuración global del sistem a. Si se añade un nuevo m ecanism o de autenticación posteriorm ente, se puede insertar en el archivo de configura­ ción, y todos los com ponentes del sistem a podrán aprovecharse de él de form a inmediata. Los m ódulos PAM pueden especificar m étodos de autenticación, restricciones que afecten cuentas, funciones de configuración de sesión y funciones de m odificación de contraseña (de modo que, cuando los usuarios cam bien sus contraseñas, puedan actualizarse a la vez todos los mecanismos de autenticación necesarios).

21.11.2 Control de acceso El control de acceso en los sistem as UNIX, incluyendo Linux, se realizan utilizando identificadores num éricos unívocos. Un identificador de usuario (uid) identifica a un único usuario a o único conjunto de derechos de acceso. U n identificador de grupo (gid) es un identificador adicional que puede em plearse para especificar aquellos derechos que pertenecen a más de un usuario.El m ecanism o de control de acceso se aplica a diversos objetos del sistema. Cada archivo dis­ ponible en el sistem a está protegido por el m ecanism o estándar de control de acceso; además, otros objetos com partidos, com o las secciones de m em oria com partida y los sem áforos, emplean el m ism o sistem a de acceso. Todo objeto de un sistem a a UNIX som etido al control de acceso de usuario y de grupo tiene asociado un único uid y un único gid. Los procesos de usuario tam bién tienen un único uid pero pueden tener m ás de un gid. Si el uid de>un proceso se corresponde con el uid de un objeto, enton­ ces el proceso tiene d e re c h o s d e u s u a rio o d e re c h o s d e p r o p ie ta r io sobre dicho objeto. Si los valo­ res uid no se corresponden, pero algunos de los valores gid del proceso sí se corresponden con el gid del objeto, entonces se conceden al proceso d e r e c h o s d e g ru p o ; en caso contrario, el proceso tiene d e re c h o s d e l re s to d e l m u n d o sobre el objeto. Linux realiza el control de acceso asignando a los objetos una m áscara de protección, que espe­ cifica los m odos de acceso (lectura, escritura o ejecución) que hay que conceder a los procesos que tengan acceso de propietario, de grupo o resto del m undo. Por tanto, el propietario de un objeto puede tener un acceso com pleto de lectura, escritura y ejecución sobre un archivo, m ientras que otros usuarios de un cierto grupo podrían entre acceso de lectura, pero no de escriti ira y tocios los dem ás podrían no tener ningún acceso en absoluto. La única excepción es el uid r o o t privilegiado. U n proceso con este uid especial tiene automá­ ticam ente acceso a todos los objetos del sistem a, puenteando los controles de acceso normales. J-

21.12 Resumen

709

Tales procesos tam bién tienen perm iso para realizar operaciones privilegiadas, com o leer cual­ quier sección de la m em oria física o abrir sockets de red reservados. Este m ecanism o perm ite al ker­ nel im pedir que los usuarios norm ales accedan a estos recursos. La m ayoría de los principales recursos internos del k em el son propiedad im plícitam ente del uid root. Linux im plem enta el m ecanism o s e t u i d estándar de UNIX descrito en el Sección A .3.2. Este m ecanism o perm ite a un program a ejecutarse con privilegios diferentes de los del usuario que está ejecutando el program a. Por ejem plo, el program a l p r (que coloca un trabajo en una cola de im presión) tiene acceso a las colas de im presión del sistem a incluso si el usuario que está ejecu­ tando el program a no dispone de dicho acceso. La im plem entación UNIX de s e t u i d distingue entre un uid real y el uid efectivo de un proceso. El uid real es el del usuario que está ejecutando el program a el uid efectivo es el del propietario del archivo. En Linux, este m ecanism o está am pliado de dos form as distintas. En prim er lugar, Linux im plem enta el m ecanism o s a v e d u s e r - i d de la especificación POSIX, que perm ite a un proceso renunciar y readquirir su uid efectivo repetidam ente. Por razones de seguridad, un program a puede querer realizar la m ayoría de sus operaciones en un m odo seguro, renunciando a los privi­ legios concedidos por el estado s e t u i d , pero al m ism o tiem po puede querer realizar determ ina­ das operaciones seleccionadas con todos los privilegios. Las im plem entaciones estándar de UNIX consiguen esta capacidad únicam ente intercam biando los valores uid real y efectivo; el uid efec­ tivo anterior se recuerda, pero el uid real del program a no siem pre se corresponde con el uid del usuario que ejecuta el program a. Los uid guardados perm iten a un proceso utilizar com o uid efec­ tivo su uid real y luego volver al valor anterior de uid efectivo, sin tener que m odificar el uid real en ningún m om ento. La segunda m ejora proporcionada por Linux es la adición de una característica de los procesos que concede únicam ente un subconjunto de los derechos del uid efectivo. Las propiedades fsu id y fsg id de los procesos se utilizan cuando se conceden derechos de acceso a los archivos. La pro­ piedad correspondiente se configura cada vez que se configura el uid o gid efectivo. Sin em bargo, los valores fsuid y fsgid pueden configurarse independientem ente de los identificadores efectivos, lo que perm ite a un proceso acceder a archivos por cuenta de otro usuario sin adoptar la identi­ dad de ese otro usuario en ninguna form a. Específicam ente, los procesos de servidor pueden uti­ lizar este m ecanism o para servir archivos a un cierto usuario sin que el proceso pueda ser m atado o suspendido por ese usuario. Finalm ente, Linux proporciona un m ecanism o flexible para pasar los derechos de un progra­ m a a otro, un m ecanism o que ha llegado a ser com ún en las versiones m odernas de UNIX. Cuando se ha configurado un socket de red local entre dos procesos del sistem a, cualquiera de esos proce­ sos puede enviar al otro un descriptor de archivo que se corresponda con uno de sus archivos abiertos, él otro proceso recibirá un descriptor de archivo duplicado para ese m ism o archivo. Este m ecanism o perm ite a un cliente pasar selectivam ente el acceso a un archivo a otro proceso servi­ dor sin conceder a dicho proceso ningún otro privilegio. Por ejem plo, ya no es necesario que un servidor de im presión pueda leer todos los archivos de un usuario que envíe un nuevo trabajo de im presión; el cliente de im presión puede sim plem ente pasar al servidor los descriptores de los archivos que haya que im prim ir denegando al servidor el acceso a los restantes archivos del usuario.

21,12 Resumen L in u x es un m o d e rn o sis te m a o p e ra tiv o g ra tu ito b a s a d o e n e s tá n d a re s UNIX. H a sid o d ise ñ a d o p a ra e jecu tarse d e m a n e ra eficien te y fiable so b re h a r d w a r e c o m ú n d e tip o PC; ta m b ié n se p u e d e eje cu ta r en o tra s p la ta fo rm a s . P ro p o rc io n a u n a in te rfa z d e p ro g ra m a c ió n y u n a in te rfa z d e u su a ­ rio co m p a tib le c o n los s is te m a s e s tá n d a r UNIX y p e rm ite e je cu ta r u n g ra n n ú m e ro d e a p lica cio n e s UNIX, in clu y e n d o u n c re c ie n te n ú m e ro d e a p lic a cio n e s co m e rc ia lm e n te so p o rta d a s.

Linux no ha evolucionado dentro de una burbuja. Un sistem a Linux com pleto incluye m uchos com ponentes que fueron desarrollados de Linux. El kem el básico del sistem a operativo Linux es enteramente original, pero perm ite ejecutar buena parte del softw are UNIX gratuito existente, lo

710

Capítulo 21 El sistema Linux

q u e d a c o m o re s u lta d o u n s is te m a o p e ra tiv o co m p le to co m p a tib le co n UNIX y co m p le ta m e n te libre d e c ó d ig o p ro p ie ta rio .

El kem el de Linux está im plem entado com o un kem el m onolítico tradicional por razones de ren­ dim iento, pero es suficientem ente m odular en su diseño com o para perm itir cargar y descargar dinám icam ente la m ayoría de los controladores eyrt tiem po de ejecución. Linux es un sistem a m ultiusuario, que proporciona protección entre los procesos y que puede ejecutar m últiples procesos de acuerdo con un planificador de tiem po com partido. Los procesos recién creados pueden com partir partes seleccionadas de su entorno de ejecución con sus pro­ cesos padre, lo que perm ite la program ación m ultihebra. La program ación interprocesos está soportada tanto por m ecanism os de tipo System V (colas de m ensajes, sem áforos y m em oria com­ partida) com o por la interfaz socket de BSD. A través de la interfaz socket puede accederse simultá­ neam ente a m últiples protocolos de red. Para el usuario, el sistem a de archivos aparece com o un árbol de directorios jerárquico que cum ple con la sem ántica UNIX. Internam ente, Linux utiliza una capa de abstracción para gestio­ nar m últiples sistem as de archivos diferentes. Se perm ite el uso de sistem as de archivos orienta­ dos a dispositivo, sistem as de archivos en red y sistem as de archivos virtuales. Los sistemas de archivos orientados a dispositivo acceden al alm acenam iento en disco a través de una caché de páginas que está unificada con el sistem a de m em oria virtual. El sistem a de gestión de m em oria utiliza com partición de páginas y m ecanism os de copia durante la escritura para m inim izar la duplicación de los datos com partidos por los diferentes procesos. Las páginas se cargan bajo dem anda la prim era vez que se hace referencia a las mismas y se descargan en el alm acén de respaldo de acuerdo con un algoritm o LFU cuando es necesario reclam ar la m em oria física.

Ejercicios

v

21.1

¿Cuáles son las ventajas y desventajas de escribir un sistem a operativo en un lenguaje dé alto nivel, com o C?

21.2

¿En qué circunstancias resulta más apropiada la secuencia de llam adas al sistema f o r k () e x e c () ? ¿C uándo es preferible utilizar v f o r k () ?

21.3

¿Q ué tipo de socket debería utilizarse para im plem entar un program a de transferencia de archivos entre com putadoras? ¿Qué tipo debería utilizarse para un program a que compro­ bara periódicam ente si otra com putadora está encendida en la red? Razone su respuesta.

21.4

Linux se ejecuta sobre diversas plataform as hardware. ¿Q ué pasos deben dar los desarrolla­ dores de Linux para garantizar que el sistem a sea portable a diferentes procesadores y arquitecturas de gestión de m em oria, y para m inim izar la cantidad de código de kem el espe­ cífico de la arquitectura?

21.5

¿Cuáles son las ventajas y desventajas de hacer que sólo parte de los sím bolos definidos dentro de un kem el sean accesibles a un m ódulo cargable del k em el?

21.6

¿C uáles son los objetivos principales del m ecanism o de resolución de conflictos usado por el kem el de Linux para cargar los m ódulos del kem el?

21.7

Explique el m odo en que se utiliza la operación c l o n e () de Linux para perm itir el uso tanto de procesos com o de hebras.

21.8

¿C óm o clasificaría las hebras de Linux: cóm o hebras de nivel de usuario o com o hebras de nivel del kernel? Razone su respuesta con los argum entos apropiados.'

21.9

¿Q ué costes adicionales tiene la creación y planificación de un proceso, si se com para con el coste de una hebra clonada?

21.10 El planificador de Linux im plem enta una planificación en tiempo real no estricta. ¿Qu~ características necesarias para ciertas tareas de program ación en tiempo real son las que .a-' tan? ¿C óm o podrían añadirse al k em el?

Notas bibliográficas

711

21.11 ¿En qué circunstancias solicitaría un proceso de usuario una operación que provocará la asignación de una región de m em oria con ceros bajo dem anda? 21.12 ¿Q ué escenarios harían que se m apeara una página de m em oria sobre el espacio de direc­ ciones de un program a de usuario con el atributo de copia durante la escritura activado? . 21.13 En Linux, las bibliotecas com partidas realizan m uchas operaciones cruciales para el sistem a operativo. ¿Cuál es la ventaja de m antener esta funcionalidad fuera del kernel? ¿Existe algu­ na desventaja? R azone su respuesta. 21.14 La estructura de directorios de un sistem a operativo Linux puede com prender archivos correspondientes a diferentes sistem as de archivos, incluyendo el sistem a de archivos / p r o c de Linux. ¿C uáles son las im plicaciones de tener que soportar diferentes tipos de sis­ tem as de archivos en la estructura del kernel de Linux? 21.15 ¿D e qu é form a difiere la funcionalidad s e t u i d de L in u x de la funcionalidad s e t u i d del UNIX están d ar?

21.16

El código fuente de Linux está am pliam ente disponible de form a gratuita a través de Internet o de diversos sum inistradores en CD-ROM. ¿Podría citar tres consecuencias que esta disponibilidad tiene para la seguridad del sistem a Linux?

Notas bibliográficas El sistem a Linux es un producto de Internet; en consecuencia, buena parte de la docum entación disponible sobre Linux está accesible de una u otra form a a través Internet. Los siguientes sitios principales contienen referencias a la m ayor parte de la inform ación útil disponible: • Linux C ross-R eference Pages en http://lxr.linux.no/ m antiene listados actuales del kem el de Linux, que pueden consultarse a través de la W eb y están com pletam ente referenciados entre sí. • Linux-H Q en http://w w w .linuxhq.com / alberga una gran cantidad de inform ación relaciona­ da con los kem els 2.x de Linux 2.x. Este sitio tam bién incluye vínculos con las páginas prin­ cipales de la m ayoría de las distribuciones Linux, así com o archivos de las principales listas de correo. • Linux D ocum entatíon Project en http://sunsite.unc.edu/linux/cita m uchos libros sobre Linux que están disponibles en form ato fuente como parte del proyector de doctím entación de Linux, el proyecto tam bién alberga las guías tutoriales How-To, que contienen una serie de consejos y sugerencias relativas a diversos aspectos de este sistem a operativo. • La guía K em el H ackers'Guide es una guía basada en Internet de los detalles internos genera­ les del kernel. Este sitio en constante expansión se encuentra en http://w w w .redhat. com :8080/H yperN ews/get/khg.htm l. • El sitio web Kernel N ewbies (http://w w w .kem elnew bies.org/) proporciona diversos recursos introductorios al kernel de Linux para los principiantes. Tam bién hay disponibles m uchas listas de correo dedicadas a Linux. Las más im portantes son las m antenidas por un gestor de listas de correo con el que se puede conectar en la dirección de correo electrónico m ajordom o@ vger.rutgers.edu. Envíe un m ensaje de correo electrónico a esta direc­ ción incluyendo una única línea con el texto “help” en el cuerpo del m ensaje para obtener infor­ m ación sobre cóm o acceder ál servidor de listas y cóm o suscribirse a alguna de ellas. Por últim o, el propio sistem a Linux puede obtenerse a través de Internet. Pueden obtenerse distribuciones Linux com pletas en los sitios web de las correspondientes em presas, y la com uni­ dad Linux tam bién m antiene archivos de los com ponentes actuales del sistem a en diversos luga­ res de Internet. Los más im portantes son: • ftp :/ /tsx-ll.m it.edu/p ub/lin ux/

712

Capítulo 21 El sistema Linux

• ftp://sunsite.unc.edu/pub/Linux/ • ftp :/ / linuxLernd.org/pub/linux/ A dem ás de investigar los recursos disponibles en Internet, puede aprender acerca de los deta­ lles internos del kem el de Linux en Bovet y C esati [2002] y Love [2004],

Windows XP El sistem a operativo M icrosoft W indow s XP es un sistem a operativo m ultitarea apropiativo de 32/64-bits para los m icroprocesadores AMD K6/K7, Intel IA 32\IA 64 y posteriores. Sucesor de W indow s NT y W indow s 2000, W indow s XP tam bién trata de reem plazar al sistem as operativo W indow s 95/98. Los objetivos clave del sistem a operativo son la seguridad, la fiabilidad, la faci­ lidad de uso, la com patibilidad con aplicaciones W indow s y POSIX, las altas prestaciones, am pliabilidad, la portabilidad y el soporte internacional. En este capítulo, vam os a analizar los objetivos clave de W indow s XP, la arquitectura en niveles que los hace tan fácil de utilizar, el sistem a de archivos, las funciones de conexión por red y la interfaz de program ación.

OBJETIVOS DEL CAPÍTULO • Explorar los principios en los que se basa el diseño de Windows XP y los componentes específi­ cos que forman el sistema. • Comprender cómo Windows XP puede ejecutar programas diseñados para otros sistemas opera­ tivos. •

Proporcionar unas explicaciones detalladas del sistem a de archivos de Windows XP.

• Ilustrar los protocolos de red soportados en Windows XP. • Analizar la interfaz disponible para los programadores de sistemas y aplicaciones.

22.1 Historia A m ed iad o s de 1980, M icrosoft e IBM co o p eraro n en el desarrollo del sistem a op erativo O S /2, que fue escrito en lenguaje en sam b lad or p ara sistem as Intel 80286 m onoprocesador. E n 1988, M icro­ soft d ecidió co m en zar de n u ev o y d esarrollar un sistem a op erativo portable basado en una “nueva tecnología” (o NT, new technology) que sop ortara las interfaz de p rogram ación de aplicaciones (API, ap p lication -p rogram m in g interface) tanto de O S /2 co m o de POSIX. En octubre de 1988, D ave C utler, el arquitecto del sistem a o p erativo VAX/ VMS d e DEC fue con tratad o por M icrosoft y se le en cargo con stru ir ese n u ev o sistem a op erativo. . O riginalm ente, el equipo de desarrollo pretendía usar para NT la API O S /2 com o entorno nati­ vo, pero durante el desarrollo NT fue m odificado para utilizar la API W indows de 32 bits (o API W in32), com o resultado de la popularidad de W indow s 3.0. Las prim era versiones de NT fueron W indow s NT 3.1 y W indow s NT 3.1 A dvanced Server (en aquella época, la versión actual del sis­ tema operativo W indow s de 16 bits era la 3.1.) La versión 4.0 de W indows NT adoptó la interfaz

de usuario de W indow s 95 e incorporó softw are de servidor web y explorador w eb internet. A dem ás, las rutinas de interfaz de usuario y todo el código gráfico se incluyeron en el kernel para m ejorar las prestaciones, aunque eso tuvo el efecto colateral de reducir la fiabilidad del sistema. Aunque las versiones anteriores de NT habían sido portadas a otras arquitecturas de m icroproce-

714

Capítulo 22 Windows XP

sador, la versión W indow s 2000, lanzada en febrero de 2000, dejó de dar soporte para otros pro­ cesadores distintos de Intel (y com patibles) debido a consideraciones de m ercado. W indow s 2000 incorporó varios cam bios significativos respecto a W indow s NT. Se añadió A ctive Directory (un servicio de directorio basado en X.500), un m ejor soporte de red y de dispositivos portátiles soporte para dispositivos plug-and-play, un sistem a distribuido de archivos y soporte para más procesadores y m ás m em oria. En octubre de 2001, se presentó W indow s XP com o actualización del sistem a operativo d e sobrem esa W indow s 2000 y com o sustituto de W indow s 95/98. En 2002, estuvieron disponibles las versiones de servidor de W indow s XP (denom inadas W indow s .Net Server). W indow s XP actualiza la interfaz gráfica de usuario (GUI, graphical user interface) con un diseño visual q u e aprovecha los m ás recientes avances hardw are e incorpora m uchas nuevas características qué. increm entan la facilid ad de uso. Se han añadido num erosas funciones para reparar automática­ m ente los problem as de las aplicaciones y del propio sistem a operativo. W indow s XP proporcio­ na unas posibilidades m ás sim ples de configuración de la red y de los dispositivos (incluyendo com unicación inalám brica de configuración cero, m ensajería instantánea, flujos m ultim edia y vídeo/fotografía digital). Tam bién se han aum entado enorm em ente las prestaciones tanto para las m áquinas de sobrem esa com o para los grandes sistem as m ultiprocesador, y la fiabilidad y la seguridad son aún m ejores que las de W indow s 2000. W indow s XP utiliza una arquitectura cliente-servidor (como M ach) para poder implementar m últiples personalidades del sistem a operativo, com o por ejem plo la API W in32 y POSIX, con una serie de procesos de nivel de usuario, denom inados subsistem as. La arquitectura de subsistemas perm ite realizar m ejoras en una de las personalidades del sistem a operativo sin afectar a la com­ patibilidad con las aplicaciones de las restantes personalidades. W indow s X P es un sistem a operativo m ultiusuario, que perm ite el acceso sim ultáneo a través de servicios distribuidos o m ediante m últiples instancias de la interfaz gráfica de usuario, a tra/ vés del servidor de term inales de W indows. Las versiones de servidor de. W indow s X P permiten el establecim iento de varias sesiones sim ultáneas del servidor de term inales, desde sistemas W indow s de sobrem esa. Las versiones de sobrem esa del servidor de term inales m ultiplexan el teclado, el ratón y el m onitor entre las distintas sesiones de term inal virtual, para cada uno de los usuarios que hayan iniciado la sesión. Esta característica, denom inada conm utación rápida de usuario, perm ite a los usuarios desalojarse unos a otros en la consola de un PC sin tener que cerrar y volver a abrir una sesión en el sistema. W indow s XP es la prim era versión de W indow s en incorporar soporte de 64 bits. El sistem a de archivos nativo NT (NTFS) y m uchas de las API W in32 han utilizado siem pre enteros de 64 bits en todos los lugares apropiados, por lo que la extensión principal a 64 bits en W indow s XP se refiere ' principalm ente al soporte de direcciones de gran tamaño. Existen dos versiones de sobrem esa de W indow s XP. W indow s XP Professional, es la opción preferida para sistem as de escritorio utilizados por usuarios avanzados, tanto en entornos domés­ ticos com o de oficina. Para los usuarios dom ésticos que están efectuando la m igración de W indow s 95/98, W indow s X P Personal proporciona la fiabilidad y la facilidad de uso de W indow s XP, aunque carece de las características más avanzadas para poder trabajar con Active D irectory o para ejecutar aplicaciones POSIX. Los m iem bros de la fam ilia W indow s .Net Server utilizan los m ism os com ponentes principa­ les que las versiones de sobrem esa, pero añaden una serie de características necesarias para apli' ' caciones tales com o granjas de servidores web, servidores de archivos y de im presión, sistem as en cluster y m áquinas para grandes centros de datos. Esas m áquinas para grandes centros de datos pueden tener hasta 64 GB de m em oria y 32 procesadores en los sistem as IA32 y hasta 128 G B y 64 procesadores en los sistem as IA64.

22.2 Principios de diseño Los objetivos de diseño de M icrosoft para W indow s XP incluyen la seguridad, la fiabilidad, la com patibilidad con aplicaciones W indows y POSIX, las altas prestaciones, la am pliabilidad, la portabilidad y el soporte internacional.

22.2 Principios de diseno

715

22.2.1 Seguridad Los objetivos de s e g u r id a d de W indow s XP requerían algo m ás que una sim ple adherencia a los estándares que perm itieron que W indow s N T 4.0 recibiera una clasificación de seguridad C-2 por parte del gobierno de EE. U U . (lo que significa un nivel m oderado de protección frente al soft­ w are defectuoso de los ataques m aliciosos). Se com binó una revisión y pruebas profundas del código con la utilización de herram ientas autom áticas sofisticadas de análisis para identificar e investigar los defectos potenciales que pudieran representar vulnerabilidades de seguridad del sistem a.

22.2.2 Fiabilidad W indow s 2000 era el sistem a operativo más fiable y estable que M icrosoft había lanzando hasta la fecha. Buena parte de esta fiabilidad se debía a la m adurez del código fuente, a las profundas pruebas de carga del sistem a y a las herram ientas de detección autom ática de num erosos errores graves en los controladores. Los requisitos de fia b ilid a d para W indow s XP eran todavía más estrictos. M icrosoft utilizó profundas revisiones de código, tanto m anuales com o autom áticas, par identificar más de 63.000 líneas en los archivos fuente que pudieran contener potenciales proble­ m as no detectados por las pruebas, después de lo cual revisó cada una de las áreas para verificar que el código era correcto. W indow s XP am plía la verificación de los controladores con el fin de detectar errores más suti­ les, m ejora las facilidades para detectar los errores de program ación en el código de nivel de usua­ rio y som ete a los dispositivos, controladores y aplicaciones de terceras fuentes, a un riguroso proceso de certificación. A dem ás, W indow s XP añade nuevas facilidades para m onitorizar el esta­ do del PC, incluyendo la descarga de parches para los problem as, antes de que estos lleguen a ser experim entados por los usuarios. La fiabilidad percibida de W indow s XP tam bién se mejoró haciendo que la interfaz gráfica de usuario fuera más fácil de utilizar; para ello se em pleó un m ejor diseño visual, unos m enús m ás sim ples y unas m ejoras m ensurables en la facilidad con la que los usuarios pueden descubrir cóm o realizar determ inadas tareas comunes.

22.2.3 Compatibilidad con aplicaciones W indows y POSIX W indow s XP no sólo es una actualización de W indow s 2000, sino tam bién sustituto para W indows 95/98. W indow s 2000 se centraba principalm ente en la com patibilidad para aplicaciones de ofimática. Los requisitos para W indow s XP incluían una m ucho m ayor com patibilidad con las apli­ caciones de consum o que se ejecutan sobre W indows 95/98. La c o m p a tib ilid a d d e a p lic a c io n e s es difícil de conseguir, porque cada aplicación com prueba para ver si está instalada una versión concreta de W indows, puede tener una cierta dependencia con respecto a las particularidades de im plem entación de las API, puede exhibir errores latentes de aplicación que estuvieran ocultos en el sistem a anterior, etc. W indow s XP introduce un nivel de com patibilidad que se sitúa entre las aplicaciones y las API W in32. Este nivel hace que W indow s XP parezca (casi com pletam ente) com patible con las versio­ nes anteriores de W indow s, cuyos errores es capaz de emular. W indow s XP, al igual que las ver­ siones de NT anteriores, m antiene el soporte para ejecutar m uchas aplicaciones de 16 bits utilizando un nivel de conversión que traduce las llam adas a la API de 16 bits a sus llam adas de 32 bits equivalentes. De form a sim ilar, la versión de 64 bits de W indow s XP proporciona un nivel de conversión que traduce las llam adas a la API de 32bits en llam adas de 64 bits nativas. El sopor­ te POSIX en W indow s XP ha sido notablem ente m ejorado. A hora hay disponible un nuevo subsis­ tema POSIX denom inado Interix. La m ayoría del softw are com patible con UNIX actualm ente disponible se puede com pilar y ejecutar en Interix sin ninguna m odificación.

22.2.4 Altas prestaciones W indow s XP está diseñado para proporcionar unas a lta s p re s ta c io n e s en los sistem as de sobre­ mesa (que están fundam entalm ente restringidos por el rendim iento de E/S), en los sistem as ser­ >

716

Capítulo 22 Windows XP

vidores (en los que la CPU es a m enudo el cuello de botella) y en los grandes entornos multihebra y m ultiprocesador (donde la gestión de los m ecanism os de bloqueo y de las líneas de caché resul­ tan claves para la escalabilidad). Las altas prestaciones han sido un objetivo de im portancia cre­ ciente en W indow s XP. W indow s 2000 con SQL 2000 sobre un hardw are Com paq consiguió unas m arcas TPC-C extraordinarias en el m om ento de su lanzam iento. Para satisfacer los requisitos de prestaciones, NT utiliza diversas técnicas com o la E /S asincro­ na, protocolos optim izados para las redes (por ejem plo, m ecanism os de bloqueo optim ista de datos distribuidos y consolidación de las solicitudes en lotes), gráficos basados en el kem el y meca­ nism os sofisticados de alm acenam iento en caché de los datos del sistem a de archivos. Los algorit­ m os de gestión de m em oria y de sincronización están diseñados teniendo en cuenta las consideraciones de rendim iento relativas a las líneas de caché y a los m ultiprocesadores. W indow s XP ha conseguido m ejorar aún m ás las prestaciones, reduciendo la longitud de la ruta de código en las funciones críticas, utilizando m ejores algoritm os y estructuras de datos sepa­ radas para cada procesador, utilizando m ecanism os de coloreados de m em oria para máquinas NUMA (non-uniform m em ory access, acceso de m em oria no uniform e), e im plem entando proto­ colos de bloqueo m ás escalables, com o por ejem plo los cerrojos de bucle sin fin en cola. Los nue­ vos protocolos de bloqueo ayudan a reducir los ciclos del bus del sistem a e incluyen colas y listas de procesos bloqueados libres, operaciones atóm icas de lectura-m odificación-escritura (como por ejem plo las operaciones de increm ento interbloqueado) y otras técnicas de bloqueo avanzado. Los subsistem as que constituyen W indow s XP se com unican entre sí de form a eficiente m ediante una funcionalidad de llam adas a procedim ientos locales (LPC, local procedure cali), que proporcionan un sistem a de m ensajería de altas prestaciones. Salvo cuando se están ejecutando en el despachador del kem el, las hebras de los subsistem as de W indow s XP pueden ser desalojadas por otras hebras de m ayor prioridad. De este m odo, el sistem a puede responder rápidam ente a los sucesos externos. A dem ás, W indow s XP está diseñado para el m ultiprocesam iento simétrico; las m áquinas m ultiprocesador pueden ejecutar varias hebras al m ism o tiempo.

22.2.5 Ampliabilidad El concepto de am p liab ilid ad hace referencia a la capacidad de un sistem a operativo para man­ tenerse actualizado con respecto a los avances en tecnología inform ática. Para poder facilitar los cam bios a lo largo del tiem po, los desarrolladores im plem entaron W indow s XP utilizando una arquitectura de niveles. El program a ejecutivo (Exgcutive) de W indow s XP se ejecuta en m odo ker­ nel o en m odo protegido y proporciona los servicios básicos del sistem a. Por encim a del ejecutivo, hay varios subsistem as de servidor que trabajan en modo usuario. Entre unos subsistem as y otros se encuentra el su bsistem a de entorno que em ula diferentes sistem as operativos. De este modo, puede ejecutarse sobre W indow s XP, en el entorno apropiado, program ás escritos para MS-DOS, M icrosoft W indow s y POSIX (en la Sección 22.4 podrá encontrar m ás inform ación sobre los subsis­ tem as de entorno). Debido a la estructura m odular, pueden añadirse subsistem as de entornos sin afectar al ejecutivo. Adem ás, W indow s XP utiliza controladores cargables en el sistem a de E /S , por lo que pueden añadirse nuevos sistem as de archivos, nuevos tipos de dispositivos de E /S y nue­ vos m ecanism os de interconexión por red m ientras el sistem a continúa funcionando. W indows XP em plea un m odelo cliente-servidor com o el sistem a operativo M ach, y perm ite el uso de mecanis­ m os de procesam iento distribuido basados en llam adas a procedim ientos rem otos (RPC) como define la organización O pen Softw are Foundation.

22.2.6 Portabilidad U n sistem a operativo es p o rtable si se le puede desplazar de una arquitectura hardw are a otra con un núm ero de cam bios relativam ente pequeño. W indow s XP está diseñado para ser portable. Al igual que sucede con el sistem a operativo UNIX, la m ayor parte del sistem a está escrito en C y C++Casi todo el código dependiente del procesador está aislado en una biblioteca de m ontaje dinám i­ co (DLL, dynam ic link library) denom inada n iv el de abstracción del hardw are (HAL, hardwareabstraction layer). Una DLL es un archivo que se m apea dentro del espacio de direcciones de un proceso, de m odo que todas las funciones d e la DLL parezcan ser parte de ese proceso. Los nive-

22.3 Componentes del sistema

717

les superiores del kem el de W indow s XP dependen de las interfaces HAL en vez de depender del hardw are subyacente, lo que aum enta la portabilidad de W indow s XP. El nivel HAL m anipula el hardw are directam ente, aislando al resto de W indow s XP de las diferencias hardw are que puedan existir entre las diversas plataform as sobre las que se ejecuta. A unque W indow s 2000 sólo se vendía, por razones de m ercado, para plataform as Intel com ­ patibles con IA32, tam bién fue probado sobre plataform as A lpha de DEC e IA32 hasta poco antes del lanzam iento con el fin de garantizar la portabilidad. W indow s XP se ejecuta sobré los protesadores com patibles con las especificaciones IA 32 e íA64. M icrosoft es consciente de la importancia del desarrollo y las pruebas m ultiplataform a, ya que, desde el punto de vista práctico, el no m an­ tener la portabilidad equivale a renunciar a un m ercado que ciertam ente existe.

22.2.7 Soporte internacional W indow s XP tam bién está diseñado para su utilización en entornos in tern acio n ales y m ultina­ cion ales. Proporciona soporte para diferentes configuraciones nacionales m ediante la API de soporte de id iom a n acion al (NLS, national-language-support). La API NLS proporciona rutinas especializadas para dar form ato a las fechas, las horas y las unidades m onetarias de acuerdo con las diversas costum bres nacionales. Las com paraciones de cadenas de caracteres están especiali­ zadas, para tener en cuenta las diferencias entre conjuntos de caracteres. UNICODE es el conjunto nativo de caracteres de W indow s XP. Este sistem a operativo perm ite tam bién el uso del conjunto de caracteres ANSI, convirtiéndoles a caracteres UNICODE antes de m anipularlos (conversión de 8bits a 16-bits). Las cadenas de caracteres utilizadas por el sistem a se m antienen en archivos de recursos que pueden ser sustituidos fácilm ente para localizar el sistem a en diferentes idiomas. Pueden usarse concurrentem ente m últiples configuraciones locales, lo cual es im portante para personas y em presas que operen en entornos m ultilingües.

22.3 Componentes del sistema La arquitectura de W indow s XP es un sistem a de m ódulos organizado en niveles, como se m ues­ tra en la Figura 22.1. Los niveles principales son el nivel HAL, el kem el y el subsistem a ejecutivo, todos los cuales se ejecutan en modo protegido, junto con una colección de subsistem as y servi­ cios que se ejecutan en m odo usuario. Los subsistem as de m odo usuario pueden clasificarse en dos categorías: los subsistem as de entorno, que em ulan diferentes sistem as operativos y su bsiste­ m as de protección, que proporcionan funciones de seguridad. Una de las principales ventajas de este tipo de arquitectura es que las interacciones entre los distintos m ódulos resultan simples. En el resto de esta sección se describen estos niveles y subsistem as.

22.3.1 Nivel de abstracción hardware El nivel HAL es la capa de softw are que oculta las diferencias de tipo hardw are a ojos de los nive­ les superiores del sistem a operativo, con el fin de hacer que W indow s XP sea portable. El nivel HAL exporta una interfaz de m áquina virtual que es utilizada por el despachador del kem el, por el eje­ cutivo y por los controladores de dispositivos. Una de las ventajas de esta técnica es que sólo se necesita una versión de cada controlador de dispositivo; esa versión se podrá ejecutar sobre todas las plataform as hardw are sin necesitar portar el código del controlador. El nivel HAL también pro­ porciona soporte para el m ultiprocesam iento sim étrico. Los controladores de dispositivo m apean los dispositivos y acceden a ellos directam ente, pero los detalles adm inistrativos de m apeo de m em oria, de configuración de los buses de E /S , de configuración del m ecanism os DMA y de tratam iento de las características de cada placa m adre son proporcionados por la interfaces HAL.

22.3.2 Kernel El kem el de W indow s XP proporciona la base para el ejecutivo y para los distintos subsistemas. El kernel perm anece cargado en m em oria y su ejecución nunca puede ser desalojada. Tiene cuatro

718

Capítulo 22 Windows XP

aplicaciones OS/2

Figura 22.1

aplicaciones Win32

applications POSIX

D iag ram a de bloques de W indows XP.

responsabilidades principales: planificación de hebras, tratam iento de interrupciones y excepcio­ nes, sincronización del procesador a bajo nivel y recuperación después de un fallo de alimenta­ ción. El kem el está orientado a objetos. U n tipo de objeto en W indow s 2000 es un tipo de dato defini­ do por el sistem a que tiene un conjunto de atributos (valores de datos) y un conjunto de métodos (por ejem plo, funciones u operaciones). Un objeto es una instancia de un tipo de objeto. El kem el lleva a cabo su trabajo utilizando un conjunto de objetos del kernel cuyos atributos alm acenan los datos del kernel y cuyos m étodos realizan las actividades del kernel. 22.3.2.1 D espachador del kernel El despachador del kem el proporciona la base para el ejecutivo y para los distintos subsiste­ mas. La m ayor parte del despachador nunca es descargada de m em oria por el m ecanismo de paginación y su ejecución nunca puede ser desalojada. Sus principales responsabilidades son la planificación de hebras, la im plem entación de prim itivas de sincronización, la gestión de temporizadores, las interrupciones softw are (llam adas a procedim ientos asincronas y diferidas) y el des­ pacho de excepciones. 22.3.2.2 H ebras y planificación Al igual que otros m uchos sistem as operativos m odernos, W indow s XP utiliza procesos y hebras para estructurar el código ejecutable. Los procesos tienen un espacio de direcciones de memoria virtual y una serie de inform aciones que se utilizan para inicializar cada hebra, como por ejemplo una prioridad base y una afinidad para uno o más procesadores. Cada proceso tiene una o maS hebras, cada una de las cuales es una unidad ejecutable que el kem el se encarga de despachar. Cada hebra tiene su propio estado de planificación, incluyendo su prioridad real, la afinidad de procesador y la inform ación de utilización de la CPU.

22.3 Componentes del sistema

719

Los seis posibles estados d e las hebras son: preparada, lista, en ejecución, en espera, en transi­ ción y term inada. El estado preparada indica que la hebra está esperando para ser ejecutada. En cada decisión de planificación, la hebra preparada de m ayor prioridad se pasa al estado de lista, lo que quiere decir que será la siguiente hebra que se ejecute. En un sistem a m ultiprocesador, cada proceso m antiene una hebra en el estado de lista. Una hebra estará en ejecu ció n cuando esté eje­ cutándose sobre un procesador. Esa hebra se ejecutará hasta que sea desalojada por una hebra de m ayor prioridad, hasta que term ine, hasta que finalice su tiem po de ejecución asignado (cuanto) o hasta que se bloquee en espera de un objeto del despachador, com o por ejem plo un suceso que señalice la term inación de una operación de E/S. Una hebra se encontrará en el estado de espera cuando esté esperando a que se señalice u n objeto del despachador. Una nueva hebra estará en el estado de tran sición cuando esté esperando a los recursos necesarios para su ejecución. U na hebra entrará en el estado de term in ad a cuando haya finalizado su ejecución. El despachador utiliza un esquem a de prioridades de 32 niveles para determ inar el orden de ejecución de las hebras. Las prioridades se dividen en dos clases: clase variable y clase de tiempo real. La clase variable contiene hebras cuyas prioridades van de 0 a 15, m ientras que la clase de tiempo real contiene hebras cuyas prioridades están com prendidas entre 16 y 31. El despachador utiliza una cola diferente para cada prioridad de planificación y recorre el conjunto de colas desde la prioridad m ás alta a la m ás baja hasta qu e encuentra una hebra que esté lista para ejecutarse. Si una hebra tiene una afinidad de procesador concreta pero el procesador no está disponible, el des­ pachador se la salta y continúa buscando una hebra preparada que sí que quiera ejecutarse en el procesador disponible. Si n o encuentra una hebra preparada, el despachador ejecuta una hebra especial denom inada hebra de inactividad. Cuando se agota el cuanto de tiem po de una hebra, la interrupción del reloj efectúa una llam a­ da a procedim iento diferida (DPC, deferred procedure cali) al procesador en la que se señaliza el final del cuanto, con el fin de volver a planificar el procesador. Si la hebra desalojada pertenece a la clase de prioridad variable, su prioridad se reduce. La prioridad no puede nunca reducirse por debajo de la prioridad base. Este m ecanism o de reducción de prioridad de la hebra tiende a lim i­ tar el consum o de CPU por parte de las hebras lim itadas por un procesador. Cuando una hebra de prioridad variable finaliza una operación de espera, el despachador aum enta su prioridad. El grado de aum ento dependerá del dispositivo por el que la hebra estuviera esperando, por ejem ­ plo, una hebra que estuviera esperando una operación de E /S de teclado obtendría un gran aumento de prioridad, m ientras que una hebra que estuviera esperando por una operación de disco obtendría sólo un aum ento de prioridad m oderado. Esta estrategia tiende a proporcionar buenos tiempo de respuesta a las hebras interactivas que utilicen un ratón y un sistem a de venta­ nas; tam bién perm ite que las hebras lim itadas por E /S m antengan ocupados a los dispositivos de E /S , al m ismo tiempo que se perm ite que la hebras lim itadas por procesador utilicen en segundo plano los ciclos de CPU que queden libres. Esta estrategia se em plea en diversos sistem as operati­ vos de tiempo com partido, incluyendo UNIX. Adem ás, la hebra asociada con la ventana GUI acti­ va del usuario recibe un aum ento de prioridad, con el fin de optim izar su tiem po de respuesta. Las decisiones de planificación se tom an cuando una hebra entra en el estado de preparada o de espera, cuando una hebra termina o cuando una aplicación m odifica la prioridad o la afinidad de procesador de una cierta hebra. Si una hebra de tiem po real con m ayor prioridad pasa a estar preparada m ientras se está ejecutando una hebra de m enor prioridad, esa hebra de m enor priori­ dad será desalojada. Este m ecanism o apropiativo proporciona a las hebras de tiempo real un acce­ so preferencial a la CPU en los m om entos en que esas hebras necesiten dicho acceso. Sin em bargo, W indows XP no es un sistem a operativo de tiem po real estricto, porque no garantiza que una hebra de ñem po real pueda com enzar a ejecutarse dentro de un límite de tiempo concreto. 22.3.2.3 Im p lem en tación de las prim itivas de sincronización Las estructuras de datos clave del sistem a operativo se gestionan como objetos, utilizando funcio­ nalidades com unes para la asignación, para el recuento de las referencias y para la seguridad. Los ob jeto s del despachador controlan el despacho y la sincronización dentro del sistem a. Ejemplos de estos objetos son los sucesos, los m utantes, los mútex, los semáforos, los procesos, las hebras y

J-

Capítulo 22 Windows XP

los tem porizadores. El o b jeto su ceso se utiliza para registrar un determ inado suceso y para sin­ cronizarlo con alguna acción. Los sucesos de notificación se encargan de señalizar a todas las hebras que estén en espera, m ientras que los sucesos de sincronización señalizan a una única hebra en espera. Los objetos m utantes proporcionan exclusión m utua en m odo kernel o en modo usuario, teniendo esa exclusión m utua aparejada la noción de propiedad. Los m útex, disponibles sólo en m od o kem el, proporcionan exclusión m utua libre dé interbloqueos. U n o b jeto semáforo actúa com o un contador o puerta para controlar el núm ero de hebras que acceden a un recurso. El o b jeto h eb ra es la entidad que se encarga de despachar el despachador del kem el y está asocia­ da con un o b jeto proceso, que encapsula un espacio de direcciones virtual. Los o b jeto s tem pori­ zadores se em plean para controlar el tiempo y para señalizar los fines de tem porización cuando las operaciones son m uy largas y es necesario interrum pirlas, o cuando se necesita planificar una actividad periódica. A m uchos de los objetos del despachador se puede acceder en m odo usuario, m ediante una operación de apertura que devuelve un descriptor. El código en m odo usuario sondea y/o espe­ ra a recibir los descriptores, para sincronizarse con otras hebras, así com o con el sistem a operati­ vo (véase la Sección 22.7.1). 22.3.2.4 In terru p ciones softw are: llam adas a p rocedim ientos asincronas y diferid as El despachador im plem enta dos tipos de interrupciones softw are: llam adas a procedimientos asincronas y llam adas a procedim ientos diferidas. Las llam adas a procedim ientos asincronas (APC, A synchronous procedure cali) interrum pen a una hebra en ejecución e invocan un procedi­ m iento. Las APC se usan para iniciar la ejecución de una nueva hebra, para term inar procesos y para notificar que se ha com pletado una operación de E /S asincrona. Las APC se ponen en cola para ser atendidas por hebras específicas y perm iten al sistem a ejecutar tanto código del sistema com o del usuario dentro del contexto de un proceso. Las llam adas a procedim ientos diferidas (DPC, deferred procedure cali) se utilizan para pospo­ ner el procesam iento de interrupciones. Después de tratar todos los procesos bloqueados por la interrupción de un dispositivo, la rutina de servicio de interrupción (ISR, interrupt Service routine) planifica el procesam iento restante poniendo en cola una DPC. El despachador planifica las interrupciones softw are con una prioridad m enor que las interrupciones de dispositivo, por lo que las llam adas DPC no bloqueen otras rutinas ISR. Adem ás de diferir el procesam iento de las inte­ rrupciones de dispositivos, el despachador utiliza las llam adas DPC para procesar los sucesos de caducidad de los tem porizadores y para desalojar la ejecución de una hebra al final de su cuanto de planificación. La ejecución de las llam adas DPC impide que las hebras sean planificadas para su ejecución en el procesador actual y tam bién evita que las APC señalicen la term inación de las operaciones de E /S . Esto se hace para que las rutinas DPC no tarden dem asiado tiem po en com pletarse. Como alternativa, el despachador m antiene un conjunto de hebras de trabajo; las rutinas ISR y las llama­ das DPC ponen en cola una serie de tareas para que las ejecuten las hebras de trabajo. Las rutinas DPC están restringidas, de m odo que no puedan provocar fallos de página, invocar servicios del sistem a o realizar cualquier otra acción que pudiera resultar en un intento de bloquear la ejecu­ ción de un objeto del despachador. A diferencia de las APC, las rutinas DPC no realizan ningún tipo de suposición acerca del contexto del proceso que está ejecutando el procesador. 22.3.2.5

E xcep cion es e in terru p cion es

El despachador del kem el tam bién proporciona rutinas para tratar las excepciones e interrupcio­ nes generadas por el hardw are o por el software. W indows XP define diversas' excepciones inde­ pendientes de la arquitectura, entre las que se incluyen: • Violación de acceso a m em oria. • D esbordam iento de entero. • D esbordam iento o subdesbordam iento de coma flotante. >

22,3 Componentes del sistema

721

• División entera por cero. • División en com a flotante por cero. • Instrucción ilegal. • A lineación incorrecta de los datos. • Instrucción privilegiada. • Error de lectura de página. • Violación de acceso. • Cuota de archivo de paginación excedida. • Punto de ruptura del depurador. • Ejecución paso a paso del depurador. Las rutinas de tratam iento se encargan de gestionar excepciones sim ples. La gestión m ás sofisti­ cada de las excepciones la lleva a cabo el despachador de excepciones del kem el. El despachador de excepciones crea un registro de excepción que contiene la razón de la excepción y localiza una rutina de tratam iento de excepciones apropiada. Cuando se produce una excepción en m odo kem el, el despachador de excepciones sim plem en­ te invoca una rutina para localizar la rutina de tratam iento correspondiente. Si no se encuentra una rutina de tratam iento apropiada se produce un error del sistem a fatal y se presenta al usua­ rio la “pantalla azul” que indica que el sistem a ha fallado. El tratam iento de las excepciones es m ás com plejo para los procesos en m odo usuario, porque los subsistem as de entorno (com o por ejem plo el sistema POSIX) activan un puerto de depurador y un puerto de excepciones para cada proceso que crean. Si hay registrado un puerto de depura­ dor, la rutina de tratam iento de la excepción envía la excepción a dicho puerto. Si-no se encuen­ tra el puerto del depurador o ese puerto no perm ite tratar la excepción, el despachador trata de localizar una rutina de tratam iento de excepciones apropiada. Si no encuentra dicha rutina, se invoca de nuevo el depurador para capturar el error con vistas a su depuración. Si no hay ningún depurador ejecutándose, se envía el m ensaje al puerto de excepciones del proceso, para propor­ cionar al subsistem a de entorno una oportunidad de traducir dicha excepción. Por ejem plo, el entorno POSIX traduce los m ensajes de excepción W indow s XP a señales POSIX antes de enviarlas a la hebra que ha provocado la excepción. Finalm ente, si ninguna de las otras alternativas funcio­ na, el kem el se lim ita a term inar sim plem ente el proceso que contiene la hebra que provocó la excepción. El despachador de interrupciones del kem el se encarga de gestionar las interrupciones, llam an­ do a una rutina de servicio de interrupción (ISR) sum inistrada por un controlador de dispositivo, o a una rutina de tratam iento del kem el. La interrupción se representa m ediante un objeto inte­ rrupción que contiene toda la inform ación necesaria para gestionarla. U tilizar un objeto interrup­ ción hace que resulte sencillo asociar las rutinas de servicio con su interrupción correspondiente sin tener que acceder directam ente al hardw are de interrupciones. Las diferentes arquitecturas de procesador, com o por ejem plo Intel y A lpha de DEC tienen dife­ rentes tipos y núm eros de interrupciones. Para facilitar la portabilidad, el despachador de inte­ rrupciones hace corresponder las interrupciones hardw are con un conjunto estándar de interrupciones predefinidas. Cada interrupción tiene una prioridad asociada y el servicio de las interrupciones se realiza según el orden de prioridad. En W indow s XP hay 32 niveles de solicitud de interrupción (IRQL, interrupt request level). Ocho de ellos están reservados para ser utilizados por el kem el; los 24 niveles restantes representan interrupciones hardw are que tienen lugar a tra­ vés del nivel HAL (aunque la m ayor parte de los sistem as IA 32 sólo utilizan 16). En la Figura 22.2 se definen las interrupciones de W indows XP. El kem el utiliza una tab la de despacho de interru pciones para asociar cada nivel de interrup­ ción con una rutina de servicio. En una com putadora m ulciprocesador, W indow s XP m antiene una tabla de despacho de interrupciones separada para ca d a procesador, y el IRQL dé cada procesador

722

Capítulo 22 Windows XP

Figura 2 2 .2 Niveles de solicitud de interrupción de Windows XP. puede configurarse de m anera independiente con el fin de enm ascarar las interrupciones. Todas las interrupciones con un nivel igual o inferior al IRQL de un procesador estarán bloqueadas hasta que el IRQL sea reducido por una hebra del nivel del kem el o por una rutina ISR en el momento de volver del procesam iento de una interrupción. W indow s XP aprovecha esta propiedad y utiliza las interrupciones softw are para realizar llam adas APC y DPC, para realizar funciones del sistema tales com o la sincronización de hebras con la term inación de las operaciones E /S , para comenzar las tareas de despacho de hebras y para gestionar los tem porizadores.

22.3.3 Executive El sistem a ejecutivo (Executive) de W indow s XP proporciona un conjunto de servicios utilizado por todos los subsistem as de entorno. Los servicios se agrupan del siguiente m odo: gestor de obje­ tos, gestor de m em oria virtual, gestor de procesos, funcionalidad de llam ada a procedimientos lo cales, gestor de E /S , gestor de caché, m onitor de referencia de seguridad, gestores plug-and-play y de seguridad, registro y arranque.

22.3.3.1

G esto r de o b jeto s

Para gestionar las entidades de modo kernel, W indow s XP utiliza un conjunto genérico de interfa­ ces que son m anipuladas por los program as en modo usuario. W indow s XP denom ina a estas enti­ dades objetos, y el com ponente del program a ejecutivo que los m anipula es el gestor de objetos. Cada proceso tiene una tabla de objetos que contiene entradas utilizadas para controlar los obje­ tos usados por el proceso. El código en m odo usuario accede a estos objetos em pleando un valor opaco denom inado descriptor que es devuelto por m uchas de las funciones de diversas API (inter­ faces de program ación de aplicaciones). Los descriptores de objetos tam bién pueden crearse du plicand o un descriptor existente del m ism o proceso o de otro proceso distinto. Como ejemplo de objetos podríam os citar los sem áforos, los m útex, los sucesos, los procesos y las hebras; todos ellos son objetos del despachador. Las hebras pueden bloquearse en el despachador del kernel, en espera de qu e alguno de estos objetos sea señalizado. Las API de los procesos, de las hebras y de la m em oria virtual utilizan los descriptores de los procesos y hebras para identificar el proceso o la hebra sobre la que hay que actuar. O tros ejem plos de objetos serían los archivos, las secciones, los puertos y diversos objetos de E /S internos. Los objetos archivo se em plean para mantener el estado de apertura de los archivos y dispositivos. Las secciones se utilizan para mapear archivos. Los arch iv os abiertos se describen en térm inos de los objetos archivo. Los puntos terminales de com u n icación local se im plem entan com o objetos puerto. El g e sto r de objetos m antiene el espacio interno de nom bres de W indow s XP. A diferencia de UNIX, qu e asocia el espacio de nom bres del sistem a con el sistem a de archivos, W indow s XP utili­ za un e sp a cio de nom b res ab stracto y con ecta los sistem as de archivos com o dispositivos. J-

22.3 Componentes del sistema

723

El gestor de objetos proporciona interfaces para definir tanto tipos de objetos como instancias de objetos, traduciendo los nom bres a objetos, m anteniendo el espacio de nombres abstracto (m ediante directorios internos y enlaces sim bólicos) y encargándose de gestionar la creación y eli­ m inación de objetos. Los objetos se suelen gestionar usando contadores de referencias dentro del código en m odo protegido y descriptores dentro del código en modo usuario. Sin embargo, algu­ nos com ponentes'de m odo kem el utilizan las m ism as API que el código en m odo usuario, así que em plean descriptores para m anipular los objetos. Si es necesario que un descriptor persista una vez que ha term inado el proceso actual, se puede m arcar com o descriptor del kernel y alm acenar en la tabla de objetos del proceso del sistem a. El espacio de nom bres abstracto no persiste entre un arranque del sistem a y otro, sino que se crea a partir de la inform ación de configuración alm a­ cenada en el registro del sistem a, a partir de los datos recopilados durante la fase de descubri­ m iento de dispositivos plug-and-play y a partir de las operaciones de creación de objetos por parte de los com ponentes del sistem a. El sistem a ejecutivo de W indow s XP perm ite proporcionar un nom bre a cada objeto. Un pro­ ceso puede crear un proceso nom inado, m ientras que un segundo proceso puede abrir un des­ criptor de dicho objeto y com partirlo con el prim er proceso. Los procesos también pueden com partir objetos duplicando los descriptores, en cuyo caso no es necesario proporcionar un nom ­ bre a los objetos. Los nom bres pueden ser perm anentes o tem porales. U n nom bre perm anente representa una entidad, com o por ejem plo una unidad de disco, que sigue existiendo incluso aunque no haya nin­ gún proceso accediendo a la m ism a. P or el contrario, un nom bre temporal sólo existe m ientras un proceso posea un descriptor de dicho objeto. Los nom bres de los objetos están estructurados com o los nom bres de ruta de los archivos en MS-DOS y UNIX. Los directorios del espacio de nom bres se representan m ediante o bjetos d irecto­ rio que contienen los nom bres de todos los objetos del directorio. El espacio de nom bres de obje­ tos se am plía m ediante la adición de objetos dispositivo que representan volúm enes que contienen sistem as de archivos. Los objetos se m anipulan m ediante un conjunto de funciones virtuales, para las que se propor­ cionan im plem entaciones para cada tipo de objeto: c r e a t e ( ) , o p en ( ) , c i ó s e í ), d e l e t e ( ) , q u e ry _ n a m e ( ) , p a r s e ( ) y s e c u r i t y (). Conviene hacer algunas aclaraciones sobre las tres últimas funciones: • q u e ry _ n a m e () se invoca cuando una hebra tiene una referencia a un objeto, pero quiere conocer el nom bre del objeto. • p a r s e () es utilizada por el gestor de objetos para buscar un objeto una vez que se conoce su nombre. • s e c u r i t y () se invoca para realizar com probaciones de seguridad en todas las operacio­ nes sobre objetos, com o por ejem plo un procesador abre o cierra un objeto, realiza m odifi­ caciones en el descriptor de seguridad o duplica un m anejador de un objeto. El procedim iento de análisis sintáctico (parse) se utiliza para am pliar el espacio de nom bres abs­ tracto con el fin de incluir archivos. La traducción de un nom bre de ruta a un objeto archivo com ienza en la raíz del espacio de nom bres abstracto. Los com ponentes del nombre de ruta están separados m ediante caracteres de barra invertida ('\') en lugar de los caracteres de barra inclinada ('/') utilizados en UNIX. Durante el proceso de traducción, se busca cada componente en el direc­ torio actual de análisis sintáctico del espacio de nom bres. Los nodos internos dentro del espacio de nom bres pueden ser directorios o enlaces sim bólicos. Si se encuentra un objeto' Hoja y no queda ya ningún com ponente en el nombre de ruta, se devuelve el objeto hoja. En caso contrario, se invo­ ca el procedim iento de análisis sintáctico del objeto hoja, pasándole el resto del hom bre de ruta. Los procedim ientos de análisis sintáctico sólo se usan con un pequeño número de objetos per­ tenecientes a la interfaz de W indows, al gestor de configuración (registro) y, especialm ente, a los objetos dispositivos que representan a los sistem as de archivos. El procedim iento de análisis sintáctico para el tipo de objeto dispositivo asigna un objeto archi­ vo e inicia una operación de E/S de apertura o de creación sobre el sistema de archivos. Si la ope­ ración tiene éxito, se rellenan los cam pos del objeto archivo para describir ei archivo. J-

Capítulo 22 Windows XP

En resum en, el nom bre de ruta de un archivo se em plea para recorrer el espacio de nombres del gestor de objetos, traduciendo el nom bre de ruta absoluto original a una pareja (objeto dispo­ sitivo, nom bre de ruta relativo). Esta pareja se pasa entonces al sistem a de archivos a través del gestor de E /S , que se encarga de proporcionar el objeto archivo. El propio objeto archivo no tiene ningún nom bre, efectuándose las referencias al m ism o a través de un descriptor. Los sistem as de archivos UNIX tienen en laces sim b ó lico s que perm iten utilizar m últiples alias para un m ism o archivo. El ob jeto e n lace sim b ó lico im plem entado por el gestor de objetos de W indow s XP se utiliza dentro del espacio de nom bres abstracto, no para proporcionar alias de archivos dentro de un sistem a de archivos. A ún así, los enlaces sim bólicos resultan m uy útiles; se em plean para organizar el espacio de nom bres, de form a sim ilar a la organización del directorio / d e v ic e s en UNIX. Tam bién se usan para asignar nom bres de unidad a las letras de unidad estándar de MS-DOS. Las letras de unidad son enlaces sim bólicos que pueden reasignarse a volun­ tad del usuario o del adm inistrador. Las letras de unidad son uno de los puntos en los que el espacio de nom bres abstracto de W indows XP no tiene un carácter global. C ada usuario que inicia una sesión tiene su propio con­ junto de letras de unidad para evitar que los usuarios se interfieran entre sí. Por contraste, las sesiones de servidor de term inales com parten todos los procesos dentro de una sesión. Los obje­ tos B aseN am ed O b j e c t s contienen los objetos con nom bre creados por la m ayor parte de las apli­ caciones. Aunque el espacio de nom bres no es directam ente visible a través de una red, el método p a r s e () del gestor de objetos se utiliza com o ayuda para acceder a un objeto con nom bre alma­ cenado en otro sistem a. C uando un proceso intenta abrir un objeto que reside en una computado­ ra rem ota, el gestor de objetos llam a al m étodo de análisis sintáctico p a r s e para el objeto dispositivo correspondiente a un redirector de red. Esto provoca una operación de E /S que acce- de al archivo a través de la red. í Los objetos son instancias de un tip o de o b jeto. El tipo de objeto especifica cóm o hay que asig­ nar las instancias, las definiciones de los cam pos de datos y la im plem entación del conjunto están­ dar de funciones virtuales utilizadas para todos los objetos. Estas funciones implementan operaciones tales com o la asignación de nom bres a los objetos, el cierre y borrado de objetos y la aplicación de m edidas de seguridad. El gestor de objetos m antiene dos contadores para cada objeto. El contador de punteros es el núm ero de referencias diferentes realizadas a un objeto. El código en m odo protegido que hace referencia a los objetos debe m antener una referencia al objeto con el fin de asegurar que el obje­ to no será borrado m ientras esté en uso. Por su parte, el contador de descriptores representa el núm ero de entradas de la tabla de descriptores que hacen referencia a un objeto. Cada descriptor está tam bién reflejado en el contador de referencias. Cuando se cierra un descriptor de un objeto, se invoca la rutina de cierre de ese objeto. En el caso de los objetos archivo, esta llam ada hace que el gestor de E /S realice una operación de lim­ pieza en el m om ento de cerrar el últim o descriptor. Esa operación de lim pieza indica al sistema de archivos que el archivo ya no está siendo accedido en m odo usuario, por lo que se pueden eli­ m inar las restricciones de com partición, los bloqueos de rangos y otras inform aciones de estado específicas de la correspondiente rutina de apertura. Cada cierre de un descriptor elim ina una referencia del contador de punteros, pero los compo­ nentes internos del sistem a pueden contener referencias adicionales. Cuando se elim ina la última referencia, se invoca el procedim iento de borrado del objeto. U tilizando de nuevo los objetos archivo com o ejem plo, el procedim iento de borrado haría que el gestor de E /S enviara al sistema de archivos una operación de cierre relativa al objeto archivo. Esto hace que el sistem a de archi­ vos elim ine la asignación de las estructuras de datos internas que hubieran sido asignadas para el objeto archivo. Después de com pletarse el procedim iento de borrado para un objeto tem poral, el objeto se borra de m emoria. Los objetos pueden hacerse perm anentes (al menos en lo que respecta al arran­ que actual del sistem a) pidiendo al gestor de objetos que defina una referencia adicional al obje­ to. De este modo, los objetos perm anentes no se borran incluso cuando se elim ine la última referencia situada fuera del gestor de objetos. Cuando se vuelve a hacer tem poral un objeto per-

22.3 Componentes del sistema

725

m o rien te, el gestor de objetos elim ina esa referencia adicional. Si esa referencia adicional era la ü lr m a . se borra el objeto. Los objetos perm anentes no resultan m uy com unes y se usan principal~ e r .r e p ara los dispositivos, para el establecim iento de correspondencias entre unidades y letras de u n id a d y para los objetos directorio y objetos de enlace sim bólico. L a tarea del gestor de objetos consiste en supervisar la utilización de todos los objetos gestio­ n a d o s. C u an d o una hebra quiere utilizar un objetó, invoca el m étodo o p e n () del gestor para obte­ n e r u n a referencia al objeto. Si el objeto está siendo abierto desde una API en m odo usuario, la re fe re n cia se inserta en la tabla de objetos del proceso y se devuelve un descriptor. L n proceso obtiene un descriptor creando un objeto, abriendo un objeto existente, recibiendo ur. d escrip to r duplicado de otro proceso o heredando un descriptor de un p ro ceso p ad re, de forma sim ilar a la m anera en que un proceso UNIX obtiene un descriptor de archivo. Estos descrip­ to re s se alm acenan en la tab la d e o b jeto s del p roceso. Cada entrada de la tabla de objetos contie­ ne ios derechos de acceso al objeto e indica si el descriptor debe ser heredado por los p rocesos h i j o . C u an d o un proceso term ina, W indow s XP cierra autom áticam ente todos los descriptores a b ie rto s por el proceso. L o s d e scrip to re s son una interfaz estandarizada para todos los tipos de objetos. Al igual que ur. d escrip to r de archivo en UNIX, un descriptor de objeto es un identificador unívoco para un pro­ ce so y qu e confiere a éste la capacidad de acceder y m anipular un recurso del sistem a. Los descrm to re s se pueden duplicar dentro de un proceso o entre un proceso y otro. Este últim o caso se u n iiz a cuand o se crean procesos hijo y cuando se im plem entan contextos de ejecución fuera del p ro ce so . P u esto que el gestor de objetos es la única entidad que genera descriptores de objetos, repre­ s e n ta el lu gar natural en el que realizar las com probaciones de seguridad. El gestor de objetos co m p ru e b a si un proceso tiene el derecho de acceder a un objeto en el m om ento en que el proce­ s o trata de abrir dicho objeto. El gestor de objetos tam bién se encarga de verificar que se respeten la s cu otas, com o por ejem plo la cantidad m áxim a de m em oria que un proceso puede utilizar; para ¿L o . atribu ye al proceso la m em oria ocupada por todos los objetos a los que hace referencia e im p ed irá que se le asigne m ás m em oria cuando el proceso haya excedido la cuota asignada. C uando el proceso de inicio de sesión autentica a un usuario, se asocia un testigo de acceso con el p ro ceso del usuario. Ese testigo de acceso contiene inform ación tal com o el ID de seguridad, los ir> de grupo, los privilegios, el grupo principal y la lista predeterm inada de control de acceso. L o s servicios y objetos a los que el usuario puede acceder están determ inados por estos atributos. El testigo que controla el acceso está asociado con la hebra que efectúa el acceso. Normalmente, n o se utiliza un testigo de hebra, em pleándose de m anera predeterm inada el testigo del proceso, ñ e ro los servicios necesitan a m enudo ejecutar código por cuenta de sus clientes. Por ello, W in d o w s XP perm ite que las hebras adopten tem poralm ente una personalidad, utilizando el tesn g o de un cliente. De este m odo, el testigo de la hebra no tiene p o r qué coincidir necesariam ente co n el testigo del proceso. E n W indow s XP, cada objeto está protegido m ediante una lista de control de acceso que con­ tie n e los ID de seguridad y los derechos de acceso concedidos. Cuando una hebra trata de acceder a u n objeto, el sistem a com para el ID de seguridad del testigo de acceso de la hebra con la lista de co n tro l de acceso del objeto para determ inar si ese acceso debe perm itirse. La com probación se efectú a sólo en el m om ento de abrir un objeto, por lo que no resulta posible denegar el acceso des­ p u és de efectuada la apertura. Los com ponentes del sistem a operativo que se ejecutan en modo cerne/ puentean estas com probaciones de acceso, ya que se asum e que el código en modo kernel es de confianza. Por tanto, el código en modo kem el puede tratar de evitar las vulnerabilidades de segu rid ad , com o por ejem plo dejar inhabilitadas las com probaciones m ientras se crea un descrip­ to r accesible en modo usuario dentro de un proceso que no sea de confianza. G eneralm ente, el creador del objeto determ ina la lista de control de acceso al m ismo. Si no se su m in istra una lista explícitam ente, la rutina de apertura del tipo de objeto puede definir una lista predeterm inada, o bien puede obtenerse una lista predeterm inada a partir del objeto que repre­ senta el testigo de acceso del usuario. El testigo de acceso tiene un cam po que controla la auditoría de los accesos al objeto. Las ope­ racion es auditadas se registran en el registro de seguridad del sistem a junto con una identifica­

76

Capítulo 22 Windows XP

ción del usuario. U n adm inistrador puede m onitorizar este registro para descubrir los intentos de irrupción en el sistem a o los intentos de acceder a objetos protegidos. 22.3.3.2 G estor de m em oria virtu al El com ponente ejecutivo que gestiona el espacio virtual de direcciones, la asignación de memoria física y la paginación es el g estor de m em oria virtu al (VM, virtual m em ory). El diseño del gestor VM asum e que el hardw are subyacente da soporte a la traducción de direcciones virtuales a físi­ cas, un m ecanism o de paginación y un m ecanism o de coherencia transparente de caché en los sis­ tem as m ultiprocesador, adem ás de perm itir que se asignen m últiples entradas de la tabla de páginas al m ism o m arco de página físico. El gestor VM en W indow s XP utiliza un esquem a de ges­ tión basado en página con un tam año de página de 4 KB en los procesadores com patibles con IA32 y de 8 KB en las m áquinas IA 64. Las páginas de datos asignadas a un proceso que no se encuen­ tran en m em oria física se alm acenan en los archivos de pág in ación en disco o se m apean directa­ m ente a un archivo norm al en un sistem a de archivos local o rem oto. Las páginas tam bién pueden m arcarse para rellenarse con ceros bajo dem anda, lo que escribe una serie de ceros en la página antes de asignarla, borrando así el contenido anterior. En los procesadores IA32, cada proceso tiene un espacio virtual de direcciones de 4 GB. Los 2 G B superiores son fundam entalm ente idénticos para todos los procesos y los utiliza W indows XP en m odo kernel para acceder al código y a las estructuras de datos del sistem a operativo. Las áreas clave de la región en m odo kernel que no son idénticas para todos los proceso son el autom apa de ta b la de páginas, el h ip eresp acio y el espacio de sesión . El hardw are hace referencia a las tablas de páginas de un proceso utilizando los núm eros de m arco físico de página. El gestor VM hace corresponder las tablas de páginas con una única región de 4 M B dentro del espacio de direccio­ nes del proceso, de m odo que se accede a ellas m ediante direcciones virtuales. El hiperespacio m apea la inform ación del conjunto de trabajo actual del proceso sobre el espacio de direcciones de modo kernel. El espacio de sesión se utiliza para com partir los controladores de W in32 y otros controladores específicos de la sesión entre todos los procesos, dentro de una m ism a sesión de servidor de term inales, en lugar de para todos los procesos del sistem a. Los 2 GB inferiores son específicos de cada proceso y a ellos pueden acceder tanto las hebras de m odo kem el com o las de m odo usuario. D eterm inadas configuraciones de W indow s XP sólo reservan 1 G B para el uso del sistem a opera­ tivo, perm itiendo a los procesos em plear un espacio de direcciones de 3 GB. Ejecutar el sistem a en el m odo 3 GB reduce drásticam ente el alm acenam iento de datos en caché dentro del kem el. Sin em bargo, para las aplicaciones de gran envergadura que gestionan su propia E /S , com o por ejem­ plo las bases de datos SQL, esta pérdida de tam año de caché se ve com pensada por la ventaja de disponer de un espacio de direcciones en m odo usuario de m ayor tamaño El gestor VM de W indow s XP utiliza un proceso en dos pasos para asignar la m em oria al usua­ rio. El prim er paso reserva una parte del espacio virtual de direcciones del proceso. El segundo paso confirm a la asignación, asignando espacio de m em oria virtual (m em oria física o espacio en los archivos de paginación). W indow s XP limita la cantidad de espacio de m em oria virtual que un proceso consum e, por el procedim iento de im poner una cuota m áxim a que restringe la memoria confirm ada. Los procesos liberan la m em oria que ya no utilizan con el fin de liberar m em oria vir­ tual para que la puedan utilizar otros procesos. Las API utilizadas para reservar direcciones vir­ tuales y para confirm ar m em oria virtual tom an com o parám etro un descriptor de un objeto proceso. Esto perm ite que un proceso controle la m em oria virtual del otro. Los subsistem as de entorno gestionan la m em oria de sus procesos cliente de esta m anera. Por razones de rendim iento, el gestor VM perm ite que un proceso privilegiado bloquee una serie de páginas seleccionadas en la m em oria física, garantizando así que esas páginas no descar­ guen al archivo de paginación. Los procesos pueden tam bién asignar m em oria física y luego m apear regiones de la m ism a dentro de su espacio virtual de direcciones. Los procesadores IA32 con extensión de direcciones físicas (PAE, physicai address extensión) pueden tener hasta 64 GB de m em oria física dentro de un m ism o sistema. Esta m em oria no puede m apearse de una sola vez dentro del espacio de direcciones de un proceso, pero W indow s XP hace que se pueda acceder a

22.3 Componentes del sistema

727

ella utilizando las API de extensión de ventanas de direcciones (AWE, address window ing exten­ sión), que asignan m em oria física y luego m apean regiones de direcciones virtuales pertenecien­ tes al espacio de direcciones del proceso sobre parte de la m em oria física. La funcionalidad AWE es utilizada principalm ente por aplicaciones de gran envergadura, com o la base de datos de SQL. W indow s XP im plem enta la m em oria com partida definiendo lo que se denom ina un o b jeto sección . Después de obtener un descriptor de un objeto sección, los procesos m apean la parte de m em oria que necesitan dentro de su espacio de direcciones. Cada una de esas partes se denom i­ na vista. U n proceso puede redefinir su vista de u n objeto con el fin de acceder al objeto com ple­ to, pasando de una región a otra. U n proceso puede controlar de diferentes form as el uso de u n objeto sección de memoria com ­ partida. El tam año m áxim o de una sección puede estar acotado. Asim ism o, la sección puede estar respaldada por espacio de disco dentro del archivo de paginación del sistema o dentro de un archivo norm al (lo que se denom inaría archivo m apeado en m em oria). Las secciones pueden estar basadas, lo que quiere decir que la sección aparece en la m ism a dirección virtual para todos los procesos que quieren acceder a ella. Finalm ente, la protección de memoria de las páginas com ­ ponentes de la sección puede configurarse com o de sólo lectura, de lectura-escritura, de lecturaescritura-ejecución, de sólo ejecución, sin acceso o de copia durante la escritura. Conviene explicar estos dos últim os m odos de configurar la protección: • U na página sin acceso genera una excepción cad a vez que se intenta acceder a ella; esa excep­ ción se utiliza, por ejem plo, para com probar si un program a erróneo está tratando de reali­ zar una iteración m ás allá del final de una m atriz. Tanto el asignador de m emoria en m odo usuario com o el asignador especial del kem el utilizado por el verificador de dispositivos pueden configurarse para m apear cada asignación al final de una página que esté seguida por otra página sin acceso, con el fin de detectar los desbordam ientos de búfer. • El m ecanism o de copia durante la escritura m ejora la eficiencia del uso de memoria física por parte del gestor VM. Cuando dos procesos quieren tener copias independientes de un obje­ to, el gestor VM coloca una única copia com partida en m em oria virtual y activa la propie­ dad de copia durante la escritura para esa región de m em oria. Si uno de los procesos trata de m odificar los datos contenidos en una página de copia durante la escritura, el gestor VM hace una copia privada de la página para ese proceso. La traducción de direcciones virtuales en W indow s XP utiliza una tabla de página m ultinivel. Para los procesadores IA 32 que no tengan habilitada la extensión de direcciones físicas, cada pro­ ceso tiene un directorio de páginas que contiene 1.024 entradas de directorio de páginas (PDE, page-directory entry), cada una de las cuales tiene un tam año de 4 bytes. Cada PDE apunta a una tab la de págin as que contiene 1.024 entradas de ta b la de páginas (PTE, page-table entry), cada una de las cuales tiene tam bién 4 bytes. Cada PTE apunta a un m arco de páginas de 4 KB en la m em oria física. El tam año total de todas las tablas de página para un proceso es de 4 MB, por lo que el gestor VM descarga las tablas individuales a disco cada vez que sea necesario, utilizando el m ecanism o de paginación. En la Figura 22.3 se m uestra un diagram a de esta estructura, El hardw are hace referencia al directorio de páginas y a las tablas de páginas m ediante sus direcciones físicas. Para m ejorar el rendim iento, el gestor VM autom apea el directorio de páginas y las tablas de página sobre una región de 4 M B de direcciones virtuales. El automapa perm ite que el gestor VM traduzca una dirección virtual a la correspondiente PDE o PTE sin necesidad de acce­ sos a m em oria adicionales. C uando se cam bia el contexto de un proceso, sólo se necesita m odifi­ car una única entrada del directorio de páginas, con el fin de hacerla corresponder con las nuevas tablas de páginas del proceso. Por diversas razones, el hardw are requiere que cada directorio de páginas o tabla de páginas ocupe una única página. Por tanto, el núm ero de entradas PDE o PTE que caben en una página determ ina el m odo en que se traducen las direcciones virtuales. Vam os a describir a continuación la m anera de traducir las direcciones virtuales a direcciones físicas en los procesadores com patibles con IA 32 (que no tengan habilitada la extensión PAE). Un cam po de 10 bits perm ite representar todos los valores de 0 a 1.023. Por tanto, un valor de 10 bits puede seleccionar cualquier entrada del directorio de páginas o de una tabla de páginas. Esta propiedad se em plea cuando se traduce un puntero de dirección virtual a una dirección de byte

728

Capítulo 22 Windows XP

página d e4K

página d e4K

página de4K

Figura 22.3

página de 4K

Disposición de las tablas de páginas.

dentro de la m em oria física. U na dirección virtual de m em oria de 32 bits se divide en tres valores, com o se m uestra en la Figura 22.4. Los prim eros 10 bits de la dirección virtual se utilizan como índice para acceder al directorio de páginas. Esta dirección selecciona una entrada del directorio de páginas (PDE), que contiene el m arco de página físico de una tabla de páginas. La unidad de gestión de m em oria (MMU) utiliza los siguientes 10 bits de la dirección virtual para seleccionar una PTE de la tabla de páginas. La entrada PTE especifica un m arco de página dentro de la memoria física. Los restantes 12 bits de la dirección virtual son el desplazam iento correspondiente a un byte específico dentro del marco de página. La MMU crea un puntero al byte específico de m em oria físi­ ca concatenando los 20 bits de la PTE con los 12 bits inferiores de la dirección virtual. De este m odo, la PTE de 32 bits dispone de 12 bits para describir el estado de la página física. El hardwa­ re IA32 reserva 3 de esos bits para su uso por el sistem a operativo, m ientras que los restantes bits especifican si se ha accedido a la página o se ha escrito en ella, los atributos de caché, el modo de acceso, si se trata de una página global y si la PTE es válida. Los procesadores IA32 que tengan habilitada la extensión PAE utilizan entradas PDE y PTE de 64 bits para representar el cam po del núm ero de m arco de página, que tiene un tam año mayor de 24 bits. Por esto, los directorios de página de segundo nivel y las tablas de páginas contienen sólo 512 entradas PDE y PTE, respectivam ente. Para proporcionar 4 GB de espacio virtual de direc­ ciones hace falta un nivel adicional de directorio de páginas que contenga cuatro entradas PDE. La traducción de direcciones virtuales de 32 bits utiliza 2 bits com o índice para el directorio de nivel superior y 9 bits para los directorios de páginas segundo nivel y para las tablas de páginas. Para evitar tener que traducir todas las direcciones virtuales buscando las entradas PDE y PTE, los procesadores em plean un bú fer de traducción directa (TLB, translation-lookaside buffer), que contiene una caché de m em oria asociativa que asigna páginas virtuales a entradas PTE. A diferen­ cia de la arquitectura IA32, en la que el TLB es m antenido por la M M U hardware, la arquitectura 31

o

% fe

PDE ■ ?* " • ¡ V s i £&

.

m

4 m 1m A mp m PIE P m FH St -'J m i fe#

desplazam ientodepágina

a

Figura 22.4 Traducción de direcciones virtuales a físicas en la arquitectura IA32.

22.3 Componentes del sistema

729

IA 64 invoca una rutina de interrupción softw are para poder realizar las traducciones que no se pueden llevar a cabo a p artir del contenido del TLB. Esto proporciona flexibilidad al gestor VM a la hora de elegir las estructuras de datos que haya que utilizar. En W indow s XP, se selecciona una estructura en árbol de tres niveles para traducir las direcciones virtuales de m odo usuario en la especificación IA64. En los procesadores LA64, el tam año de página es de 8 KB, pero las entradas PTE ocupan 64 bits, por lo que cada página segu irá conteniendo sólo 1.024 (lo que equivale a 10 bits) entradas PDE o PTE. Por tanto, con 10 bits p ara la PDE de nivel superior, 10 bits para el segundo nivel, 10 bits para la tabla de páginas y 13 bits de desplazam iento de página, la parte del usuario del espacio virtual de direcciones de un proceso en W indow s XP sobre arquitectura IA64 es de 8 TB (lo que equivale a 43 bits). La lim itación de 8 TB en la versión actual de W indow s XP es m ás restrictiva que las capa­ cidades del procesador IA 64, pero representa un com prom iso entre el núm ero de referencias de m em oria requeridas para gestionar los fallos de TLB y el tam año del espacio de direcciones sopor­ tado en m odo usuario. Una página física puede encontrarse en uno de seis posibles estados: válida, Ubre, borrada, m odificada, reserva, corrupta o en transición. • Una página válida es aquella que está siendo usada por un proceso activo. • U na página líbre es u na página que no está referenciada por una entrada PTE. • U na página borrada es una página libre que ha sido rellenada de ceros y está lista para ser inm ediatam ente utilizada con el fin de satisfacer fallos de relleno de ceros bajo dem anda. • U na página m odificada es aquella en la que ha escrito u n proceso y debe enviarse a disco antes de asignarla a otro proceso. • U na página de reserva es una copia de inform ación que ya está alm acenada en disco. Las páginas de reserva pueden ser páginas que no hayan sido m odificadas, páginas m odifica­ das que ya hayan sido escritas en el disco o páginas que hayan sido extraídas de m anera anticipada para aprovechar la característica de localidad de los datos. • U na página corrupta no es utilizable porque se ha detectado un error hardw are. • Por últim o, una página en transición es aquella que está en cam ino desde el disco a un m arco de página asignado dentro de la m em oria física. Cuando el bit válido/inválido en .u n a entrada PTE es cero, el gestor VM define el form ato de los otros bits. Las páginas no válidas pueden tener diversos estados que estarán representados por los bits contenidos en la entrada PTE. Las páginas del archivo de páginas que nunca hayan sido car­ gadas com o consecuencia de un fallo página se m arcan com o páginas de relleno de ceros bajo dem anda. Los archivos m apeados a través de objetos sección tienen asociado u n puntero a dicho objeto sección. Las páginas que hayan sido escritas en el archivo de páginas contendrán suficien­ te inform ación com o para encontrar la página en disco, y asi sucesivam ente. En la Figura 22.5 se m uestra la estructura real de la PTE del archivo de páginas. La PTE contie­ ne 5 bits de protección de página, 20 bits para el desplazam iento dentro del archivo de páginas, 4 bits para seleccionar el archivo de paginación y 3 bits que describen el estado de la página. Una PTE del archivo de páginas se marca com o dirección virtual no válida de cara a la MMU. Puesto que el código ejecutable y los archivos m apeados en m em oria disponen ya de una copia en el disco, no necesitan espacio dentro de un archivo de paginación. Si una de estas páginas no se encuentra en la m em oria física, la estructura de la PTE es la siguiente: el bit m ás significativo se utiliza para especificar la protección de página, los siguientes 28 bits se usan com o índice dentro de una estructura de datos del sistem a que indica un archivo y un desplazam iento dentro del archivo correspondientes a la página, y los 3 bits inferiores especifican el estado de la página. Las direcciones virtuales no válidas tam bién pueden encontrarse en diversos estados tem pora­ les que form an parte de los algoritm os de paginación. C uando se elim ina una página del conjun­ to de trabajo de un proceso, se la m ueve a la lista de páginas m odificadas (que habrá que escribir en el disco) o directam ente a la lista de páginas de reserva. Si se escribe en la lista de páginas de reserva, se reclam ará la página sin volver a leerla del disco cuando se la necesite de nuevo,

730

Capítulo 22 W indows XP

Figura 2 2 .5

Entrada de la tabla de páginas del archivo de páginas. El bit válido/inválido e s cero.

siem pre y cuando la página no haya sido trasladada todavía a la lista de páginas libres. Siempre que sea posible, el gestor VM utilizará ciclos de inactividad de la CPU para escribir ceros en la lista'"--' de páginas libres y así m overlas a la lista de páginas borradas. Las páginas en transición son aqueíT' lias a las que se les ha asignado una página física y que están esperando a que term ine la opera­ ción de E /S de paginación antes de m arcar la entrada PTE com o válida. W indow s XP utiliza los objetos sección para describir aquellas páginas que son compartibles ~ entre distintos procesos. C ada proceso tiene su propio conjunto de tablas de páginas virtuales, pero el objeto sección tam bién incluye un conjunto de tablas de páginas que contiene las entradasPTE m aestra (o prototípicas). Cuando una PTE dentro de la tabla de páginas de un proceso está m arcada com o válida, apunta al m arco de página físico que contiene a esa página, com o debe ser en los procesadores LA.32, en los que la MMU hardw are lee las tablas de páginas directamente jdeu la m em oria. Pero cuando una página com partida pasa a ser no válida, se m odifica la PTE para qué apunte a la PTE prototípica asociada con el objeto sección. Las tablas de páginas asociadas con un objeto sección son virtuales en el sentido de que se las” ' crea y se las elim ina según sea necesario. Las únicas PTE prototípicas necesarias son aquellas quedescriben páginas para las que existe una vista actualm ente m apeada. Esto m ejora enormemente el rendim iento y perm ite utilizar' de form a m ás eficiente las direcciones virtuales del kem el. La PTE prototípica contiene la dirección del m arco de página y los bits de protección y de esta-, do. A sí, el prim er acceso a una página com partida por u n proceso genera un fallo de página. D espués del prim er acceso, los accesos siguientes se realizan de la form a norm al. Si un proceso escribe en una página de copia durante la escritura m arcada com o de sólo lectura en la PTE, el ges­ tor VM hace una copia de la página y m arca la PTE com o escribible, después de lo cual el proceso dejará en la práctica de tener una página com partida. Las páginas com partidas nunca aparecen en el archivo de páginas, sino que se las puede localizar en el sistem a de archivos. El gestor VM controla las páginas de m em oria física m ediante una base de d a to s de m a rc o s de p á g in a . Existe una entrada por cada página de m em oria física que haya en el sistema. Esa entra­ da apunta a la PTE, que a su vez apunta al m arco de página, de modo que el gestor VM puede con­ trolar el estado de la página. Los m arcos de página que no estén referenciados por una PTE válida se enlazan en una serie de listas de acuerdo con el tipo de página concreto, com o por ejem plo pági­ nas borradas, m odificadas o libres. Si se m arca una página física com partida com o válida para cualquier proceso, esa página no puede elim inarse de la m em oria. El gestor VM m antiene un contador de entradas PTE válidas para cada página, dentro de la base de datos de m arcos de página. Cuando el contador pasa a valer cero, la página física puede reutilizarse, después de escribir su contenido en el disco (si la página había sido m od ificada y estaba m arcada com o “sucia”). C uando se produce un fallo de página, el gestor VM localiza una página física para albergar los datos. Para las páginas con relleno de ceros bajo dem anda, la prim era opción consiste en localizar una página que ya haya sido borrada. Si no hay ninguna disponible, se selecciona una página de la lista de páginas libres o de la lista de páginas de reserva, y se borran los datos de la página antes de continuar. Si la página que ha provocado el fallo ha sido m arcada com o página en transición, ya estará siendo leída del disco o habrá sido elim inada y continuará estando disponible en la lista de páginas de reserva o de páginas m odificadas. Entonces, la hebra esperará a que la operación de E /S se com plete o, en los últim os casos, reclam ará la página de la lista apropiada.

732

Capítulo 22 Windows XP

2. La fu n ció n C r e a t e P r o c e s s ( ) e n el p ro c e s o o rig in a l in v o c a e n to n ce s u n a API d e g e sto r de p ro c e s o s d e l e jecu tiv o NT p a r a p ro c e d e r a la c r e a c ió n d el p ro ce so .

3. El gestor de procesos invoca al gestor de objetos para crear un objeto proceso y devuelve el descriptor del objeto a la API W in32. 4. La API W in32 invoca al gestor de procesos de nuevo para crear una hebra para el proceso, y devuelve los descriptores del nuevo proceso y de la nueva hebra. Las API de W indow s XP para m anipular la m em oria virtual y las hebras y para duplicar los des­ criptores tom an com o parám etro u n descriptor de proceso, de m odo que los subsistem as puedan realizar operaciones por cuenta de un nuevo proceso sin tener que ejecutar código directamente dentro del contexto del nuevo proceso. U na vez creado u n nuevo proceso, se crea la hebra inicial:'' y se entrega una llam ada a procedim iento asincrona a la hebra para provocar el com ienzo de la ejecución, que tendrá lugar en el cargador de im agen de m odo usuario. El cargador es u na biblio­ teca ntdll.dll, que es una biblioteca de m ontaje que se m apea autom áticam ente en todo proceso de­ nueva creación. W indow s XP tam bién soporta un estilo de creación de procesos de tipo fork() de UNIX, con el fin de dar soporte al subsistem a de entorno POSIX. A unque el entorno API W in32 invo­ ca al gestor de procesos desde el proceso cliente, POSIX em plea la naturaleza inter-procesos de las API W indow s XP para crear el nuevo proceso desde el proceso de subsistem a. A jí' El gestor de procesos tam bién im plem enta la entrega y puesta en cola de llam adas a procedió m iento asincronas (APC, asynchronous procedure cali) a las hebras. Las APC son utilizadas.por el - sistem a para iniciar la ejecución de las hebras, para com pletar la E /S , para term inar las hebras y/ procesos y para asociar depuradores. El código en m odo usuario tam bién puede tener en cola una’ APC dirigida a una hebra, para entregar notificaciones de tipo señal. Para soportar la especifica-/ „ ción POSIX, el gestor de procesos proporciona diversas API que envían alertas a las hebras con e l.* fin de desbloquearlas después de que estás hayan efectuado llam adas al sistem a. E1 soporte de depuración en el gestor de procesos incluye la capacidad de suspender y reanu­ dar hebras y de crear hebras que com iencen en m odo suspendido. Tam bién hay diversas API del -~ gestor de procesos que perm iten configurar y consultar el contexto de registros de una hebra y acceder a la m em oria virtual de otro proceso. Pueden crearse hebras dentro del proceso actual y tam bién se las puede inyectar dentro de otro proceso. D entro del ejecutivo, las hebras existentes pueden asociarse tem poralm ente a otro proce­ so. Las hebras de trabajo que necesitan ejecutarse dentro del contexto de un proceso que haya ori­ ginado una solicitud de trabajo utilizan este m étodo. El gestor de procesos tam bién soporta la característica de suplantación. U na hebra que se esté ejecutando dentro de un proceso con un testigo de seguridad que pertenezca a un usuario puede configurar un testigo específico de la hebra perteneciente a otro usuario. Esta funcionalidad resul­ ta fundam ental dentro del m odelo cliente-servidor, en el que los servicios necesitan actuar por cuenta de diversos clientes, los cuales tendrán diferentes ID de seguridad 22.3.3.4 Fu n cion alid ad de llam ad as a p ro ced im ien to s lo cales La im plem entación de W indow s XP utiliza un m odelo cliente-servidor. Los subsistem as de entor­ no son servidores que im plem entan personalidades concretas del sistem a operativo. El modelo cliente-servidor se em plea para im plem entar diversos servicios del sistem a operativo, que no pertenecen a ios subsistem as de entorno. La gestión de seguridad, la gestión de im presión, los ser­ vicios w eb, los sistem as de archivos de red, las funciones plug-and-play y m uchas otras caracte­ rísticas se im plem entan utilizando este m odelo. Para redu cir el consum o de m em oria, se suelen agrupar m últiples servicios dentro de unos cuantos procesos, que utilizan la funcionalidad de ges­ tión de conjuntos de hebras en m odo usuario para com partir hebras y esperar a la recepción de m ensajes (véase la Sección 22.3.3). El sistem a operativo utiliza la funcionalidad de llam ada a procedim iento local (LPC, local pro­ cedure cali) para intercam biar solicitudes y resultados entre los procesos cliente y servidor dentro de una m isnta m áquina. En particular, la funcionalidad LPC se utiliza para solicitar servicios de los diversos subsistem as W indow s XP. LPC es sim ilar en m uchos aspectos a los m ecanism os RPC

22.3 Componentes del sistema

733

utilizados por m uchos sistem as operativos para procesam iento distribuido a través de las redes, pero LPC está optim izado para usarlo dentro de un único sistem a. L a im plem entación W indow s XP del m ecanism o RPC de OSF (Open Softw are Foundation) a m enudo utiliza la funcionalidad LPC com o transporte dentro de la m áquina local. LPC es un m ecanism o de paso de m ensajes. El proceso servidor publica un objeto puerto de conexión que es visible globalm ente. Cuando un cliente desea un servicio de un subsistem a, abre un descriptor del objeto puerto de conexión del subsistem a y envía una solicitud de conexión a dicho puerto. El servidor crea un canal y devuelve un descriptor al cliente. El canal está com pues­ to por un par de puertos privados de com unicación: uno para los m ensajes del cliente al servidor y otro para los m ensajes del servidor al cliente. Los canales de com unicación soportan un m eca­ nism o de retrollam ada, por lo que el cliente y el servidor pueden aceptar solicitudes en aquellos casos en los que norm alm ente estarían esperando recibir una respuesta. Cuando se crea un canal LPC, debe especificarse una de tres posibles técnicas de paso de m en­ sajes. 1. L a prim era técnica es adecuada para m ensajes de pequeño tam año (hasta un par de cientos de bytes). En este caso, la cola de m ensajes del puerto se em plea com o alm acenam iento inter­ m edio y los m ensajes se copian de un proceso al otro. 2. La segunda técnica se em plea para m ensajes de m ayor tam año. En este caso, se crea un obje­ to sección de m em oria com partida para el canal. Los m ensajes enviados a través de la cola de m ensajes del puerto contienen un puntero que hace referencia al objeto sección junto con la necesaria inform ación de tam año. Esto evita la necesidad de copiar mensajes de gran longi­ tud. El em isor coloca los datos en la sección com partida y el receptor los puede consultar directam ente. 3. La tercera técnica utiliza las API que leen y escriben directam ente en el espacio de direccio­ nes de un proceso. La funcionalidad LPC proporciona funciones y m ecanism os de sincroni­ zación, de m odo que un servidor pueda acceder a los datos alm acenados en un cliente. El gestor de ventanas de la API W in32 utiliza su propia form a de paso de mensajes, que es inde­ pendiente del m ecanism o LPC ejecutivo. Cuando un cliente solicita una conexión que utiliza m en­ sajes del gestor de ventanas, el servidor construye tres objetos: (1) una hebra dedicada de servidor para gestionar las solicitudes, (2) un objeto sección de 64 KB y (3) un objeto pareja de sucesos. U n objeto pareja de sucesos es un objeto de sincronización em pleado por el subsistema API W in32 para proporcionar una notificación cuando la hebra cliente haya copiado un mensaje al servidor API W in32, o viceversa. El objeto sección pasa los m ensajes y el objeto pareja de sucesos se encarga de la sincronización. El m ecanism o de m ensajería del gestor de ventanas tiene varias ventajas: • El objeto sección elim ina la necesidad de copiar m ensajes, ya que representa una región de m em oria com partida. • El objeto pareja de sucesos elim ina el gasto adicional im plicado en la utilización del objeto puerto para pasar m ensajes que contienen punteros de inform ación de longitud. • La hebra dedicada de servidor elim ina el coste adicional de determ inar qué hebra cliente está llam ando al servidor, ya que existe una hebra de servidor por cada hebra cliente. • El kem el asigna una preferencia de planificación a estas hebras dedicadas de servidor, con el fin de m ejorar las prestaciones.

22.3.3.5

G estor de E/S

El g estor de F/S es responsable de los sistem as de archivos, controladores de dispositivos y con­ troladores de red. Se encarga de controlar qué controladores de dispositivo, controladores de fil­ trado y sistem as de archivos se han cargado, y tam bién gestiona los búferes para las solicitudes de E /S . Coopera con el gestor VM para proporcionar un m ecanism o de E /S de archivo m apeada

734

Capítulo 22 W indows XP

en m em oria y controla el gestor de caché de W indow s XP que se encarga de gestionar el alm ace­ nam iento en caché para todo el sistem a de E /S . El gestor de E /S es fundam entalm ente asincrono La E /S síncrona se proporciona esperando explícitam ente a que se com plete una operación de E /s El gestor de E /S proporciona varios m odelos de term inación asincrona de las operaciones de E /S , incluyendo la configuración de sucesos, la entrega de llam adas APC a la hebra iniciadora y el uso de puertos de term inación de E /S , que perm iten que una única hebra procese los sucesos S de term inación de E /S correspondientes a otras m uchas hebras. “ Los controladores de dispositivos están organizados com o una lista para cada dispositivo (lo que se denom ina una pila de controlador o de E /S , debido al m odo en que se añaden los contro­ ladores de dispositivo). El gestor de E /S convierte las solicitudes que recibe a un form ato estándar denom inado p a q u e te d e s o lic itu d d e T/S (IRP, request packet I/O ). A continuación, re-envía el IRP al prim er controlador de la pila para su procesam iento. D espués de que cada controlador procese el IRP, invoca al gestor de E /S , bien para re-enviar el paquete al siguiente controlador de la pila o, si ha finalizado todo el procesam iento, para com pletar las operaciones realizadas con el IRP. La term inación de esas operaciones puede producirse en un contexto distinto del correspon­ diente a la solicitud de E /S original. P or ejem plo, si un controlador está llevando a cabo su parte de una operación de E /S y se ve obligado a bloquearse durante un período de tiem po prolonga­ do, puede poner en cola la IRP para que una hebra de trabajo continúe con el procesam iento den- « tro del contexto del sistem a. En la hebra original, el controlador devuelve un código de estado que indica que la solicitud de E /S está pendiente, de m odo que la hebra pueda seguir ejecutándose en paralelo con la operación de E /S . Los paquetes IRP tam bién pueden procesarse en rutinas de ser­ vicio de interrupciones y com pletarse dentro de un contexto arbitrario. Puesto que puede ser nece­ sario realizar un cierto procesam iento final dentro del contexto que inició la operación de E /S , el gestor de E /S utiliza una APC para realizar el procesam iento final de term inación de la E /S dentro del contexto de la hebra original. i El m odelo de pila es m uy flexible. A m edida que se construye una pila de controladores, los diversos controladores tienen la oportunidad de insertarse dentro de la pila com o c o n tr o la d o r e s d e f iltr a d o . Los controladores de filtrado pueden exam inar y, potencialm ente, m odificar cada una de las operaciones de E /S . La gestión de m ontaje, la gestión de particiones y los m ecanism os de duplicación de duplicación en bandas de los discos son algunos ejem plos de funcionalidad implem entada m ediante controladores de filtrado que se ejecutan por debajo del sistem a de archivos . dentro de la pila. Los controladores de filtrado del sistem a de archivos se ejecutan por encim a del sistem a de archivos y se los utiliza para im plem entar funcionalidad tal com o la gestión de alm a­ cenam iento jerárquico, la instanciación sim ple de archivos para arranque rem oto y la conversión dinám ica de form atos. O tros fabricantes de softw are utilizan tam bién controladores de filtrado del sistem a de archivos para im plem entar m ecan ism os de detección de virus. Los controladores de dispositivos de W indow s XP se escriben de acuerdo con la especificación WDM (W indow s D river M odel). Este m odelo establece todos los requisitos para los controladores de dispositivo, incluyendo cóm o apilar controladores de filtrado, cóm o com partir código com ún para gestionar las solicitudes plug-and-play y de adm inistración de energía, cóm o construir lógi­ ca de cancelación correcta, etc. D ebido a la com plejidad del m odelo WDM, escribir un controlador de dispositivo WDM para cada nu ev o d isp ositivo de hard w are puede requ erir una cantidad de trabajo excesiva. A fortunadam ente, el m odelo puerto/m inipuerto hace que esto sea innecesario. D entro de una clase de dispositivos sim ilares, com o por ejem plo controladores de audio, dispositivos SCSI o con­ troladoras Ethernet, cada instancia de un dispositivo com parte un controlador com ún de la clase denom inado c o n tr o la d o r d e p u e rto . El controlador de puerto im plem enta las operaciones están­ dar para la clase y luego invoca las rutinas específicas del dispositivo dentro del c o n tr o la d o r d e m in ip u e r to de éste, con el fin de im plem entar la funcionalidad específica que ese dispositivo pro­ porcione. 22.3.3.6 G estor de caché En m uchos sistem as operativos, del alm acenam iento en caché se encarga el sistem a de archivos. Por el contrario, W indow s XP proporciona una funcionalidad de caché centralizada. El g esto r de

>

22.3 Componentes del sistema

735

c a c h é coopera estrecham ente con el gestor VM con el fin de proporcionar servicios de caché para todos los com ponentes que están bajo el control del gestor de E /S . El alm acenam iento en caché en W indow s XP está basado en archivos en lugar de en bloque sin formato.

El tam año de la caché cam bia dinám icam ente de acuerdo con la m em oria libre que haya dis­ ponible en el sistem a. Recuerde que los 2 GB superiores del espacio de direcciones de un proceso form an el área del sistem a, que estará disponible dentro del contexto de todos los procesos. El ges­ tor VM asigna hasta un cincuenta por ciento de este espacio a la caché del sistem a. El gestor de caché m apea archivos sobre este espacio de direcciones y em plea las capacidades del gestor VM para gestionar la E /S de archivos. La caché está dividida en bloques de 256 KB. Cada bloque de la caché puede alm acenar una vista (es decir, com o una región m apeada en m emoria) de u n archivo. Cada bloque de caché está descrito en un b lo q u e d e c o n tr o l d e d ir e c c ió n v ir tu a l (VACB, virtual address control block), que alm acena la dirección virtual y el desplazam iento dentro del archivo para la vista, así com o el núm ero de procesos que están utilizando la vista. Los VACB residen en una única m atriz, de cuyo m antenim iento se encarga el gestor de caché. Para cada archivo abierto, el gestor de caché m antiene una m atriz índice VACB independiente que describe el alm acenam iento en caché para el archivo com pleto. Esta m atriz tiene una entrada por cada fragm ento de 256 KB del archivo; de este m odo, por ejem plo, un archivo de 2 M B ten­ dría una m atriz índice VACB de 8 entradas. Cada entrada de la m atriz índice VACB apunta al VACB si dicha parte del archivo se encuentra en la caché; en caso contrario, la entrada tendrá un valor nulo. C uando el gestor de E /S recibe una solicitud de lectura de archivo de nivel de usuario, envía un paquete IRP a la pila de controladores de dispositivo en la que reside el archivo. El sistem a de archivos trata de buscar los datos solicitados m ediante el gestor de caché (a m enos que la solici­ tud especifique que debe realizarse una lectura no dirigida a la m em oria caché). El gestor de caché calcula qué entrada de la m atriz índice VACB de dicho archivo se corresponde con el desplaza­ m iento en bytes de la solicitud. Esa entrada apuntará a la vista alm acenada en la caché o será invá­ lida. Si es inválida, el gestor de caché asignará un bloque de caché (y la entrada correspondiente en la m atriz VACB) y m apeará la vista sobre el bloque de caché. El gestor de caché tratará enton­ ces de copiar los datos del archivo m apeado al búfer del proceso que ha realizado la invocación. Si la copia tiene éxito, la operación se com pleta. Si la copia falla, lo hará debido a un fallo de pági­ na que provocará que el gestor VM envíe al gestor de E /S una solicitud de lectura no dirigida a la caché. El gestor de E /S enviará otra solicitud hacia abajo a través de la pila de controladores soli­ citando esta vez una operación de paginación, que puentea al gestor de caché y lee los datos del archivo directam ente en la página asignada al gestor de caché. Al term inar la operación, se m odi­ fica el VACB para que apunte a esa página. Los datos, que ahora estarán en la caché, se copian en el búfer del proceso que ha realizado la invocación, y la solicitud de E /S original se com pleta. La Figura 22.6 m uestra un resum en de estas operaciones. Siem pre que sea posible, para las operaciones síncronas sobre los archivos alm acenados en caché, las operaciones de E /S gestionadas por el m e c a n is m o d e rá p id a . Este m ecanism o es sim ilar a la E / S norm al basada en paquetes IRP, pero invoca la pila de controladores directam en­ te, en lugar de pasar hacia abajo un paquete IRP. Puesto que no se utiliza un IRP, la operación no debe bloquearse durante un período largo de tiem po y no debe ponerse en una cola para ser pro­ cesada por una hebra de trabajo. Por tanto, cuando la operación alcanza el sistem a de archivos e invoca al gestor de caché, la operación fallará si la inform ación no se encuentra ya en la caché. El gestor de E /S tratará entonces de llevar a cabo la operación utilizando la ruta norm al basada en paquetes IRP. L as operaciones de lectura de nivel de kem el son sim ilares, excepto en que puede accederse a los datos directam ente desde la caché, en lugar de copiarlos a un búfer en el espacio de usuario. Para utilizar los m etadatos del sistem a de archivos (estructuras de datos qüe describen el sistem a de archivos), el kem el em plea la interfaz de m apeo del gestor de caché con el fin de leer los m etadatos. Para m odificar los m etadatos, el sistem a de archivos utiliza la interfaz de anclaje del gestor de caché. A nclar una página hace que esa página quede fija en un m arco de página de m emoria física, de m odo que el gestor VM no pueda m overla ni descargarla como resultado de una opera­ ción de paginación. D espués de actualizar los m etadatos, el sistem a de archivos solicita al gestor

736

Capítulo 22 Windows XP

proceso gestor de E/S

Figura 2 2 .6

E/S de archivo.

de caché que elim ine el anclaje de la página. Las páginas m odificadas se m arcan com o sucias, para que el gestor V M las vuelque al disco. Los m etadatos se alm acenan en un archivo. Para m ejorar las prestaciones, el gestor de caché m antiene un pequeño historial de las solici­ tudes de lectura trata de predecir las solicitudes futuras a partir de este historial. Si el gestor de caché encuentra un patrón en las tres solicitudes anteriores, com o por ejem plo un acceso secuen­ cial hacia delante o hacia atrás, extrae anticipadam ente los datos los alm acena en la caché antes de que la aplicación envíe la siguiente solicitud. De esta form a, la aplicación encontrará los. datos en la caché no necesitará esperar a que se produzca una operación de de disco. Las fun­ ciones () de la W in32 adm iten com o parám etro un indicador que es una sugerencia para que el gestor de caché trate de extraer anticipadam ente 192 más allá de las solicitudes efectuadas por la hebra. Normalmente, W indow s realiza operaciones de en fragm entos de 64 o 16 páginas; por tanto, esta lec­ tura anticipada equivale a tres veces la cantidad norm al de datos leídos. El gestor de caché tam bién es responsable de decir al gestor que vuelque el contenido de la caché en el disco. El com portam iento predeterm inado del gestor de caché consiste en aplicar un m ecanism o de escritura retardada: acum ula las escrituras durante 4 o 5 segundos y luego despier­ ta a la hebra escritora de caché. Cuando se necesita em plear un m ecanism o de escritura directa, un proceso puede configurar un indicador en el m om ento de abrir un archivo, o bien el proceso puede invocar una función explícita de volcado de caché. Un proceso que realice escrituras con gran rapidez podría llegar a llenar todas las páginas libres de caché antes de que la hebra escritora de caché tenga la oportunidad de despertarse y vol­ car las páginas al disco. El escritor de caché evita que un proceso inunde el sistem a de la siguien­ te forma: cuando la cantidad de m em oria libre en la caché es m uy baja, el gestor de caché bloquea tem poralm ente los procesos que estén intentando escribir datos y despierta a la hebra escritora de caché, con el fin de que vuelque las páginas al disco. Si el proceso que realiza escrituras con gran rapidez es un redirector de red para un sistem a de archivos' de red, bloquearlo durante dem asia­ do tiem po podría provocar fines de tem porización en las transferencias de red con sus consiguien­ tes retransm isiones. Estas retransm isiones representarían ün desperdicio del ancho de banda de red. Para evitar este desperdicio, los redirectores de red pueden ordenar al gestor de caché que limite el núm ero de escrituras pendientes en la caché. Puesto que los sistem as de archivos en red necesitan transferir datos entre el disco y la interfaz de red, el gestor de caché también proporciona una interfaz DMA para poder m over los datos directam ente. Esa transferencia directa de los datos evita la necesidad de copiarlos en un búfer intermedio.

y

y

y O penFile 0 y C re a te F ile FILE_FLAG_SEQUENTIAL_SCAN, KB XP E/S

E/S

API

KB

VM

>

22.3 Componentes del sistema

737

22.3.3.7 M on ito r de referen cia de seguridad La centralización de la gestión de las entidades del sistem a en el gestor de objetos perm ite a W indow s XP utilizar un m ecanism o uniform e para llevar a cabo las validaciones de acceso en tiem po de ejecución y las com probaciones de auditoría para todas las entidades del sistem a a las que puedan acceder los usuarios. Cada vez que un proceso abre un descriptor de un objeto, el m on itor de referen cia de seguridad (SRM, security reference m onitor) com prueba el testigo de seguridad del proceso y la lista de control de acceso del objeto para ver si el proceso tiene los dere­ chos necesarios. El SRM tam bién es responsable de m anipular los privilegios en los testigos de seguridad. Se requieren privilegios especiales para que los usuarios realicen operaciones de copia de seguridad o restauración en los sistem as de archivos, para evitar ciertas com probaciones com o adm inistra­ dor, para depurar los procesos, etc. Los testigos tam bién pueden m arcarse com o restringidos en lo que a sus privilegios se refiere, para que no puedan acceder a objetos que estén disponibles para la m ayoría de los usuarios. Los testigos restringidos se utilizan principalm ente para lim itar el daño que puede provocar la ejecución de código que no sea de confianza. Otra responsabilidad del SRM es llevar un registro de los sucesos de auditoría de seguridad. La clasificación de seguridad C-2 requiere que el sistem a tenga la capacidad de detectar y registrar todos los intentos de acceder a recursos del sistem a, para que resulte m ás sencillo trazar los inten­ tos de acceso no autorizados. Puesto que el SRM es responsable de realizar las com probaciones de acceso, es él quien genera la m ayoría de las entradas de registro de auditoría en el registro de suce­ sos de seguridad. 22.3.3.8 G estores plu g-and-play y de ad m in istración de en ergía El sistem a operativo utiliza el gestor p lu g-and-play (PnP) para reconocer los cam bios en la confi­ guración hardw are y adaptarse a los m ism os. Para que el m ecanism o PnP funcione, tanto el dispositivo com o el controlador deben soportar el estándar PnP. El gestor PnP reconoce autom á­ ticam ente los dispositivos instalados y detecta los cam bios en dichos dispositivos m ientras el sis­ tem a sigue funcionando. El gestor tam bién controla los recursos utilizados por cada dispositivo, así com o los recursos potenciales que podrían llegar a utilizarse y se responsabiliza de cargar los controladores apropiados. Esta gestión de los recursos hardw are (principalm ente interrupciones y rangos de m em oria de E/S) tiene el objetivo de determ inar una configuración hardw are en la que todos los dispositivos sean capaces de funcionar correctam ente. Por ejem plo, si el dispositivo B puede utilizar la interrupción 5 y el dispositivo A puede usar la 5 o la 7, entonces el gestor PnP asignará la 5 a B y la 7 a A. En las versiones anteriores, el usua­ rio podía tener que elim inar el dispositivo A y reconfigurarlo para que utilizara la interrupción 7 antes de poder instalar el dispositivo B. Eso obligaba al usuario a estudiar los recursos del siste­ ma antes de instalar nuevo hardware y determ inar qué dispositivos estaban usando cada recurso hardware. La proliferación de tarjetas PCMCIA, de estaciones de acoplam iento de portátiles y de dispositivos USB, IEEE 1394, Infiniband y otros dispositivos conectables en caliente tam bién exige soportar la existencia de recursos dinám icam ente configurables. El gestor PnP gestiona la reconfiguración dinám ica de la form a siguiente: en prim er lugar, obtiene una lista de dispositivos de cada controlador de bus (por ejem plo, PCI, USB). Después carga el controlador instalado (o instala uno en caso necesario) y envía una solicitud a d d d e v i c e al controlador apropiado para cada dispositivo. El gestor PnP determ ina la asignación óptim a de recursos y envía una solicitud s t a r t - d e v i c e a cada controlador, junto con la asigna­ ción de recursos correspondiente a ese dispositivo. Si es necesario reconfigurar un dispositivo, el gestor PnP envía una solicitud q u e r y - s t o p , que pregunta al controlador si puede desactivarse tem poralm ente el dispositivo. Si el controlador puede desactivar el dispositivo, entonces se com ­ pletan todas las operaciones pendientes y se im pide que com iencen nuevas operaciones. Después el gestor PnP envía una solicitud s t o p tras lo cual puede reconfigurar el dispositivo con otra soli­ citud s t a r t - d e v i c e .

^38

Capítulo 22 Windows XP

El gestor P nP tam bién soporta otras solicitudes, com o q u e r y -r e m o v e . Esta solicitud, que se utiliza cuando el usuario se está preparando para expulsar un dispositivo PCCARD, funciona de form a sim ilar a q u e r y - s t o p . La solicitud s u r p r i s e - r e m o v e se utiliza cuando un dispositivo falla o, más probablem ente, un usuario extrae un dispositivo PCCARD sin detenerlo primero. La solicitud rem o v e dice al controlador que deje de usar el dispositivo y que libere todos los recur­ sos asignados al m ismo. W indow s XP soporta sofisticados m ecanism os de adm inistración de energía, Aunque estas fun­ cionalidades son útiles en los sistem as dom ésticos para reducir el consum o de energía, su princi­ pal aplicación es la facilidad de uso (un acceso m ás rápido) y la am pliación del tiempo de vida de las baterías en los equipos portátiles. El sistem a y los dispositivos individuales pueden ponerse en modo de baja energía (denom inado m odo de suspensión o hibernación) cuando no se están usan­ do, con lo que la batería se utilizará principalm ente para retener los datos en la memoria física (RAM). El sistem a puede volver a activarse autom áticam ente cuando se reciban paquetes a través de la red, cuando se produzca una llam ada a través de una línea telefónica conectada a un m ódem , o cuando un usuario abra una com putadora portátil o pulse un cierto botón de re-arranque del sistem a. W indow s XP tam bién puede hibernar un sistem a, alm acenando el contenido de la m em oria física en disco y apagando com pletam ente la m áquina, para posteriorm ente restaurar el sistem a en algún instante posterior antes de continuar con la ejecución. Tam bién hay disponibles otras estrategias para reducir el consumo de energía. En lugar de dejar que la CPU ejecute u n bucle de inactividad en los m om entos que no tenga otra cosa que hacer, W indow s XP pone el sistem a en un estado que requiere un m enor consum o de energía, si la CPU se está infrautilizando, W indow s XP reduce la velocidad de reloj de la CPU, lo que permite ahorrar una cantidad significativa de energía. 22.3.3.9 El R egistro W indow s XP m antiene bu ena parte de su configuración en una base de datos interna conocida com o el R egistro. Una base de datos del Registro se denom ina colm ena. Existen colm enas sepa­ radas para la inform ación del sistem a, las preferencias predeterm inadas del usuario, la instalación softw are y para la seguridad. Puesto que la inform ación contenida en la colm ena del sistem a es necesaria para poder arrancar el sistem a, el gestor del Registro se im plem enta com o componente del program a ejecutivo. C ada vez que el sistem a arranca correctam ente, alm acena la colm ena del sistem a com o última colm ena correcta conocida. Si el usuario instala softw are, com o por ejem plo un controlador de dispositivo, que genere una configuración de la colm ena del sistem a que no permita el arranque, el usuario puede normal­ m ente arrancar utilizando la últim a configuración correcta conocida. Los daños en la colm ena del sistem a debidos a la instalación de aplicaciones y controladores de otros fabricantes suelen ser tan com unes, que W indow s XP tiene un com ponente denominado R estaurar e l sistem a, que guarda periódicam ente las colm enas, adem ás de otra inform ación de estado del softw are, com o por ejem plo los ejecutables de los controladores y los archivos de con­ figuración, para poder restaurar el sistem a a un estado correcto anterior en aquellos casos en los que el sistem a arranque pero haya dejado de funcionar en la forma esperada. 22.3.3.10 A rranque El arranque de un PC W indow s XP com ienza cuando se alim enta el hardw are y el sistem a BIOS com ienza a ejecutarse a partir de la ROM. El sistem a BIOS identifica el d ispositivo del sistem a a partir del cual hay que arrancar, y carga y ejecuta el cargador de arranque situado al inicio del disco. Este cargador conoce la inform ación suficiente acerca del form ato del sistem a de archivos com o para cargar el program a NTLDR del directorio raíz del dispositivo del sistema. NTLDR se uti­ liza para determ inar qué disp ositivo de arranque contiene el sistema operativo. A continuación, el NTLDR carga la biblioteca HAL, el kem el y la colm ena del sistem a desde el dispositivo de arran­ que. Gracias a la colm ena del sistem a determ ina qué controladores de dispositivo son necesarios para arrancar el sistem a (los controladores de arranque) y los carga. Por último, NTLDR com ienza la ejecución del kem el.

22.4 Subsistemas de entorno

739

El kernel inicializa el sistem a y crea dos procesos. El p r o c e s o d e l s is te m a contiene todas las hebras de trabajo internas y nunca se ejecuta en modo usuario. El prim er proceso en m odo usua­ rio es el SMSS, que es sim ilar al proceso INIT (inicialización) de UNIX. SMSS realiza tareas adiciona­ les de inicialización del sistem a, incluyendo el establecim iento de los archivos de paginación y la carga de los controladores de dispositivo, y crea los procesos WINLOGON y CSRSS. CSRSS es el sub­ sistem a API W in32. WINLOGON se encarga de poner en m archa el resto del sistem a, incluyendo el subsistem a de seguridad LSASS y los restantes servicios necesarios para ejecutar el sistema. El sistem a optim iza el proceso de arranque precargando archivos desde el disco basándose en los arranques anteriores del sistem a. Los patrones de acceso a disco durante el arranque tam bién se utilizan para disponer los archivos del sistem a en disco con el fin de reducir las operaciones de E /S necesarias. El núm ero de procesos requeridos para arrancar el sistem a se reduce agrupando los servicios dentro de un único proceso. Todas estas técnicas perm iten reducir enorm em ente el tiempo de arranque del sistem a. Por supuesto, el tiempo de arranque del sistem a es m enos im por­ tante que anteriorm ente debido a las capacidades de suspensión e hibernación de W indow s XP, que perm iten a los usuarios apagar sus com putadoras y luego continuar rápidam ente en el punto en que se habían quedado.

22.4 Subsistemas de entorno Los subsistem as de entorno son procesos en m odo usuario apilados sobre los servicios ejecutivos nativos de W indow s XP y que perm iten a W indow s XP desarrollar program as desarrollados para otros sistem as operativos, incluyendo W indow s de 16 bits, MS-DOS y POSIX. Cada subsistem a de entorno proporciona un único entorno de aplicación. W indow s XP utiliza el subsistem a API W in32 como el principal entorno de operación, por lo que es este subsistem a el que arranca todos los procesos. C uando se ejecuta una aplicación, el sub­ sistem a API W in32 invoca al gestor VM para cargar el código ejecutable de la aplicación. El gestor de m emoria devuelve un código de estado a W in32 que indica el tipo de ejecutable. Si no es un ejecutable nativo API W in32, el entorno API W in32 com prueba si se está ejecutando el subsistem a de entorno apropiado, si no es así, lo arranca com o proceso en m odo usuario. El subsistem a toma entonces el control del arranque de la aplicación. Los subsistem as de entorno utilizan la funcionalidad LPC para proporcionar servicios del sis­ tema operativo a los procesos cliente. La arquitectura de subsistem as de W indow s XP evita que las aplicaciones m ezclen rutinas API de diferentes entornos. Por ejem plo, una aplicación API W in32 no puede hacer una llam ada al sistem a POSIX, por que sólo puede haber un subsistem a de entor­ no asociado con cada proceso. Puesto que cada subsistem a se ejecuta com o un proceso separado en m odo usuario, un fallo catastrófico en uno de los subsistem as no tiene efectos sobre los procesos. La excepción es la API W in32, que proporciona todas las capacidades de interfaz con el teclado, el ratón y la pantalla grá­ fica. Si falla, el sistem a se detiene y requiere un re-arranque. El entorno API W in32 clasifica las aplicaciones como aplicaciones gráficas o basadas en carac­ teres, siendo una aplicación basada en caracteres aquella que cree que la salida interactiva va a una ventana (de com andos) basada en caracteres. La API W in32 transform a la salida de una aplicación basada en caracteres a una representación gráfica dentro de la ventana de com andos. Esta trans­ form ación resulta sencilla: cada vez que se invoca una rutina de salida, el subsistem a de entorno llama a una rutina W in32 para m ostrar el texto. Puesto que el entorno API W in32 realiza esta fu n­ ción para todas las ventanas basadas en caracteres, perm ite transferir texto de la pantalla entre unas ventanas y otras a través del portapapeles. Esta transform ación funciona tanto para las apli­ caciones MS-DOS com o para Fas aplicaciones de línea de com andos POSIX.

22.4.1 Entorno MS-DOS El entorno MS-DOS no tiene la com plejidad de los otros subsistem as de entorno de W indow s XP. Este entorno se proporciona m ediante una aplicación API W in32 denom inada m á q u in a DOS v ir­ tu al (VDM, virtual DOS m achine). Puesto que la VDM es un proceso en modo usuario, se pagina y

740

Capítulo 22 Windows XP

se despacha com o cualquier otra aplicación de W indows XP. La VDM tiene una unidad de ejecu­ ción de in stru ccio n es, para ejecutar o em ular instrucciones Intel 4 8 6 . La VDM tam bién proporcio­ na rutina para em ular el BIOS ROM MS-DOS y los servicios de la interrupción softw are “int 2 1 ” y

disponen de controladores de dispositivo virtuales para la pantalla, el teclado y los puertos de com unicaciones. La VDM está basada en el código fuente de MS-DOS 5.0 y asigna al m enos 620 KB de m em oria a la aplicación. La shell de com andos de W indow s XP es un program a que crea una ventana que se asemeja a un entorno MS-DOS. Puede ejecutar program as tanto de 16 com o de 32 bits. Cuando se ejecuta una aplicación MS-DOS, la shell de com andos arranca un proceso VDM para ejecutar el programa. Si W indow s XP está ejecutándose sobre un procesador com patible con IA32, las aplicaciones gráficas se ejecutan en m odo de pantalla com pleta y las aplicaciones de caracteres pueden ejecu­ tarse en m odo de pantalla com pleta o en una ventana. No todas las aplicaciones MS-DOS se ejecu­ tan sobre la VDM. Por ejem plo, algunas aplicaciones MS-DOS acceden directam ente al hardware de disco, asi que no podrán ejecutarse en W indow s XP porque el acceso a disco está restringido con el fin de proteger el sistem a de archivos. En general, las aplicaciones MS-DOS que acceden directa­ m ente al hardw are no podrán funcionar en W indow s XP. Puesto que MS-DOS no es un entorno m ultitarea, algunas aplicaciones se han escrito de tal m odo que “acaparan” la CPU. Por ejem plo, la utilización de bucles de espera puede provocar retar­ dos o pausas en la ejecución. El planificador del despachador del kem el detecta dichos retardos y ajusta autom áticam ente el uso de la CPU, pero esto puede hacer que la aplicación funcione inco­ rrectam ente.

22.4.2 Entorno W indows de 16 bits El entorno de ejecución W in l6 se proporciona m ediante una VDM que incorpora un softw are adi­ cional denom inado W indows on W indows (W OW 32 para las aplicaciones de 16 bits); este software proporciona las rutinas del kem el W indow s 3.1 y las rutinas de interfaz para las funciones de ges­ tión de ventanas y de interfaz de dispositivo gráfico (GDI, graphicai-device-interface). Las rutinas de interfaz invocan a las subrutinas apropiadas de la API W in32, convirtiendo las direcciones de 16 bits en direcciones de 32 bits. Las aplicaciones que utilizan la estructura interna del gestor de ventanas de 16 bits o de GDI, pueden no funcionar, porque la im plem entación subyacente de la API W in32 es, por supuesto, diferente del verdadero W indow s de 16 bits. W O W 32 puede ejecutarse concurrentem ente con otros procesos en W indow s XP, pero se ase­ m eja a W indow s 3.1 en m uchos aspectos. Sólo se puede ejecutar una aplicación W in ló en cada instante, todas las aplicaciones son m onohebra y residen en el m ismo espacio de direcciones y todas ellas com parten la m ism a cola de entrada. Estas características im plican que una aplicación que detenga la recepción de datos de entrada bloqueará a todas las dem ás aplicaciones W in ló, al igual que en W indow s 3.x, y una aplicación W in ló puede hacer que sufran un fallo catastrófico otras aplicaciones W in ló corrom piendo el espacio de direcciones. Sin em bargo, pueden coexistir m últiples entornos W in ló , utilizando el com ando start /sepárate aplicacionW in!6 en la línea de com andos. Son relativam ente pocas las aplicaciones de 16 bits que los usuarios necesiten continuar ejecu­ tando en W indow s XP, pero algunas de ellas son, por ejem plo, program as com unes de instalación y configuración. Por ello, el entorno W O W 32 continúa existiendo principalm ente debido a que una serie de aplicaciones de 32 bits no pueden instalarse en W indow s XP sin dicho entorno.

22.4.3 Entorno W indows de 32 bits en IA64 El en to rn o n ativ o para W in d o w s en las m áq u in as co m p atib les con IA 64 u tiliza d ireccion es de 64 bits y el co n ju n to de in stru ccio n es n ativ o IA 64. Para ejecu tar p ro g ram as IA 32 en este en torn o, se req u iere un n ivel de tra d u cció n para tran sform ar las llam ad as a la API W in 3 2 de 32 b its en las co rre sp o n d ie n tes lla m a d a s de 64 bits, de la m ism a m an era q u e las ap licacio n es de 16 b its req u ie­ ren una tra d u cció n en los sistem as IA 32. P or ello, W in d ow s de 64 bits so p o rta el en torn o W O W 64. Las im plem en taci.on es de 3 2 y 64 bits de W in d ow s son esen cialm en te id én ticas, y el p ro cesad or >

22.4 Subsistemas de entorno

741

IA 64 proporciona un m ecanism o de ejecución directa de las instrucciones IA32, por lo que W O W 64 consigue un nivel m ayor de com patibilidad que W OW 32.

22.4.4 Entorno Win32 El subsistem a principal en W indow s XP es la API W in32. Ejecuta aplicaciones API W in32 y gestio­ na toda la E /S de teclado, ratón y pantalla. Puesto que es el entorno de control, está diseñado para ser extrem adam ente robusto, y a esta robustez contribuyen diversas características de la API W in32. A diferencia de los procesos en el entorno W in ló, cada proceso W in32 tiene su propia cola de entra­ da. El gestor de ventanas despacha todas las entradas recibidas en el sistem a a la cola de entrada del proceso apropiado, por lo que un proceso fallido no bloqueará la entrada a otros procesos. El kem el de W indow s XP tam bién proporciona m ecanism os m ultitarea apropiativos, lo que per­ m ite al usuario term inar las aplicaciones que hayan fallado o que ya no sean necesarias. La API W in32 tam bién valida todos los objetos antes de utilizarlos, para evitar fallos catastróficos que podrían producirse si una aplicación tratara de em plear un descriptor no válido o incorrecto. El subsistem a API W in32 verifica el tipo de objeto al que el descriptor apunta antes de utilizar dicho objeto. L os contadores de referencias que el gestor de objetos m antiene evitan que los objetos sean borrados m ientras están siendo utilizados y evitan tam bién que se los use después de haber sido borrados. Para conseguir un alto grado de com patibilidad con los sistem as W indow s 95/98, W indow s XP perm ite a los usuarios especificar que ciertas aplicaciones individuales se ejecuten utilizando una capa de m od ificación , que m odifica la API W in32 para aproxim arse m ás exactam ente al com por­ tam iento esperado por las aplicaciones antiguas. Por ejem plo, algunas aplicaciones esperan ver una versión concreta del sistem a y fallan en fas nuevas versiones. Frecuentem ente, las aplicacio­ nes tienen errores latentes que quedan expuestos debido a los cam bios en la im plem entación. Por ejem plo, la utilización de m em oria después de haberla liberado puede provocar una corrupción sólo si cam bia el orden de reutilización de la m em oria por parte del cúm ulo de m em oria; asim is­ m o una aplicación puede realizar suposiciones acerca de los errores que puedan ser devueltos por una rutina o acerca del núm ero de bits válidos en una dirección. Al ejecutar una aplicación con la capa de m odificación W indow s 95/98 habilitada, el sistem a proporciona un com portam iento m ucho m ás próxim o al de W indow s 95/98, aunque a expensas de un rendim iento reducido y una interoperabilidad limitada con las otras aplicaciones.

22.4.5 Subsistema POSIX El subsistem a POSIX está diseñado para ejecutar aplicaciones POSIX escritas de acuerdo con el estándar POSIX, el cual e&tá basado en el modelo UNIX. Las aplicaciones POSIX pueden ser inicia­ das por el subsistem a API W in32 o por otra aplicación POSIX. Las aplicaciones POSIX utilizan el ser­ vidor P S X S S . E X E del subsistem a POSIX, la biblioteca de m ontaje dinám ico POSIX P S X D L L . DLL y el gestor de sesión de consola POSIX, P O S I X . EXE. A unque el estándar POSIX no especifica los tem as de im presión, las aplicaciones POSIX pueden utilizar im presoras de form a transparente a través del m ecanism o de redirección de W indow s XP. Las aplicaciones POSIX tienen acceso a todos los sistem as de archivos existentes en el sistema W indow s XP; el entorno POSIX im pone una serie de perm isos de tipo UNIX en los árboles de direc­ torios. D ebido a cuestiones de planificación, el sistema POSIX en W indow s XP no se incluye con el sis­ tema, sino que se com ercializa por separado para los servidores y sistem as de sobrem esa profe­ sionales. Proporciona un nivel m ucho más alto de com patibilidad con las aplicaciones UNIX que las versiones anteriores de NT. La m ayoría de las aplicaciones UNIX com únm ente disponibles se pueden com pilar y ejecutar sin ningún cambio sobre la últim a versión de Interix.

22.4.6 Subsistemas de inicio de sesión y de seguridad Antes de que un usuario pueda acceder a ningún objeto en W indow s XP, dicho usuario debe ser autenticado por el servicio de inicio de sesión WINLOGON. WINLOGON se encarga de responder a J-

742

Capítulo 22 Windows XP

la secuencia de atención segura (Contro 1-Alt-Supr.). La secuencia de atención segura es un meca­ nism o obligatorio para evitar que una aplicación pueda actuar com o caballo de Troya. Sólo WlNLOGON puede interceptar esta secuencia para m ostrar una pantalla de inicio de sesión, modificar contraseñas y bloquear la estación de trabajo. Para poder ser autenticado, un usuario debe dispo­ ner de una cuenta y proporcionar la contraseña correspondiente. Alternativam ente, el usuario puede iniciar una sesión em pleando una tarjeta inteligente y un núm ero de identificación perso­ nal, de acuerdo con las políticas de seguridad (o directivas de seguridad de acuerdo con la termi­ nología de M icrosoft) que se estén aplicando dentro del dom inio. El subsistem a local de autoridad de seguridad (LSASS, local security authority subsystem ) es el proceso que genera los testigos de acceso que representan a los usuarios en el sistema. Este sub­ sistem a invoca un p a q u e te d e a u te n tic a c ió n para llevar a acabo la autenticación utilizando la inform ación procedente del subsistem a de inicio de sesión o del servidor de red. Normalmente, el paquete de autenticación sim plem ente consulta la inform ación de cuentas en una base de datos local y com prueba si la contraseña es correcta. A continuación, el subsistem a de seguridad gene­ ra el testigo de acceso para el ID de usuario, que contendrá los privilegios apropiados, los límites de cuota y los identificadores de grupo. Cuando el usuario trate de acceder a un objeto en el sis­ tema, com o por ejem plo, abriendo un descriptor del objeto, se pasa el testigo de acceso al monitor de referencia de seguridad, que com prueba los privilegios y cuotas. El paquete de autenticación predeterm inado para los dom inios W indow s XP es Kerberos. LSASS tam bién se encarga de imple­ m entar políticas de seguridad tales com o las contraseñas fuertes, es responsable de autenticar a los usuarios y se encarga de realizar el cifrado de los datos y las claves.

22.5 Sistema de archivos H istóricam ente, los sistem as MS-DOS han utilizado el sistem a de archivos FAT (FAT, file-allocation table, tabla de asignación de archivos). El sistem a de archivos FAT de 16 bits tiene diversas des­ ventajas, incluyendo el fenóm eno de la fragm entación interna, un lím ite de tamaño de 2 GB y una falta de protección de acceso para los archivos. El sistem a de archivos FAT de 32 bits resolvió los problem as de tam año y de fragm entación, pero su rendim iento y sus características siguen sien­ do pobres por com paración con los sistem as de archivos m odernos. El sistem a NTFS es mucho mejor. Fue diseñado para incluir num erosas funciones, incluyendo m ecanism os de recuperación de datos, seguridad, tolerancia a fallos, soporte de sistem as de archivos y archivos de gran tama­ ño, m últiples flujos de datos, nom bres UNICODE, archivos dispersos, cifrado, m ecanism o de dia­ rio, copias de volúm enes ocultas y com presión de archivos. W indow s XP utiliza NTFS com o su sistem a de archivos básico, asi que nos vamos a centrar aquí en ese sistem a de archivos. Sin em bargo, W indow s XP continúa utilizando FAT16 para leer dis­ quetes y otros soportes extraíbles. Y, a pesar de las ventajas de NTFS, FAT32 continúa siendo im portante para la interoperabilidad de soportes físicos con sistem as W indow s 95/98. Windows XP perm ite em plear tipos de sistem as de archivos adicionales para los form atos com unes utiliza­ dos en los soportes CD y DVD.

22.5.1 Estructura interna de NTFS _ . La entidad fundam ental en NTFS es el volum en. Los volúm enes se crean con la utilidad de gestión de discos lógicos de W indow s XP y están basados en una partición de disco lógico. Un volum en puede ocupar una parte de un disco, un disco com pleto o incluso varios discos. NTFS no trata con los sectores individuales del disco, sino que utiliza clusters com o unidades de asignación de disco. U n clu ster es un conjunto de sectores de disco, cuyo número es una potencia de 2. El tam año de cluster se configura en el m om ento de form atear el sistem a de archivos NTFS. El tam año de cluster predeterm inado es igual al tam año de sector para los volúm enes de hasta 512 MB, es igual a 1 KB para volúm enes de hasta 1 GB, 2 KB para volúm enes de hasta 2 GB y 4 KB para los volúm enes de m ayqr tam año. Este tam año de cluster es m ucho m enor que el del sistema de archivos FAT de 16 bits, y este pequeño tam año reduce la cantidad de fragm entación interna. Com o ejem plo, considere un disco de 1,6 GB con 16.000 archivos. Si utilizamos un sistem a de

22.5 Sistema de archivos

743

archivos FA T-16, se podrían perder 400 M B debido a la fragm entación interna por el tam año de cluster es de 32 KB. En NTFS, sólo se perderían 17 M B al alm acenar los mismos archivos. NTFS utiliza n ú m e ro s ló g ic o s d e c lu s te r (LCN, logical cluster num bers) com o direcciones d e disco. El sistem a asigna esos identificadores num erando los clusters desde el com ienzo del disco hasta el final, de m anera secuencial. U tilizando este esquem a, el sistem a puede calcular el despla­ zam iento en disco físico (en bytes) m ultiplicando el LCN por el tamaño de cluster. Un archivo en NTFS no es un sim ple flujo de bytes com o en MS-DOS o UNIX; en lugar de ello, es un objeto estructurado com puesto de a tr ib u to s con tipo. Cada atributo de un archivo es un flujo de bytes independiente que puede ser creado, borrado, leído y escrito. Algunos tipos de atributo son estándar para todos los archivos, incluyendo el nom bre de archivo (o nom bres, si el archivo tiene alias, com o por ejem plo un nom bre corto MS-DOS), la fecha de creación y el descriptor de seguridad que especifica el control de acceso. Los datos de usuario se alm acenan en los atributos de datos. La m ayoría de los archivos de datos tradicionales tienen un atributo de datos sin nom bre que contiene todos los datos del archivo. Sin em bargo, pueden crearse flujos de datos adicionales con nom bres explícitos. Por ejem plo, en archivos M acintosh alm acenados en un servidor W indow s XP, el subarchivo de recursos es un flujo de datos nom inado. Las interfaces IProp del m odelo COM (Com ponent O bject M odel, m odelo de objetos com ponentes) utiliza un flujo de datos nom inado para alm acenar propiedades de los archivos norm ales, incluyendo m iniaturas de las im ágenes. En general, pueden añadirse atributos según sea necesario y a esos atributos se accede utilizando una sintaxis nom bre_archivo:atributo. NTFS devuelve el tam año del atributo sin nom bre sólo en respues­ ta a las operaciones de consulta de archivo, com o por ejem plo cuando se ejecuta el com ando d i r . Todos los archivos en NTFS se describen m ediante uno o más registros dentro de una m atriz alm acenada en un archivo especial denom inado tabla m aestra de archivos (MFT, m aster file table). El tam año de un registro se determ ina cuando se crea el sistem a de archivos y puede ir de 1 a 4 KB. Los atributos de pequeño tam año se alm acenan en el propio registro de la MFT y se denom i­ nan a trib u to s r e s id e n te s . Los atributos de m ayor tam año, com o por ejem plo el cuerpo de los datos sin nom bre, se denom inan a trib u to s n o re s id e n te s y se alm acenan en una o más e x te n s io ­ n e s contiguas del disco; en el registro MFT se alm acena un puntero a cada extensión. Para un archi­ vo de pequeño tam año, incluso el propio atributo de datos puede caber dentro del registro MFT. Si un archivo tiene m uchos atributos o si está altam ente fragm entado (de modo que se necesitan m uchos punteros para apuntar a todos los fragm entos), puede que un sólo registro de la MFT no sea lo suficientem ente grande. En este caso, el archivo se describe m ediante un registro denom i­ nado re g is tr o b a s e d e l a rc h iv o , que contiene punteros a una serie de registros de desbordam ien­ to que alm acenan los atributos y punteros adicionales. Cada archivo de un volum en NTFS tiene un ID unívoco denom inado re fe r e n c ia d e a rc h iv o . La referencia de archivo es un valor de 64 bits com puesto por un núm ero de archivos de 48 bits y de un núm ero de secuencia de 16 bits. El núm ero de archivo es el núm ero de registro (es decir, la posición en la matriz) dentro de la MFT que describe el archivo. El núm ero de secuencia se incre­ menta cada vez que se reutiliza una entrada de la MFT. El núm ero de secuencia perm ite a NTFS realizar com probaciones internas de coherencia, com o por ejem plo detectar una referencia obso­ leta a un archivo borrado después de que la correspondiente entrada a la MFT haya sido reutilizada para un nuevo archivo. 22.5.1.1 Á rbol B + d e N TFS Al igual que en MS-DOS y UNIX, el espacio de nom bres de NTFS está organizado com o una jerar­ quía de directorios. C ada directorio utiliza una estructura de datos denom inada árbol B+ para alm acenar un índice de los nom bres de archivo contenidos en ese directorio. Se utiliza un árbol B+ porque elim ina el coste de reorganizar el árbol y tiene la propiedad de que la longitud de cada ruta desde la raíz del árbol hasta un nodo hoja es idéntica. La raíz del índice de un directorio con­ tiene el nivel superior del árbol B+. Para un directorio de gran tamaño, este nivel superior conten­ drá punteros a extensiones del disco donde se alm acena el resto del árbol. Cada entrada del directorio contiene el nom bre y la referencia del archivo, así como una copia de la marca tempo-

744

Capítulo 22 Windows XP

ra l d e la ú ltim a a c tu a liz a c ió n y del ta m a ñ o d el a rc h iv o , v a lo re s a m b o s to m a d o s d e los atrib u tos d el a rc h iv o re s id e n te s e n la MFT. E n el d ire cto rio se a lm a c e n a n c o p ia s d e e s ta in fo rm a ció n , p ara p o d e r g e n e ra r d e m a n e ra e ficien te lista d o s d e d ire cto rio . P u e s to q u e to d o s lo s n o m b re s d e arch i­ v o , ta m a ñ o s y fe ch a s d e a c tu a liz a c ió n e stá n d isp o n ib les e n el p ro p io d ire cto rio , n o h a y n ecesid ad d e e x tra e r e sto s a trib u to s d e las e n tra d a s MFT d e c a d a u n o d e lo s a rc h iv o s .

22.5.1.2 M etadatos NTFS Los m etadatos del volum en NTFS se alm acenan en archivos. El prim ero de estos archivos es la MFT. El segundo archivo, que se utiliza durante la recuperación si resulta dañada la MFT, contie­ ne una copia de las prim eras 16 entradas de la MFT. Los siguientes archivos tam bién son de pro­ pósito especial e incluyen el archivo de registro, el archivo de volum en, la tabla de definición de atributos, el directorio raíz, el archivo de m apa de bits, el archivo de arranque y el archivo de clus­ ters erróneos. A continuación se describe el papel de cada uno de estos archivos. • El archivo de registro alm acena todas las actualizaciones de m etadatos realizadas en el archivo. • El archivo de volum en contiene el nom bre del volum en, la versión de NTFS que ha forma­ teado el volum en y un bit que indica si el volum en puede haber resultado corrom pido y necesita com probarse su coherencia. • La tabla de definición de atributos indica qué tipos de atributos se usan en el volum en y qué operaciones pueden realizarse con cada uno de ellos. • El directorio raíz es el directorio del nivel superior dentro de la jerarqu ía del sistem a de archivos. • El archivo de m apa de bits indica qué clusters del volum en están asignados a archivos y cuáles otros están libres. • El archivo de arranque contiene el código de arranque de W indow s XP y debe estar ubica­ do en una dirección concreta del disco, para que pueda ser localizado fácilm ente por un car­ gador de arranque sim ple alm acenado en ROM. El archivo de arranque tam bién contiene la dirección física de la MFT. • El archivo de c lu sters erróneos re g is tra las á re a s in c o rre c ta s q u e el v o lu m e n p u e d a co n te ­ n e r; NTFS u tiliza este re g is tro p a ra p ro p ó sito s d e r e c u p e ra c ió n d e e rro re s .

22.5.2 Recuperación En m uchos sistem as de archivos simples, un fallo de alim entación en el instante incorrecto puede dañar las estructuras de datos del sistema de archivos tan gravem ente que el volum en completo resulta corrom pido. M uchas versiones de UNIX alm acenan m etadatos redundantes en el disco, y se recuperan de los fallos catastróficos utilizando el program a f s c k para com probar todas las estructuras de datos del sistem a de archivos y restaurarlas obligatoriam ente a un estado coheren­ te. La restauración de estas estructuras im plica a m enudo borrar los archivos dañados y liberar clusters de datos que hubieran sido escritos con datos del usuario pero no hubieran sido registra­ dos adecuadam ente dentro de las estructuras de m etadatos del sistem a de archivos. Esta com pro­ bación puede ser un proceso m uy lento y puede hacer que se pierdan cantidades significativas de datos. NTFS adopta una técnica diferente para garantizar la robustez del sistem a de archivos. En NTFS, todas las actualizaciones de las estructuras de datos del sistem a de archivos se realizan dentro de transacciones. A ntes de m odificar una estructura de datos, la transacción escribe una entrada de registro que contiene inform ación de rehacer y deshacer; después de haber m odificado las estruc­ turas de datos, la transacción escribe una entrada de confirm ación en el registro para indicar que la transacción ha tenido éxito. >

22.5 Sistema de archivos

745

D espués de un fallo catastrófico, el sistem a puede restaurar las estructuras de datos del siste­ m a de archivos a un estado coherente procesando las entradas del registro, prim ero rehaciendo las operaciones de las transacciones confirm adas y luego deshaciendo las operaciones de las trans­ acciones que no hu bieran sido confirm adas adecuadam ente an tes del fallo catastrófico. Periódicam ente (usualm ente cada cinco segundos), se escribe en el registro un punto de com pro­ bación. El sistem a no necesita las entradas de registro previas al punto de com probación para recuperarse de un fallo catastrófico. Dichas entradas pueden descartarse, con te que e'l archivo de registro no crecerá de form a ilim itada. La primera vez en que se accede a un volum en NTFS des­ pués del arranque del sistem a, NTFS lleva a cabo autom áticam ente una recuperación del sistema de archivos. Este esquem a no garantiza que todos los contenidos de los archivos de usuario sean correctos después de un fallo catastrófico; sólo garantiza que las estructuras de datos del sistem a de archi­ vos (los archivos de m etadatos no estén dañadas y reflejen un cierto estado coherente que existía antes del fallo catastrófico. Teóricam ente, resultaría posible am pliar este esquem a basado en transacciones para cubrir tam bién a los archivos de usuario, y puede que M icrosoft lo haga en el futuro. El registro está alm acenado en el tercero de los archivos de m etadatos colocado, al principio del volum en. Se crea con un tam año fijo m áximo en el m om ento de form atear el sistem a de archi­ vos. El registro tiene dos secciones: el área de registro, que es una cola circular de entradas de registro y el área de rein icio , que alm acena inform ación de contexto, com o por ejem plo la posi­ ción dentro del área de registro donde NTFS debe com enzar a leer durante una recuperación. De hecho, el área de reinicio alberga dos copias de su inform ación, por lo que sigue siendo posible la recuperación si una de las copias resulta dañada durante el fallo. La funcionalidad de registro es proporcionada por el servicio d el archivo de registro de W indow s XP. Adem ás de escribir las entradas de registro y efectuar acciones de recuperación, el servicio del archivo de registro controla el espacio libre existente en dicho archivo. Si el espacio libre llega a ser dem asiado bajo, el servicio del archivo de registro pone en cola las transacciones pendientes y NTFS detiene todas las nuevas operaciones de E /S . D espués de que se com pleten las operaciones que estuvieran en curso, NTFS invoca al gestor de caché para volcar en disco todos los datos y luego reinicia el archivo de registro y aplica las transacciones que estuvieran en cola.

22.5.3 Seguridad La seguridad de un volum en NTFS se deriva del m odelo de objetos de W indows XP. Cada archivo NTFS hace referencia a un descriptor de seguridad, que contiene el testigo de acceso del propieta­ rio del archivo y una lista de control de acceso, que indica los privilegios de acceso concedidos a cada usuario que tenga acceso al archivo. En operación norm al, NTFS no im pone perm isos durante el recorrido de los directorios conte­ nidos en los nom bres de ruta de los archivos. Sin em bargo, por com patibilidad con POSIX, pueden habilitarse estas com probaciones. Las com probaciones de recorrido son inherentem ente más cos­ tosas, ya que el análisis sintáctico m oderno de los nom bres de ruta de los archivos utiliza técnicas de detección de prefijos, en lugar de realizar una apertura com ponente a com ponente de los nom ­ bres de directorio.

22.5.4 Gestión de volúmenes y tolerancia a fallos FtDisk es el controlador de disco tolerante a fallos de W indow s XP. Cuando se instala, propor­ ciona diversas m aneras de com binar múltiples unidades de disco en un único volum en lógico, para m ejorar las prestaciones, la capacidad o la fiabilidad. 22.5.4.1 C on ju n to de volú m enes Una form a de com binar m últiples disco consiste en concatenarlos lógicam ente para form ar un volum en lógico de gran tam año, como se m uestra en la Figura 22.7. En W indow s XP, este J-

746

Capítulo 22 Windows XP

F ig u ra 2 2 .7

Conjunto de volúm enes con dos unidades.

volum en lógico, denom inado co n ju n to d e v o lú m en es, puede estar com puesto de hasta 32 parti­ ciones físicas. U n conjunto de volúm enes que contenga un volum en NTFS puede am pliarse sin perturbar los datos que ya estén alm acenados en el sistem a de archivos. Los m etadatos de mapa de bits contenidos en el volum en NTFS se am plían sim plem ente para cubrir el espacio recién aña­ dido. NTFS continúa utilizando el m ism o m ecanism o LCN que utiliza para un único disco físico, y el FtDisk se encarga de traducir cada desplazam iento dentro del volum en lógico al correspon­ diente desplazam iento dentro de un disco concreto. 22.5.4.2 C onjunto de distribución en bandas Otra form a de com binar m últiples particiones físicas consiste en entrelazar sus bloques por tur­ nos con el fin de form ar lo que denom ina co n ju n to de d istrib u ció n en bandas, como se muestra en la Figura 22.8. Este esquem a tam bién se denom ina RAID nivel 0 o bandas de disco. FtDisk uti­ liza una tam año de banda de 64 KB: los prim eros 64 KB del volum en lógico se alm acenan en la prim era partición física, los segundos 64 KB se alm acenan en la segunda partición física, y así sucesivam ente, hasta que cada una de las particiones ha proporcionado 64 KB de espacio. D espués, la asignación com ienza de nuevo por el prim er disco, asignando el segundo bloque de

disco1(2GB) ■v • f

disco2(2G B)

°r 1

1■

“T LCNs 32- 47 ■

-.•'r-V '»

' '' LCNs 48-6ÍJ '

* •**.-? TV" -- • - . ‘ Sk T E L .

. : 0 r 'v > . .

' - A LCNs 16-31 it\ :l

: * « « ’. ~ ÍKEPáiStV •-■ W

'

-2 ‘

s

•>

unidadlógicaC:4G B Figura 22.8 Conjunto de distribución en bandas con dos discos.

22.5 Sistema de archivos

disco 1 (2 GB)

F ig u ra 22 .9

disco 2 (2 GB)

747

disco 3 (2 GB)

C onjunto de distribución en bandas con paridad, utilizando tres discos.

64 KB. U n conjunto de distribución en bandas form a un único volum en de gran tam año, pero esa peculiar distribución física perm ite m ejorar el ancho de banda de E/S, porque para una operación de E/S de gran tamaño, todos los discos pueden transferir sus datos en paralelo. 22.5.4.3 Conjunto de distribución en bandas con paridad Una variante de esta idea es el denom inado conjunto de distribución en bandas con paridad, que se m uestra en Figura 22.9. Este esquem a tam bién se denom ina RAID nivel 5. Suponga que un con­ junto de distribución en banda tuviera ocho discos. Siete de estos discos alm acenarían bandas de datos, estando cada banda alm acenada en un disco y el octavo disco alm acenaría una banda de paridad para cada banda de datos. La banda de paridad contiene el resultado de aplicar la opera­ ción e x c l u s i v e o r byte a byte a las otras bandas de datos. Si alguna de las ocho bandas resul­ tara destruida, el sistem a puede reconstruir los datos calculando el resultado de la operación e x c l u s i v e o r de las siete restantes. Esta capacidad de reconstruir los datos hace que la m atriz de discos tenga una probabilidad m ucho m enor de perder datos en caso de que se produzca un fallo de disco. O bserve que una actualización de una de las bandas de datos también requiere volver a calcu­ lar la banda de datos. Por tanto, siete escrituras concurrentes en siete diferentes bandas de datos requerirían tam bién actu alizar siete bandas de paridad. Si las bandas de paridad estuvieran todas en el m ism o disco, dicho disco podría tener una carga de E/S siete veces m ayor que la de los dis­ cos de datos. Para evitar crear este cuello de botella, distribuim os las bandas de paridad entre todos los discos, asignándolas por turnos a cada uno de ellos. Para construir un conjunto de dis­ tribución en bandas con paridad, necesitam os un m ínim o de tres particiones de igual tam año loca­ lizadas en tres discos separados. 22.5.4.4 Espejo de disco Un esquem a aún más robusto es el que se denom ina espejo de disco o RAID nivel 1, la Figura 22.10 ilustra este esquem a. Un conjunto espejo com prende dos particiones de igual tam año situadas en dos discos distintos. C uando una aplicación escribe datos en un conjunto espejo, FtDisk escribe los datos en am bas particiones, de m odo que el contenidos de las dos particiones será idéntico. Si una de las particiones falla, FtDisk dispone de otra copia alm acenada en el espejo. Los conjun­ tos espejo tam bién pueden m ejorar las prestaciones, porque las solicitudes de lectura pueden dis­ tribuirse entre las dos copias en espejo, asignando a cada una de las copias la m itad de la carga de trabajo. Para proteger frente al fallo de una controladora de disco podemos conectar los dos dis-

748

Capítulo 22 Windows XP

Figura 2.10

Conjunto espejo con dos unidades de disco.

eos de un conjunto espejo a dos controladoras de disco separadas. Esta disposición se denomina co n ju n to dúplex. 22.5.4.5

S ecto res de reserva y reasignación de clu sters

Para resolver el problem a de los fallos de los sectores de disco, F t D i s k utiliza una técnica hard­ w are denom inada de sectores de reserva y NTFS em plea una técnica denom inada reasignación de clusters. Los sectores de reserva es una capacidad hardw are proporcionada por m uchas unidades de disco. Cuando se form atea una unidad de disco, se crea un m apa que asigna los núm eros de bloques lógicos a los sectores correctos del disco; durante esta operación se dejan tam bién secto­ res adicionales sin asignar, como reserva. Si falla un sector, F t D i s k ordena a la unidad de disco que lo sustituya por uno de los sectores de reserva. La reasignación de clu sters es una técnica soft­ ware realizada por el sistem a de archivos. Si falla un bloque del disco, NTFS lo sustituye por un bloque diferente no asignado, m odificando los punteros afectados en la M FT. NTFS tam bién anota que ese bloque erróneo nunca debe volver a ser asignado a ningún archivo. Cuando un bloque de disco se vuelve defectuoso, el resultado usual es una pérdida de datos. Pero pueden com binarse las técnicas de sectores de reserva o de asignación de clusters con volú­ m enes tolerantes a fallos con el fin de que el usuario no perciba ese fallo de un bloque de disco. Si falla una operación de lectura, el sistem a reconstruye los datos que faltan leyendo la copia en espejo o calculando el valor de paridad e x c l u s i v e o r en un conjunto de distribución en ban­ das con paridad. Los datos reconstruidos se alm acenan en una nueva ubicación que se obtiene aplicando las técnicas de sectores de reserva o de reasignación de clusters. 2 2 . 5 .5

Compresión y cifrado

NTFS puede com prim ir los datos de archivos individuales o todos los archivos de datos de un directorio. Para com prim ir un archivo, NTFS divide los datos del archivo en u nid ades de com pre­

sión, que son bloques de 16 clusters contiguos. Cuando se escribe cada unidad de com presión, se aplica un algoritm o de com presión de datos. Si el resultado cabe en m enos de 16 clusters, se alma­ cena la versión com prim ida. A la hora de leer, NTFS puede determ inar si los datos han sido com ­ prim idos. En caso afirm ativo, la longitud de la unidad de com presión alm acenada será inferior a 16 clusters. Para m ejorar la velocidad a la hora de leer unidades de com presión contiguas, NTFS extrae los datos anticipadam ente y los descom prim e, adelantándose a las solicitudes de la aplica¿Hnn

22.6 Conexión de red

749

Para los archivos dispersos o para los archivos que contengan fundam entalm ente ceros, NTFS em plea otra técnica para ahorrar espacio. Los clusters que sólo contienen ceros porque nunca se ha escrito en ellos, no están realm ente asignados ni se los alm acena en disco. En lugar de ello, se dejan huecos en la secuencia de núm eros de cluster virtuales alm acenada en la entrada MFT del archivo. A la hora de leer el archivo, si el sistem a encuentra un hueco en los núm eros de cluster virtuales, NTFS se lim ita a rellenar de ceros esa parte del búfer del proceso que haya realizado la invocación. Esta técnica tam bién se em plea en el sistem a operativo UNIX. NTFS p e rm ite el cifra d o d e a rc h iv o s , p u d ié n d o s e e sp e cifica r q u e se cifre n a rc h iv o s in d iv id u a ­ les o d ire cto rio s co m p le to s. E l siste m a d e s e g u rid a d g e stio n a las cla v e s u tiliz a d a s y h a y d is p o n i­ b le u n se rv icio d e re c u p e ra c ió n d e cla v e s p a r a re c u p e ra r las cla v e s p e rd id a s .

22.5.6 Puntos de montaje Los puntos de m ontaje son u n tipo de enlace sim bólico específicos de los directorios de NTFS. P roporcionan un m ecanism o para que los adm inistradores organicen los volúm enes de disco de una form a m ás flexible que utilizando nom bres globales (como por ejem plo las letras de unidad). Los puntos de m ontaje se im plem entan com o un enlace sim bólico con una serie de datos asocia­ dos que contienen el verdadero nom bre del volum en. En el futuro, los puntos de m ontaje susti­ tuirán com pletam ente a las letras de unidad, aunque existirá un período de transición largo, debido a la dependencia que m uchas aplicaciones tienen del esquem a de letras de unidad.

22.5.7 Diario de cam bios NTFS m antiene un diario que describe todos los cam bios que se han realizado en el sistem a de archivos. Los servicios de m odo usuario pueden recibir notificaciones de los cam bios sufridos por el diario e identificar así qu é archivos han sido m odificados. El servicio de indexación de conteni­ dos utiliza el diario de cam bios para identificar los archivos que hay que volver a indexar. El ser­ vicio de replicación de archivos lo utiliza para identificar los archivos que deben replicarse a través de la red.

22.5.8 Copias ocultas de volúmenes W indow s XP im plem enta la capacidad de poner un volum en en un estado conocido y luego crear una copia oculta que puede utilizarse para disponer de una reserva con una vista coherente del volum en. La realización de una copia oculta de un volum en es un tipo de m ecanism o de copia durante la escritura, en el que los bloques m odificados después de haber creado la copia oculta se añaden a la copia. Para conseguir que el bloque esté en un estado coherente se requiere que las aplicaciones cooperen, y a que el sistema no puede saber cuándo los datos utilizados por una apli­ cación se encuentran un estado estable a partir del cual pueda reiniciarse la aplicación de form a segura. La versión de servidor de W indow s XP utiliza copias ocultas para m antener de m anera eficien­ te versiones antiguas de los archivos alm acenados en los servidores de archivos. Esto perm ite a los usuarios ver docum entos alm acenados en los servidores de archivos en el estado que tenían en algún instante anterior. El usuario puede utilizar esta característica para recuperar archivos que accidentalm ente se hayan borrado, o sim plem ente para exam inar versiones anteriores del archivo, todo ello sin necesidad de introducir una cinta con una copia de seguridad.

22.6 Conexión de red W in d o w s XP p erm ite u tiliz a r tan to red e s e n tre igu ales (p e e r-to -p e e r) c o m o re d e s clie n te -se rv id o r. T am b ié n d isp o n e d e fu n cio n a lid a d e s p a ra la g e stió n d e re d . L o s c o m p o n e n te s d e re d d e W in d o w s XP p ro p o rc io n a n m e c a n is m o s d e tra n sp o rte d e d a to s, c o m u n ic a c ió n in te rp ro ce s o s , co m p a rtic ió n d e a rc h iv o s a tra v é s d e la re d y en v ío d e trab ajo s a im p re so ra s re m o ta s .

750

Capítulo 22 W indows XP

22.6.1 Interfaces de red Para describir los m ecanism os de com unicación por red en W indow s XP, en prim er lugar debe­ m os m encionar dos de las interfaces internas de com unicación por red: la esp ecificació n de inter­ fa z de d isp o sitivo de red (NDIS, netw ork device interface specification) y la interfaz de controlador de transporte (TDI, transport driver interface ). La interfaz NDIS fue desarrollada en 1989 por M icrosoft y 3C om para separar los adaptadores de red de los protocolos dé transporte de m odo que cualquiera de ellos pudiera m odificarse sin afectar al otro. NDIS reside en la interfaz entre los niveles de control de enlace de datos y de control de acceso al m edio dentro del modelo OSI y perm ite que diversos protocolos operen sobre m uchos adaptadores de red diferentes. En tér­ m inos del m odelo OSI, la TDI es la interfaz entre el nivel de transporte (nivel 4) y el nivel de sesión (nivel 5). Esta interfaz perm ite que cualquier com ponente del nivel de sesión utilice cualquiera de los m ecanism os de transporte disponibles (un razonam iento sim ilar fue el que condujo al meca­ nism o de stream s en UNIX). La TDI soporta m ecanism os de transportes tanto orientados a conexión com o sin conexión y dispone de funciones para enviar cualquier tipo de datos.

22.6.2 Protocolos W indow s XP im plem enta los protocolos de transporte com o controladores. Estos controladores pueden cargarse y descargarse en el sistem a dinám icam ente, aunque en la práctica suele ser nece­ sario reiniciar el sistem a después de un cam bio. W indow s XP se sum inistra con diversos protoco­ los de com unicación por red. A continuación, vam os a analizar algunos de los protocolos utilizados en W indow s XP para proporcionar diversas funcionalidades de com unicación por red. 22.6.2.1

Protocolo S M B

El protocolo SMB (server-m essage-block, bloque de m ensajes de servidor) fue introducido por pri­ mera vez en MS-DOS 3.1. El sistem a em plea el protocolo para enviar solicitudes de E /S a través de la red. El protocolo SMB utiliza cuatro tipos de mensajes. Los m ensajes S e s s i o n c o n t r o l (con­ trol de sesión) son com andos que inician y term inan una conexión de redirección com o un recur­ so com partido situado en el servidor. Un redirector usa m ensajes F i l e (archivo) para acceder a los archivos del servidor. El sistem a utilizas m ensajes P r i n t e r (impresora) para enviar datos a una cola de im presión rem ota y para recibir inform ación de estado y el m ensaje M e s s a g e se em­ plea para com unicarse con otras estaciones de trabajo. El protocolo SMB fue publicado con el nom­ bre de C om m on In tern et F ile System (CIFS) y está soportado por diversos sistem as operativos. 22.6.2.2 Protocolo N etB IO S El p ro to co lo NetBIOS (n e tw o rk b asic i n p u t /o u t p u t sy ste m , sis te m a b ásico d e e n tr a d a /s a l id a de red ) es u n a in te rfa z d e a b s tra c c ió n h a rd w a r e p a ra re d e s, a n á lo g a a la in terfaz d e a b stra c ció n h a rd ­ w a re BIOS d e s a rr o lla d a p a r a las m á q u in a s d e tip o PC q u e e je cu ta n MS-DOS. NetBIOS, d e sa rro lla d o a p rin cip io s d e la d é c a d a d e los a ñ o s 8 0 , se h a n c o n v e rtid o e n u n a in te rfa z e s tá n d a r d e p ro g ra m a ­ ció n p o r re d . NetBIOS se u tiliz a p a ra e sta b le ce r n o m b re s ló g ic o s e n la re d , p a ra e sta b le ce r co n e x io ­ nes ló g ic a s, o sesio n e s, e n tre d o s n o m b re s ló g ic o s d e la red y p a ra p e rm itir la tra n sfe re n cia fiable d e d a to s e n u n a sesió n m e d ia n te so licitu d e s NetBIOS o SMB.

22.6.2.3 Protocolo N etB E U I El p ro to co lo NetBEUI (NetBIOS e x te n d e d u se r in te rfa ce , in te rfa z d e u su a rio e x te n d id a NetBIOS) fue in tro d u c id o p o r IBM en 1 9 8 5 c o m o p ro to c o lo sim p le y e ficie n te d e co m u n ic a ció n p a ra re d e s de h asta 2 5 4 m á q u in a s . E s el p ro to c o lo p re d e te rm in a d o p a ra las re d e s e n tre ig u a le s W in d o w s 9 5 y p a ra W in d o w s p a ra G ru p o s d e trab ajo . W in d o w s XP u tiliz a NetBEUI cu a n d o q u iere co m p a rtir re c u rso s co n e s ta s red es. E n tre las lim ita cio n e s d e NetBEUI p o d e m o s cita r q u e u tiliza el n om b re real d e las c o m p u ta d o ra s c o m o d ire cc ió n d e las m ism a s y q u e n o s o p o rta el e n ca m in a m ie n to de '-'los d ato s.

22.6 Conexión de red

751

22.6.2.4 Protocolo TCP/IP El conjunto de protocolos TCP/IP (transm ission control protocol/Internet protocol, protocolo de control de transm isión/ protocolo Internet) que se utiliza en Internet, ha llegado a convertirse en un estándar de facto para las estructuras de com unicación por red. W indow s XP em plea T C P/IP para conectarse con una am plia variedad de sistem as operativos y plataform as hardware. El paquete T C P /IP de. .W indows incluye el protocolo SNM (sim ple netw ork-m anagem ent, gestión sim ple de red), el protocolo DHCP (dynamic host-configuration protocol, protocolo dinám ico de configuración de host), el servicio WINS (W indows Internet ñam e Service, servicio de nombres Internet de W indows) y NetBIOS. 22.6.2.5 Protocolo PPTP El p ro to co lo PPTP (point-to-point tunneling protocol, protocolo de túnel punto a punto) es un pro­ tocolo proporcionado por W indow s XP para poder com unicar m ódulos de servidor de acceso rem oto que se ejecuten en m áquinas servidor W indow s XP con otros sistem as cliente que esté conectados a través de Internet. Los servidores de acceso rem oto pueden cifrar los datos enviados a través de la conexión y soportan red es privad as v irtu a le s (VPN, virtual private network) multiprocolo a través de Internet. 22.6.2.6 Protocolos N ovell NetW are Los protocolos N ovell N etW are (servicios de datagram as IPX sobre el nivel de transporte SPX) se utilizan am pliam ente en las redes LAN de tipo PC. El protocolo NWLink de W indows XP conecta NetBIOS con las redes N etW are. En com binación con un redirector (como por ejemplo Client Service for N etW are de M icrosoft o N etW are Client for W indow s de N ovell), este protocolo per­ mite a un cliente W indow s XP conectarse con un servidor N etW are. 22.6.2.7 Protocolo W ebD A V El p ro to c o lo WebDAV (W eb d istrib u te d a u th o rin g a n d v e rsio n in g , a u to ría y v e rsio n a d o d istrib u i­ d os a tra v é s d e W eb ) es u n p ro to co lo b a sa d o en h ttp p a ra la a u to ría e n co la b o ra c ió n a tra v é s d e la red . W in d o w s XP in clu y e u n re d ire cto r WebDAV d e n tro d el siste m a d e a rch iv o s. A l incluir el W eb­ DAV d ire c ta m e n te d e n tro del siste m a d e a rc h iv o s , p u e d e in te g ra rs e co n o tra s fu n cio n alid ad es, c o m o la d e cifrad o . D e e ste m o d o , los a rch iv o s p e rso n a le s p u e d e n a lm a ce n a rs e co n se g u rid a d en e sp a c io s p ú b lico s d e la re d .

22.6.2.8 Protocolo A ppleTalk El protocolo A ppleTalk fue diseñado por Apple com o conexión de bajo coste p a ra p e rm itir a las com putadoras M acintosh com partir archivos. Los sistem as W indow s XP pueden co m p a rtir a rc h i­ vos e im presoras con com putadoras M acintosh a través de A ppleTalk si hay un se rv id o r W indow s XP en la red que esté ejecutando el paquete de servicios de W indow s p a ra M acin tosh .

22.6.3 Mecanismos de procesamiento distribuido Aunque W indow s XP no es un sistem a operativo distribuido, sí que perm ite utilizar.aplicaciones distribuidas. Entre los m ecanism os que dan soporte al procesam iento distribuido en W indows XP podem os citar NetBIOS, las pipes con nom bre y los buzones de correo, los sockets de W indows, el m ecanism o RPC, el lenguaje de definición de interfaces de M icrosoft y, finalm ente, COM. 22.6.3.1

N etBIOS

En W in d o w s XP, las a p lic a cio n e s NetBIOS p u e d e n c o m u n ic a rs e a tra v é s d e la red u tilizan d o N et­ BEUI, NW Link o TC P/IP.

752

Capítulo 22 Windows XP

22.6.3.2 Pipes con nom bre Las pipes con n o m b re son un m ecanism o de m ensajería orientados a conexión. Las pipes con nom ­ bre fueron originalm ente desarrolladas com o interfaz de alto nivel con las conexiones NetBIOS a través de la red. Un proceso tam bién puede utilizar pipes con nom bre para com unicarse con otros procesos situados en la m ism a m áquina. Puesto que a las pipes con nom bre se accede a través de la interfaz del sistem a de archivos, los m ecanism os de seguridad usados para los objetos archivos tam bién se aplican a las pipes con nom bre. El nom bre de una pipe con nom bre tiene un form ato denom inado co n v en io u n ifo rm e de nom ­ b rad o (UNC, uniform nam ing convention). U n nom bre UNC se asem eja a un nom bre típico de un archivo rem oto. El form ato de un nom bre UNC es \ \ n o m b r e _ s e r v id o r \ n o m b r e _ r e c u r s o \x\ y\ z, donde n o m b r e _ s e r v id o r identifica a un servidor de la red; n o m b r e _ r e c u r s o iden­ tifica cualquier recurso que esté a disposición de los usuarios de la red, com o por ejem plo un directorio, un archivo, una pipe con nom bre o una im presoras, y la parte \x\y\z es un nom bre de ruta norm al de un archivo. 22.6.3.3 Buzones de correo Los bu zones de correo son un m ecanism o de m ensajería sin conexión. No son fiables cuando se accede a ellos a través de la red, en el sentido de que un m ensaje enviado a un buzón de correo puede perderse antes de que el receptor llegue a leerlo. Los buzones de correo se em plean para aplicaciones de difusión, com o por ejem plo para localizar com ponentes en la red y tam bién son usados por el servicio explorador de la com putadora W indow s. 22.6.3.4 W in so ck W in so ck es la API de sockets de W indow s XP. W insock es una interfaz de nivel de sesión bastante com patible con los sockets de UNIX, aunque tiene algunas extensiones propias de W indow s XP. Proporciona una interfaz estándar con m uchos protocolos de transporte que pueden tener dife­ rentes esquem as de direccionam iento, de m odo que cualquier aplicación W insock puede ejecutar­ se sobre cualquier pila de protocolos com patible con W insock. 22.6.3.5 Llam adas a proced im iento rem oto Una llam ada a procedim iento rem oto (RPC, rem óte procedure cali) es un m ecanism o cliente-ser­ vidor que perm ite a una aplicación en una m áquina realizar una llamada a procedim iento que invoque código situado en otra m áquina. El cliente llam a a un procedim iento local (una rutina stub) que em paqueta los argum entos dentro de un m ensaje y los envía a través de la red a un pro­ ceso servidor concreto. La rutina stub del lado del cliente se bloquea entonces en espera de una respuesta. M ientras tanto, el servidor desem paqueta el m ensaje, invoca el procedim iento, em pa­ queta los resultados que hay que devolver en un m ensaje y devuelve éste a la rutina stub del clien­ te. La rutina stub del cliente se desbloquea, recibe el m ensaje, desem paqueta los resultados de la llam ada RPC y los devuelve al proceso que realizó la invocación. Este em paquetam iento de los argum entos a veces se denom ina con form ación (marshalling). El m ecanism o RPC de W indow s XP se ajusta al am pliam ente utilizado estándar para entornos de inform ática distribuida basada en m ensajes RPC, por lo que los program as escritos con llam adas RPC de W indows XP son altam ente portables. El estándar RPC es m uy detallado y oculta m uchas de las diferencias de arquitectura existentes entre unas com putadoras y otras, com o por ejem plo los tam años de los núm eros bina­ rios y el orden de los bytes y bits dentro de las palabras usadas en una m áquina concreta, al espe­ cificar form atos de datos estándar para los m ensajes RPC. W in d o w s XP p u e d e e n v ia r m en sajes RPC u tiliz a n d o NetBIOS, u sa n d o W in so ck en re d e s T C P /IP o e m p le a n d o pipes co n n o m b re so b re re d e s L A N M a n a g e r. L a fu n cio n a lid a d LPC, e x p lic a d a a n te ­ rio rm e n te , es sim ilar a RPC, e x c e p to en q u e e n el c a s o d e LPC los m en sajes se p a sa n e n tr e d o s p r o ­ ce s o s q u e se e stá n e je cu ta n d o en la m ism a c o m p u ta d o r a . >

22.6 Conexión de red

753

22.6.3.6 L en g u aje de d efin ició n de in terfaces de M icrosoft Resulta tedioso y bastante proclive a errores escribir el código para conform ar y transm itir los argum entos en el form ato estándar, extraerlos y ejecutar el procedim iento rem oto, conform ar y enviar los resultados devueltos, y extraer y devolver esos resultados al proceso invocador. A fortunadam ente, sin em bargo, buena parte de este código puede generarse autom áticam ente a partir de una sim ple descripción de los argum entos y'd e los resaltados de retom o. W indow s XP proporciona el L en gu aje de d efinición de interfaces de M icrosoft para describir los nom bres, los argum entos y resultados de los procedimientos remotos. El com pilador de este lenguaje genera archivos de cabecera que declaran las rutinas stub para los procedim ientos rem o­ tos, así com o los tipos de datos de los m ensajes de argum entos y valores de retom o. Tam bién gene­ ra el código fuente para las rutinas stub utilizadas en el lado del cliente y para el m ecanism o de extracción y despacho en el lado del servidor. Cuando se m onta la aplicación, se incluyen las ruti­ nas stub. Cuando la aplicación ejecuta la rutina stub RPC, el código generado se encarga del resto. 22.6.3.7 M od elo C O M El m o d e lo COM (com ponent object m odel, m odelo de objetos com ponentes) es un m ecanism o para la com unicación interprocesos que fue desarrollada para W indows. Los objetos COM propor­ cionan una interfaz bien definida para m anipular los datos del objeto. Por ejem plo, COM es la infraestructura utilizada por la te c n o lo g ía OLE (object linking and em bedding, m ontaje e incrus­ tación de objetos) de M icrosoft para insertar hojas de cálculo en docum entos de M icrosoft W ord. W indow s XP tiene una extensión distribuida denom inada DCOM que puede utilizarse a través de una red m ediante RPC con el fin de proporcionar un m étodo transparente de desarrollo de aplica­ ciones distribuidas.

22.6.4 Redirectores y servidores En W indow s XP, una aplicación puede utilizar la API de E /S de W indow s XP para acceder a archi­ vos de una com putadora rem ota com o si fueran locales, siem pre y cuando la com putadora rem o­ ta esté ejecutando un servidor CIFS, com o el proporcionado por W indow s XP o por los sistem as W indow s anteriores. Un re d ir e c to r es el objeto del lado cliente que re-envía las solicitudes de E /S relativas a archivos rem otos, solicitudes que serán satisfechas por un servidor. Para m ejorar las prestaciones y la seguridad, los redirectores y servidores se ejecutan en m odo kem el. A nalizando m ás en detalle este tema, el acceso a un archivo rem oto se produce de la siguiente m anera: 1. La aplicación invoca al gestor de E /S para solicitar que se abra un archivo con un nom bre de archivo en form ato UNC estándar. 2 . El gestor de E /S construye un paquete de solicitud de E /S , com o se describe en la Sección 2 2 .3 .3 .5 .

3. El gestor de E /S detecta que el acceso se refiere a un archivo remoto e invoca un controlador denom inado p r o v e e d o r m ú ltip le UNC [múltiple universal-nam ing-convention provider (MUP)].

4. El MUP envía el paquete de solicitud de E/s asincronam ente a todos los redirectores registra­ dos. 5. Un redirector que pueda satisfacer la solicitud responderá al MUP. Para evitar preguntar a todos los redirectores la m ism a cuestión en el futuro, MUP utiliza una caché para recordar qué redirector puede gestionar este archivo. 6. El redirector envía la solicitud de red al sistema remoto. 7. Los controladores de red del sistem a rem oto reciben la solicitud y la pasan al controlador del servidor.

754

Capítulo 22 Windows XP

8. El controlador del servidor entrega la solicitud al controlador apropiado del sistem a de archi­ vos local. 9. Se invoca el controlador de dispositivo apropiado para acceder a los datos. 10. Los resultados se devuelven al controlador del servidor, el cual los envía al redirector solici­ tante. El redirector devuelve entonces los datos a la aplicación que realizó la invocación a tra­ vés del gestor de E/S. Para las aplicaciones que utilizan la API de red de la API W in32 en lugar de los servicios UNC, se lleva a cabo un proceso sim ilar, salvo porque se em plea un m ódulo denom inado encam inador m ultiproveedor, en lugar de utilizar MUP. En aras de la portabilidad, los redirectores y servidores utilizan la API TDI para el transporte de red. Las propias solicitudes se expresan en un protocolo de m ayor nivel, que es de form a prede­ term inada el protocolo SMB m encionado en la Sección 22.6.2. La lista de redirectores se m antiene en la base de datos del R egistro del sistema. 22.6.4.1 Sistem a de archivos distribuido Los nom bres UNC no siem pre resultan cóm odos, por que puede haber disponibles m últiples ser­ vidores de archivos para proporcionar un m ism o contenido, y los nom bres UNC incluyen explíci­ tam ente el nom bre del servidor. W indow s XP soporta tam bién un protocolo de s is te m a de a rc h iv o s d is trib u id o (DFS, distributed file system) que perm ite a un adm inistrador de red servir los archivos desde m últiples servidores, utilizando un espacio de nom bres distribuido. 22.6.4.2 Redirección de carpetas y caché del lado del cliente Para m ejorar la interactividad de las m áquinas PC em pleadas por los usuarios de em presas que cam bian frecuentem ente de una com putadora a otra, W indow s XP perm ite a los adm inistradores asignar a los usuarios p e r f ile s m ó v ile s , que m antienen las preferencias de los usuarios y otros datos de configuración en los servidores. Entonces, se utiliza un m ecanism o de re d ire c c ió n d e ca r­ p e ta s para alm acenar autom áticam ente los docum entos y otros archivos de los usuarios en un ser­ vidor. Este m ecanism o funciona bien hasta que una de las com putadoras deja de estar conectada a la red, com o por ejem plo una com putadora portátil en un avión. Para proporcionar a los usua­ rios acceso fuera de línea a sus archivos redirigidos, W indow s XP utiliza un m ecanism o de ca c h é d el la d o d el c lie n te (CSC, client-side caching). CSC se utiliza cuando la com putadora está en línea para m antener copias de los archivos del servidor en la m áquina local, con el fin de m ejorar las prestaciones.. Los archivos se vuelcan en el servidor en cuanto son m odificados. Si la com putado­ ra se desconecta, los archivos seguirán estando disponibles y la actualización del servidor se dife­ rirá hasta la siguiente vez que la com putadora esté en línea y disponga de un enlace de red con las adecuadas prestaciones.

22.6.5 Dominios M uchos entornos de red tienen grupos naturales de usuarios, com o por ejem plo los estudiantes de un laboratorio de inform ática o los em pleados de cierto departam ento de una empresa. Frecuentem ente, surge la necesidad de que todos los m iem bros del grupo sean capaces de acce­ der a una serie de recursos com partidos situados en las diversas com putadoras que form a el grupo. Para gestionar los derechos globales de acceso dentro de estos grupos. W indow s XP utili­ za el concepto de dom inio. A nteriorm ente, estos dom inios no tenían ningún tipo de relación con el sistem a de nom bres de dom inio (DNS, dom ain-nam e system) que asigna nom bre de host de Internet a direcciones IP. Sin em bargo, ahora am bos conceptos están estrecham ente relacionados. Específicam ente, un dom inio de W indow s XP es un grupo de estaciones de trabajo y servido­ res W indow s XP que com parten una política de seguridad y una base de datos de usuarios com u­ nes. Puesto que W indow s XP ahora utiliza el protocolo Kerberos para las cuestiones de confianza y de autenticación, un dom inio W indow s XP es lo m ism o que un dom inio Kerberos. Las versiones >

22.6 Conexión de red

755

anteriores de NT utilizaban la idea de controladores de dom inio principales y de reserva; ahora todos los servidores de un dom inio son controladores de dom inio. Adem ás, las versiones anterio­ res requerían que se definieran relaciones de confianza unidireccionales entre los dominios. W indow s X P em plea un enfoque jerárquico basado en DNS y perm ite establecer relaciones de con­ fianza transitivas que p u eden fluir hacia arriba y hacia abajo de la jerarquía. Esta técnica reduce el núm ero de relaciones de confianza requeridas para n dom inios, desde t i * {n - 1) a 0 (n ). Las estaciones de trabajo del dom inio confían en que el controlador de dom inio proporcione informa.-, ción correcta acerca de los derechos de acceso de cada usuario (a través del testigo de acceso del usuario). Todos los usuarios continúan teniendo la capacidad de restringir el acceso a sus propias estaciones de trabajo, independientem ente de lo que cualquier controlador de dom inio pueda decir. 22.6.5.1 B osques y árboles de dom inio Dado que una em presa puede tener m uchos departam entos y un centro educativo m uchas clases, a m enudo es necesario gestionar m últiples dom inios dentro de una m isa organización. U n árbol de dom inios es una jerarqu ía de denom inación DNS contigua para la gestión de m últiples dom i­ nios. Por ejem plo, bell-labs.com podría ser la raíz del árbol, teniendo research.bell-labs.com y pez.belllabs.com com o hijos (correspondientes a los dom inios research y pez). U n bosque es un conjunto de nom bres no contiguos. U n ejem plo serían los árboles bell-labs.com y/o lucent.com. Sin em bargo, un bosque puede estar form ado tam bién por un único árbol de dom inios. 22.6.5.2 Relaciones de confianza Pueden establecerse relaciones de confianza entre dom inios de tres form as distintas; unidireccio­ nales, transitivas y cruzadas. Las versiones de NT hasta la 4.0 sólo perm itían relaciones de confian­ za unidireccionales. U na relación de confianza unidireccional es exactam ente lo que su nombre indica: inform am os al dom inio A de que puede confiar en el dom inio B. Sin em bargo, B no con­ fiará en A, a m enos que se configure otra relación de confianza. En una relación de confianza transitiva, si A confía en B y B confía en C, entonces A , B y C confiarán todos entre sí, ya que las relaciones de confianza transitivas con bidireccionales de m anera predeterm inada. La relaciones de confianza transitivas están habilitadas por om isión para los nuevos dom inios de un árbol y sólo pueden configurarse entre dom inios que form en parte de un m ism o bosque. El tercer tipo, las relaciones de confianza cruzadas, resulta útil para reducir el tráfico de autenticación. Suponga que los dom inios A y B son nodos hoja y que los usuarios de A em plean a m enudo recursos que se encuentran en B. Si se utiliza una relación de confianza transitiva norm al, las solicitudes de autenticación deben recorrer el árbol hasta alcanzar el ancestro com ún de los dos nodos hoja; pero si A y B tienen establecida una relación de confianza cruzada, la inform ación de autenticación se envía directam ente al otro nodo.

22.6.6 Active Directory Active D irectory es la im plem entación de W indow s XP de los servicios LDAP (lightw eight dírectory-access protocol, protocolo ligero de acceso a directorio). Active Directory alm acena la infor­ m ación topológica acerca del dom inio, m antiene las cuentas de usuario y de grupo basadas en el dom inio, con sus correspondientes contraseñas, y proporciona un repositorio de dom inio para tec­ nologías tales com o las políticas de grupo y la duplicación inteligente en espejo (Intellimirror). Los adm inistradores em plean las políticas de grupo para establecer estándares relativos a las preferencias y al softw are de las m áquinas de sobrem esa. Para m uchos grupos de Tecnologías de la Inform ación de las grandes em presas, la uniform idad reduce enorm em ente el coste relaciona­ do con la infraestructura inform ática. La tecnología de duplicación inteligente en espejo se utiliza junto con las políticas de grupo para especificar qué softw are debe estar disponible para cada clase de usuario, e incluso para instalar autom áticam ente el softw are bajo dem anda desde un ser­ vidor corporativo.

'56

Capítulo 22 Windows XP

22.6.7 Resolución de nombres en redes TCP/IP En una red IP, la resolu ció n de n om bres es el proceso de convertir un nom bre de com putadora en una dirección IP, com o por ejem plo traduciendo www .bell-labs.com a 135.104.1.14. W indow s XP proporciona varios m étodos de resolución de nom bres, incluyendo WINS (W indows Internet ñam e service, servicio de-nombres Internet de W indow s), resolución de nom bres de difusión, DNS (dom ain-nam e system , sistem a de nom bres de dom inio), un archivo hosts y un archivo LMHOSTS. M uchos sistem as operativos em plean la m ayor parte de estos m étodos, por lo que aquí solo des­ cribirem os WINS. En W INS, dos o m ás servidores WINS m antienen una base de datos dinám ica de corresponden­ cias entre nom bres y direcciones IP, junto con un softw are cliente que perm ite consultar a los ser­ vidores. Se utilizan al m enos dos servidores para que el servicio W INS pueda sobrevivir a un fallo de servidor y para distribuir entre m últiples m áquinas la carga de trabajo de la resolución de nom­ bres. WINS utiliza el protocolo DHCP (dynamic host-configuration protocol, protocolo dinám ico de configuración de host). DHCP actualiza autom áticam ente las configuraciones de direcciones en la base de datos WINS, sin que el usuario o el adm inistrador intervengan de la form a siguiente: cuan­ do arranca un cliente DH CP, difunde un m ensaje d i s c o v e r y cada servidor DHCP que recibe el m ensaje responde con un m ensaje o f f e r que contiene una dirección IP e inform ación de configu­ ración para el cliente. El cliente selecciona una de las configuraciones y envía u n mensaje r e q u e s t al servidor DH CP seleccionado. El servidor DHCP responde con la dirección IP y con la inform ación de configuración que indicó anteriorm ente, así com o una concesión de dicha direc­ ción. La concesión proporciona al cliente el derecho a utilizar esa dirección IP durante un período de tiem po especificado. Cuando ha transcurrido la m itad del período de concesión, el cliente tra­ tará de renovar la concesión de esa dirección. Si la concesión no se renueva, el cliente deberá obte­ ner una nueva concesión.

22.7 Interfaz de programación La API W in32 es la interfaz fundam ental para em plear las capacidades ofrecidas por W indow s XP. Esta sección describe cinco aspectos principales de la API W in32: acceso a los objetos del kem el, com partición de objetos entre procesos, gestión de procesos, com unicación interprocesos y gestión de m em oria.

22.7.1 Acceso a los objetos del kernel El kem el de W indow s XP proporciona m uchos servicios que los program as de aplicación pueden utilizar. Los program as de aplicación obtienen estos servicios m anipulando objetos del kem el. Un proceso obtiene acceso a un objeto del kem el denom inado XXX llam ando a la función CreateXXX para abrir un descriptor de XXX. Este descriptor es unívoco para el proceso. Dependiendo del pro­ ceso que se esté abriendo, si la función Create() falla, puede devolver 0, o puede devolver una constante especial denom inada INVALID_HANDLE_VALUE. Un proceso puede cerrar cualquier descriptor invocando la función CloseHandle O y el sistem a puede borrar el objeto si el conta­ dor de procesos que están utilizando el objeto cae a 0.

22.7.2 Compartición de objetos entre procesos W indow s XP proporciona tres form as para com partir objetos entre los procesos. La prim era forma es que un proceso hijo herede un descriptor del objeto. Cuando el padre invoca a la función CreateXXX, sum inistra una estructura SECURITIES_ATTRIBUTES con el cam po blnheritHandle configurado con el valor TRUE. Este cam po crea un descriptor heredable. A continuación, se crea el proceso hijo, pasando un valor TRUE al argum ento blnheritHandle de la función CreateProcess ( ) . La Figura 22.11 muestra un ejem plo de código que crea un descriptor de sem áforo heredado por un proceso hijo.

22.7 Interfaz de programación

757

SECURITY ATTRIBUTES sa; sa.nlength = sizeof(sa); sa.IpSecurityDescriptor = NULL; sa.blnheritHandle = TRUE; Handle a_semaphore = CreateSemaphore(&sa, 1, 1, NULL); char command_line[13 2] ; ostrstream ostríng(command_line, sizeof(command_line)); ostring

23,1 Sistemas pioneros

769

los hum anos son considerablem ente más lentos que la com putadora. En consecuencia, resulta conveniente sustituir las operaciones hum anas por softw are del sistem a operativo. El secuenciam iento autom ático de trabajos elim ina la necesidad de que las personas lleven a cabo el secuenciam iento de trabajos y tam bién el tiem po de preparación. Sin em bargo, com o hem os apuntado anteriorm ente, incluso con esta solución, la CPU estaba inactiva a m enudo. El problema' era la'velocidad de los dispositivos de E/S m ecánicos, que son intrínsecam ente m ás lentos que los dispositivos electrónicos. Incluso una CPU lenta funciona en el rango de los m icrosegundos, ejecutando cada segundo m iles de instrucciones. Un lector de tarje­ tas rápido, por contraste, podía leer 1.200 tarjetas por m inuto (es decir, 20 tarjetas por segundo). Por tanto, la diferencia de velocidad entre la CPU y sus dispositivos de E/S podía ser de tres órde­ nes de m agnitud o m ayor. Con el tiempo, por supuesto, las m ejoras en la tecnología permitieron construir dispositivos de E/S m ás rápidos. Lam entablem ente, las velocidades de CPU se increm en­ taron con m ayor rapidez aún, por lo que el problem a no sólo no se resolvió sino que se vio exa­ cerbado.

23.1.3 E/S solapada U na solución com ún al problem a de la E/S era sustituir los lentos lectores de tarjetas (dispositivos de entrada) e im presoras de líneas (dispositivos de salida) por unidades de cinta magnética. La m ayoría de los sistem as inform áticos a finales de la década de 1950 y principios de 1960 eran sis­ tem as de procesam iento por lotes que leían utilizando lectores de tarjetas y escribían en im preso­ ras de líneas o perforadoras de tarjetas. Sin em bargo, en lugar de hacer que la CPU leyera directam ente de las tarjetas, lo que se hizo fue copiar prim ero las tarjetas en cinta magnética m ediante un dispositivo separado. Cuando la cinta estaba suficientem ente llena, se la descargaba y se llevaba hasta la com putadora. Cuando hacía falta una tarjeta para un programa, se leía el registro equivalente de la cinta. De form a sim ilar, la salida se escribía en cinta y el contenido de la cinta se im prim ía posteriorm ente. Los lectores de tarjetas y las im presoras de líneas se operaban fuera de línea, en lugar de ser controlados por la com putadora principal (Figura 23.3). U na ventaja obvia de la operación fuera de línea era que la com putadora principal ya no esta­ ba restringida por la velocidad de los lectores de tarjeta y las im presoras de líneas, sino sólo por la velocidad de las unidades de cinta m agnética que eran m ucho más rápidas. La técnica de uti­ lizar cintas m agnéticas para toda la E/S podía aplicarse para diversos tipos de equipos, como lectores de tarjetas, perforadoras de tarjetas, trazadoras gráficas, lectores de cintas de papel e im presoras. La verdadera ganancia derivada de la operación fuera de línea proviene de la facilidad de uti­ lizar m últiples sistem as de conversión lector a cinta y cinta a im presora para una misma CPU. Si la CPU puede procesar las entradas dos veces más rápido de que el lector puede leer las tarjetas, entonces dos lectores que estuvieran trabajando sim ultáneam ente podían producir suficientes cin­ tas m agnéticas com o para m antener ocupada a la CPU. Sin em bargo, existe también una desven­ taja: un retardo m ayor a la hora de ejecutar cada trabajo concreto. El trabajo debe primero leerse en cinta, después debe esperar hasta que sea leído un núm ero suficiente de otros trabajos en la

lector de tarjetas

unidades de cinta

unidades de cinta

impresora de líneas

(b)

Figura 23.3 Operación de los dispositivos de E/S (a) en línea y (b) fuera de línea.

770

Capítulo 23 Sistemas operativos influyentes

cinta, con el fin de “llenarla”. Después, había que rebobinar la cinta, descargarla, llevarla a mano hasta la CPU y m ontarla en una unidad de cinta libre. Por supuesto, este proceso no resulta poco razonable para los sistem as de procesam iento por lotes, ya que pueden agruparse m últiples tra­ bajos sim ilares en una cinta antes de llevarla a la com putadora. A unque la preparación fuera de línea de los trabajos continuó durante un cierto tiem po, pron­ to fue sustituida en la m ayoría de los sistem as. Los sistem as de disco com enzaron a estar am plia­ m ente disponibles y representaban una enorm e m ejora con respecto a la operación fuera de línea. El problem a con los sistem as de cinta era que el lector de tarjetas no podía escribir en un extrem o de la cinta m ientras que la CPU estuviera leyendo del otro extrem o. Era necesario escribir la cinta com pleta antes de rebobinarla y leerla, porque las cintas son, por naturaleza, disp ositivos de acce­ so secuencial. Los sistem as de disco elim inaban este problem a al ser dispositivos de acceso alea­ torio. Puesto que el cabezal se m ueve de un área del disco a otra, un disco puede conm utar rápidam ente del área del disco que esté siendo usada por el lector de tarjetas para alm acenar nue­ vas tarjetas, a la posición que la CPU necesita para leer la “siguiente” tarjeta. En un sistem a de disco, las tarjetas se leen directam ente desde el lector de tarjetas al disco. La ubicación de las im ágenes se registra en una tabla m antenida por el sistem a operativo. Cuando se ejecuta un trabajo, el sistem a operativo satisface sus solicitudes de entrada de lector de tarjetas leyendo del disco. De form a sim ilar, cuando el trabajo solicita a la im presora im prim ir una línea, esa línea se copia en un búfer del sistem a y se escribe en el disco. Cuando se ha com pletado el tra­ bajo, se im prim e verdaderam ente la salida. Esta form a de procesam iento se denom ina s p o o lin g (Figura 23.4); el nom bre es un acrónim o de sim ultaneous peripheral operation on line (operación sim ultánea de periféricos en línea). El spooling, en esencia, utiliza el disco com o un inm enso búfer para leer lo m ás anticipadam ente posible en los dispositivos de salida y para alm acenar los archi­ vos de salida hasta que los dispositivos de salida estén en disposición de aceptarlos. El spooling tam bién se utiliza para el procesam iento de datos en sitios rem otos. La CPU envía los datos a través de determ inadas rutas de com unicaciones a una im presora rem ota (o acepta un trabajo de entrada com pleto de un lector de tarjetas rem oto). El procesam iento rem oto se realiza a su propia velocidad, sin intervención de la CPU. La CPU sólo necesita que se le notifique cuando se ha com pletado el procesam iento, para poder enviar el siguiente lote de datos. El spooling solapa la E /S de un trabajo con los cálculos de otros trabajos. Incluso en un sistema sim ple, el gestor de spooling puede estar leyendo la entrada de un trabajo m ientras im prim e la sali­ da de un trabajo diferente. Durante este tiem po, pueden tam bién estar ejecutándose otros traba­ jo s, o bien esos trabajos pueden estar leyendo sus “tarjetas” del disco e “im prim iendo” su línea de salida en el disco. El spooling tien e un e fe cto b en eficio so d ire cto so b re el re n d im ie n to del siste m a . El ú n ico co ste a so c ia d o es el e sp a c io d e d isco y u n as p o c a s tab las, y a c a m b io se p u e d e n so la p a r los cá lc u lo s de u n trab ajo c o n las o p e ra cio n e s d e E /S d e o tro s trab ajo s. P o r ta n to , el spooling p u e d e m a n te n e r tra ­ b a ja n d o ta n to a la CPU c o m o a los d is p o sitiv o s d e E /S a u n a ta s a m u c h o m á s a lta. El spooling co n disco

Figura 23.4 Spooling.

23.3 XDS-940

771

duce de m anera natural al concepto de m ultiprogram ación, que es la base de todos los sistem as operativos m odernos.

23.2 Atlas El sistem a operativo Atlas (Kilburn et al. [1961], H ow arth et al. [1961]) fue diseñado e n la univer­ sidad de M anchester, Inglaterra, a finales de los años 50 y principios de los 60. M uchas de sus características básicas que eran novedosas en aquel m om ento han llegado a convertirse en com ­ ponentes estándar de los sistem as operativos m odernos. Los controladores de dispositivo eran una de las partes principales del sistem a. A dem ás, se añadieron llam adas al sistem a m ediante un conjunto de instrucciones especiales denom inado códigos extra. A tlas era un sistem a operativo de procesam iento por lotes con spooling. El spooling perm itía al sistem a planificar los trabajos de acuerdo con la disponibilidad de los dispositivos periféricos, com o unidades de cinta m agnética, lectores de cinta de papel, perforadoras de cinta de papel, im presoras de líneas, lectores de tarjetas y perforadoras de tarjetas. Sin em bargo, la característica m ás destacable de A tlas era su gestión de la m em oria. La m em o­ ria de n ú cleo era novedosa y m uy cara en aquella época. M uchas com putadoras, com o la IBM 650, utilizaban un tam bor com o sistem a principal. El sistem a A tlas em pleaba un tam bor com o m em o­ ria principal, pero tenía una pequeña cantidad de la m em oria de núcleo que se usaba com o caché para el tam bor. Se em pleaba un m ecanism o de paginación bajo dem anda para transferir autom á­ ticam ente inform ación entre la m em oria de núcleo y el tambor. El sistem a Atlas utilizaba una com putadora de fabricación británica con palabras de 48 bits. Las direcciones tenían 24 bits, pero estaban codificadas en decimal, lo qu e sólo perm itía direccionar 1 m illón de palabras. En aquella época, este espacio de direcciones era extrem adam ente gran­ de. La m em oria física de A tlas era un tam bor con 98 KB-palabras y u n núcleo m agnético de 16 KB-palabras. La m em oria se dividía en páginas de 512 palabras, proporcionando 32 m arcos de m em oria física. Una m em oria asociativa de 32 registros im plem entaba la correspondencia entre direcciones virtuales y direcciones físicas. Si se producía un fallo de página, se invocaba un algoritm o de sustitución de páginas. U no de los m arcos de m em oria se m antenía siem pre vacío, para que la transferencia del tam bor pudiera iniciarse inm ediatam ente. El algoritm o de sustitución de páginas trataba de predecir el com porta­ m iento futuro del acceso a m em oria basándose en el com portam iento anterior. Cada vez que se accedía a un m arco, se activaba un bit de referencia para el mismo. Los bits de referencia se leían en m em oria cada 1.024 instrucciones y se retenían los últim os 32 valores de estos bits. Este histo­ rial se utilizaba para definir el tiem po transcurrido desde la referencia m ás reciente (q) y el inter­ valo entre las dos últim as referencias (í2). Las páginas para sustitución se elegían en el orden siguiente: 1. Cualquier página con q > t2 + 1. Se consideraba que dicha página ya no estaba en uso. 2. Si q < f2 para todas las páginas, entonces se sustituía la página con el valor t2 - q m ás grande. El algoritm o de sustitución de páginas asum e que los program as acceden a la m em oria en bucles. Si el tiem po entre las dos últim as referencias es t2, entonces se espera que se produzca otra referencia t2 unidades de tiem po m ás tarde. Si no se produce una referencia (q > t2), se asum e que la página ya no está siendo utilizada y esa página se sustituye. Si todas las páginas siguen estan­ do en uso, se sustituye a la página que no va a ser necesaria durante el período más largo de tiem ­ po. El tiem po esperado hasta la siguiente referencia es t2 - q.

23.3 XDS-940 El sistem a operativo XDS-940 (Lichtenberger y Pirtle [1965]) fue diseñado en la U niversidad de California en Berkeley. Al igual que el sistem a Atlas, utilizaba un m ecanism o de paginación para la gestión de m em oria. Sin em bargo, a diferencia del sistem a Atlas, era un sistem a de tiem po com ­ partido.

772

Capítulo 23 Sistemas operativos influyentes

La paginación se utilizaba únicam ente para la reubicación, y no para la paginación bajo dem anda. La m em oria virtual de cualquier proceso de usuario estaba form ada por hasta 16 KBpalabras, m ientras que la m em oria física estaba form ada por 64 KB-palabras. Cada página tenía 2 K B-palabras y la tabla de páginas se alm acenaba en registros. Puesto que la m em oria física era m ás grande que la m em oria virtual, podía haber varios procesos de usuario sim ultáneam ente en m emoria. EÍ núm ero de usuarios podía increm entarse com partiendo páginas que contuvieran código re-entrante de sólo lectura. Los procesos se m antenían en un tam bor y se intercam biaban para cargarlos en m em oria según fuera necesario. El sistem a XDS-940 fue construido a partir de un sistem a XDS-930 m odificado. Las m odificacio­ nes eran las típicas que se realizan en una com putadora básica para poder escribir apropiada­ m ente un sistem a operativo. Se añadió un m odo m onitor de usuario y se definieron com o privi­ legiadas ciertas instrucciones com o las de detención y E/S. Los intentos de ejecutar una instruc­ ción privilegiada en m odo usuario provocaban una interrupción dirigida al sistem a operativo. Se añadió una instrucción de llam ada al sistem a al conjunto de instrucciones en m odo usuario. Esta instrucción se utilizaba para crear nuevos recursos, com o archivos, perm itiendo al sistema operativo gestionar los recursos físicos. Los archivos, por ejem plo, se asignan en bloques de 256palabras del espacio de alm acenam iento del tam bor. Se em pleaba un m apa de bits para gestionar los bloques libres del tam bor. C ada archivo tenía un bloque de índice con punteros a los bloques de datos reales. Los bloques de índice estaban encadenados. El sistem a XD S-940 tam bién proporcionaba llam adas al sistem a para perm itir a los procesos crear, iniciar, suspender y destruir subprocesos. U n program ador podía construir un sistem a de procesos y los distintos procesos podían com partir m em oria para com unicación y sincronización. La creación de procesos definía una estructura en árbol, en la que un proceso era la raíz y sus sub­ procesos eran los nodos situados por debajo de ella en el árbol. C ada uno de los subprocesos podía, a su vez, crear m ás subprocesos

23.4 THE El sistem a operativo THE (D ijkstra [1968], M ckeag y W ilson [1976]) fue diseñado en la Technische H ogeschool en Eindhoven, H olanda. Era un sistem a de procesam iento por lotes que se ejecuta­ ba en una com putadora de fabricación holandesa, la EL X8, con 32 KB de palabras de 27-bits. El sistem a era realm ente notable por su lim pio diseño, particularm ente por su estructura en ni­ veles, y por su uso de un conjunto de procesos concurrentes que em pleaban sem áforos para sin­ cronización. Sin em bargo, a diferencia del sistem a XD S-940, el conjunto de procesos en el sistem a THE era estático. El propio sistem a operativo estaba diseñado com o un conjunto de procesos cooperantes. Adem ás, se crearon cinco procesos de usuario que servían com o agentes activos para compilar, ejecutar e im prim ir program as de usuario. Cuando se term inaba un trabajo, el proceso volvía a la cola de entrada para seleccionar otro trabajo. Se utilizaba un algoritm o de planificación de la CPU basado en prioridades. Las prioridades se recalculaban cada dos segundos y eran inversam ente proporcionales al tiem po de CPU utilizado recientem ente (es decir, en los últim os 8 a 10 segundos). Este esquem a proporcionaba una priori­ dad m ás alta a los procesos lim itados por E/S y a los procesos nuevos. La gestión de m em oria estaba lim itada por la falta de soporte hardware. Sin em bargo, puesto que el sistem a era lim itado y los program as de usuario sólo podían escribirse en Algol, se empleó un esquem a softw are de paginación. El com pilador A lgol generaba autom áticam ente llamadas a las rutinas del sistem a, lo que garantizaba que la inform ación solicitada estuviera en memoria, produciéndose intercam bios según fuera necesario. El alm acén de respaldo era un tam bor de 512 KB-palabras. Se utilizaba un tam año de página de 512 palabras con una estrategia LRU de sustitu­ ción de páginas. Otra de las principales preocupaciones abordada por el sistem a THE era ei control de los inter­ bloqueos. Para evitar los interbloqueos se em pleaba el algoritm o del banquero. Estrecham ente relacionado con el sistem a THE está el sistem a Venus (Liskov [1972]). El sistema Venus tam bién tema un diseño estructurado en niveles y utilizaba sem áforos para la sincroniza­ >

23.6 CTSS

773

ción de los procesos. Sin em bargo, los niveles inferiores del diseño estaban im plem entados en m icrocódigo, lo que proporcionaba un sistem a m ucho m ás rápido. La gestión de m em oria se cam ­ bió por una m em oria segm entada paginada. El sistem a tam bién se diseñó com o sistem a de tiem­ po com partido en lugar de para procesam iento por lotes.

23.5 RC 4000 El sistem a RC 4 0 0 0 , com o el sistem a THE, era m uy notable principalm ente por conceptos de dise­ ño. Fue diseñado para la com putadora D anish 4 0 0 0 por Regnecentralen, particularm ente por B rinch-H ansen (Brinchhansen [1 9 7 0 ], Brinchhansen [1 9 7 3 ]). El objetivo no era diseñar un sistema de procesam iento por lotes n i un sistem a de tiem po com partido, ni ningún otro sistem a específi­ co. En lugar de ello, el objetivo era crear un núcleo de sistem a operativo, o kem el, sobre el que pudiera construirse un sistem a operativo com pleto. Por tanto, la estructura del sistem a era en niveles, y sólo se sum inistraron los niveles inferiores, que era los que form aban el kem el. El kem el soportaba una colección de procesos concurrentes, utilizándose un planificador de CPU con un algoritm o de asignación por tu m os. Aunque los procesos podían com partir memoria, el m ecanism o principal de com unicación y sincronización era el sistem a de m en sajería propor­ cionado por el kem el. Los procesos podían intercam biarse entre sí intercam biando mensajes de tam año fijo que tenían una longitud de ocho palabras. Todos los m ensajes se alm acenaban en búferes que se extraían de un conjunto de búferes com ún. C uando ya no se necesitaba un búfer de m ensaje, se le devolvía al conjunto com ún. C o n c a d a p ro c e s o h ab ía a s o c ia d a u n a cola de m ensajes. L a c o la co n te n ía to d o s los m en sajes q u e h u b ie ra n sid o e n v ia d o s a d ich o p ro c e s o , p e ro q u e to d a v ía n o h u b ie ra n sid o recib id os. L os m e n sa je s se elim in a b a n d e la c o la en o rd e n FIFO. E l sis te m a s o p o r ta b a c u a tro o p e ra cio n e s p rim i­ tiv a s q u e se e je cu ta n a tó m ic a m e n te :

• send-m essage (in receiver, in message, out buffer) •

w ait-m essage (out sender, out message, out buffer)

• send -an sw er (out result, in message, in buffer) • w ait-answ er (out result, out message, in buffer) Las dos últim as operaciones perm itían a los procesos intercam biar varios m ensajes al mismo tiempo. Estas prim itivas requerían que los procesos dieran servicio a su cola de m ensajes en orden FIFO y que se bloquearan m ientras otros procesos estaban gestionando sus mensajes. Para eliminar estas restricciones, los desarrolladores proporcionaron dos prim itivas adicionales de com unica­ ción, que perm itían a un proceso esperar la llegada del siguiente m ensaje o responder y dar ser­ vicio a su cola de m ensajes en cualquier orden: • w ait-even t (in previous-buffer, out next-buffer, out result) •

get-even t (out buffer)

Los dispositivos de E/S tam bién se trataban com o procesos. Los controladores de dispositivo eran fragm entos de código que convertían las interrupciones de dispositivo y los registros en m ensajes. Así, un proceso escribía en un term inal enviando a ese terminal un m ensaje. El contro­ lador de dispositivo recibía el m ensaje y presentaba el carácter por el terminal. Los caracteres de entrada interrum pían al sistem a y se transferían a un controlador de dispositivo, el cual creaba un m ensaje con el carácter de entrada y lo enviaba a un proceso que estuviera en espera.

23.6 CTSS El sistem a CTSS (Com patible Tim e-Sharing System ) (Corbato et al. [1962]) fue diseñado en el MIT com o sistem a experim ental de tiempo com partido. Se im plem ento en un IBM 7090 y llegó a sopor­ tar hasta 32 usuarios interactivos. A los usuarios se les proporcionaba un conjunto de comandos

774

Capítulo 23 Sistemas operativos influyentes

interactivos que les perm itían m anipular archivos y com pilar y ejecutar program as a través de un term inal. El 7090 tenía una m em oria de 32 KB form ada por palabras de 36 bits. El m onitor utilizaba pala­ bras de 5 KB dejando 27 KB para los usuarios. Las im ágenes de m em oria de los usuarios se inter­ cam biaban entre la m em oria y un tam bor de alta velocidad. La planificación de la CPU empleaba un algoritm o de cola de realim entación m ultinivel. El cuanto de tiem po para el nivel i era de 2 * i unidades de tiem po. Si u n program a no term inaba su ráfaga de CPU en un cuanto de tiempo, se le m ovía al siguiente nivel de la cola, dándole el doble de tiem po. El program a en el nivel supe­ rior (con el cuanto m ás corto) se ejecutaba en prim er lugar. El nivel inicial de cada program a se determ inaba según su tam año, de m odo que el cuanto de tiem po fuera al m enos igual de grande que el tiem po de intercam bio. CTSS tuvo u n gran éxito y fue utilizado hasta 1972. A unque estaba lim itado, fue de capaz de dem ostrar que el tiem po com partido era una form a de procesam iento cóm oda y práctica. Uno de los resultados de CTSS fue prom over el desarrollo de sistem as de tiempo com partido. Otro resul­ tado fue el desarrollo de MULTICS.

23.7 MULTICS El sistem a operativo MULTICS (Corbato y Vyssotski [1965], Organick [1972]) fue diseñado en el MIT com o una extensión natural de CTSS. El sistem a CTSS y otros sistem as pioneros de tiem po com par­ tido tuvieron tanto éxito que incentivaron el deseo inm ediato de desarrollar rápidam ente otros sistem as m ejores y de m ayor envergadura. A m edida que fueron estando disponibles las compu­ tadoras de gran tam año, los diseñadores de CTSS decidieron crear una utilidad de tiem po com par­ tido. Los servicios inform áticos se proporcionarían, según este concepto, com o la energía eléctrica: los grandes sistem as inform áticos estarían conectados por hilos telefónicos a term inales situados en oficina y dom icilios de toda la ciudad. El sistema operativo sería un sistem a de tiempo com­ partido ejecutándose continuam ente con un vasto sistem a de archivos com puesto por programas y datos com partidos. MULTICS fue diseñado por un equipo de desarrolladores del MIT, de GE (que posteriormente vendió su división de inform ática a H oneyw ell) y de Bell Laboratories (que se salió del proyecto en 1969). Se m odificó la com putadora básica GE 635 para desarrollar un nuevo sistem a informá­ tico denom inado GE 645, y cuya principal diferencia era la adición de un hardw are de memoria con segm entación paginada. Cada dirección virtual estaba com puesta por un núm ero de segm ento de 18 bits y un despla­ zam iento de palabra de 16 bits. Los segm entos se paginaban utilizando páginas de 1 KB-palabras. Se utilizó el algoritm o de sustitución de páginas de segunda oportunidad. El espacio virtual de direcciones segm entado estaba m ezclado conceptualm ente con el sistema de archivos. Cada segm ento era un archivo. Los segm entos se direccionaban utilizando el nombre del archivo y el propio sistem a de archivos era una estructura en árbol m ultinivel, que permitía a los usuarios crear sus propias estructuras de subdirectorios. Al igual que CTSS, MULTICS utilizaba una cola de realim entación m ultinivel para la planifica­ ción de la CPU. La protección se conseguía m ediante una lista de acceso asociada a cada archivo y un conjunto de anillos de protección para los procesos en ejecución. El sistem a, que estaba escri­ to, casi por com pleto, en PL/1, tenía unas 300.000 líneas de código. Posteriorm ente, se am plió para transform arlo en un sistem a m ultiprocesador, perm itiendo retirar una CPU para tareas de mante­ nim iento m ientras el sistem a continuaba funcionando.

23.8 IBM OS/360 La línea m ás larga de desarrollo de sistem as operativos es, sin ninguna duda, la de las com puta­ doras IBM . Las prim eras com putadoras IBM , com o la IBM 7090 y la IBM 7094, constituyen ejem­ plos notables del desarrollo de subrutinas de E/S com unes, seguido del desarrollo de un monitor residente y de m ecanism os de instrucciones privilegiadas, protección de m em oria y procesamien-

23.8 IBM OS/360

775

to por lotes sim ple. Estos sistem as se desarrollaron de m anera separada, a m enudo en distintas sedes de la com pañía, que funcionaban independientem ente. Com o resultado, IBM se encontró varias com putadoras distintas, con diferentes lenguajes y diferentes softw are del sistema. Para resolver esta situación se desarrolló el IBM /360. El IBM /360 se diseñó como una fam ilia de com putadoras que abarcaba el rango com pleto que iba desde m áquinas para pequeñas em pre­ sas hasta las grandes m áquinas de cálculo científico. Sólo hacía falta un conjunto de program as softw are para todos estos sistem as, ya que todos ellos utilizaban el m ism o sistem a operativo: el OS/360 (M ealy et al. [1966]). Esta decisión se tom ó para reducir los problem as de m antenim iento en IBM y para perm itir a los usuarios transferir program as y aplicaciones librem ente desde un sis­ tema IBM a otro. Lam entablem ente, O S/360 com etió el error de tratar de resolver todos los problem as de todos los tipos de personas al m ism o tiem po. Com o resultado, no llevaba a cabo ninguna de sus tareas especialm ente bien. El sistem a de archivos incluía un cam po de tipo que definía el tipo de cada archivo, y se definieron diferentes tipos de archivo para registros de longitud fija y de longitud variable y para archivos con bloques y sin bloques. Se utilizaba un m ecanism o de asignación con­ tigua, por lo que usuario tenía que adivinar el tam año de cada archivo de salida. El lenguaje JCL (Job Control Language, lenguaje de control de trabajos) añadía parám etros para todas las opcio­ nes posibles, haciendo que fuera incom prensible para el usuario medio. Las rutinas de gestión de m em oria estaban dictadas por la arquitectura. Aunque se utilizó un m odo de direccionam iento con registro base, el program a podía acceder al registro base y m odi­ ficarlo, de m odo que la CPU generaba direcciones absolutas. Este m ecanism o impedía la reubica­ ción dinám ica, con lo que los program as estaban ligados a la m em oria física desde el m om ento de su carga. Se generaron dos versiones distintas del sistem a operativo: OS/M FT, que utilizaba regiones fijas y OS/M VT, que em pleaba regiones variables. El sistem a fue escrito en lenguaje ensam blador por m iles de program adores, lo que dio como resultado m illones de líneas de código. El propio sistem a operativo requería grandes cantidades de m em oria para el código y las tablas. El gasto de procesam iento del sistem a operativo requería a m enudo un 50 por ciento de los ciclos de CPU totales. A lo largo de los años, se lanzaron nuevas versiones para añadir nuevas características y corregir errores. Sin em bargo, la corrección de un error causaba a m enudo otro en alguna parte rem ota del sistem a, por lo que el número de errores conocidos en el sistem a perm aneció prácticam ente constante. La m em oria virtual se añadió al O S/360 con el cam bio a la arquitectura IBM 370. El hardw are subyacente proporcionaba una m em oria virtual segm entada-paginada. Las nuevas versiones del sistem a operativo utilizaban este hardw are de m anera diferente. OS/VS1 creaba un espacio vir­ tual de direcciones de gran tam año y ejecutaba O S/M FT en dicha m em oria virtual. Por tanto, el propio sistem a operativo estaba paginado, adem ás de estarlo los program as de usuario. OS/VS2 Versión 1 ejecutaba O S/M VT en m em oria virtual. Por últim o, O S/VS2 Versión 2, que ahora se denom ina M VS, proporcionaba a cada usuario su propia m em oria virtual. M VS sigue siendo, básicam ente, un sistem a operativo de procesam iento por lotes. El sistema CTSS se ejecutaba en un IBM 7094, pero el MIT decidió que el espacio de direcciones del 360, el sucesor del IBM 7094, era dem asiado pequeño para MULT1CS, por lo que cam biaron de fabricante. IBM decidió entonces crear su propio sistem a de tiem po com partido, el TSS/360 (Lett y Konigsford [1968]). Al igual que MULTICS, TSS/360 pretendía ser una utilidad de tiempo com par­ tido a gran escala. La arquitectura básica 360 fue m odificada en el m odelo 67 para proporcionar m em oria virtual. Diversas organizaciones adquirieron el 360/67 com o anticipación al TSS/360. Sin em bargo, el TSS/360 se retrasó, por lo que se desarrollaron otros sistem as de tiempo com ­ partido com o solución tem poral hasta que el TSS/360 estuviera disponible. De este modo, se aña­ dió una opción de tiempo com partido (TSO, tim e-sharing option) al OS/360. El centro de investigación Cam bridge de IBM desarrolló CMS com o sistem a m onousuario de CP/67 para pro­ porcionar una m áquina virtual sobre la que se pudiera ejecutar (M eyer y Seawríght [1970], Parm elee et al. [1972]). Cuando fue lanzado finalm ente el TSS/360 fue un fracaso. Era dem asiado com plejo y dem a­ siado lento. Com o resultado, ninguna organización hizo sustituir su sistem a tem poral por el TSS/360. Hoy en día, el tiem po com partido en los sistem as IBM se proporciona principalm ente m ediante TSO sobre MVS o m ediante CMS sobre CP/67 (renom brado VM).

776

Capítulo 23 Sistemas operativos influyentes

Tanto TSS/360 com o MULTICS no tuvieron un gran éxito com ercial. ¿Qué era lo que fallaba con estos sistem as? Parte del problem a era que estos sistem as avanzados eran dem asiado com plejos y dem asiado volum inosos com o para poder ser com prendidos por quienes los tenían que utilizar. Otro problem a era la suposición de que las capacidades inform áticas se proporcionarían median­ te grandes com putadoras rem otas. A hora sabem os que la m ayor parte del procesam iento infor­ m ático se realiza m ediante pequeñas m áquinas individuales (com putadoras personales), no m ediante sistem as com plejos y rem otos de tiem po com partido que traten de resolver todos los problem as de todos los usuarios.

23.9 Mach El sistem a operativo M ach tiene tu antecesor en el sistem a operativo A ccent desarrollado en la U niversidad C M U (C am egie M ellon University) (Rashid y R obertson [1981]). La filosofía y el sis­ tem a de com unicaciones de M ach se derivan de Accent, pero otras partes significativas del siste­ m a (por ejem plo, el sistem a de m em oria virtual y la gestión de tareas y de hebras) fueron desarrollados partiendo de cero (Rashid [1986], Tevanian et al. [1989] y A ccetta et al. [1986]). El planificador de M ach se describe en detalle en Tevanian et al. [1987a] y Black [1990]. Tevanian et al. [1987b] .presentó una prim era versión del sistem a de m em oria com partida y de m apeo de m em oria de M ach El sistem a operativo M ach fue diseñado teniendo en m ente los tres siguientes objetivos crí­ ticos:

1. Emular un UNIX BSD 4.3 de modo que los archivos ejecutables de un sistema UNIX pudieran funcionar correctamente sobre Mach. 2. Ser un sistem a operativo m oderno que soportara distintos m odelos de m em oria, y tanto pro­ cesam iento paralelo com o distribuido. 3. D isponer de un kem el que fuera m ás fácil y sencillo de m odificar que BSD 4.3. El desarrollo de M ach siguió un cam ino evolutivo a partir de los sistem as UNIX BSD. El código de M ach fue desarrollado inicialm ente dentro del k em el BSD 4.2, sustituyendo com ponentes del kem el BSD por com ponentes de M ach a m edida que éstos iban siendo com pletados. Los compo­ nentes de BSD se actualizaron a BSD 4.3 cuando esta versión apareció. En 1986, los subsistem as de m em oria virtual y de com unicaciones funcionaban sobre la fam ilia de com putadoras VAX de DEC, incluyendo las versiones m ultiprocesador del VAX. Poco después se lanzarían las versiones para el R T/PC de IBM y para las estaciones de trabajo SU N 3. D espués, en 1987 se term inaron las ver­ siones m ultiprocesador para Encoré M ultim ax y Sequent Balance, incluyendo el soporte de tare­ as y hebras; en ese m ism o año se lanzaron las prim eras versiones oficiales del sistem a, la versión 0 y la versión 1. H asta la versión 2, M ach proporcionaba com patibilidad con los correspondientes sistem as BSD, incluyendo gran parte del código de BSD en el kem el. Las nuevas características y capacidades de M ach hicieron que el k em el de estas versiones fuera m ayor que el k em el BSD correspondiente. M ach 3 desplazó el código BSD fuera del kem el, dejando un m icrokernel m ucho más pequeño. El sistem a sólo im plem enta las características de M ach en el kem el, todo el código específico de UNIX se ejecuta en servidores de modo usuario. Excluir el código específico de UNIX del kem el permite sustituir BSD por otro sistem a operativo, y tam bién la ejecución sim ultánea de m últiples interfa­ ces de sistem a operativo sobre el m icrokernel. A dem ás, de BSD, se han desarrollado implementaciones en m odo usuario para DOS, para el sistem a operativo M acintosh y para OSF/1. Esta técnica presenta sim ilitudes con el concepto de m áquina virtual, pero aquí la m áquina virtual está defini­ da por softw are (la interfaz del kem el de M ach), en lugar de por hardware. Con la versión 3.0, M ach pasó a estar disponible sobre una am plia variedad de sistem as, incluyendo m áquina monoprocesador de SUN, Intel, IBM y DEC, y sistem as m ultiprocesador de DEC, Sequent y Encoré. M ach obtuvo una gran atención del sector in form ático cuando OSF (O pen Softw are Foundation) anunció en 1989 que utilizaría M ach 2.5 com o base para su sistem a operativo OSF/1. El lanzam iento inicial de O SF/1 tuvo lugar un año después, y este sistem a entró en com petencia

J-

Ejercicios

777

con UNIX System V, versión 4, el sistem a operativo m ás extendido en ese m om ento entre los m iem bros de UI (UNIX International). Entre los m iem bros de OSF había em presas tecnológicas de gran im portancia com o IBM, DEC y HP. D esde entonces, OSF ha cam biado de dirección y sólo el UNIX de DEC está basado en el kem el de M ach. M ach 2.5 tam bién form a la base del sistem a operativo de la estación de trabajo NeXT, una de las criaturas de Steve Jobs, que fue fundador de A pple C om puter. A diferencia de UNIX, que fue desarrollado sin tener en cuenta el m ultiprocesam iento. M ach incorpora soporte de m ultiprocesam iento en todo el sistem a. Su soporte de m ultiprocesam iento es enorm em ente flexible, abarcando todo el rango desde los sistem as de m em oria com partida hasta sistem as en los que los procesadores no com parten ninguna m em oria. M atch utiliza proce­ sos ligeros, en la form a de m últiples hebras de ejecución dentro de una tarea (espacio de direccio­ nes), para perm itir el m ultiprocesam iento y el procesam iento paralelo. Su intensivo uso de m ensajes com o único m étodo de com unicación garantiza que los m ecanism os de protección sean com pletos y eficientes. Integrando los m ensajes com o el sistem a de m em oria virtual, M ach tam ­ bién garantiza que los m ensajes se puedan gestionar de m anera eficiente. Finalm ente, al hacer que el sistem a de m em oria virtual utilice m ensajes para com unicarse con los dem onios que gestionan el alm acén de respaldo, M ach proporciona una gran flexibilidad en el diseño e im plem entación de estas tareas de gestión de objetos de m em oria. Proporcionando llam adas al sistem a de bajo nivel o prim itivas, a partir de las cuales pueden construirse funciones más com plejas, M ach reduce el tam año del kem el, al m ism o tiem po que perm ite em ular sistem as operativos en el nivel del usua­ rio de form a bastante sim ilar a los sistem as de m áquina virtual de IBM. Las anteriores ediciones de este libro incluían un capítulo com pleto dedicado a M ach. Este capítulo, tal com o aparecía en la cuarta edición, está disponible en la W eb (http://m vw .os-book.com ).

23.10 Otros sistemas >

Por supuesto, existen otros sistem as operativos y la m ayoría de ellos tienen propiedades interesantes. El sistem a operativo MCP para la fam ilia de com putadoras Burroughs (M ckeag y W ilson [1976]) fue el prim ero en ser escrito en un lenguaje de program ación de sistem as. Soportaba m eca­ nism os de segm entación y m últiples procesadores. El sistem a operativo SCOPE para el CDC 6600 (M ckeag y W ilson [1976]) tam bién era un sistem a m ultiprocesador. La coordinación y sincroniza­ ción de los m últiples procesos estaban sorprendentem ente bien diseñadas. Tenex (Bobrow et al. [1972]) fue un sistem a de paginación bajo dem anda pionero para el PDP-10, que ha tenido una gran influencia en los sistem as de tiem po com partido posteriores, com o por ejem plo el TO PS-20 para DEC-20. El sistem a operativo VMS para el VAX está basado en el sistem a operativo RSX del PDP-11. C P / M fue el sistem a operativo m ás com ún para las m icrocom putadoras de 8 bits, de los cuales quedan ya pocos ejem plares; MS-DOS es el sistem a m ás com ún para las m icrocom putado­ ras de 16 bits. Las interfaces gráficas de usuario (GUI, G raphical user interface) se han hecho popu­ lares debido a que facilitan la utilización de las com putadoras; el sistem a operativo M acintosh y M icrosoft W indow s son los dos líderes en este área.

Ejercicios 23.1

Explique las consideraciones que el operador inform ático tenía en cuenta a la hora de deci­ dir las secuencias con las que los program as debían ejecutarse en los primeros sistem as inform áticos que se operaban de form a m anual.

23.2

¿Qué m ecanism os de optim ización se utilizaron para m inim izar la discrepancia entre las velocidades de la CPU y de la E /S en los prim eros sistem as inform áticos?

23.3

Considere el algoritm o de sustitución de páginas utilizado por Atlas. ¿Cuáles son las dife­ rencias respecto al algoritm o del reloj explicado en la Sección 9.4.5.2?

23.4

Considere la cola de realim entación m ultinivel utilizada por CTSS y MULTICS. Suponga que un program a utiliza constantem ente siete unidades de tiem po cada vez que se le planifica,

778

Capítulo 23 Sistemas operativos influyentes

antes de llevar a cabo una operación de E/S y bloquearse. ¿Cuántas unidades de tiempo se asignarán a este program a cuando se planifique para ejecución en diferentes m om entos? 23.5

>

¿C uáles son las im plicaciones de soportar la funcionalidad BSD m ediante servidores de m odo usuario dentro del sistem a operativo M ach?

Bibliografía [A bbot 1984] C. Abbot, “Intervention Schedules for Real-Tim e Program m ing”, IEEE Transactions on Software Engineering, Vol. SE-10, N° 4 (1984), págs. 268-274. [A ccett et al. 1986] M. A ccett, R. Barón, W . Bolosky, D. B. Golub, R. Rashid, A. Tevanian y M. Y oung, “M ach: A New K em el Foundation for U nix D evelopm ent”, Proceedings o f the Sum m er USENIX Conference (1986), págs. 93-112. [A graw al y A bb ad i 1991] D. P. A graw al y A. E. A bbadi, “A n Efficient and Fault-Tolerant Solution of Distributed M utual Exclusión”, ACM Transactions on C om puter Systems, Vol. 9, N° 1 (1991), págs. 1-20. [Agre 2003] P. E. Agre, “P 2P and the Prom ise of Internet Equality”, Com m unications o f the ACM , Vol. 46, N° 2 (2003), págs. 39-42. [A hituv et al. 1987] N. A hituv, Y. Lapid y S. N eum ann, “P rocessing Encrypted D ata”, Com m unications o fth e ACM, Vol. 30, N° 9 (1987), páginas 777-780. [A hm ed 1000] I. A hm ed, “C luster Com puting: A G lance al Recent Events”, IEEE Concurrency, Vol. 8, N° 1 (2000). [A kl 1983] S. G. Akl, “Digital Signatures: A Tutorial Survey”, Computer, Vol. 16, N° 2 (1983), págs. 15-24. . .. [A kyurek y S alem 1993] S. A kyurek y K. Salem , “A daptative Block Rearrangem ent”, Proceedings o ft h e International Conference on Data Engineering (1993), págs. 182-189. [A lt 1993] H. Alt, “Rem ovable M edia in Solaris”, Proceedings o f the W inter USENIX Conference (1993), págs. 281-287. [A nderson 1990] T. E. A nderson, “The Perform ance o f Spín Lock A lternatives for Shared-M oney M ultiprocessors”, IEEE Trans. Parallel Distrib. Syst., Vol. 1, N° 1 (1990), págs. 6-16. [A nderson e t .a l. 1989] T. E. A nderson, E. D. Lazow ska y H. M . Levy, “The Perform ance Im plications of Thread M anagem ent Alternatives for Shared-M em ory M ultiprocessors”, IEEE Transactions on Computers, Vol. 38, N° 12 (1989), págs. 1631-1644. [A nderson et al. 1991] T. E. A nderson, B. N. Bershad, E. D. Lazow ska y H. M. Levy, “Scheduler Activations: Effective K ernel Support for the U ser-Level M anagem ent of P arallelism ”, Proceedings o fth e A C M Symposium on Operating System s Principies (1991), págs. 95-109. [A nderson et al. 1995] T. E. A nderson, M. D., Dahlin, J. M. Neefe, D. A. Patterson, D. S. Roselli y R. Y W ang, “Serverless N etw ork File System s”, Proceedings o fth e A C M Symposium on O perating Systems Principies (1995), págs. 109-206. > 779

780

Bibliografía

[A nderson e t al. 2000] D. A nderson, J. Chase y A. Vahdat, “Interposed Request Routing for Scalable N etw ork Storage”, Proceedings o fth e Fourth Symposium on Operating Systems Design and Im plem entation (2000). [A sthana and F in k e lste in 1995] P. A sthana y B. Finkelstein, “Superdense O ptical Storage”, IEEE Spectrum , Vol. 32, N° 8 (1995), páginas 25-31. [A udsley et al. 1991] N. C. A udsley, A. Bum s, M . F. Richardson y A. J. W ellings, “H ard RealTim e Scheduling: T h e D eadline M onotonic A pproach”, Proceedings o f the IEEE W orkshop on R eal-Tim e O perating System s and Softw are (1991). [A x elsso n 1999] S. A xelsson, “The Base-Rate F allacy and Its Im plications for Intrusión D etection”, Proceedings o f the A C M Conference on C om puter and Communications Security (1999), págs. 1 -7 . [B abaoglu y M arzu llo 1993] O. Babaoglu y K. M arzullo. “Consistent Global States of Distributed System s: Fundam ental Concepts and M echanism s”, págs. 55-56. A ddison-W esley (1993). [Bach 1987] M. J. Bach, The Design o ft h e UNIX O perating System , Prentice H all (1987). [Back et al. 2000] G. Back, P. Tullm an, L. Stoller, W . C. H sieh y J. Lepreau, “Techniques for the D esign o f Java O perating System s”, 2000 USENIX A nnual Technical Conference (2000). [B ak er e t al. 1991] M . G. Baker, J. H. H artm an, M . D. Kupfer, K. W. Shirriff y J. K. Ousterhout, “M easurem ents of a D istributed File System ”, Proceedings o f the A C M Symposium on Operating System s Principies (1991), págs. 198-212. [B alak rish n an et al. 2003] H. Balakrishnan, M. F. K aashoek, D. Karger, R. M orris e I. Stoica, “L ooking Up D ata in P2P System s”, Com m unications o f the ACM, Vol. 46, N° 2 (2003), págs. 4 3 -4 8 . [B ald w in 2002] J. Baldw in, “Locking in the M ultithreaded FreeBSD K em el”, U SENIX BSD

(2002). [Basu et al. 1995] A. Basu, V. Buch, W . Vogels y T. von Eicken, “U-N et: A U ser-Level NetWork Interface for Parallel and D istributed C om puting”, Proceedings o f the ACM Symposium on O perating Systems Principies (1995). [Bayer et. 1978] R. Bayer, R. M. G raham y G. Seegm uller, editores, Operating Systems-An A dvanced Course, Springer Verlag (1978). [Bays 1977] C. Bays, “A Com parison of N ext-Fit, First-Fit and Best-Fit”, Communications o f the A C M , Vol. 20, N° 3 (1977), págs. 191-192. [B elad y 1966] L. A. Belady, “A Study of R eplacem ent A lgorithm s for a Virtual-Storage C om puter”, IBM System s Journal, Vol. 5, N° 2 (1966), págs. 78-101. [B elad y e t al. 1969] L. A. Belady, R. A. N elson y G. S. Shedler, “A n Anom aly in Space-Time C haracteristics of C ertain Program s Running in a Paging M achine”, Communications o f the ACM , Vol. 12, N° 6 (1969), págs. 349-353. [B ello v in 1989] S. M. Bellovin, “Security Problem s in the TCP/IP Protocol Suite”, Computer Com m unications R eview , Vol. 19:2, (1989), págs. 3 2 -4 8 . [B en -A ri 1990] M. Ben-A ri, Principies o f Concurrent and D istributed Programming, Prentice Hall (1990). [B e n ja m ín 1990] C. D. Benjam in, “The Role of O ptical Storage Technology for N ASA”, Proceedings, Storage and Retrieval System s and A pplications (1990), págs. 10-17. [B e m ste in y G ood m an 1980] P. A. B em stein y N. G oodm an, “Tim e-Stam p-Based Algorithm s for C oncurrency C ontrol in D istributed Database System s”, Proceedings o f the International Conference on Very Large Databases (1980), págs. 285-300. >

Bibliografía

781

[B ern stein et al. 1987] A. Bem stein. V. H adzilacos y N. Goodm an, Concurrency Control and Recovery in D atabase Systems, A ddison-W esley (1987). [Bershad 1993] B. Bershad, “Practical Considerations for N on-Blocking Concurrent O bjects”, IEEE International Conference on D istributed Com puting System s (1993), págs. 264-273. [Bershad and P in kerto n 1988] B. N. Bershad y C. B. Pinkerton, “W atchdogs: Extending the Unix File System ”, Proceedings o f the W inter USENIX Conference (1988). [Bershad et al. 1990] B. N. Bershad, T. E. A nderson, E. D. Lazow ska y H. M. Levy, “Lightw eight Rem óte Procedure Cali”, A C M Transactions on Com puter Systems, Vol. 8, N° 1 (1990), págs. 37-55. [B ersh ad et al. 1995] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers y C. Cham bers, “Extensibility Safety and Perform ance in the SPIN O perating Sys­ tem”, Proceedings o fth e A C M Symposium on O perating System s Principies^1995), págs. 267-284. [Beverid ge y W ien er 1997] J. Beveridge y R. W iener, M ultithreading Applications in W in32, A ddison-W esley (1997). [B irrell 1989] A. D. Birrell. “A n Introduction to Program m ing w ith Threads”. Technical Report 35, D EC -SRC (1989). [B irrell y N elson 1984] A. D. Birrell y B. J. N elson, “Im plem enting Rem óte Procedure C alis”, A C M Transactions on Com puter Systems, Vol. 2, N° 1 (1984), págs. 39-59. [B lack 1990] D. L. Black, “Scheduling Support for Concurrency and Parallelism in the M ach O perating System ”, IEEE Computer, Vol. 23, N° 5 (1990), págs. 35-43. [B lu m o fe y L e ise rso n 1994] R. B lum ofe y C. L eiserso n , “Sch ed uling M ultithread ed Com putations by W ork Stealing”, Proceedings o f the A nnual Symposium on Foundations o f Com puter Science (1994), págs. 356-368. [B obrow et al. 1972] D. G. Bobrow, J. D. Burchfiel, D. L. M urphy y R. S. Tom linson, “TEN EX, a Paged Tim e Sharing System for the PD P-10”, Com m unications o ft h e ACM , Vol. 15, N° 3 (1972). [B o lo sky et al. 1997] W. J. Bolosky, R. P. Fitzgerald y J. R. Douceur, “Distributed Schedule M anagem ent in the Tiger Video Fileserver”, Proceedings o f the ACM Symposium on Operating Systems Principies (1997), págs. 212.-223. [B o n w ick 1994] J. Bonw ick, “The Slab Allocator: A n O bject-Caching K em el M em ory A llocator”, USENIX Sum m er (1994), págs. 87-98. [B o n w ick y Adam s 2001] J. Bonw ick y J. Adam s, “M agazines and Vmem: Extending the Slab A llocator to M any CPU s and A rbitrary Resources”, Proceedings o f the 2001 USENIX Annual Technical Conference(2001). [Bovet y C esati 2002] D. P. Bovet y M. Cesati, U nderstanding the Linux Kem el, Second Edition, O ’Reilly & Associates (2002). [B rain 1996] M. Brain, W in32 System Services, Second Edition, Prentice Hall (1996). [B ren t 1989] R. Brent, “Efficient Im plem entation of the First-Fit Strategy for Dynam ic Storage A llocation”, A C M Transactions on Programm ing Languages and System s, Vol. 11, N° 3 (1989), págs. 388-403. [Brereton 1986] O. P. Brereton, “M anagem ent of Replicated Files in a UNIX Environm ent”, Softw are-Practice and Experience, Vol. 16, (1986), páginas 771-780. [B rin ch -H an sen 1970] P. Brinch-H ansen, “The N ucleus of a M ultiprogram m ing System ”, Com m unications o fth e A CM , Vol. 13, N°*4 (1970), págs. 238-241 y 250. [B rinch-H ansen 1972] P. Brinch-H ansen, “Structured M ultiprogram m ing”. Communications o fth e . ACM , Vol. 15, N° 7 (1972), págs. 574-578. ~

«A

782

Bibliografía

[B rinch-H ansen 1973] P. Brinch-H ansen, O perating System Principies, Prentice Hall (1973). [Brookshear 2003] J. G. Brookshear, C om puter Science: A n OverView, Seventh Edition, AddisonW esley (2003). [Brow nbridge et al. 1982]D . R. Brow nbridge, L. F. M arshall y B. Randell, “The Newcastle Connectíon or U N IXes of the W orld U nite!”, Softw are-Practice an d Experience, Vol. 12, N° 12 (1982), págs. 1147-1162. [B u m s 1978] J. E. B u m s, “M utual Exclusión w ith Linear W aiting U sing Binary Shared Variables”, SIG A C T N ews, Vol. 10, N° 2 (1978), págs. 42-47. [B u ten h o f 1997] D. Butenhof, Program m ing with PO SIX Threads, A ddison-W esley (1997). [Buyya 1999] R. Buyya, H igh Perform ance Cluster Com puting: A rchitectures an d Systems, Prentice Hall (1999). [C allaghan 2000] B. C allaghan, N FS Illustrated, A ddison-W esley (2000). [C alvert y D onah oo 2001] K. Calvert y M . D onahoo, TCP/IP Sockets in Java: Practicad Guide fo r Programmers, M organ K aufm ann (2001). [C antrill et al. 2004] B. M. C antrill, M. W . Shapiro y A. H. Leventhal, “Techniques for the Design of Java O perating System s”, 2004 U SENIX Annual Technical C onference (2004). [Carr y H en n essy 1981] W . R. C arr y J. L. H ennessy, “W S C lock -A Sim ple and Effective A lgorithm for V irtual M em ory M anagem ent”, Proceedings o ft h e A CM Symposium on Operating System s Principies (1981), págs. 87-95. [Carvalho y R oucairol 1983] O. S. C arvalho y G. Roucairol, “O n M utu al Exclusión in Com puter - N etw orks”, Com m unications o ft h e A CM , Vol. 26, N° 2 (1983), págs. 146-147. [Chandy y Lam port 1985] K. M. C handy y L. Lam port, “D istributed Snapshots: Determ ining G lobal States of D istributed System s”, ACM Transactions on C om puter System s, Vol. 3, N° 1 (1985), págs. 63-75. [C hang 1980] E. Chang, “N -Philosophers: A n Exercise in D istribu ted C ontrol”, Computer Networks, Vol. 4, N° 2 (1980), págs. 71-76. [C h an g y M erg en 1988] A. C hang y M . F. M ergen , “801 S to rag e: A rch itectu re and Program m ing”, ACM Transactions on Com puter Systems, Vol. 6, N° 1 (1988), págs. 28-50. [Chase et al. 1994] J. S. Chase, H. M. Levy, M . J. Feeley y E. D, Lazow ska, “Sharing and Protection in a Single-A ddress-Space O perating System ”, ACM Transactions on C om puter Systems, Vol. 12, N° 4 (1994), págs. 271-307. [Chen et al. 1994] P. M. C hen, E. K. Lee, G. A. Gibson, R. H. Katz y D . A. Patterson, “RAID: HighPerform ance, R eliable Secondary Storage”, ACM Com puting Survey, Vol. 26, N° 2 (1994), págs. 145-185. [C hesw ick et al. 2003] W . Chesw ick, S. Bellovin y A. Rubin, Fireivalls an d Internet Security: Repelling the W ily H acker, segunda edición, A ddison-W esley (2003). [C heung y Loong 1995] W . H. Cheung y A. H. S. Loong, “Exploring Issu es o f O perating System s Structuring: From M icrokernel to Extensible System s”, O perating System s Review, Vol. 29, (1995), págs. 4 -1 6 . [Chi 1982] C. S. Chi, “A dvances in Com puter M ass Storage T echn ology”, Com puter, Vol. 15, N° 5 (1982), págs. 60-74. [C offm an et al. 1971] E. G. C offm an, M. J. Elphick y A. Shoshani, “S y stem D eadlocks”, Computing Surveys, Vol. 3, N° 2 (1971), págs. 67-78. [C ohén y Je ffe rso n 1975] E. S. Cohén y D. Jefferson, “P rotection in the H y d ra O perating System ”, Proceedings o ft h e A C M Symposium on O perating Systems Principies (1975), págs. 141-160. >

Bibliografía

783

[C ohén y W ood ring 1997] A. Cohén y M. W oodring, Wzn32 M ultithreaded Programm ing, O 'Reilly & A ssociates (1997). [Com er 1999] D. Com er, Internetworking with TCP/IP, Volunte II, Third Edition, Prentice Hall (1999). [C om er 2000] D. Com er, Internetw orking with TCP/IP, Volunte II, Fourth Edition, Prentice Hall

(2000).

[C orbato y V y sso tsk y 1965] F. J. Corbato y V. A. Vyssotsky, “Introduction and OverView o f the M ULTICS System ”, Proceedings o f theA F IP S Fall Joint Com puter Conference (1965), págs. 185-196. [C orbato et al. 1962] F. J. C orbato, M. M erw in-D aggett y R. C. Daley, “A n Experim ental Tim eSharing System ”, Proceedings o f the AFIPS Fall Joint Com puter Conference (1962), págs. 335-344. [C oulouris et al. 2001] G. Coulouris, J. Dollim ore y T. Kindberg, D istributed Systems Concepts and Designs, Third Edition, A ddison W esley (2001). [C ourtois et al. 1971] P. J. C ourtois, F. H eym ans y D. L. Pam as, “C oncurrent Control w ith 'Readers' and 'W riters'”, Com m unications o ft h e A CM , Vol. 14, N° 10 (1971), págs. 667-668. [C u ller et al. 1998] D. E. Culler, J. P. Singh y A. Gupta, Parallel C om puter A rchitecture: A H ardware/Software Approach, M organ Kaufm ann Publishers Inc. (1998). [C uster 1994] H. Custer, Inside the Windows N T File System, M icrosoft Press (1994). [D ab ek et al. 2001] F. D abek, M . F. Kaashoek, D. Karger, R. M orris e I. Stoica, “W ide-A rea C ooperative Storage w ith D FS”, Proceedings o f the A C M Symposium on O perating System s Principies (2001), págs. 202-215. [D aley y D en n is 1967] R. C. D aley y J. B. Dermis, “Virtual M em ory, Processes, and Sharing in M ultics”, Proceedings o f the A C M Symposium on O perating System s Principies (1967), págs. 121-128. [D avcev y Bu rkh ard 1985] D. D avcev y W. A. Burkhard, “C onsistency and Recovery Control for Replicated Files”, Proceedings o f the A C M Symposium on Operating System s Principies (1985), págs. 87-96. [D avies 1983] D. W. Davies, “A pplying the RSA Digital Signature to Electronic M ail”, Computer, Vol. 16, N° 2 (1983), págs. 55-62. [d e B ru ijn 1967] N. G. d eB ru ijn , “A d dition al C om m ents on a P ro blem in C on cu rren t Program m ing and Control”, Communications o fth e A CM , Vol. 10, N° 3 (1967), págs. 137-138. [D eitel 1990] H. M. Deitel, A n Introduction to O perating Systems, Second Edition, A ddison-W esley (1990). [D en n in g 1968] P. J. Denning, “The W orking Set M odel for Program Behavior”, Com m unications o f the A C M , Vol. 11, N° 5 (1968), págs. 323-333. [D en n in g 1982]

D. E. Denning, Cryptography and Data Security, A ddison-W esley (1982).

[D en n in g 1983] D. E. Denning, “Protecting Public Keys and Signature K eys”, Computer, Vol. 16, N° 2 (1983), págs. 27-35. [D e n n in g 1984] D. E. D en ning , “D igital Signatures' w ith R SA and O th er P u blic-K ey C ryptosystem s”, Com m unications o fth e ACM , Vol. 27, N° 4 (1984), págs. 388-392. [D en n in g y D e n n in g 1979] D. E. Denning y P. J. Denning, “D ata Security”, A C M Comput. Surv., Vol. 11, N° 3 (1979), págs. 227-249. [D en n is 1965] J. B. Dennis, “Segm entation and the Design o f M ultiprogram m ed C om puter System s”, Com m unications o ft h e ACM , Vol. 8, N °4 (1965), págs. 589-602. [D en n is y H orn 1966] J. B. D ennis y E. C. V. H om , “Program m ing Sem antics for M ultiprogram mgd C om putations”, Com m unications o fth e ACM , Vol. 9, N° 3 (1966), págs. 143-155.

784

Bibliografía

[D i P ietro y M an cin i 2003] R. Di Pietro y L. V. M ancini, “Security and Privacy Issues of H andheld and W earable W ireless D evices”, Com m unications o f the ACM , Vol. 46, N° 9 (2003), págs. 74-79. [D iffie y H ellm an 1979] W . D iffie y M. E. H ellm an, “Privacy and A uthentication”, Proceedings o f the IEEE(1979), págs. 397-427. [D ijk s tra 1965a] E. W . D ijkstra. “C oo p eratin g S eq u en tial P ro cesses”. T ech n ical Report, Technological U niversity, Eindhoven, H olanda (1965). [D ijk stra 1965b] E. W. D ijkstra, “Solution of a Problem in C oncurrent Program m ing Control”, Com m unications o fth e ACM, Vol. 8, N° 9 (1965), pág. 569. [D ijk stra 1968] E. W . D ijkstra, “The Structure o f the TH E M ultiprogram m ing System ”, Com m unications o ft h e A C M , Vol. 11, N° 5 (1968), págs. 341-346. [D ijk stra 1971] E. W. D ijkstra, “H ierarchical Ordering o f Sequential Processes”, A cta Informática, Vol. 1, N° 2 (1971), págs. 115-138. [D oD 1985] Trusted C om puter System Evaluation Criteria. D epartm ent of D efense (1985). [D ougan et al. 1999] C. D ougan, P. M ackerras y V. Yodaiken, “O ptim izing the Idle Task and O ther M M U Tricks”, Proceedings o ft h e Symposium on O perating System Des ign an d Implementation (1999). [D ouglis y O u sterhout 1991] F. Douglis y J. K. O usterhout, “Transparent Process M igration: Design A ltem atives and the Sprite Im plem entation”, softw are, Vol. 21, N° 8 (1991), págs. 757-785. [D ou glis et al. 1994] F. D ouglis, F. K aashoek, K. Li, R. Caceres, B. M arsh y J. A. Tauber, “Storage A ltem atives for M obile C om puters”, Proceedings o ft h e Symposium on O perating System s Des ign and Implementation(199A), págs. 25-37. [D ouglis et al. 1995] F. D ouglis, P. K rishnan y B. Bershad, “A daptive Disk Spin-D ow n Policies for M obile C om puters”, Proceedings o f the USEN1X Sym posium on M obile and Location Independent Com puting (1995), págs. 121-137. [D raves et al. 1991] R. P. Draves, B. N . Bershad, R. F. Rashid y R. W . Dean, “U sing continuations to im plem ent thread m anagem ent and com m unication in operating system s”, Proceedings ofth e A C M Symposium on O perating Systems Principies (1991), págs. 122-136. [D ru schel y Peterson 1993] P. D ruschel y L. L. Peterson, “Fbufs: A H igh-Bandw idth CrossD om ain Transfer Fácility”, Proceedings o f the A C M Sym posium on O perating System s Principies (1993), págs. 189-202. [Eastlake 1999] D. Eastlake, “D om ain Ñ am e System Security Extensions”, N etw ork Working Group, R equ estfor Com m ents: 2535 (1999). [E isen berg y M cG u ire 1972] M. A. Eisenberg y M. R. M cG uire, “Further Com m ents on Dijkstra's Concurrent Program m ing Control Problem ”, Com m unications o fth e ACM , Vol. 15, N° 11 (1972), pág. 999. [Ekanadham y B em stein 1979] K. Ekanadham y A. J. Bem stein, “C onditional Capabilities”, IEEE Transactions on Software Engiríeering, Vol. SE-5, N° 5 (1979), págs. 458-464. [E n gelschall 2000] R. Engelschall, “Portable M ultithreading: The Signal Stack T rick For UserSpace Thread Creation”, Proceedings o ft h e 2000 U SENIX A nnual Technical Conference (2000). [Esw aran et al. 1976] K- P. Esvvaran, H. N. Gray, R. A. Lorie e I. L. Traiger, “The Notions of C onsistency and Predícate Locks in a DataBase System ”, Com m unications o ft h e A CM , Vol. 19, N° 11 (1976), págs. 624-633. [Fang et al. 2001] Z. Fang, L. Zhang, J. B. Cárter, W. C. H sieh y S . A. M cKee, “Reevaluating Online Superpage Prom otion vvith H ard w are Support”, Proceedings o f the International Symposium on H igh-Performance C om puter Architecture, Vol. 50, N° 5 (2001).

Bibliografía

785

[Farrow 1986a] R. Farrow , “Security for Superusers, or How to Break the UNIX System ”, UNIX W orld (M ayo 1986), págs. 65-70. [Farrow 1986b] R. Farrow, “Security Issues and Strategies for U sers”, UNIX W orld (Abril 1986), págs. 65-71. [F eitelson y R u d olp h 1990] D. Feitelson y L. Rudolph, “M apping and Scheduling ip a Shared Parallel Environm ent U sing D istributed H ierarchical Control”, Proceedings o f the International Conference on Parallel Processing (1990). [Fidge 1991] C. Fidge, “Logical Tim e in D istributed Com puting System s”, Computer, Vol. 24, N° 8 (1991), págs. 28-33. [F ilip sk i y H an ko 1986] A. Filipski y J. H anko, “M aking U N IX Secure”, Byte (Abril 1986), págs. 113-128. [Fisher 1981] J. A. Fisher, “Trace Scheduling: A Techrtique for G lobal M icrocode Com paction”, IEEE Transactions on Computers, Vol. 30, N° 7 (1981), págs. 478-490. [Folk y Z o e llick 1987] M. J. Folk y B. Zoellick, File Structures, A ddison-W esley (1987). [Forrest et al. 1996] S. Forrest, S. A. H ofm eyr y T. A. Longstaff,, “A Sense of Self for UNIX Processes”, Proceedings o f the IEEE Symposium on Security and Privacy (1996), págs. 120-128. [Fortier 1989] P. J. Fortier, H andbook o fL A N Technology, M cGraw -H ill (1989). [F reeB SD 1999] FreeBSD, FreeBSD H andbook, The FreeBSD D ocum entation Project (1999). [Freedm an 1983] D. H. Freedm an, “Searching for Denser Disks”, Infosystem s (1983), pág. 56. [Fuhrt 1994] B. Fuhrt, “M ultim edia System s: A n OverView”, IEEE M ultiM edia, Vol. 1, N° 1 (1994), págs. 4 7-59. [F u jitan i 1984] L. Fujitani, “Láser O ptical Disk: The Corning Revolution in On-Line Storage”, Com m unications o f the A C M , Vol. 27, N° 6 (1984), páginas 546-554. [G ait 1988] J. Gait, “The O ptical File Cabinet: A Random -A ccess File System for W rite-O n Optical Disks”, Computer, Vol. 21, N° 6 (1988). [G anapathy y Sch im m el 1998] N. G anapathy y C. Schim m el, “General Purpose Operating System Support for M últiple Page Sizes”, Proceedings o fth e U SEN IX Technical Conference (1998). [G anger et al. 2002] G. R. Ganger, D. R. Engler, M. F. K aashoek, H. M . Briceno, R. Hunt y T. Pinckney, “Fast and Flexible A pplication-Level N etworking on Exokem el System s”, ACM Transactions on Com puter Systems, Vol. 20, N° 1 (2002), págs. 49-83. [G arcía-M olin a 1982] H. G arcía-M olina, “Elections in Distributed Com puting System s”, IEEE Transactions on Computers, Vol. c-31, N° 1 (1982). [G arfin k el et al. 2003] S. G arfinkel, G. Spafford y A. Schwartz, Practical UNIX & Internet Security, O 'Reilly & Associates (2003). [G ib so n et al. 1997a] G. G ibson, D. N agle, K. Am iri, F. Chang, H. Gobioff, E. Riedel, D. Rochberg y J. Zelenka. “Filesystem s for N etw ork-A ttached Secure D isks”. Technical Report, CM U-CS-97112 (1997). [G ib so n e t al. 1997b] G. G ibson, D. N agle, K. A m iri, F. W. Chang, E. M. Feinberg, H. Gobioff, C. Lee, B. O zceri, E. Riedel, D. Rochberg y }. Zelenka, “File Server Scaling with N etw ork-A ttached Secure D isks”, M easurem ent and M odeling o f Com puter Systems (1997), págs. 272-284. [G iffo rd 1982] D. K. G ifford, “C ryptographic Sealing for Inform ation Secrecy and Authentication”, Com m unications o f the A CM , Vol. 25, N° 4 (1982), págs. 274-286. [G old berg et al. 19% ] 1. G oldberg, D. W agner, R. Thom as y E. A. Brew er, “A Secure Environ­ m ent fo r U ntrusted H elp er A pplications”, Proceedings o f the 6th Usenix Security Symppsium(1996).

786

Bibliografía

[G old en y Pechura 1986] D. G olden y M . Pechura, “The Structure of M icrocom puter File System s”, Com m unications o f the ACM , Vol. 29, N° 3 (1986), páginas 222-230. [G o ld in g et al, 1995] R. A. Golding, P. B. II, C. Staelin, T. Sullivan y J. W ilkes, “Idleness is Not . Sloth”, U SENIX W inter (1995), págs. 201-212. **■— .

*

[G olm e t al. 2002] M. Golm , M. Felser, C. W aw ersich y J. Kleinoder, “The JX O perating System ”, 2002 U SENIX A nnual Technical Conference (2002). [G ong et al. 1997] L. G ong, M. M ueller, H. Prafullchandra y R. Schem ers, “G oing Beyond the Sandbox: A n OverView of the N ew Security A rchitecture in the Java D evelopm ent Kit 1.2”, Proceedings o ft h e U SEN IX Symposium on Internet Technologies and Systems (1997). [G ood m an et al. 1989] J. R. Goodm an, M . K. V em on y P. J. W oest, “Efficient Synchronization Prim itives for Large-Scale Cache-Coherent M ultiprocessors”, Proceedings o f the International Conference on Architectural Support fo r Programm ing Languages and O perating Systems (1989), págs. 64-75. [G o slin g et al. 1996] J. G osling, B. Joy y G. Steele, The Java Language Specification, Addison-W esley (1996). [G ovind an y A nderson 1991] R. G ovindan y D. P. A nderson, “Scheduling and IPC M echanisms for C ontinuous M edia”, Proceedings o f the A C M Symposium on O perating Systems Principies (1991), págs. 68-80. [G ram pp y M orris 1984] F. T. Gram pp y R. H. M orris, “U N IX O perating-System Security”, A T& T Bell Laboratories Technical Journal, Vol. 63, (1984), págs. 1649-1672. [G ray 1978] J. N. Gray, “N otes on D ata Base O perating System s”, in [Bayer et al. 1978] (1978), págs. 393-481. [G ray 1981] J. N. G ray, “The Transaction Concept: Virtues and Lim itations”, Proceedings o f the International Conference on Very Large D atabases (1981), págs. 144-154. [G ray 1997] J. Gray, Interprocess Communications in UNIX, Prentice Hall (1997). [G ray et al. 1981] J. N. G ray, P. R. M cjon es y M. Blasgen, “The Recovery M anager of the System R D atabase M anager”, ACM Com puting Survey, Vol. 13, N° 2 (1981), págs. 223-242. [G reen aw alt 1994] P. G reenaw alt, “M odeling Pow er M anagem ent for Hard D isks”, Proceedings o fth e Symposium on M odeling and Simulation o f Com puter Telecommunication System s (1994), págs. 6 2 -66. [G ro ssh an s 1986] D. G rosshans, Pile Systems Design and Im plem entation, Prentice Hall (1986). [G rosso 2002] W . G rosso, Java RMI, O 'Reilly & A ssociates (2002). [H aberm ann 1969] A. N. H aberm ann, “Prevention of System D eadlocks”, Communications o fth e A C M , Vol. 12, N° 7 (1969), págs. 373-377, 385. [H all e t al. 1996] L. H all, D. Shm oys y J. W ein, “Scheduling To M inim ize A verage Completion Tim e: O ff-line and O n-line A lgorithm s”, SODA: A C M SIA M Symposium on Discrete Algorithm s (1996). [H alsall 1992] F. H alsall, Data Communications, Com puter Netivorks and Open Systems, AddisonW esley (1992). [H am acher et al. 2002] C. Hám acher, Z. Vranesic y S. Zaky, Com puter Organization, Fifth Edition, M cG raw -H ill (2002). [H an y G h o sh 1998] K. H an y S. Ghosh, “A C om parative Analysis of Virtual Versus Physical Process-M igration Strategies for Distributed M odeling and Sim ulation of M obile Computing.. N etw orks”, W ireless Networks, Vol. 4, N° 5 (1998), págs. 365-378. J-

Bibliografía

787

[H ansen y A tk in s 1993] S. E. H ansen y E. T. Atkins, “A utom ated System M onitoring and N otification W ith Sw atch”, Proceedings o ft h e USENIX System s Adm inistration Conference (1993). [H archol-B alter y D ow n ey 1997] M. H archol-Balter y A. B. Downey, “Exploiting Process Lifetim e D istributions for D ynam ic Load Balancing”, A CM Transactions on Com puter Systems, Vol. 15, N° 3 (1997), págs. 253-285. [H arish y O w ens 1999] V. C. H arish y B. O w ens, “D ynam ic Load Balancing D N S”, Linux Journal, Vol. 1999, N° 64 (1999). [H arker et al. 1981] J. M. H arker, D. W. Brede, R. E. Pattison, G. R. Santana y L. G. Taft, “A Q uarter Century of D isk File Innovation”, IBM Journal o f R esearch and Development, Vol. 25, N° 5 (1981), págs. 677-689. [H arrison et al. 1976] M. A. H arrison, W. L. Ruzzo y J. D. U llm an, “Protection in Operating System s”, Com m unications o fth e ACM, Vol. 19, N° 8 (1976), págs. 461-471. [H artm an y O u sterhou t 1995] J. H. H artm an y J. K. O usterhout, “The Zebra Striped NetWork File System ”, ACM Transactions on Com puter Systems, Vol. 13, N ° 3 (1995), págs. 274-310. [H avender 1968] J.W . H avender, “A voiding D eadlock in M ultitasking System s”, IBM Systems Journal, Vol. 7, N° 2 (1968), págs. 74-84. [H echt et al. 1988] M. S. H echt, A. Johri, R. A ditham y T. J. W ei, “Experience A dding C2 Security Features to U N IX”, Proceedings o ft h e Sum m er USENIX Conference (1988), págs. 133-146. [H en n essy y Patterson 2002] J. L. H ennessy y D. A. Patterson, Com puter Architecture: A Q uantitative Approach, Third Edition, M organ K aufm ann Publishers (2002). [H enry 1984] G. Henry, “The Fair Share Scheduler”, A T & T Bell Laboratories Technical Journal (1984). [H erlih y 1993] M. Herlihy, “A M ethodology for Im plem enting H ighly Concurrent Data O bjects”, ACM Transactions on Program m ing Languages and System s, Vol. 15, N° 5 (1993), págs. 745-770. [H erlihy y M oss 1993] M. H erlihy y J. E. B. M oss, “Transactional M emory: Architectural Sup port For Lock-Free D ata Structures”, Proceedings o f the Twentieth Annual International Symposium on Com puter A rchitecture (1993). [H itz et al. 1995] D. Hitz, J. Lau y M. M alcolm , “File System Design for an N FS File Server A ppliance”, Technical R eport TR3002 (http://w ww.netapp.com /tech library/3002.html), NetApp (1995). [H oagland 1985] A. S. H oagland, “Inform ation Storage T echn ology—A Look at the Future”, Com puter, Vol. 18, N° 7 (1985), págs. 60-68. [H oare 1972] C. A. R. Hoare, “Tow ards a Theory of Parallel Program m ing”, in [Hoare y Perrott 1972] (1972), páginas 61-71. [H oare 1974] C. A. R. H oare, “M onitors: A n O p eratin g System Stru ctu ring C on cep t”, Com m unications o fth e A CM , Vol. 17, N° 10 (1974), págs. 549-557. [H oare y Perrott 1972] C. A. R. H oare y R. H. Perrott, editors, Operating Systems Techniques, A cadem ic Press (1972). [H olt 1971] R. C. Holt, “C om m ents on Prevention of System D eadlocks”, Communications o f the ACM , Vol. 14, N° 1 (1971), págs. 36-38. [H olt 1972] R. C. Holt, “Som e Deadlock Properties of C om puter System s”, Computing Surveys, Vol. 4, N° 3 (1972), págs. 179-196. [H olub 2000] A. Holub, Tam ing Java Threads, A press (2000).

Jé

788

Bibliografía

[H ong et al. 1989] J. H ong, X. Tan y D. Tow sley, “A Perform ance A nalysis of M ínim um Laxity and Earliest Deadline Scheduling in a Real-Tim e System ”, IEEE Transactions on Computers, Vol 38, N° 12 (1989), págs. 1736-1744. [How ard ét al. 1988] J. H. H ow ard, M. L. Kazar, S. G. M enees, D. A. N ichols, M. Satyanarayanan y R. N. Sidebotham , “Scale and Perform ance in a Distributed File System ”, ACM Transactions on Com puter System s, V ol. 6, N° 1 (1988), págs. 55-81. [H ow arth et al. 1961] D. J. H owarth, R. B. Payne y F. H. Sum ner, “The M anchester University Atlas O perating System , Part II: U ser's D escription”, Com puter Journal, Vol. 4, N° 3 (1961), págs. 226-2291 [H siao et al. 1979] D. K. H siao, D. S. K err y S. E. M adnick, Com puter Security, A cadem ic Press (1979). [Hu y P errig 2004] Y.-C. H u y A. Perrig, “SPV: A Secure Path V ector Routing Schem e for Securing BG P”, Proceedings o f A C M SIGCO M M Conference on Data Communication (2004). [Hu et al. 2002] Y.-C. H u, A. Perrig y D. Johnson, “Ariadne: A Secure O n-D em and Routing Protocol for Ad H oc N etw orks”, Proceedings o f the Annual International Conference on Mobile Com puting and Netzoorking (2002). [H ym an 1985] D. H ym an, The Columbus Chicken Statute and M ore Bonehead Legislation, S. Greene Press (1985). [Iacobu cci 1988] E. Iacobucci, OS/2 Programmer's Guide, O sbom e M cG raw -H ill (1988). [IB M 1983]

Technical Reference. IBM Corporation (1983).

[Iliffe y Jo d e it 1962] J. K. Üiffe y J. G. Jodeit, “A D ynam ic Storage A llocation System ”, Computer Journal, Vol. 5, N° 3 (1962), págs. 200-209. [Intel 1985a] iA PX 286 Programm er's Reference M anual. Intel Corporation (1985). [In tel 1985b] iA PX 86/88,186/188 User's M anual Programm er's Reference. Intel Corporation (1985). [In tel 1986] iAPX 386 Programmer's R eference M anual. Intel Corporation (1986). [Intel 1990] i486 M icroprocessor Programmer's Reference M anual. Intel Corporation (1990). [In tel 1993] Pentium Processor User's M anual, Volume 3: A rchitecture and Program m ing Manual. Intel C orporation (1993). [Isem inger 2000] D. Isem inger, A ctive Directory Services fo r M icrosoft W indows 2000. Technical Reference, M icrosoft Press (2000). [Jacob y M u d g e 1997] B. Jacob y T. M udge, “Softw are-M anaged A ddress Translation”, Proceedings o f the International Symposium on H igh Perform ance Com puter A rchitecture and Im plem entation (1997). [Jacob y M udge 1998a] B. Jacob y T. M udge, “V irtual M em ory in Contem porary M icroprocessors”, IEEE M icro M agazine, Vol. 18, (1998), páginas 60-75. [Jacob y M udge 1998b] B. Jacob y T. M udge, “V irtual M em ory: Issues of Im plem entation”, IEEE Com puter M agazine, V ol. 31, (1998), págs. 33-43. [Jacob y M udge 2001] B. Jacob y T. M udge, “U niprocessor V irtual M em ory W ithout TLBs”, IEEE Transactions on Com puters, Vol. 50, N° 5 (2001). Q acobson y W ilk es 1991] D. M. Jacobson y J. W ilkes. “Disk Scheduling A lgorithm s Based on Rotational Position”. Technical Report H PL-C SP-91-7 (1991). [Jen sen e t al. 1985] E. D . Jensen, C. D. Locke y H. Tokuda, “A Tim e-D riven Scheduling M odel for Real-Tim e O perating System s”, Proceedings o f the IEEE Real-Tim e Systems Symposium (1985), págs. 112-122.

Bibliografía

789

[Joh nstone y W ilso n 1998] M . S. Johrtstone y P. R. W ilson, “The M em ory Fragm entation Problem : Solved?”, Proceedings o f the First International Symposium on M em ory managem ent (1998), págs. 26-36. [Jones y L iskov 1978] A. K. Jones y B. H. Liskov, “A Language Extensión for Expressing Constraints on D ata A ccess”, Communications o ft h e ACM, Vol. 21, N° 5 (1978), págs. 358-367. [Jul et al. 1988] E. Jul, H. Levy, N. H utchinson y A. Black, “Fine-G rained M obility in the Em erald System ”, ACM Transactions on Computer Systems, Vol. 6, N° 1 (1988), págs. 109-133. [K aashoek et al. 1997] M. F. Kaashoek, D. R. Engler, G. R. Ganger, H. M . Briceno, R. H unt, D. M azieres, T. Pinckney, R. G rim m , J. Jannotti y K. M ackenzie, “A pplication perform ance and flexibility on exokem el system s”, Proceedings o f the ACM Symposium on Operating Systems Principies (1997), págs. 52-65. [K atz et al. 1989] R. H. Katz, G. A. G ibson y D. A. Patterson, “D isk System Architectures for H igh Perform ance C om puting”, Proceedings o fth e IEEE (1989). [K ay y Lauder 1988] J. K ay y P. Lauder, “A Fair Share Scheduler”, Communications o ft h e ACM , Vol. 31, N° 1 (1988), págs. 44-55. [K en t et al. 2000] S. Kent, C. Lynn y K. Seo, “Secure Border G atew ay Protocol (Secure-BGP)”, IEEE Journal on Selected A reas in Communications, Vol. 18, N° 4 (2000), páginas 582-592. [K en v ille 1982] R. F. Kenville, “O ptical D isk D ata Storage”, Com puter, Vol. 15, N° 7 (1982), págs. 21-26. [K essels 1977] J. L. W . Kessels, “A n A ltem ative to Event Q ueues for Synchronization in M onitors”, Com m unications o fth e ACM , Vol. 20, -N° 7 (1977), págs. 500-503. [K hanna et al. 1992] S. K hanna, M. Sebree y J. Zolnow sky, “R ealtim e Scheduling in SunO S 5.0”, Proceedings o ft h e W inter U SENIX Conference (1992), págs. 375-390. [K iebu rtz y S ilb ersch atz 1978] R. B. Kieburtz y A. Silberschatz, “Capability M anagers”, IEEE Transactions on Software Engineering, Vol. SE-4,N um ber 6 (1978), págs. 467-477. [K iebu rtz y Silbersch atz 1983] R. B. K ieburtz y A. Silberschatz, “A ccess Right Expressions”, ACM Transactions on Program m ing Languages and Systems, Vol. 5, N° 1 (1983), páginas 78-96. [K ilb u m et al. 1961] T. K ilbu m , D. J. H ow arth, R. B. Payne y F. H. Sum ner, “The M anchester U niversity A tlas O perating System , Part I: Intem al Orgarúzation”, Com puter Journal, Vol. 4, N° 3 (1961), págs. 222-225. [K im y S p a ffo rd 1993] G. H . K im y E. H. Spafford, “The D esign and Im plem entation of Tripw ire: A File System Integrity Checker”, Technical Report, Purdue U niversity (1993). [K in g 1990] R. P. King, “D isk Arm M ovem ent in A nticipation of Future Requests”, ACM Transactions on Com puter Systems, Vol. 8, N° 3 (1990), págs. 214-229. [K istler y Satyanarayanan 1992] J. Kistler y M. Satyanarayanan, “D isconnected Operation in the Coda File System ”, ACM Transactions on Com puter Systems, Vol. 10, N° 1 (1992), págs. 3-25. [K lein ro ck 1975] L. Kleinrock, Queueing Systems, Volume II: Com puter Applications, W ileyInterscience (1975). [K napp 1987] E. Knapp, “D eadlock Detection in Distributed D atabases”, Computing Surveys, Vol. 19, N° 4 (1987), págs. 303-328. [K n ow lton 1965] K. C. K now lton, “A Fast Storage A llocator”, Com m unications o f the A CM , Vol. 8, N° 10 (1965), págs. 623-624. [K nuth 1966] D. E. Knuth, “A dditional Com m ents on a Problem in Concurrent Program m ing ^ C o n tr o l”, Com m unications o ft h e ACM , Vol. 9, N° 5 (1966), págs. 321-322.

790

Bibliografía

[K nuth 1973] D. E. K nuth, The Art o f Com puter Programming, Volume 1: Fundamental Algorithms, Second Edition, A ddison-W esley (1973). [K och 1987] P. D. L. Koch, “Disk File A llocation Based on the Buddy System ”, ACM Transactions on C om puter Systems, Vol. 5, N° 4 (1987), págs. 352-370. [K opetz y R eisin g er 1993] H. Kopetz y J. Reisinger, “The N on-Blockiñg W rite Protocol NBW : A Solution to a Real-Tim e Synchronisation Problem ”, IEEE Real-Tim e Systems Symposium (1993), págs. 131-137. [K osaraju 1973] S. Kosaraju, “Lim itations o f D ijkstra's Sem aphore Primitives and Petri Nets”, O perating Systems Review , Vol. 7, N° 4 (1973), págs. 122-126. [K ram er 1988] S. M. Kram er, “Retaining SU ID Program s in a Secure UNIX”, Proceedings o f the Sum m er USENIX Conference (1988), págs. 107-118. [K u biato w icz et al. 2000] J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels, R. G um m adi, S. Rhea, H. W eatherspoon, W . W eim er, C. W ells y B. Zhao, “O ceanStore: An A rchitecture for G lobal-Scale Persistent Storage”, Proc. o f A rchitectural S u pportfor Programming Languages and O perating Systems (2000). [K urose y R oss 2005] J. K urose y K. Ross, Com puter N etw orking - A Top-Doum Approach Featuring the Internet, Third Edition, A ddison-W esley (2005). [Lam port 1974] L. Lam port, “A New Solution o f D ijkstra's Concurrent Program m ing Problem ”, Com m unications o fth e A C M , Vol. 17, N° 8 (1974), págs. 453-455. [Lam port 1976] L. Lam port, ‘‘Synchronization of Independent Processes”, Acta Inform ática, Vol. 7, N° 1 (1976), págs. 15-34. [Lam port 1977] L. Lam port, “Concurrent Reading and W riting”, Communications o fth e ACM , Vol. 20, N ° 11 (1977), págs. 806-811. [Lam port 1978a] L. Lam port, “The Im plem entation o f R eliable D istributed M ultiprocess System s”, Com puter N etworks, Vol. 2, N° 2 (1978), págs. 95-114. [Lam port 1978b] L. Lam port, “Time, Clocks and the O rdering of Events in a Distributed System ”, Com m unications o fth e A C M , Vol. 21, N° 7 (1978), págs. 558-565. [Lam port 1981] L. Lam port, “Passw ord A uthentication w ith Insecure C om m unications”, Com m unications o fth e A C M , Vol. 24, N° 11 (1981), págs. 770-772. [Lam port 1986] L. Lam port, “The M utual Exclusión Problem ”, Communications o f the ACM , Vol. . 33, N° 2 (1986), págs. 313-348. [Lam port 1987] L. Lam port, “A Fast M utual Exclusión A lgorithm ”, ACM Transactions on C om puter Systems, Vol. 5, N° 1 (1987), págs. 1-11. [Lam port 1991] L. Lam port, “The M utual Exclusión P roblem H as Been Solved”, Communications o ft h e A C M , Vol. 34, N ° 1 (1991), pág. 110. [Lam port e t al. 1982] L. Lam port, R. Shostak y M. Pease, “The Byzantine G eneráis Problem ”, A C M Transactions on Programm ing Languages and System s, Vol. 4, N° 3 (1982), págs. 382-401. [Lam pson 1969] B. W. Lam pson, “Dynam ic Protection Structures”, Proceedings o f the AFIPS Poli Joint C om puter Conference (1969), págs. 27-38. [Lam pson 1971] B. W. Lam pson, “Protection”, Proceedings o fth e Fifth Annual Princeton Conference on Inform ation Systems Science (1971), págs. 437-443. [Lam pson 1973] B. W. Lam pson, “A N ote on the Confinem ent Problem ”, Com m unications o f the ACM , Vol. 10, N° 16 (1973), págs. 613-615. [Lam pson y R ed ell 1979] B.W. Lam pson y D. D. Redell, “Experience with Processes and M onitors in M esa”, Proceedings o f the 7th A C M Symposium on O perating Systems Principies (SOSP) (1979), págs. 43-44.

Bibliografía

791

[Lam pson y Stu rgis 1976] B. Lam pson y H. Sturgis, “Crash Recovery in a Distributed Data Storage System ”, Technical Report, Xerox Research Center (1976). [Landw ehr 1981] C. E. Landw ehr, “Form al M odels o f Com puter Security”, Computing Surveys, Vol. 13, N° 3 (1981), págs. 247-278. [Lann 1977] G. L. Lann, “D istributed S ystem s—Tow ard a Form al A pproach”, Proceedings o f the IFIP Congress (1977), págs. 155-160. [Larson y K a jla 1984] P. Larson y A. Kajla, “File Organization: Im plem entation of a M ethod G uaranteeing Retrieval in O ne A ccess”, Com m unications o fth e A CM , Vol. 27, N° 7 (1984), págs. 670-677. [Lauzac e t al. 2003] S. Lauzac, R. M elhem y D. M osse, “A n Im proved Rate-M onotonic A dm ission Control and Its A pplications”, IEEE Transactions on Computers, Vol. 52, N° 3 (2003). [Lee 2003] J. Lee, “A n End-U ser Perspective on File-Sharing System s”, Communications o f the ACM , Vol. 46, N° 2 (2003), págs. 49-53. [Lee y T h e k k a th 1996] E. K. Lee y C. A. Thekkath, “Petal: Distributed Virtual D isks”, Proceedings o f the Seventh International Conference on A rchitectural Support fo r Programm ing Languages and O perating System s (1996), págs. 84-92. [L effler et al. 1989] S. J. Leffler, M. K. M cKusick, M. J. Karels y J. S. Q uarterm an, The Design and Im plem entation o ft h e 4.3BSD UNIX Operating System, A ddison-W esley (1989). [Lehm ann 1987] F. Lehm ann, “C om puter Break-Ins”, Com m unications o f the A CM , Vol. 30, N° 7 (1987), págs. 584-585. [L eh oczky e t al. 1989] J. Lehoczky, L. Sha y Y. Ding, “The Rate M onotonic Scheduling A lgorithm : Exact C haracterization and A verage Case Behaviour”, Proceedings o f lOth IEEE Real-Tim e Systems Symposium (1989). [Lem pel 1979] A. Lem pel, “Cryptology in Transition”, Computing Surveys, Vol. 11, N° 4 (1979), págs. 286-303. [L eslie et al. 1996] I. M. Leslie, D. M cAuley, R. Black, T. Roscoe, P. T. Barham , D. Evers, R. Fairbaim s y E. Hyden, “The D esign and Im plem entation of an O perating System to Support Distributed M ultim edia A pplications”, IEEE Journal o f Selected Areas in Communications, Vol. 14, N° 7 (1996), págs. 1280-1297. [Lett y K o n igsfo rd 1 9 6 8 ] 'A. L. Lett y W. L. K onigsford, “TSS/360: A Tim e-Shared O perating System ”, Proceedings o ft h e A FIPS Fall Joint Com puter Conference (1968), págs. 15-28. [Leutenegger y V ern o n 1990] S. Leutenegger y M. V em on, “The Perform ance of M ultiprogram m ed M ultiprocessor Scheduling Policies”, Proceedings o f the Conference on M easurem ent and M odelíng o f Com puter Systems (1990). [Levin et al. 1975] R. Levin, E. S. Cohén, W. M. Corw in, F. J. Pollack y W . A. W ulf, “Policy/ M echanism Separation in H ydra”, Proceedings o f the A C M Symposium on Operating Systems Principies (1975), págs. 132-140. [Levine 2003] G. Levine, “D efining Deadlock”, O perating Systems Review, Vol. 37, N° 1 (2003). [L ew is y B erg 1998] B. Lew is y D. Berg, M ultithreaded Program m ing with Pthreads, Sun M icrosystem s Press (1998). [Lew is y B erg 2000] B. Lew is y D. Berg, M ultithreaded Program m ing with Java Technology, Sun M icrosystem s Press (2000). [L ich te n b e rg e r y P irtle 1965] W. W. L ich ten berg er y M. W . P irtle, “A F acility for Experim entation in M an-M achine Interaction”, Proceedings o f the A FIPS Fall Joint Com puter Conference (1965), págs. 589-598.

792

Bibliografía

[L ind h olm y Y ellin 1999] T. Lindholm y F. Yellin, The Java Virtual M achine Specification, Second Edition, A ddison-W esley (1999). [Ling et al. 2000] Y. Ling, T. M ullen y X. Lin, “A nalysis of O ptim al Thread Pool Size”, Operating System Review, Vol. 34, N° 2 (2000). [Lipner 1975] S. Lipner, “A C om m ent on the Confinem ent P roblem ”, O perating System Review, Vol. 9, N° 5 (1975), págs. 192-196. [Lipton 1974] R. Lipton. “O n Synchronization Prim itive System s”. Ph.D. Thesis, C am egie-M ellon U niversity (1974). [Liskov 1972] B. H. Liskov, “The D esign of the V enus O perating System ”,Communications o f the A CM , Vol. 15, N° 3 (1972), págs. 144-149. [Liu y L ayland 1973] C. L. Liu y J.W . Layland, “Scheduling A lgorithm s for M ultiprogram m ing in a H ard Real-Tim e Environm ent”, Com m unications o f the A C M , Vol. 20, N° 1 (1973), págs. 46-61. [Lobel 1986] J. Lobel, Foiling the System Breakers: Com puter Security and Access Control, M cGraw H ill (1986). [Loo 2003] A .W. Loo, “The Future of Peer-to-Peer C om puting”, Com m unications o fth e ACM , Vol. 46, N° 9 (2003), págs. 5 6-61. [Love 2004] R. Love, Linux K em el D evelopm ent, D eveloper's Library (2004). [Low ney et al. 1993] P. G. Low ney, S. M. Freudenberger, T. J. Karzes, W. D. Lichtenstein, R. P. N ix, J. S. O 'D onnell y J. C. Ruttenberg, “The M ultiflow Trace Scheduling Com piler”, Journal o f Supercom puting, Vol. 7, N° 1-2 (1993), págs. 51-142. [Lucco 1992] S. Lucco, “A D ynam ic Scheduling M ethod for Irregular Parallel Program s”, Proceedings o f the Conference on Program m ing Language D esign and Im plem entation (1992), págs.

200 - 211 . [Ludw ig 1998] M. Ludwig, The G iant Black Book o f Com puter Viruses, Second Edition, A m erican Eagle Publications (1998). [Ludw ig 2002] M. Ludwig, The Little Black Book o f Email Viruses, Am erican Eagle Publications ( 2002 ).

-

[Lum b et al. 2000] C. Lum b, J. Schindler, G. R. G anger, D. F. N agle y E. Riedel, “Tow ards Higher D isk H ead U tilization: Extracting Free Bandw idth From Busy Disk D rives”, Symposium on O perating Systems Design an d Im plem entation (2000). [M aekaw a 1985] M. M aekaw a, “A Squaré Root A lgorithm for M utual Exclusión in Decentralized System s”, A C M Transactions on Com puter System s, Vol. 3, N° 2 (1985), págs. 145-159. [M aher et al. 1994] C. M aher, J. S. Goldick, C. K erby y B. Zum ach, “The Integration of Distributed File System s and M ass Storage System s”, Proceedings o f the IEEE Symposium on M ass Storage System s (1994), págs. 2 7-31. —

[M arsh et al. 1991] B. D. M arsh, M. L. Scott, T. J. LeBlanc y E. P. M arkatos, “First-Class U ser-Level Threads”, Proceedings o f the 13th A C M Sym posium on O perating Systems Principie (1991), págs.

110 - 121 . [M assalin y Pu 1989] H. M assalin y C. Pu, “Threads and Input/O utput in the Synthesis K em el”, Proceedings o ft h e A C M Sym posium on O perating Systems Principies (1989), págs. 191-200. [M attem 1988] F. M attem , “V irtual Tim e and G lobal States of Distributed System s”, W orkshop on Parallel and D istributed A lgorithm s (1988). [M attson et al. 1970] R. L. M attson, J. Gecsei, D. R. Slutz y I. L. Traiger, “Evaluation íechniques for Storage H ierarchies”, IBM Systems Journal, Vol. 9, N° 2 (1970), págs. 78-117.

Bibliografía

793

[M auro y M cD o u g all 2001] J. M auro y R. M cDougall, Solaris Internáis: Core K em el Architecture, Prentice Hall (2001). [M cC anne y Jacobso n 1993] S. M cC anne y V. Jacobson, “The BSD Packet Filter: A N ew A rchitecture for U ser-level Packet Capture”, USENIX W inter (1993), págs. 259-270. [M cG raw y A ndrew s 1979] J. R. M cG raw y G. R. Andrew s, “Access C ontrol in Parallel Program s”, IEEE Transactions on Software Engineering, Vol. SE-5, N° 1 (1979), págs. 1-9. [M cK eag y W ilso n 1976] R. M. M cKeag y R. W ilson, Studies in O perating Systems, A cadem ic Press (1976). [M cK eon 1985] B. M cKeon, “A n A lgorithm for D isk Caching w ith Lim ited M em ory”, Byte, Vol. 10, N° 9 (1985), págs. 129-138. [M cK u sick et al. 1984] M . K. M cKusick, W . N. Joy, S. J. Leffler y R. S. Fabry, “A Fast File System for U N IX”, A C M Transactions on Com puter Systems, Vol. 2, N° 3 (1984), págs. 181-197. [M cK u sick et al. 1996] M . K. M cKusick, K. Bostic y M. J. Karels, The Design and Im plem entation o f the 4.4 BSD UNIX O perating System, John W iley and Sons (1996). [M cV oy y K leim an 1991] L.W . M cVoy y S. R. Kleim an, “Extent-like Perform ance from a U N IX File System ”, Proceedings o ft h e W inter USENIX Conference (1991), págs. 33-44. [M ealy e t al. 1966] G. H. M ealy, B. I. W itt y W. A. Clark, “The Functional Structure of O S/360”, IBM Systems Journal, Vol. 5, N° 1 (1966). [M ellor-C rum m ey y S co tt 1991] J. M. M ellor-Crum m ey y M. L. Scott, “A lgorithm s for Scalable Synchronization on Shared-M em ory M ultiprocessors”, A C M Transactions on Com puter Systems, Vol. 9,N um ber 1 (1991), páginas 21-65. [M enasce y M untz 1979] D. M enasce y R. R. M untz, “Locking and D eadlock Detection in D istributed D ata Bases”, IEEE Transactions on Software Engineering, Vol. SE-5, N ° 3 (1979), págs. 195-202. [M ercer e t al. 1994] C.W . M ercer, S. Savage y H. Tokuda, “Processor C apadty Reserves: O p eratin g System S u p p o rt for M ultim ed ia A p p licatio n s”, In tern ation al C onference on M ultim edia Com puting and Systems (1994), págs. 90-99. [M eyer y Seaw righ t 1970] R. A. M eyer y L. H. Seaw right, “A Virtual M achine Tim e-Sharing System ”, IBM Systems Journal, Vol. 9, N° 3 (1970), págs. 199-218. [M icro so ft 1986] M icrosoft M S-D O S User's R eference and M icrosoft M S-D O S Programm er's Reference. M icrosoft Press (1986). [M icrosoft 1996] M icrosoft W indows N T W orkstation Resource Kit. M icrosoftPress (1996). [M icrosoft 2000a] M icrosoft D eveloper N etwork D evelopm ent Library. M icrosoft Press (2000). [M icrosoft 2000b] M icrosoft W indows 2000 Server Resource Kit. M icrosoft Press (2000). [M icrosystem s 1995] S. M icrosystem s, Solaris M ultithreaded Programming Guide, Prentice H all (1995). [M ilen k o v ic 1987] M. M ilenkovic, O perating Systems: Concepts and Design, M cGraw -H ill (1987). [M iller y K atz 1993] E. L. M iller y R. H. Katz, “An Analysis of File M igration in a U N IXSupercom puting Environm ent”, Proceedings o f the W inter USENIX Conference (1993), págs. 421-434. [M ilo jicic et al. 2000] D. S. M ilojicic, F. Douglis, Y. Paindaveine, R. Wheeler y S. Zhou, “Process M igration”, ACM Comput. Suro., Vol. 32, N° 3 (2000), págs. 241-299. [M o ck ap etris 1987] P. M ockapetris, “D om ain Ñ am es —C oncepts and Facilities”, Netzoork . W orking Group, R equ estfor Comments: 1034 (1987). v

794

Bibliografía

[M ohán y L in d say 1983] C. M ohán y B. Lindsay, “Efficient C om m it Protocols for the Tree of Processes M odel of D istributed Transactions”, Proceedings o f the A C M Symposium on Principies ofD atab ase System s (1983). [M ok 1983] A. K. M ok. “Fundam ental D esign Problem s o f D istributed System s for the Hard Real-Tim e Environm ent”. Ph.D. thesis, M assachussetts Institute of Technology, Cam bridge, M A (1983). [M orris 1973] J. H. M orris, “Protection in Program m ing Languages”, Com m unications o fth e ACM , Vol. 16, N° 1 (1973), págs. 15-21. [M orris y T h o m p so n 1979] R. M orris y K. Thom pson, “Passw ord Security: A C ase H istory”, Com m unications o fth e A C M , Vol. 22, N° 11 (1979), págs. 594-597. [M orris et al. 1986] J. H. M orris, M. Satyanarayanan, M . H. Cortner, J. H. H ow ard, D. S.H. R osenthal y F. D. Sm ith, “A ndrew : A D istributed Personal C om puting Environm ent”, Com m u­ nications o ft h e A CM , Vol. 29, N° 3 (1986), págs. 184-201. [M orsh ed ian 1986] D. M orshedian, “H ow to Fight Passw ord Pirates”, Computer, Vol. 19, N° 1 (1986). [M otorola 1993]

Pow erPC 601 RISC M icroprocessor User's M anual. M otorola Inc. (1993).

[M yers y B e ig l 2003] B. M yers y M. Beigl, “H andheld C om puting”, Com puter, Vol. 36, N° 9 (2003), págs. 2 7 -29. [Navarro et al. 2002] J. N avarro, S. Lyer, P. D ruschel y A. Cox, “Practical, Transparent O perating System Sup port for Superpages”, Proceedings o f the U SENIX Symposium on O perating Systems Design and Im plem entation (2002). [N eedham y W a lk er 1977] R. M. N eedham y R. D. H. W alker, “The C am bridge CA P C om puter and Its Protection System ”, Proceedings o f the Sixth Symposium on O perating System Principies (1977), págs. 1-10. [N elson et al. 1988] M. N elson, B. W elch y J. K. Ousterhout, “C aching in the Sprite NetWork File System ”, A C M Transactions on Computer Systems, Vol. 6, N° 1 (1988), p á g s. 134-154. [N orton y W ilto n 1988] P. N orton y R. W ilton, The New Peter N orton Programm er's Guide to the IBM PC & PS/2, M icrosoft Press (1988). [Nutt 2004] G. Nutt, O perating System s: A M odem Perspective, Third Edition, A ddison-W esley (2004). [O aks y W o n g 1999] S. O aks y H. W ong, Java Threads, Second Edition, O 'R eilly & A ssociates (1999). [O b e rm a rck 1982] R. O berm arck, “D istribu ted D ead lo ck D etectio n A lg o rith m ”, A C M Transactions on D atabase Systems, Vol. 7, N° 2 (1982), págs. 187-208. [O 'L eary y K itts 1985] B. T. O 'Leary y D. L. Kitts, “Optical D evice for a M ass Storage System ”, Computer, Vol. 18, N° 7 (1985). [O lsen y K en ley 1989] R. P. O lsen y G. Kenley, “Virtual O ptical D isks Solve the O n-Line Storage C runch”, Com puter D esign, Vol. 28,-N° 1 (1989), págs. 93-96. [O rganick 1972] (1972).

E. I. O rganick, The M ultics System: An Exam ination o f Its Structure, M IT Press

[O rtiz 2001] S. Ortiz, “Em bedded OSs G ain the ínside Track”, Com puter, Vol. 34, N° 11 (2001). [O usterhou t 1991] J. O usterhout. “The Role of Distributed State”. In CM U Com puter Science: a 25th A nniversary Com m em orative (1991), R. F. Rashid, Ed., A ddison-W esley (1991). [O usterhou t e t al. 1985] J. K. Ousterhout, H. D. Costa, D. H arrison, J. A. Kunze, M. K upfer y J. G. Thom pson, “A Trace-D riven A naiysis of the U N IX 4.2 BSD File System ”, Proceedings o fth e ¿'A CM Symposium on O perating Systems Principies (1985), págs. 15-24.

Bibliografía

795

[O usterhou t et al. 1988] J. K. O usterhout, A. R. Cherenson, F. Douglis, M. N. N elson y B. B. W elch, “The Sprite N etw ork-O perating System ”, Computer, Vol. 21, N° 2 (1988), págs. 23-36. [Param esw aran et al. 2001] M . Param esw aran, A. Susarla y A. B. W hinston, “P2P Networking: A n Inform ation-Sharing A ltem ative”, Computer, Vol. 34, N° 7 (2001). [Parm elee et al. 1972] R. P. Parm elee, T. I. Peterson, C. C. Tillm an y D. Hatfield, “Virtual Storage and Virtual M achine C oncepts”, IBM Systems Journal, Vol. 11, N° 2 (1972), págs. 99-130. [Parnas 1975] D. L. P am as, “O n a Solution to the Cigarette Sm okers' Problem W ithout C onditional Statem ents”, Com m unications o fth e ACM , Vol. 18, N° 3 (1975), págs. 181-183. [P atil 1971] S. Patil. “L im itation s y C apabilities o f D ijkstra's Sem aphore Prim itives for Coordination A m ong Processes”. Technical Report, M IT (1971). [Patterson et al. 1988] D. A. Patterson, G. G ibson y R. H. Katz, “A Case for Redundant Arrays of Inexpensive Disks (RA ID )”, Proceedings o f the A C M SIGM OD International Conference on the M anagem ent o fD a ta (1988). [Pease et al. 1980] M. Pease, R. Shostak y L. Lam port, “Reaching A greem ent in the Presence of Faults”, Com m unications o ft h e ACM, Vol. 27, N° 2 (1980), págs. 228-234. [Pechura y S ch o e ffle r 1983] M. A. Pechura y J. D. Schoeffler, “Estim ating File Access Tim e of Floppy D isks”, Com m unications o ft h e ACM , Vol. 26, N° 10 (1983), págs. 754-763. [Perlm an 1988] R. Perlm an, N etw ork Layer Protocols with Byzantine Robustness. PhD thesis, M assachusetts Institute of Technology (1988). [Peterson 1981] G. L. Peterson, “M yths A bout the M utual Exclusión Problem ”, Information Processing Letters, Vol. 12, N° 3 (1981). [Peterson y D avie 1996] L. L. Peterson y B. S. Davie, Com puter N etworks: a Systems Approach, M organ Kaufm ann Publishers Inc. (1996). [Peterson y N orm an 1977] J. L. Peterson y T. A. N orm an, “Buddy System s”,Communications o f the ACM , Vol. 20, N° 6 (1977), páginas 421-431. [P fleeger y P fleeg er 2003] Hall (2003).

C. Pfleeger y S. Pfleeger, Security in Computing, Third Edition, Prentice

[P h ilb in et al. 1996] J. Philbin, J. Edler, O. J. Anshus, C. C. Douglas y K. Li, “Thread Scheduling for Cache Locality”, A rchitectural Support fo r Programm ing Languages and Operating Systems (1996), págs. 60-71. [P in illa y G ilí 2003] R. Pinilla y M. Gilí, “JVM : Platform Independent vs. Perform ance D ependent”, O perating System Review (2003). [P olychronopoulos y K u ck 1987] C. D. Polychronopoulos y D. J. Kuck, “Guided Self-Scheduling: A Practical Scheduling Schem e for Parallel Supercom puters”, IEEE Transactions on Computers, Vol. 36, N° 12 (1987), págs. 1425-1439. [Popek 1974] G. J. Popek, “Protection Structures”, Computer, Vol. 7, N° 6 (1974), páginas 22-33. [P opek y W alk er 1985] G. Popek y B. W alker, editors, The LOCUS D istributed System Architecture, M IT Press (1985). [Prieve y Fabry 1976] B. G. Prieve y R. S. Fabry, “VM IN —An Optim al Variable Space PageReplacem ent A lgorithm ”, Com m unications o fth e ACM, Vol. 19, N° 5 (1976), págs. 295-297. [P saltis y M o k 1995] D. Psaltis y F. M ok, “H olographic M em ories”, Scientific Am erican, Vol. 273, N° 5 (1995), págs. 70-76. [Purdin et al. 1987] T. D. M. Purdin, R. D. Schlichting y G. R. A ndrew s, “A File Replication ^ ¿facility for Berkeley U N IX ”, Software - Practice and Experience, Vol. 17, (1987), págs. 923-940.

796

Bibliografía

[Purdom , Jr. y Stigler 1970] P. W. Purdom , Jr. y S. M. Stigler, “Statistical Properties of the Buddy System ”, /. ACM, Vol. 17, N° 4 (1970), págs. 683-697. [Q uinlan 1991] S. Quinlan, “A Cached W O RM ”, Software - Practice and Experience, Vol. 21, N° 12 (1991), págs. 1289-1299. [Rago 1993] S. Rago, UNIX System V N etw ork Programm ing, A ddison-W esley (1993). [R ishid 1986] R. F. Rashid, “From RIG to A ccent to M ach: The Evolution of a N etw ork Operating System ”, Proceedings o ft h e ACM /IEEE Com puter Society, Fall Join t Com puter Conference (1986). [Rashid y Robertson 1981] R. Rashid y G. Robertson, “A ccent: A Com m unication-Oriented N etw ork Operating System K em el”, Proceedings o f the ACM Symposium on Operating System Principies (1981). [Raynal 1986] M. Raynal, Algorithm s fo r M utual Exclusión, M IT Press (1986). [Raynal 1991] M. Raynal, “A Sim ple Taxonom y for D istributed M utual Exclusión Algorithms”, O perating Systems Review, Vol. 25, N° 1 (1991), págs. 47-50. [Raynal y Singhal 1996] M. Raynal y M. Singhal, “Logical Tim e: Capturing Causality in D istributed System s”, Computer, Vol. 29, N° 2 (1996), págs. 4 9-56. [Reddy y W yllie 1994] A. L. N. Reddy y J. C. W yllie, “I/O issues in a M ultim edia System”, Com puter, Vol. 27, N° 3 (1994), págs. 69-74. [Redell y Fabry 1974] D. D. Redell y R. S. Fabry, “Selective Revocation of Capabilities”, Proceedings o f the IRIA International W orkshop on Protection in O perating Systems (1974), págs. 197-210. [Reed 1983] D. P. Reed, “Im plem enting A tom ic A ctions o n D ecentralized D ata”, ACM Transactions on Computer Systems, Vol. 1, N° 1 (1983), págs. 3 -2 3 . [Reed y K anodia 1979] D. P. Reed y R. K. Kanodia, “Synchronization w ith Eventcounts and Sequences”, Communications o f the ACM, Vol. 22, N° 2 (1979), págs. 115-123. [Regehr et al. 2000] J. Regehr, M. B. Jones y J. A. Stankovic, “O perating System Support for M ultim edia: The Program m ing Model M atters”, Technical R eport M SR-TR-2000-89, Microsoft Research (2000). [Reid 1987] B. Reid, “R eflections on Som e R ecent W id esp read C om puter Break-Ins”, Com m unications o f the A CM , Vol. 30, N° 2 (1987), págs. 103-105. [Ricart y Agraw ala 1981] G. Ricart y A. K. A graw ala, “A n O ptim al Algorithm fór Mutual Exclusión in Com puter N etw orks”, Com m unications o fth e A CM , Vol. 24, N° 1 (1981), págs. 9-17. [Richards 1990] A. E. Richards, “A File System A pproach for Integrating Rem ovable Media D evices and Jukeboxes”, Optical Information Systems, Vol. 10, N° 5 (1990), págs. 270-274. [Richter 1997] J. Richter, Advanced Windoivs, M icrosoft Press (1997). [Riedel et al. 1998] E. Riedel, G. A. Gibson y C. Faloutsos, “A ctive Storage for Large-Scale Data M ining and M ultim edia”, Proceedings o f 24th International Conference on Verxi Large Data Bases (1998), págs. 62-73. [Ripeanu et al. 2002] M. Ripeanu, A. Im m nitchi y I. Foster, “M apping the Gnutella Network”, IEEE Internet Computing, Vol. 6, N° 1 (2002). [Rivest et al. 1978] R. L. Rivest, A. Sham ir y L. A dlem an, “O n D igital Signátures and Public Key C ryptosystem s”, Com m unications o f the A CM , Vol. 21, N° 2 (1978), págs. 120-126. [Rodeheffer y Schroeder 1991] T. L. Rodeheffer y M. D. Schroeder, “A utom atic reconfiguration in A utonet”, Proceedings o f the ACM Symposium on O perating Systems Principies (1991), págs. 183-97. >

Bibliografía

797

[R o se n b lu m y O u sterh o u t 1991] M. R osen blu m y J. K. O u sterhou t, “T he D esign and Im plem entation of a Log-Structured File System ”, Proceedings o f the A C M Symposium on O perating Systems Principies (1991), págs. 1-15. [R osen krantz et al. 1978] D. J. Rosenkrantz, R. E. Stearns y P. M. Lew is, “System Level C oncurrency Control for Distributed D atabase System s”, A C M Transactions on Database Systems, Vol. 3, N° 2 (1978), págs. 178-198. [R u em m ler y W ilk es 1991] C. Ruem m ler y J. W ilkes. “D isk Shuffling”. Technical Report, H ew lett-Packard Laboratories (1991). [R u em m ler y W ilk es 1993] C. Ruem m ler y J. W ilkes, “U nix D isk Access P attem s”, Proceedings o f the W inter USENIX Conference (1993), páginas 405-420. [R uem m ler y W ilk es 1994] C. Ruem m ler y J. W ilkes, “A n Introduction to D isk D rive M odeling”, Computer, Vol. 27, N° 3 (1994), págs. 17-29. [R u sh by 1981] J. M. Rushby, “D esign and Verification o f Secure System s”, Proceedings o fth e ACM Symposium on Operating System s Principies (1981), págs. 12-21. [R u sh by y R an d ell 1983] J. Rushby y B. Randell, “A D istributed Secure System ”, Computer, Vol. 16, N° 7 (1983), págs. 55-67. [R u ssell y G an gem i 1991] D. Russell y G. T. Gangem i, Com puter Security Basics, O 'R eilly & A ssociates (1991). [Saltzer y Sch roeder 1975] J. H. Saltzer y M . D. Schroeder, “The Protection of Inform ation in C om puter System s”, Proceedings o fth e IEEE (1975), págs. 1278-1308. [San d berg 1987] R. Sandberg, The Sun N etw ork File System : Design, Im plem entation and Experience, Sun M icrosystem s (1987). [San d berg e t al. 1985] R. Sandberg, D. Goldberg, S. Kleim an, D. W alsh y B. Lyon, “Design and Im plem entation of the Sun N etw ork Filesystem ”, Proceedings o fth e Sum m er USENIX Conference (1985), págs. 119-130. [Sargent y Shoem aker 1995] M. Sargent y R. Shoem aker, The Personal Com puter from the Inside Out, Third Edition, A ddison-W esley (1995). [Sarisk y 1983] L. Sarisky, “W ill Rem ovable H ard D isks R eplace the Floppy?”, Byte (1983), págs. 110-117. [Satyanarayanan 1990] M. Satyanarayanan, “Scalable, Secure and H ighly A vailable Distributed File A ccess”, Computer, Vol. 23, N° 5 (1990), págs. 9-21. [Savage et al. 2000] S. Savage, D. W etherall, A. R. Karlin y T. A nderson, “Practical N etw ork Support for IP Traceback”, Proceedings o f A C M SIG CO M M Conference on Data Communication (2000), páginas 295-306. [S ch ell 1983] R. R. Schell, “A Security K em el for a M ultiprocessor M icrocom puter”, Com puter (1983), págs. 47-53. [S ch in d ler y G regory 1999] J. Schindler y G. Gregory, “A utom ated D isk D rive Characterization”, Technical Report, C am egie-M ellon University (1999). [S ch lich tin g y Sch neid er 1982] R. D. Schlichting y F. B. Schneider, “U nderstanding and Using A synchronous M essage Passing Prim itives”, Proceedings o f the Symposium on Principies o f D istributed Computing (1982), págs. 141-147. [Sch n eid er 1982] F. B. Schneider, “Synchrortization in D istributed Program s”, A C M Transactions on Program m ing Languages and Systems, Vol. 4{ N ° 2 (1982), págs. 125-148. [Sch n eier 1996] B. Schneier, Applied Cryptography, Second Edition, Joh n W iley and Sons (1996).

798

Bibliografía

[Sch rage 1967] L. E. Schrage, “The Q ueue M /G/I with Feedback to Lower Priority Q ueues”, M anagem ent Science, Vol. 13, (1967), págs. 466-474. [Sch w arz y M attem 1994] R. Schw arz y F. M attem , “Detecting Causal Relationships in D istributed C om putations: In Search o f the H oly G rail”, D istributed Computing, Vol. 7, N° 3 (1994), páginas 149-174. [S eely 1989] D. Seely, “Passw ord Cracking: A Gam e of W its”, Communications o ft h e ACM, Vol. 32, N° 6 (1989), páginas 700-704. [S eltz er et al. 1990] M. Seltzer, P. Chen y J. O usterhout, “D isk Scheduling Revisited”, Proceedings o ft h e W inter USENIX Conference (1990), págs. 313-323. [S eltzer et al. 1993] M. 1. Seltzer, K. Bostic, M. K. M cKusick y C. Staelin, “An Im plem entation of a Log-Structured File System for U N IX”, U SENIX W inter (1993), págs. 307-326. [S eltzer et al. 1995] M. I. Seltzer, K. A. Sm ith, H. Balakrishnan, ]. Chang, S. M cM ains y V. N. Padm anabhan, “File System Logging versus Clustering: A Perform ance Com parison”, USE­ N IX W inter (1995), págs. 249-264. [Sh rivastava y Panzieri 1982] S. K. Shrivastava y F. Panzieri, “The Design of a Reliable Rem óte Procedure Cali M echanism ”, IEEE Transactions on Computers, Vol. C~31, N° 7 (1982), págs. 692-697. [S ilb ersch atz et al. 2001] A. Silberschatz, H. F. Korth y S. Sudarshan, Database System Concepts, Fourth Edition, M cGraw -H ill (2001). [S ilv erm an 1983] J. M. Silverm an, “Reflections on the Verification of the Security of an O perating System K ernel”, Proceedings o f the ACM Symposium on O perating Systems Principies (1983), págs. 143-154. [S ilv ers 2000] C. Silvers, “UBC: An Efficient Unified l/O and M emory Caching Subsystem for N etBSD ”, USENIX A nnual Technical C o n feren ce- FREENIX Track (2000). [Sim m on s 1979] G. J. Sim m ons, “Sym m etric and Asym m etric Hncryption”, Computing Surveys, Vol. 11, N° 4 (1979), págs. 304-330. [S in ce rb o x 1994] G. T. Sincerbox, editor, Selected Papers on H olographic Storage, O ptical Engineering Press (1994). [S in g h a l 1989] M. Singhal, “Deadlock Detection in Distributed Svstem s”, Computer, Vol. 22, N° 11 (1989), págs. 37-48. [S irer et al. 1999] E. G. Sirer, R. Grim m , A. J. Gregory y B. N. Bershad, “Design and Im plem entation of a Distributed Virtual M achine for N etw orked Com puters”, Symposium on Operating Systems Principies (1999), páginas 202-216. [S m ith 1982] 473-530.

A. J. Sm ith, “Cache M em ories”, ACM Com puting Suroeys, Vol. 14, N° 3 (1982), págs.

[S m ith 1985] A. J. Sm ith, “Disk Cache-M iss Ratio A nalysis and Design Considerations”, ACM Transactions on Com puter Systems, Vol. 3, N° 3 (1985), págs. 161-203. [S o b ti et al. 2004] S. Sobtí, N. Garg, F. Zheng, J. Lai, Y. Shao, C. Zhang, E. Ziskind, A. K rishnam urthy y R. W ang, “Segank: A D istributed M obile Storage System ”, Proceedings o f the Third USENIX Conference o?t File and Storage Technologies (2004). [So lo m o n 1998]

D. A. Solom on, Inside Windozvs NT, Second Edition, M icrosoft Press (1998).

[So lo m o n y R u ssin o v ich 2000] D. A. Solom on y M. E. Russinovich, biside M icrosoft W indows 2000, Third Edition, M icrosoft Press (2000). [S p affo rd 1989] E. H. Spafford, "The Internet W orm : Crisis and A fterm ath”, Com m unications o f the ACM , Vol. 32, N° 6 (1989), págs. 678-687.

JF

Bibliografía

799

[Spector y Schw arz 1983] A. Z. Spector y P. M. Schwarz, “Transactions: A Construct for Reliable D istributed C om puting”, ACM S1GOPS Operating Systems Review, Vol. 17, N° 2 (1983), págs. 18-35. [S tallin g s 2000a] W. Stallings, Local and M etropolitan Area Networks, Prentice Hall (2000). [S tallin g s 2000b] W. Stallings, O perating Systems, Fourth Edition, Prentice Hall (2000). [S tallin g s 2003] W. Stallings, Cryptovraphy and N etwork Security: Principies and Practice, Third Edition, Prentice Hall (2003). [Stan kovic 1982] J. S. Stankovic, “Softw are Com m unication M echanism s: Procedure Calis Versus M essages”, Com puter, Vol. 15, N° 4 (1982). [Stan kovic 1996] J. A. Stankovic, “Strategic Directions in Real-Tim e and Em bedded System s”, ACM Com puting Surueys, Vol. 28, N° 4 (1996), págs. 751-763. [Staunstrup 1982] J. Staunstrup, “M essage Passing Com m unication Versus Procedure Cali C om m unication”, Softw are - Practice and Experience, Vol. 12, N° 3 (1982), págs. 223-234. [Stein m etz 1995] R. Steinm etz, “A nalyzing the M ultim edia O perating System ”, IEEE M ultiM edia, Vol. 2, N° 1 (1995), págs. 68-84. [Step h enson 1983] C. J. Stephenson, “Fast Fits: A New M ethod for Dynam ic Storage A llocatíon”, Proceedings o fth e N inth Symposium on Operating Systems Principies (1983), páginas 30-32. [Stevens 1992] R. Stevens, Advanced Programming in the UNIX Environment, A ddison-W esley (1992). [Stevens 1994] R. Stevens, TCP/IP Illustrated Volume 1: The Protocols, A ddison-W esley (1994). [Stevens 1995] R. Stevens, TCP/IP Illustrated, Volume 2: The Implementation, A ddison-W esley (1995). [Stevens 1997] W . R. Stevens, UNIX Network Programming - Volume I, Prentice Hall (1997). [Stevens 1998] W. R. Stevens, UNIX N etwork Programming - Volume II, Prentice Hall (1998). [Stevens 1999] W. R. Stevens, UNIX N etw ork Programming Interprocess Communications — Volume 2, Prentice Hall (1999). [Stoica et al. 1996] I. Stoica, H. Abdel-W ahab, K. Jeffay, S. Baruah, J. Gehrke y G. Plaxton, “A Proportional Share Resource A llocation Algorithm for Real-Time, Tim e-Shared System s”, IEEE ____ Real-Tim e Systems Symposium (1996). ...... [Su 1982] Z. Su, “A D istributed System for Internet Ñ am e Service”, N etwork W orking Group, R equ estfor Com m ents: 830 (1982). [Sugerm an et al. 2001] J. Sugerm an, G. Venkitachalam y B. Lim, “Virtualizing 1/O D evices on VM w are W orkstatin's H osted Virtual M achine M onitor”, 2001 USENIX A nnual Technical Conference (2001). [Su n 1990] N etwork Program m ing Guide. Sun M icrosystem s (1990). [Svobodova 1984] L. Svobodova, “File Servers for Network-Based Distributed System s”, ACM Com puting Survey, Vol. 16, N° 4 (1984), págs. 353-398. [T allu ri et al. 1995] M. Talluri, M. D. H ill y Y. A. Khalidi, “A New Page Table for 64-bit Address Spaces”, Proceedings o f the A C M Symposium on Operating Systems Principies (1995). [Tam ches y M iller 1999] A. Tam ches y B. P. Miller, “Fine-Grained Dynam ic Instrum entation of Com m odity O perating System Kerneís”, USENIX Symposium on O perating Systems Design and Implementation (1999). [T anenbau m 1990] A. S. Tanenbaum , Stru ctured Cotiipiítcr O rganization, Third Edition, Prentice Hall (1990).

800

Bibliografía

[T an en b au m 2001] A. S. Tanenbaum , M odem O perating Systems, Prentice Hall (2001). [T anen bau m 2003] A. S. Tanenbaum , Com puter Networks, Fourth Edition, Prentice H all (2003). [T anen bau m y V an R en esse 1985] A. S. Tanenbaum y R. V an Renesse, “D istributed Operating System s”, ACM Com puting Survey, Vol. 17, N° 4 (1985), págs. 419-470. [T anen bau m y van S teen 2002] A. Tanenbaum y M. van Steen, D istributed System s: Principies and Paradigm s, Prentice H all (2002). [T anen bau m y W o od h u ll 1997] A. S. Tanenbaum y A. S. W oodhull, Operating System Design and Im plem entation, Second Edition, Prentice Hall (1997). [Tate 2000] S. Tate, W indows 2000 Essential Reference, N ew Riders (2000). [Tay y A nanda 1990] B. H. Tay y A. L. Ananda, “A Survey of R em óte Procedure C alis”, Operating System s Review, Vol. 24, N° 3 (1990), págs. 68-79. [T eorey y P in k erto n 1972] T. J. Teorey y T. B. Pinkerton, “A C om parative A nalysis of Disk Scheduling Policies”, Com m unications o fth e ACM , Vol. 15, N° 3 (1972), págs. 177-184. [T evan ian et al. 1987a] A. Tevanian, Jr., R. F. Rashid, D. B. G olub, D. L. Black, E. C ooper y M. W. Y oung, “M ach Threads and the U nix K em el: The Battle for C ontrol”, Proceedings o fth e Summer USENIX Conference (1987). [T evan ian et al. 1987b] A. Tevanian, Jr., R. F. Rashid, M. W. Young, D. B. G olub, M. R. Thom pson, W . Bolosky y R. Sanzi. “A U N IX Interface for Shared M em ory and M emory M apped Files U nder M ach”. Technical Report, C am egie-M ellon U niversity (1987). [T evanian et al. 1989] A. Tevanian, Jr. y B. Smith, “M ach: The M odel for Future U nix”, Byte (1989). [T h ek k a th et al. 1997] C. A. Thekkath, T. M ann y E. K. Lee, “Frangipani: A Scalable Distributed File System ”, Symposium on O perating Systems Principies (1997), páginas 224-237. [T hom pson 1984] K. Thom pson, “Reflections on Trusting T ru st”, Com m unications o f ACM , Vol. 27, N° 8 (1984), págs. 761-763. [T h o m 1997] T. Th om , “P rogram m ing Languages for M obile C ode”, ACM Com puting Surveys, Vol. 29, N° 3 (1997), págs. 213-239. [T oigo 2000] J. Toigo, “A voiding a Data Crunch”, Scientific A m erican, Vol. 282, N° 5 (2000), págs. 5 8 -74. [T raiger et al. 1982] I. L. Traiger, J. N. G ray, C. A. G altieri y B. G. Lindsay, “Transactions and C onsistency in D istributed D atabase M anagem ent System s”, A CM Transactions on Database System s, Vol. 7, N° 3 (1982), págs. 323-342. [T u cker y G u pta 1989] A. Tu cker y A. Gupta, “Process C ontrol and Scheduling Issues for M ultiprogram m ed Shared-M em ory M ultiprocessors”, Proceedings o f the ACM Symposium on O perating System s Principies (1989). [Tudor 1995] P. N. Tudor. “M PEG -2 video com pression tutorial”. IEEE Coloquium on M PEG-2 W hat it is and W hat it isn 't (1995). [V ah alia 1996]

U. Vahalia, Unix Internáis: The N ew Frontiers, P rentice Hall (1996).

[V ee y H su 2000] V. V ee y W. Hsu, “Locality-Preserving Load-Balancing M echanism s for Synchronous Sim ulations on Shared-M em ory M ultiprocessors”, Proceedings o f the Fourteenth W orkshop on Parallel an d D istributed Simulation (2000), págs. 131-138. [V en n ers 1998] B. Venners, Inside the Java Virtual M achine, M cG raw -H ill (1998). [W ah 1984] B. W. W ah, “File Placem ent on Distributed C om puter System s”, Computer, Vol. 17, j j N° 1 (1984), págs. 23-32.

Bibliografía

801

[W ahbe et al. 1993a] R. W ahbe, S. Lucco, T. E. A nderson y S. L. G raham , “Efficient Softw areBased Fault Isolation”, A C M SIGOPS O perating System s Review , Vol. 27, N° 5 (1993), págs. 203-216. [W ahbe et al. 1993b] R. W ahbe, S. Lucco, T. E. A nderson y S. L. G raham , “Efficient Softw areBased Fault Isolation”, A C M SIGOPS O perating Systems Review, Vol. 27, N° 5 (1993), págs. 203-216. [W allach e t al. 1997] D. S. W allach, D. Balfanz, D. D ean y E. W . Felten, “Extensible Security A rchitectures for Java”, Proceedings o f the A C M Symposium on O perating Systems Principies (1997). [W ilkes et al. 1996] j. W ilkes, R. Golding, C. Staelin y T. Sullivan, “The HP AutoRAID H ierarchical Storage System ”, ACM Transactions on Com puter Systems, Vol. 14, N° 1 (1996), págs. 108-136. [W illiam s 2001] R. W illiam s, Computer System s A rchitecture - A N etworking Approach, AddisonW esley (2001). [W illiam s 2002] N. W illiam s, “An Im plem entation of Scheduler A ctivations on the NetBSD O perating System ”, 2002 USENIX Annual Technical Conference, FREEN IX Track (2002). [W ilson et al. 1995] P. R. W ilson, M. S. Johnstone, M. N eely y D. Boles, “Dynam ic Storage Allocation: A Survey and Critical Review ”, Proceedings o f the International W orkshop on M em ory M anagem ent (1995), págs. 1-116. [W o lf 2003] W. Woíf, “A D ecade of H ardw are/Softw are Codesign”, Computer, Vol. 36, N° 4 (2003), págs. 38-43. [W ood y K och an 1985] P. W ood y S. Kochan, UNIX System Security, H ayden (1985). [W oodside 1986] C. W oodside, “Controllability of Com puter Perform ance Tradeoffs Obtained Using Controlled-Share Q ueue Schedulers”, IEEE Transactions on Software Engineering, Vol. SE12, N° 10 (1986), págs. 1041-1048. [W orthington et al. 1994] B. L. W orthington, G. R. G anger y Y. N. Patt, “Scheduling Algorithms for M odem Disk O rives”, Proceedings o f the A C M Sigm etrics Conference on M easurem ent and M odeling o f Computer System s (1994), págs. 241-251. [W orthington et al. 1995] B. L. W orthington, G. R. G anger, Y. N. Patt y J. W ilkes, “On-Line Extraction of SCSI D isk Drive Param eters”, Proceedings o f the A C M Sigmetrics Conference on M easurem ent and M odeling o f Computer System s (1995), págs. 146-156. [W u lf 1969] W . A. W ulf, “Perform ance M onitors for M ultiprogram m ing System s”, Proceedings o f the A C M Symposium on Operating Systems Principies (1969), págs. 175-181. [W u lf e t al. 1981] W. A. W ulf, R. Levin y S. P. H arbison, H ydra/C.m m p: An Experimental Computer System, M cGraw -H ill (1981). [Yeong et al. 1995] W. Yeong, T. Howes y S. Kille, “Lightw eight Directory Access Protocol”, N etw ork W orking Group, Request fo r Com m ents: 1777 (1995). [Young et al. 1987] M. Young, A. Tevanian, R. Rashid, D. G olub y J. Eppinger, “The Duality of M em ory and Com m unication in the Im plem entation o f a M ultiprocessor Operating System ”, Proceedings o fth e A CM Symposium on O perating Systems Principies (1987), págs. 63-76. [Yu et al. 2000] X. Yu, B. G um , Y. Chen, R. Y. W ang, K. Li, A. K rishnam urthy y T. E. Anderson, “Trading C apad ty for Perform ance in a D isk A rray”, Proceedings o f the 2000 Symposium on Operating Systems Design an d Implementation (2000), págs. 243-258. [Zabatta y Y ou ng 1998] F. Zabatta y K. Young, “A Thread Perform ance Com parison: W indows NT and Solaris on a Sym m etric M ultiprocessor”, Proceedings o f the 2nd USENIX Windoivs N T J lSymposium (1998).

Bibliografía

[Z ah orjan y M cC ann 1990] J. Zahorjan y C. M cCann, “Processor Scheduling in Shared-M em ory M ultiprocessors”, P roceedin gs o ft h e C on feren ce on M easu rem en t an d M od elin g o f C om pu ter System s (1990). [Zapata y A sokan 2002] M. Zapata y N. A sokan, “Securing Ad H oc Routing Protocols”, Proc. 2002 A C M W orkshop on W ireless S ecu rity (2002). [Zhao 1989] W. Zhao, editor, S pecial Issu e on R eal-T im e O peratin g System s, O perating System Review (1989).

Créditos Figura 1.9: de H ennesy y Patterson, Com puter Architecture: A Quantitative Approach, Third Edition, O 2002, M organ K aufm ann Publishers, Figura 5.3, pág. 394. Reimpreso con permiso del editor. Figura 3,9: de Iaccobucci, OS/2 P rogram m er's C u id e, © 1988, M cGraw -Fíill, Inc., N ueva York, N ueva York. Figura 1.7, pág. 20. Reim preso con perm iso del editor. Figura 6.8: de Khanna/Sebree/Zolnow sky, “Realtim e Scheduling in SunOS 5.0” Proceedings of W inter USENIX, enero 1992, San Francisco, C alifornia. Reim preso con permiso de los autores. Figura 6.10 adaptada con perm iso de Sun M icrosystem s, Inc. Figura 9.21: del m anual 8 0 3 8 6 P rogram m er's R eferen ce M an u al, Figura 5-12, pág. 5-12. Reimpreso con perm iso de Intel Corporation, Copyright,/ Intel C orporation 1986. Figura 10.16: de IB M System s Jou rnal, Vol. 10, N° 3, © 1971, International Business M achines Corporation. Reim preso con perm iso de IBM Corporation. Figura 12.9: de Leffler/M cK usick/K arels/Q uarterm an, The D esign and Im plem entation o f the 4 .3B S D U N IX O peratin g S ystem , © 1989 por A ddison-W esley Publishing Co., Inc., Reading, M assachusetts. Figura 7.(j, pág. 196. Reim preso con perm iso del editor. Figura 13.9: de P en tiu m P rocessor U ser's M an u al: A rchitectu re an d P rogram m ing M anual, Vol. 3, C opyright 1993. Reim preso con perm iso de Intel Corporation. Figuras 1 5 .4 ,1 5 .5 , y 15.7: de H alsall, D ata C om m unications, C om pu ter N etw orks, an d Open System s, T hird E dition, © 1992, A ddison-W esley Publishing Co., Inc., Reading, Massachusetts. Figura 1.9, pág. 14, Figura 1.10, pág. 15 y Figura 1.11, pág. 18. Reim preso con perm iso del editor. Secciones de los capítulos 7 y 17 de Silberschatz/K orth, D atabase System Concepts, Third Edition, Copyright 1997, M cG raw -H ill, Inc., N ueva York, N ueva York. Sección 13.5, págs. 451-454,14.1.1, págs. 471 -742,14.1.3, págs. 476-479,14.2, págs. 482-485, 15.2.1, págs. 512-513,15.4, págs. 517-518, 15.4.3, págs. 523-524,18.7, págs. 613-617,18.8, págs. 617-622. Reim preso con permiso del editor. Figura A .l: de Q uarterm an/W ilhelm , UNIX, P O S IX an d O pen S ystem s: The Open Standards Puzzle, © 1993, por A ddison-W esley Publishing Co., Inc. Reading, M assachusetts. Figura 2.1, pág. 31. R eim preso con perm iso del editor.

J-

¡ndice .NET Framework, 62 lOOBaseT Ethernet, 563 lOBaseT Ethernet, 563 16-bits, entorno Windows de, 740 2PC protocolo. Véase Protocolo de confirmación en dos fases 32-bits, entorno Windows de, 740-741

A Absoluto, nombre de ruta, 349 Acceso: anónimo, 357 control de acceso en Linux, 708-709 f controlado, 361 derechos de, 486, 496-497 directo (archivos), 342-343 directo a memoria (DMA), 10, 457-458 latencia de, 439 secuencial (archivos), 342 Acceso a memoria, tiempo efectivo de, 261 Acceso aleatorio, 653 tiempo de (discos), 408 Acceso efectivo, tiempo de,. 287 Acceso remoto a archivos (sistemas de archivos distribui­ dos), 590-594 coherencia, 593-594 esquema básico de caché, 590-591 mecanismo de caché y servicio remoto, 594 política de actualización de la caché, 592-593 ubicación de la caché, 591-592 a archivos, 337, 361-363 Aceleración de los cálculos, 558 Acíclico, grafo, 351 ACL (access-control list), 362 Acorazado, virus, 520 Activaciones del planificador, 127-128 Active Directory (Windows XP), 755 Administración de archivos, 49 llamadas al sistema, 46-48 Administración de dispositivos, llamadas al sistema, 48 Admisión, control de, 657, 664 AES (advanced encryption standard), 528 Afinidad del procesador, 152 >

Afinidad dura, 152 Afinidad suave, 152 Agrupación en cluster, 579 asimétrico, 13 en Windows XP, 323 Agrupamiento, 387 Agujeros, 253 Ajuste automático del conjunto de trabajo (Windows XP), 323 Algoritmo de control de admisión, 642 de firma digital, 531 de imposición, 623-624 de los bits de referencia adicionales, 299 de planificación: de colas multinivel realimentadas, 150-151 mediante colas multinivel, 148-150 por prioridad monótona en tasa, 642-644 por prioridades, 145-146 por turnos, 146-148 de política (Linux), 693 de seguridad, 230 de solicitud de recursos, 230-231 de sustitución local (algoritmo se sustitución basado en prioridades), 306 del anillo, 624-625 del banquero, 229-232 del reloj, 299 Almacén de respaldo, 249 Almacenamiento. Véase también Almacenamiento masivo, estructura de de utilidad, 431 densidad de, 446 estable, 198 holográfico, 435 no volátil, 9,198 secundario, 8, 369. Véase también Discos terciario, 21 volátil, 9-10,198 Almacenamiento en caché, 22-23, 467 del lado del cliente, 754 doble, 390 805

806

índice

Almacenamiento en caché (Cont.) escritura diferirá, 592 y servicios remotos, 594 Almacenamiento masivo, estructura de, 407-409 algoritmos de planificación de disco, 412-417 C-SCAN, 416 FCFS, 413 LOOK, 416 SCAN, 415 selección, 416-417 SSTF, 413-415 almacenamiento terciario, 433-442 cintas magnéticas, 434-435 discos extraíbles, 433-434 rendimiento, 438-442 soporte del sistema operativo, 435-438 tecnologías futuras, 435 cintas magnéticas, 409 conexión de un disco: conectado a la red, 411-412 conectado al host, 410-411 redes de área de almacenamiento, 412 de reserva en caliente, 430 discos magnéticos, 407-409 estructura de disco, 409 extensiones, 431 gestión de disco: bloque de arranque, 419-420 bloques defectuosos, 420-21 formateo de discos, 418-419 , gestión del espacio de intercambio, 421-423 implementación de un almacenamiento estable, 432-433 RAID, estructuras, 423-432 mejora de la fiabilidad, 424-425 mejoras en las prestaciones, 425-426 problemas, 432 RAID, niveles, 426-431 Alta disponibilidad, 13 Ambito de contienda del proceso, 154 Ambito de contienda del sistema, 154 Amenazas relacionadas con los programas, 513-520 bomba lógica, 514-515 .. caballo de Troya, 513-514 desbordamiento de pila y de búfer, 515-518 puerta trasera, 514 virus, 518-520 Amplificación de derechos (Hydra), 498 Análisis de desperdicios, 512 Análisis de redes de colas, 163 Ancho de banda: disco, 412 efectivo, 438 sostenido, 438 Anclar, 735 Andrew, sistema de archivos (AFS), 598-602 espacio de nombres compartido, 599-600 implementación, 601-602 operaciones con archivos, 600-601 Anónima, memoria, 423 Anónimo, acceso, 357 APC (asynchronous procedure calis), 125, 720 APC. Vénse Llarhadas asincronas a procedimientos

API Win32, 312-313, 713-714, 741 API. Véase Interfaz de programación de aplicaciones Apple Computers, 38 AppleTalk, protocolo, 751 Aprobación, 549 Apropiación de recursos,' recupéración de interbloqueos mediante, 235 Apropiativa, planificación, 139-140 Árbol B+ (NTFS), 743-744 Árboles de dominio, 755 Archivado en cinta, 435 Archivo mapeado en memoria, 727 Archivo, objeto, 376, 696 Archivo, virus de, 519 Archivos, 20, 333-334. Véase también Directorios atributos de, 334-335 bloqueo de, 337-339 codificados, 654 compartidos inmutables, 360 de paginación (Windows XP), 726 de procesamiento por lotes, 339 definición, 333 ejecutables, 74 estructura de almacenamiento para, 345 estructura interna de, 340-341 extensiones de, 339-340 métodos de acceso, 342-345 acceso directo, 342-343 acceso secuencial, 342 operaciones con, 335-339 protección, 361-365 mediante acceso a archivos, 361-363 medíante contraseñas/permisos, 363-364 recuperación de, 392-393 Área de registro, 745 Área de reinicio, 745 Arista de asignación, 220 Arista de declaración, 228 Arista de solicitud, 220 ARP (address resolution protocol), 580 Arquitectura, 11-14 basada en bus, 10 basada en conmutador, 10 de Windows XP, 717-718 sistemas de un solo procesador, 11-13 sistemas en cluster, 13-14 sistemas multiprocesador, 11-13 Arranque, 64, 738-739 bloque de control de, 371 del sistema, 64 dual, sistemas de, 374 partición de, 419 sector de, 419 virus de, 519 ASID. Véase Identificadores del espacio de direcciones Asignación: de almacenamiento dinámico, problema de, 253, 379 de espacio de disco, 378-386 asignación contigua, 378-380 asignación enlazada, 380-3S2 asignación indexada, 383-384 y prestaciones, 384-386

índice

de franjas, 316-317 de la memoria del kemel, 314-317 de memoria contigua, 252 de recursos (servicios del sistema operativo), 36-37 descomposición binaria, 315-316 - , equitativa, 303 proporcibnal, 303 Asignación de marcos, 302-305 algoritmo de, 293 asignación equitativa, 303 asignación proporcional, 303-304 global y local, 304-305 Asignador de páginas (Linux), 689 Asignador de potencias de 2,315 Asignador de recursos, sistema operativo como, 5 Asimétrico, cifrado, 528 Asincrono, dispositivo, 460 Asistente personal digital (PDA, personal digital assistants), 10, 27 ATA (advanced technology attachment), buses, 409 Ataque de denegación de servicio, 510 de día cero, 542 de reproducción, 510 por interposición, 510 Atlas, sistema operativo, 771 Atomicidad, 610-612 Atributos no residentes, 743 Atributos residentes, 743 Autenticación: de dos factores, 539 en Linux, 707-708 ? en Windows, 742 ruptura, 510 y cifrado, 530-531 Autenticación de usuario, 535-539 biométrica, 539 contraseñas, 536-539 Autocomprobaciones, 680 Automapa de tabla de páginas, 726 Automática, variable, 515 Automontaje, funcionalidad, 589 Autoridades de certificación, 533

B Bandas de disco, 746 Base de datos de marcos de página, 730 Base de datos de ubicación de volumen (NFS V4), 600 Base del segmento, 270 Base informática de confianza (TCB), 548 Base, registro, 244, 245 Básico, sistema de archivos, 370 Bayes, teorema de, 543 Belady, anomalía de, 295 Biblioteca C, 44 Bibliotecas compartidas, 248-249, 282 Bibliotecas de hebras, 117-123 acerca de, 117-118 hebras de W in32,118-121 hebras java, 121-123 Pthreads, 118

807

Bibliotecas de montaje dinámico (DLL), 248-249, 716 Bibliotecas del sistema (Linux), 676, 677 Binario, semáforo, 179 Biométrica, 539 Bit: de modificación (sucio), 292 de modo, 17 de referencia, 299 válido-inválido, 262 Bloque de control de dirección virtual (VACB), 735 Bloque de mensajes de servidor (SMB), 750 Bloque(s), 41, 253, 341-342 de arranque, 64, 371, 419 de control de archivo (FCB), 371 de control de arranque, 371 de control de proceso o bloque de control de tarea (PCB, process control block), 75-76 de control de volumen, 371 de índice, esquema indexado, 383-384 defectuosos, 420-421 definición, 703 directo, 384 dispositivos de, 459-460 doblemente indirecto, 384 índice a, 343 indirecto de un nivel, 384 lógicos, 409 número relativo de, 343 triplemente indirecto, 384 Bloqueante, E/S, 463-464 Bloqueo-clave, esquema de, 494 Bloqueo(s), 175, 494 compartido, 337 de archivos obligatorio, mecanismos de, 337-338 de archivos sugerido, mecanismos de, 337-338 en la API Java, 337-338 exclusivo, 338 indefinido (muerte por inanición), 146,181-182 lector-escritor, 185 mútex, 179, 219-220 obligatorio, 337 sugeridos, 337 Borrado de archivos, 335 Bosques, 755 Bucle arbitrado, (FC-AL), 41 Búfer, 703 almacenamiento en, 91-92, 465-467, 664 caché de, 389 circular, 394 de páginas, algoritmo de, 301 de traducción directa (TLB), 260, 728 definición, 465 Bus, 408-409’ ATA, 409 de expansión, 450 _ definición, 450 PCI, 450 USB, 409 Búsqueda en archivos, 335 Búsqueda, tiempo de (discos), 408, 412 Buzones de correo, 752 Buzones de correo, 90

808

índice

virus, 520 W indows X P, 748

C Caballo de Troya, 513-514 Cabecera de stream , 473 Caché: como búfer de memoria, 244 de búfer, 389 de búfer unificada, 390, 391 de páginas, 389, 390, 691 definición, 467 en Linux, 690 en Windows XP, 734-736 franjas en, 316 RAM no volátil, 425 y acceso a archivos remotos: política de actualización, 592-593 ubicación de la caché, 591-592 y coherencia, 593-594 y prestaciones, 389 cachéis, sistema de archivos, 592 Cadena de referencia, 293 Cajón de arena (Tripwire, sistema de archivos), 545 Cálculos, migración de, 561-562 Cambio de contexto, 80-81, 475-476 Cambio de fase, discos de, 434 Canales encubiertos, 514 Cancelación asincrona de hebras, 124 Cancelación de hebras, 124 Cancelación diferida de hebras, 124 CAP de Cambridge, sistema, 499-500 Capacidad cero (de colas), 92 Capacidad de datos, 499 Capacidad ilimitada (de colas), 92 Capacidad limitada (de colas), 92 Capacidad software, 499 Caracteres, dispositivos de (Linux), 703-704 Carga: dinámica, 248 en Linux, 694-695 tiempo de, 247 y ejecución de p rogram as, 50

^

Cargador, 768 Cargador de clases, 60 Carpetas, 38 Casi en línea, almacenamiento, almacenamiento, 435 CAV (constant angular velocity), 410 CD (collision detection, detección de colisiones), 572 Cerrojos. Véase Bloqueos Certficacion, 549 Certificado digital, 533 Ciclos: de ráfagas de CPU y de E /S , 13 8 -1 3 9 en CineBlitz, 663 robo de, 458 Cifrada, contraseña, 537-5 3 8 Cifrado, 526-533 asim étrico, 528-530 autenticación, 530-531 de bloque, 528 de flujo, 528 distribución de claves, 531-533' sim étrico, 527-528

J-

CIFS (common Internet file system), 358 CineBlitz, 663-665 Cintas de traza, 164 Cintas magnéticas, 409, 434-435 Circuitos, c onmutación de, 571 Circular, búfer, 394 Clases (Java), 503 Clave de tipo, 468 Claves, 494, 497, 526 distribución de, 531-533 flujo de, 528 privada, 529 pública, 529 CLI (command-line interface), 35 Cliente(s): de tiempo real, 663 definición, 585 en SSL, 534-535 interfaz de, 586 no de tiempo real, 663 sin disco, 588 Cliente-servidor, modelo, 357-358 C-LOOK, algoritmo de planificación, 416 closeO, operación, 336 Cluster, 418, 579, 743 asimétrico, 13 reasignación de, 748 servidor de, 598 sistemas en, 13-14 tabla de páginas en, 267 CLV (constant linear velocity), 410 Código absoluto, 246 de autenticación de mensajes (M AC), 531 de corrección de errores (ECC), 418, 426 de tipo adicional, 468 fuente, virus de, 520 independiente de la posición (PIC), 696 intermedio (bytecode), 60 puro, 263 reentrante, 263 Coherencia, 594-595 de caché, 23, 593-594 semántica de, 359-360 Cola(s), 78-79 capacidad de, 92 de bloqueos (tunrstilé), 194 de dispositivo, 467 de ejecución, 160, 684 de entrada, 245 de escritura, 703 de espera, 704 de lectura, 703 de mensajes, 773 de procesos preparados, 78, 79, 250 de trabajos, 15, 78 del dispositivo, 78 ordenada, 703 C olisiones (de n om b res de archivo), 378 C olm ena del sistem a, 738

índice

COM, modelo, 753 Compactación, 255, 380 Compartible, dispositivo, 460 Compartición: carga, 151, 558 del procesador, 147 recursos, 558 tiempo, 15 y paginación, 263-264 Compartición de archivos, 355-360 con múltiples usuarios, 356 en redes, 356-359 modelo cliente-servidor, 357-358 modos de fallo, 358-359 sistemas de información distribuidos, 358 semántica de coherencia, 359-360 Compartido, bloqueo (cerrojo), 337 Compartir la carga, 151, 558 Compilación, tiempo de, 246 Compilador C de GNU (gcc), 674 Compilador just-in-time, 62 Compilador, imposición de reglas basadas en, 500-503 Complejidad administrativa, 589 Componentes del sistema Linux, 672, 676-678 Compresión: con pérdidas, 654 en sistemas multimedia, 654-655 en Windows XP, 748 sin pérdidas, 654 tasa de, 654 unidades de, 748 Comprobación de coherencia, 392 Computadoras de mano, 4 Computadoras de red, 29 Computadoras personales (PC), 3 Comunicación interprocesos (IPC, interprocess communication), 86-92 en Linux, 672, 704-705 en los sistemas cliente-servidor, 96-103 invocación de métodos remotos, 102-103 llamadas a procedimientos remotos^99-102 sockets, 97-99 Mach, ejemplo, 93-95 memoria compartida en POSIX, ejemplo, 92-93 sistemas de memoria compartida, 87-89 sistemas de paso de mensajes, 89-92 Windows XP, ejemplo, 95-96 Comunicaciones: directas, 89 en sistemas operativos distribuidos, 559 indirectas, 90 interproceso. Véase Comunicación interprocesos llamadas al sistema, 48-49 no fiables, 625-626 programas del sistema, 50 servicios del sistema operativo, 36 Concentrador de terminales, 475 Condición de carrera, 173 Condiciones de error, 280 Conectado a la red, almacenamiento, 411-412 Conectado al host, almacenamiento, 410

J-

Conexión en cascada, 450 Confidencialidad, ruptura de la, 510 Confinamiento, problema del, 492 Conformación, 752 Conjunto: de buzones de correo, 95 de distribución en bandas, 746-747 de entrada, 193 de trabajo, 307,310 de volúmenes, 745 dúplex, 748 espejo, 747 Conjuntos compartidos: de hebras, 125-126 de páginas libres, 290 Conmutación: de circuitos, 571 de dominio, 486 de mensajes, 571 de paquetes, 571 Contador de programa, 19, 74 Contador, semáforo, 179 Contexto (del proceso), 80 Contexto de seguridad (Windows XP), 549-550 Contienda, 572 Contraseñas, 535-539 cifradas, 537-538 de un solo uso, 538-539 emparejadas, 538 vulnerabilidades de, 536-537 Control de acceso basado en roles (RBAC), 495 Control de concurrencia, 612-616 algoritmos de, 201 con marcas temporales, 615-616 con protocolos de bloqueo, 613-615 Control de flujo, 473 Control de procesos, llamadas al sistema, 42-46 Control, registro de, 452 Controlador de dipositivo, 10, 370, 471, 768 Controlador de puerto, 734 Controladora(s), 409, 450-451 de acceso directo a memoria, 457 de disco, 409 de dispositivos, 6, 471. Véase también Sistemas de E/S definición, 450 hardware de interrupciones, 454 host, 409 Controladores de filtrado, 734 Convenio uniforme de nombrado (UNC), 752 Convoy, efecto, 143 Cooperativa, planificación , 139 Coordinación distribuida: algoritmos de elección, 623-625 atomicidad, 610-612 control de concurrencia, 612-616 exclusión mutua, 607-610 interbloqueos, 616-623 detección, 618-623 prevención/evasión, 617-618 ordenación de sucesos, 605-607 procedimientos de acuerdo, 625-626

809

810

índice

Coordinador de la transacción, 610 Copia de seguridad, 392 completa, 393 incremental, 393 Copia durante la escritura, técnica de, 289-290 Cortafuegos, 29, 546-547 cadenas de, 707 de llamadas al sistema, 547 gestión de, 707 personal, 547 CPU (central processing unit), 4, 243-245 CPU y ~E¡S, ciclo de ráfaga de, 138-139 CPU, ráfaga de, 138 Crackers, 510 Creación: de archivos, 335 de procesos, 81-85 Criptografía, 525-535 cifrado, 526-533 implementación, 533-534 SSL, ejemplo, 534-535 CSC (client-side caching, caché del lado del cliente), 754 C-SCAN, algoritmo de planificación, 416 CSMA (carrier sense with múltiple access), 572 CTSS, sistema operativo, 773-774 Cuaderno de un solo uso, 539 Cualificador adicional del código de tipo, 468 Cuanto de tiempo, 146, 719 Cúmulos de memoria, 74, 762 Cuota equitativa (Solaris), 157 Cuota proporcional, planificación con, 644-645 f Cuotas, 158 D d (desplazamiento de página), 255 Datagramas, 571 Datos: archivos de, 334 de flujo continuo, 652 distribución en bandas de, 425 específicos de una hebra, 126-127 *■ multimedia, 27 recuperación de, 392-393 DCOM, 753 Dedicado, dispositivo, 460 Defectuosos, bloques, 420-421 Degradación suave, 12 Delegación (NPS V4), 596 Demonio, proceso, 487 Denegación de servicio, ataque de, 510 Densidad de almacenamiento, 446 Depuradores, 43 Derechos: auxiliares (Hydra), 498 de grupo (Linux), 708 de propietario (Linux), 708 de usuario (Linux), 708 del resto del mundo (Linux), 708 DES (data-encryption standard), 528 Desafío (contraseñas), 538 Desbordamiento de búfer, ataque, 515-518 Desbordamiento de pila, ataque, 515-518

Descarga progresiva, 652 Descomposición binaria, sistema de, 315-316 Descriptor(es), 722, 725 de archivo, 373 de direcciones virtuales (VAD), 731 de instancia, 758-759 de seguridad (Windows XP), 549 Deslizamiento de sectores, 421 Despachador, 140 Desplazamiento de página (d), 255 Detección: basada en signatura, 542 de anomalías, 542 de colisiones (CD), 572 de errores, 36 de interbloqueos completamente distribuido, algoritmo, 621-623 de interbloqueos, coordinador de, 619 de intrusiones, 541-545 de portadora con acceso múltiple (CSMA), 572 tiempo de, 380 y eliminación de huérfanos, 595 Detenerse, 244 DFS (distributed file system, sistema de archivos distribui­ do), 357, 585-604 acceso remoto a archivos, 590-595 coherencia, 593-594 esquema básico de caché, 590-591 mecanismo de caché y servicio remoto, 594-595 política de actualización de la caché, 592-593 ubicación de la caché, 591-592 AFS, ejemplo de, 598-602 espacio de nombres compartido, 599-600 implementación, 601-602 operaciones con archivos, 600-601 definición, 585 nombrado, 586-588 replicación de archivos, 597 servicios con y sin memoria del estado, 594-597 sin memoria, 359 Windows XP, 754 Día cero, ataques de, 542 Diagrama de colas, 78 Diario, 700 Diario de cambios (Windows XP), 749 Difusión, 580, 661 Dinámica, carga, 248 Dinámica, protección, 486 Dirección(es): de bucle, 98 de control de acceso al medio (MAC), 580 definición, 454 física, 247 Internet, 568 lineal, 272 lógica, 247 virtual, 247 Direccionamiento real, modo de, 637 Directo, bloque, 384 Directorios: actual, 349 de archivos de usuario (UFD), 347

índice

de dispositivo, 345. Véase también Directorios de páginas, 727 maestro de archivos (MFD), 347 objeto (Windows XP), 724 Directorios, 345-354 con estructura de árbol, 348-350 de dos niveles, 347-348 de un único nivel, 346-347 en forma de grafo general, 353-354 en un grafo acíclico, 350-352 estructura de almacenamiento, 345 implementación de, 377-378 recuperación de, 392-393 Disciplina de línea, 703 Disco(s), 407-409. Véase también Almacenamiento masivo, estructura de algoritmos de planificación de disco, 412-417 C-SCAN, 416 FCFS, 413 LOOK, 416 SCAN, 415 selección, 416-417 SSTF, 413-415 asignación de espacio de, 378-386 asignación contigua, 378-380 asignación enlazada, 380-382 asignación indexada, 383-384 y prestaciones, 384-386 bloque de arranque, 419 bloques defectuosos, 420-421 brazo del, 408 conectado a la red, 411-412 conectado al host, 410 controladora de, 409 de arranque, 64, 419 de cambio de fase, 434 de estado sólido, 22 de lectura-escritura, 434 de sólo lectura, 434 del sistema, 419 disquete, 408-409 eficiencia y prestaciones, 388-392 electrónico, 9 estructura, 409 extraíbles, 433-434 formateo a bajo nivel, 409 formateo, 418-419 gestión del espacio libre, 386-388 magnético, 8 magneto-ópticos, 434 redes de área de almacenamiento, 412 sin formato, 302 uso eficiente de, 388 WORM, 434 Diseño de sistemas operativos: Linux, 675-678 mecanismos y políticas, 51 objetivos, 50-51 sistemas operativos distribuidos, 577-579 Windows XP, 714-717 Dispersión, 267, 282

J-

811

Dispositivos de acceso aleatorio, 460, 770 de acceso secuencial, 770 de almacenamiento terciario, 21 de sólo escritura, 460 del sistema, 738 Disquetes, 408-409 Distribución en bandas de nivel bit, 425 Distribución en bandas de nivel de bloque, 425 Distribución fuera de banda, 532 Distribuciones Linux, 672, 674-675 DLL. Véase Biblioteca de montaje dinámico DLM (distributed lock manager), 14 DMA (direct-memory-access) controladora, 457 DMA. Véase Acceso directo a memoria DMZ (demilitarized zone), 546 DNS (domain-name system), 358, 568 Doble búfer, 466, 664 Doble caché, 390 Doblemente indirecto, bloque, 384 Dominio de aplicación, 62 Dominio de protección, 486 Dominio público, 675 Dominio, conmutación, 486 Dominios, 358, 754-756 de seguridad, 546 DOS (denial-of-service, denegación de servicio), ataques de, 510 Dos niveles, directorios en, 347-348 DPC (deferred procedure calis), 720 DRAM (dynamic random-access memory), 7-8 Duplicación en espejo, 424 Duplicación inteligente en espejo, 755 DVMA (direct virtual memory access), 458 E iyS (entrada/salida), 3, 9-11 canal de, 475, 476 directa, 461 gestor de, 733-736 interbloqueo de, 321-323 mapeada en memoria, 313 programada, 314 puertos de, 314 ráfaga de, 138 rápida, mecanismo de, 735 sin formato, 461 solapada, 769-771 E/S, sistema(s) de, 449-480 hardware, 450-458 acceso directo a memoria, 457-458 interrupciones, 453-456 sondeo, 452-453 interfaz de las aplicaciones, 458-464 dispositivos de bloques y de caracteres, 461-462 dispositivos de red, 462 E/S bloqueante y no bloqueante, 463-464 relojes y temporizadores, 462-463 kernel 464-470 almacenamiento en búfer, 465-467 almacenamiento en caché, 467

812

índice

E/S, sistema(s) de, (Cont.) estructuras de datos del, 469-470 gestión de colas y reserva de dispositivos, 467-468 planificación de E/S, 464-465 protección, 468-469 tratamiento de errores, 468 y subsistemas de E/S, 470 Linux, 702-704 dispositivos de bloque, 703 dispositivos de caracteres, 703-704 rendimiento, 475-478 STREAMS, mecanismos de, 473-475 transformación de solicitudes del kemel en operaciones hardware, 471-473 ECC (error-correcting code, código de corrección de erro­ res), 418, 426 EDF (earliest-deadline-first), planificación, 644, 658-659 Efectivo, ancho de banda, 438 Eficiencia, 3, 388-389 EIDE (enhanced integrated drive electronics) buses, 408 Ejecución, de instrucciones, ciclo de, 243-245 de programas (servicios del sistema operativo), 36 de programas de usuario, 694 tiempo de, 247 Ejecutables, archivos, 74, 334 Elección, 572 Elección, algoritmos de, 623-625 Empaquetar, 341 En ejecución, estado, 75 En ejecución, estado de hebra (Windows XP), 719 En espera, estado, 75 En línea, compactación de espacio, 380 Encaminamiento: de bloques cifrados, 528 de interrupciones, 454 dinámico, 569-570 en redes parcialmente conectadas, 566 fijo, 569-570 tabla de, 569 virtual, 569-570 y comunicación de redes, 569-570 Encapsulación (Java), 505 Enlaces: de comunicaciones, 89 definición, 351 duros o no simbólicos, 352 resolución, 351 simbólico, 724 Enmascarable, interrupción, 454 Entornos informáticos, 28-31 cliente-servidor, 29-30 sistema basado en la Web, 30-31 sistema entre iguales, 30 tradicional, 28-29 Entrada de datos, registro de, 452 Entrada de directorio (objeto), 376, 696 Entrada de directorio de páginas (PDE), 727 Entrada de pila, 516-517 Envejecimiento, 146, 580 EPROM (erasable programmable read only memorv), 64 Equilibrado de carga, 152-153

Equitativa, asignación, 303 Error(es): blandos, 418 duros, 421 tratamiento de, 468 Escalabilidad, 578 Escalar privilegios, 25 Escaneo de puertos, 524 Escape (sistemas operativos), 460 Escritores, 183-185 Escritorio, 38 Escritura anticipada, 391 asincrona, 391 de archivos, 335 diferida, caché de, 592 diferida, política de, 592 síncrona, 391 Espacio de direcciones: lógico y físico, 247-248 virtuales, 280, 692-693 Espacio de disco asignación contigua, 378-380 asignación enlazada, 380-382 asignación indexada, 383-384 sin formato, 345 Espacio de intercambio, 286 Espacio de nombres compartido, 599-600 Espacio de nombres local, 598 Espacio de sesión, 726 Especificación de interfaz de dispositivo de red (NDIS), 750 Espejo de disco, 747 Espera activa, 180, 453 Espera circular, condición de (interbloqueos), 225-226 Espera condicional, estructura, 191 Espera, estado de hebra (Windows XP), 719 Espera-muere, esquema, 617 Esqueleto, 102 Esquema combinado, bloque de índice, 384 Esquema de redundancia P + Q, 428 Esquema de temporización, 576, 625-626 Estable, almacenamiento, 198, 432-442 Estaciones de trabajo, 4 Estado de la arquitectura, 153 del proceso, 74-75 información de, 359 no señalizado, 195 registro de, 452 señalizado, 195 suspendido, 759 Estándar avanzado de cifrado (AES), 528 Estática, protección, 486 Estricto, sistema de tiempo real, 634, 658 Estructura de árbol, directorios con, 348-350 en anillo, 609 en niveles (estructura del sistema operativo), 53-55 simple del sistema operativo, 53 Etiqueta, 494 Evaluación analítica, 162 Evaluación de riesgos, 540-541

índice

Evaluación de vulnerabilidades, 540-541 Excepción, 16 Excepciones (con interrupciones), 455 Exclusión mutua, 220, 607-610 condición de (interbloqueos), 224 enfoque centralizado, 607 enfoque completamente distribuido, 608-609 técnicas basadas en paso de testigo, 609-610 Exclusivo, bloqueo (cerrojo), 337 exec(), llamada al sistema, 123 Expansión, bus de, 450 Exportación, lista de, 397 Extensión (espacio contiguo), 380 Extensiones, 743 Extensiones del kem el, 57 Extremo de controlador (STREAM), 473

F Facilidad de trazado dinámico de Solaris 10, 47 Facilidad de uso, 4, 714 Fallos: detección de, 575-576 durante la escritura de bloques, 432-433 gestión de (protocolo 2PC), 611-612 recuperación de, 577 tiempo medio entre, 424 Falsos negativos, 543 Falsos positivos, 543 Fase de conflicto (de la latencia de despacho), 640 FAT (file-allocation table), 382 FC (fiber channel) buses, 409 FC (fiber channel), 411 FC-AL (arbitrated loop), 411 FCB (file-control block), 371 FCFS, algoritmo de planificación, 142-143, 413 Fiabilidad: de sistemas operativos distribuidos, 558-559 de Windows XP, 715 en sistemas multimedia, 656 paquetes, 571 Fibras, 760 fid (NFS V4), 599 File descriptor (descriptor de archivo), 373 File hartdle (descriptor de archivo), 373 File System Hierarchy Standard, documento, 674 FileLock (Java), 337 FireWire, 410 Firma digital, 531 Firmware, 6, 64 Física, dirección, 247 Físico, espacio de direcciones, 247-248 Fluctuación, 656 - Flujo a la carta, 653 de caracteres, dispositivo de, 459-460, 703-704 de clave, 528 en tiempo real, 652, 661-663 en vivo (Uve streaming), 653 fork para memoria virtual, 290 forkQ, llamadas al sistema, 123 fork() y exec(), modelo de procesos (Linux), 681-683 Formateo, 418-419

813

de discos a bajo nivel, 409, 418-419 físico, 418 lógico, 418 Fragmentación, 254-255 externa, 254-255, 379 interna, 255, 342 Fragmentos de paquetes, 707 Franjas, 345 asignación de, 316-317, 690 Frecuencia de fallos de página (PFF), 309 FTP (file transfer protocol), 560-561 ftp, 357 Fuente, archivo, 334 Fuera de línea, compactación de espacio, 380 Funciones seguras respecto a las señales, 110

G Gantt, diagrama de, 142 GB (gigabyte), 5 gcc (compilador C de GNU), 674 GDT (global descriptor table), 272 Generación del sistema (SYSGEN, system generation), 63-64 Generales bizantinos, problema de los, 625 Gestión de almacenamiento, 20-24 en caché, 22-23 jerárquico (HSM), 437-438 masivo, 21 sistemas de E/S, 23-24 Gestión de colas, 467-468 Gestión de la caché, 22 Gestión de memoria, 19-20 en Linux, 688-696 ejecución y carga de programas de usuario, 694-696 memoria física, 688-691 memoria virtual, 691-694 en Windows XP, 761-763 almacenamiento local en una hebra, 762 cúmulos de memoria, 762 mapeo de archivos de memoria, 761 memoria virtual, 761 Gestión de procesos, 19 en Linux, 681-684 forkQ y execQ, modelo de procesos, 681-682 procesos y hebras, 683-684 Gestión de red en sistemas multimedia, 660-663 Gestión de volúmenes (Windows XP), 745-748 Gestión del ciclo de vida de la información (ILM), 438 Gestión del espacio libre en discos, 386-388 agrupamiento, 387 lista enlazada, 387 recuento, 388 vector de bits, 386-387 Gestión del sistema de archivos, 20-21 Gestor de bloqueos distribuido (DLM, distributed lock manager), 14 de memoria virtual (VM), 726-731 de procesos (Windows XP), 731-732 de recurso, 657 de solicitudes, 703 plug-and-play (PnP), 737-738

814

índice

Gigabyte (GB), 5 Global, sustitución, 304 GNU Portable Threads, 116 Grado de multiprogramación, 80 Grafo acíclico, 351 directorios en un, 350-352 Grafo de asignación de recursos del sistema, 220-223 Grafo de asignación de recursos, algoritmo, 228-229 Grafo general, directorio en forma de, 353-354 Green, hebras, 116 Grupos de bloques, 698 Grupos de cilindros, 698 Gusanos, 521-524

H Ha sucedido antes, relación, 605-606 HAL (hardware-abstraction layer), 717 Hardware, 4 de sistemas de E/S, 450-458 acceso directo a memoria, 457-458 interrupciones, 453-456 sondeo, 452-453 objetos, 485 para almacenar tablas de páginas, 259-261 sincronización, 175-178 H ash: funciones, 530 tablas, 377-378 tabla' de páginas, 266 valor (resumen de mensaje), 530 Hebras. Véase también Multihebra ? cancelación, 124 componentes de, 113 conjuntos compartidos, 125-126 de usuario, 115 en Linux, 128-130, 682-683 en Windows XP, 128,129, 718-719, 757, 759-760 funciones, 113-115 inactiva, 158 Java, 121-123 kernel, 115 ^ objetivo, 124 planificación de, 154-155 principal, 757 y el modelo de proceso, 76-77 Herido-espera, esquema, 617 H ijos, 81 Hiperespacio, 726 Holográfico, almacenamiento, 435 Homogeneidad, 151 H ost, adaptadora, 450 Host, controladora, 409 HSM (hierarchical storage management), 437 Huella, 635 Husmear, 536 Hydra, 498-499

I IBM QS/360, 774-776 Identidad de cliente suplantada, 357 Identidad del proceso (Linux), 681-6S2

I dentificadores: de archivo, 334

de archivos independientes de la ubicación, 589 de grupo, 25 de usuario (ID), 24 efectivo, 25 para archivos, 335 del espacio de direcciones (ASID), 260-261 de proceso (pid), 81 IDP (intrusion-prevention system,sistema de prevención de intrusiones), 542 IDS (intrusion-detection system,sistema de detección de intrusiones), 542 IKE, protocolo, 533 ILM (information life-cycle management), 438 Implementación: de algoritmos de planificación de la CPU, 165 de máquinas virtuales, 59 de sistema operativos de tiempo real, 637-641 kernels apropiativos, 638-639 minimización de la latencia, 639-641 planificación basada en prioridades, 638 de sistemas operativos, 52 de técnicas de nombrado transparente, 589-590 Independencia de ubicación, 587 Independientes, discos, 425 índice, 343 bloque de, 383 multinivel, 384 Indirecto, bloque, 384 Información de estado, 49 Informática segura, 545 Ingeniería social, 512 Inicio de sesión de red, 358 remoto, 559 unificado seguro, 358 Inodo, objeto, 376, 696 InServ, matriz de almacenamiento, 431 Inspección de pila, 504 Instrucciones privilegiadas, 17 Integridad, ruptura de, 510 Intel Pentium, procesador, 271-275 Intellimirror, 755 Interbloqueos, 181-182, 616-622 con cerrojos mútex, 219-220 condiciones necesarias para, 219-220 de E/S, 321-323 definición, 217 detección de, 232-235, 618-622 una sola instancia de cada tipo de recurso, 232-233 utilización del algoritmo de, 234 varías instancias de cada tipo de recurso, 233-234 evasión de, 223, 226-232 con el algoritmo de estado seguro, 227-228 con el algoritmo del banquero, 229-232 con el grafo de asignación de recursos, 228-229 grafos de asignación de recursos del sistema, 220-223 métodos para tratar los, 223-224 modelo de sistema, 217-218 prevención de, 223-226 condición de espera circular, 225-226

índice

condición de exclusión mutua, 224 condición de retención y espera, 224-225 no apropiativo (sin desalojo), 225 prevención y evasión de, 617-618 recuperación de, 235-236 mediante apropiación de recursos, 235 mediante terminación de procesos, 235 Intercambiador (jukebox) robotizado, 437 Intercambiador perezoso, 283 Intercambio, 16, 80, 249-252, 283 en Linux, 693 espacio de, 286 gestión del espacio de, 421-423 paginación e, 421 Interfaz: cliente, 585 de controlador de transporte (TDI), 750 de línea de comandos (CLI), 35 de llamadas al sistema, 40 de proceso por lotes, 35-36 de programación de aplicaciones (API, application program interface), 39-40 de red de Windows XP, 750 de usuario (UI), 36-37 definición, 459 gráfica de usuario (GUI), 37-39 intermáquinas, 586 Interfaz de las aplicaciones (sistemas de E/S), 458-464 dispositivos de bloques y de caracteres, 461-462 dispositivos de red, 462 E/S bloqueante y no bloqueante, 463-464 relojes y temporizadores, 462-463 Intermáquinas, interfaz, 586 Interna, fragmentación, 255, 342 Internet, dirección, 568 Internet, protocolo (IP), 533-534 Interposición, ataque de, 510 Intérprete de comandos, 37-38 Intérprete de tarjetas de control, 768 Interrupción(es), 6, 453-456 de fallo de página, 284 definición, 453 yen Linux, 687-688 ¡ encadenamiento de, 454 niveles de prioridad de, 455 vector de, 454 Intrusos, 510 Inversión de prioridad, 195, 641 Invertida, tabla de páginas, 267-268, 320 Invocación de métodos remotos (RMI, remote method invocation), 102-103 IP (Internet Protocol), 533-534 IPC. Véase Comunicación interprocesos IPSec, 533 IRP (paquete de solicitud de E/S), 734 ISCSI, 411 ISO, modelo de referencia, 533 ISO , pila del protocolo, 574

J Java: bloqueo de archivos en, 337-338

J-

815

monitores en, 193 protección basada en el lenguaje, 503-505 JVM (Java Virtual Machine), 60-63

K KB (kilobyte), 5 Kerberos, 742 Kem el, 5, 464-470 almacenamiento en búfer, 465-467 almacenamiento en caché, 467 apropiativo, 174, 638-639 de desarrollo (Linux), 672 de producción (Linux), 672 de tiempo real, 636-637 estructuras de datos, 469-470 gestión de colas y reserva de dispositivos, 467-468 Linux, 676, 678 no apropiativos, 174 planificación de E/S, 464-465 protección, 468-469 sicronización de tareas (en Linux), 686-688 sistemas multimedia, 655-658 tratamiento de errores, 468 Windows XP, 717-722 y subsistemas de E/S, 470 K em el, módulos (Linux), 678-681 gestión de módulos, 679 registro de controladores, 679-680 resolución de conflictos, 680-681 Kerr, efecto, 434 Kilobyte (KB), 5

L LAN. Véase Red de área local Latencia de despacho, 140, 639-641 de interrupción, 639-640 del suceso, 639 en sistemas de tiempo real, 639-641 rotacional (discos), 408, 412 LCN (logical cluster numbers), 743 LDAP (lightweight directory-access protocol), 358, 755 LDT (local descriptor table), 272 Lectores, 183-185 Lectura de archivos, 335 Lectura-escritura, discos de, 434 Lectura-modificación-escritura, ciclo de, 428 Lenguaje de definición de interfaces de Microsoft, 753 LFU (least-frequently used), algoritmo de sustitución de páginas, 300 Liberación retardada, técnica, 391 Libres, objetos, 316, 690 Libros de código, 539 Licencias software, ¿08 Límite del segmento, 270 Límite, registro, 244, 245 Línea de solicitud de interrupción, 453 Lineal, dirección, 272 Linux, 671-712 adición de una llamada al sistema al kernel de Linux (pro­ yecto), 67-70 comunicación interprocesos, 704-705

816

índice

Linux (Cont.) ejemplo de planificación, 160-161 ejemplos de hebras, 129-130 en sistemas Pentium, 273-275 en tiempo real, 648 estructura de red, 705-707 gestión de memoria, 688-696 ejecución y carga de programas de usuario, 694-696 memoria física, 688-691 memoria virtual, 691-694 gestión de procesos, 681-684 modelo de procesos forkQ y exec(), 681-683 procesos y hebras, 683-684 gestión del espacio de intercambio, 424 historia, 671-675 descripción del sistema, 674 distribuciones, 674-675 licencias, 675 primer kemel, 672-674 modelo de seguridad, 707-709 autenticación, 707-708 control de acceso, 708-709 módulos del kemel, 678-681 planificación, 684-688 de procesos, 684-686 multiprocesamiento simétrico, 688 sincronización del kemel, 686-688 principios de diseño, 675-678 representación de un proceso en, 77 sincronización en, 196 sistema de E/S, 702-704 dispositivos de bloque, 703 f dispositivos de caracteres, 703-704 sistemas de archivos, 696-702 diario, 700 ext2fs, 698-700 proc, 700-702 virtual, 696-698 Lista de acceso (NFS V4), 599 de activos,' 624 _ _ de capacidades, 493-494 de control de acceso (ACL), 362 de espacio libre, 386 enlazada, 387 lineal (archivos), 377 Little, fórmula de, 163 Llamadas a procedimiento diferidas (DPC), 720 Llamadas a procedimiento remoto (RPC), 752 Llamadas a procedimientos locales (LPC), 716, 732-733 Llamadas al sistema (llamada del monitor), 6, 39-49 administración de archivos, 46-48 administración de dispositivos, 48 comunicaciones, 48-49 control de procesos, 42-46 funcionamiento, 39-40 mantenimiento de información, 48 y API, 39-40 Llamadas asincronas a procedimientos (APC), 125, 720 Local, sustitución, 304 Localidad de referencia, 285 lock(), operación, 337

Lógica, dirección, 247 Lógico, bloque, 409 Lógico, espacio de direcciones, 247-248 Lógico, registro, 342 Lógico, reloj, 606 Lógico, sistema de archivos, 370 LOOK, algoritmo de planificación, 416 LPC (local procedure cali), 716, 732-733 LRU (least-recently-used), algoritmo de sustitución de páginas, 296-298 LRU, algoritmo de sustitución de páginas mediante aproxi­ mación, 298-300

M MAC (médium access control), dirección, 580 MAC (message-authentication code), 531 Mach, sistema operativo, 55, 93-95, 776-777 Macintosh, sistema operativo, 341 Macro, virus de, 519 Maestra, clave, 497 Magnética, cinta, 409, 434-435 Magnético, disco, 8, 407-409. Véase también Discos Magneto-óptico, disco, 434 Mainframe, 4 MAN (metropolitan-area network), 25 Manipulación del sistema de archivos (servicios del siste­ ma operativo), 36 Mantenimiento de información, llamadas al sistema, 48 Mapa de intercambio, 423 Mapeo de archivos de memoria, 761 Mapeo de memoria, 252, 309-314 de archivos, 311 definición, 309 E/S, mapeada en memoria, 313 en la API Win32, 312-313 en Linux, 694-695 mecanismo básico, 309-311 Máquina DOS virtual (VDM), 739-740 Máquinas virtuales, 58-63 beneficios, 59-60 idea fundamental, 58 implementación, 59 máquina virtual Java, ejemplo, 60-63 VMware, ejemplo, 60 Marca temporal, 606, 615-616 Marcas temporales, esquema conservador de ordenación de, 616 Marco de páginas, 727 Marcos, 255 víctima, 292 Máscara de protección (Linux), 708 Mascarada, 510 Matchmaker, 101 Matrices, 280 Matriz de acceso, 489-493 definición, 489 implementación de, 493-495 revocación de derechos de acceso, 496-497 y control de acceso, 495-496 Matriz de almacenamiento, 424 Matriz de tareas activas (Linux), 684 Matriz de tareas caducadas (Linux), 684

índice

Máximo del conjunto de trabajo (Windows XP), 323 MB (megabyte), 5 M BR (master book record), 419 MCP, sistema operativo, 777 Mecanismos, 51 de equilibrado de carga, 31 de paginación (Linux), 693 de protección retroimplementados, 364 Medios de almacenamiento extraibles, 435-438 cintas magnéticas, 409,434-435 denominación de archivos, 437 discos magnéticos, 407-409 discos, 433-434 gestión del almacenamiento jerárquico, 437-438 interfaz de aplicación, 436-437 Megabyte (MB), 5 Mejor ajuste, estrategia de, 254 Memoria: acceso directo a memoria virtual, 458 acceso directo a memoria, 10 anónima, 423 asignación de, 253-254 compartida, 86, 282 de acceso aleatorio (RAM, random-access memory), 7 de núcleo, 771 de sólo lectura (ROM, read-only memory), 64,419 demandada con ceros, 692 dinámica de acceso aleatorio (DRAM), 7-8 física, 16, 279-280, 688-691 lógica, 16, 280. Véase también Memoria virtual principal. Véase Memoria principal secundaria, 286 semiconductora, 8 ' sobreasignación, 290 virtual. Véase Memoria virtual virtual unificada, 390 Memoria principal, a través de la red, 591 asignación contigua de, 252-255 mapeo, 252 métodos, 253-254 protección, 252 ^ y fragmentación, 254-255 e intercambio, 249-252 espacio de direcciones lógico y físico, 247-248 Intel Pentium, ejemplo: con Linux, 273-275 paginación, 273 segmentación, 272 paginación para gestión de, 255-259 hardware, 259-261 Intel Pentium, ejemplo, 273 método básico, 255-259 paginación jerárquica, 264-266 protección, 261-263 tablas de páginas hash, 266 tablas de páginas invertidas, 267-268 y páginas compartidas, 263-264 segmentación para gestión de, 269-271 hardware, 270-271 Intel Pentium, ejemplo, 271-275 método básico, 269-270 >

817

y carga dinámica, 248 y hardware, 244-245 y montaje dinámico, 248-249 y reasignación de direcciones, 245-247 Memoria virtual, 16, 279-282 acceso directo a memoria virtual (DVMA), 458 archivos mapeados en memoria, 309-314 E/S mapeada en memoria, 313 en la API Win32, 312-313 mecanismo básico, 309-311 asignación de la memoria del kemel, 314-317 del kemel, 693 en Linux, 691-694 en Solaris, 324-325 en Windows XP, 323-324 paginación bajo demanda, 282-289 alcance del TLB, 319-320 con tablas de páginas invertidas, 320 e instrucciones de reinicio, 286-287 estructura de los programas, 320-321 interbloqueo de E/S, 321-323 mecanismo básico, 283-287 prepaginación, 317-318 pura, 285 tamaño de página, 318-319 y rendimiento, 287-289 separación de la memoria lógica de la memoria física, 282 sustitución de páginas para conservar, 290-302 algoritmos de búfer de páginas, 301 mecanismo básico, 291-294 sustitución de páginas basada en contador, 300 sustitución de páginas FIFO, 294-295 sustitución de páginas LRU, 296-298 sustitución de páginas mediante aproximación LRU, 298-300 sustitución óptima de páginas, 296 y aplicaciones, 301 tamaño, 280 unificada, 390 y asignación de marcos, 302-305 asignación equitativa, 303 asignación global y local, 304-305 asignación proporcional, 303-304 y sobrepaginación, 305-309 causa de, 305-307 frecuencia de fallos de página, 309 modelo del conjunto de trabajo, 307-308 y técnica de copia durante la escritura, 289-290 MEMS (micro-electronic mechanical systems), 435 Mensajes: cola de, 773 conmutación de, 571 en sistemas operativos distribuidos, 559 sin conexión, 571 Metaarchivo, 661 Metadatos, 359, 744 Método de particiones múltiples, 253 Métodos (Java), 503 Mezcla de procesos, 80 MFD (master file directorvi, 347 MFU, algoritmo de sustitución de páginas, 301 Microcomputadora, 4

índice

818

M icrokernels, 55-57 Microsoft Windows. Véase Windows Migración: comandada, 152 de archivos, 587 de cálculos, 561-562 de datos, 561 de procesos, 562-563 solicitada, 152 Minidiscos, 345 Mínimo del conjunto de trabajo (Windows XP), 323 Mínimo privilegio, principio del, 484-485 Minipuerto, controlador de, 734 MMU. Véase Unidad de gestión de memoria Modelo: de localidad, 306 de memoria compartida, 49, 87-89 de paso de mensajes, 48, 89-92 de referencia ISO, 533 del conjunto de trabajo, 307-308 determinista, 162-163 multihebra muchos-a-muchos, 116-117 multihebra muchos-a-uno, 115-116 multihebra uno-a-uno, 116 Modificación, bits de, 292 Modificación de archivos, 50 Modificación de mensaje, 510 Modo bit de, 17 de bloqueo compartido, 613 de bloqueo, exclusivo, 613 de espera en caliente, 13 kemel, 17, 677 simétrico, 13 usuario, 17 Modos de fallo (directorios), 358-359 Módulo de organización de archivos, 370 Módulos, 56-57, 473 Módulos de autenticación conectables (PAM), 708 Monitor de referencia de seguridad, 737 Monitor residente, 767 Monitores, 186-193 implementación de, usando semáforos, 190-191 reanudación de procesos dentro de, 191-193 solución al problema de la cena de los filósofos usando, 189-190 utilización, 187-189 Monocultura, 520 Montaje, 373 dinámico, 248-249, 695-696 dinámico y estático, 248-249 tabla de, 375, 471 Morris, Robert, 521-524 Movilidad de los usuarios, 397 MPEG, archivos, 654-655 M S-DOS, 739-740 Muerte por inanición. Véase Bloqueo indefinido MULTICS, sistema operativo, 488-489, 774 Multidifusión, 660-661 Multihebra: activaciones del planificador, 127-128 beneficios, 113-115

J-

cancelación de una hebra, 123-124 conjuntos compartidos de hebras, 125-126 datos específicos de la hebra, 126-127 llamadas al sistema execQ, 123 llamadas al sistema forkQ, 123 modelos, 115-117 tratamiento de señales, 124-125 Multimedia, 651-652 como término, 651-652 cuestiones relativas al sistema operativo, 654 datos, 27, 652-653 Multiprocesamiento: asimétrico, 12,151 simétrico (SMP), 12,151,153, 688 Multiprogramación, 14-16, 80 Multitarea, 15 MUP (proveedor múltiple UNC), 753 Mútex: adaptativo, 194 en Windows XP, 720

N NDIS (network device interface specification), 750 Negociación, 452, 656 NetBEUI, protocolo, 750 NetBIOS, protocolo, 750 NFS (network file system,sistema de archivos de red), 395-400 operaciones remotas, 400 protocolo de montaje, 397 protocolo NFS, 398-399 traducción de nombres de ruta, 399-400 NFS V4, 596 NFS, protocolo, 398-399 NIS (network information Service), 358 Nivel de abstracción de hardware (HAL), 717 de aplicación, 574 de enlace de datos, 573 de presentación, 573 de red, 573 de sesión, 573 - -----de transporte, 573 del sistema, 655 físico, 573 físico, seguridad, 511 humano, seguridad, 512 Niveles, 655 de prioridad de interrupción, 455 de protocolos de red, 533 RAID, 426-431 NLS (national-language-support), API, 717 No apropiativo (sin desalojo), (interbloqueos), 225 No bloqueante I/O, 463-464 No enmascarable, interrupción, 454 No estrictos, sistemas de tiempo real, 634, 658 No repudio, 531 Nombrado, 89-91, 358 de archivos, 334 definición, 586 LDAP (lightweight diretorv-access protocol), 358., sistema de nombres de dominio, 358

índice

y comunicación de redes, 567-569 Nombre de ruta, 347-348 absoluto, 349 relativo, 349 Nombres: en Windows XP, 722-723 resolución de, 567-569, 756 Novell NetWare, protocolos, 751 NTFS, 742-744 Núcleo, memoria de, 771 Nuevo, estado, 75 Número: de bloque relativo, 343 de página (p), 255 de prioridad, 191 mágico (archivos), 340 personal de identificación (PIN), 539 Números lógicos de cluster, 743 NVRAM (RAM no volátil), 9 caché, 425

O Objeto(s): archivo, 334 contenedores (Windows XP), 550 despachadores, 195 en Windows XP, 719 en caché, 316 en Linux, 690 en Windows XP, 722-726 hardware y software, 485 , libres, 316 listas de acceso para, 493 locales (no remotos), 103 no contenedores (Windows XP), 550 no remotos (locales), 103 sección, 96 trabajo, 731 usados, 317 OLE (object linking and embedding), 753 open(), operación, 336 Operaciones conflictivas, 201 Operaciones de E/S (servicios del sistema operativo), 36 Operaciones remotas, 400 Ordenación de sucesos, 605-607 Ordenación global, 606 Organización con códigos de corrección de errores (ECC) de tipo memoria, 426 Organización de paridad con entrelazado de bits, 426 Organización de paridad con entrelazado de bloques, 426-427 OS/2, sistema operativo, 713

P

_____

p (número de página), 255 pageout (Solaris), 324-3 2 5 Paginación, 255-264 con prioridad, 325 e intercambio, 421 en Linux, 693 Intel Pentium, ejemplo, 273 invertida, 267-268

jerárquica, 264-266 método básico, 255-259 soporte hardware, 259-261 tablas de páginas hash, 266 y páginas compartidas, 263-264 y protección de memoria, 261-263 Paginación bajo demanda, 282-289 alcance del TLB, 319-320 con tablas de páginas invertidas, 320 definición, 282 e instrucciones de reinicio, 286-287 estructura de los programas, 320-321 interbloqueo de E/S, 321-323 mecanismo básico, 283-287 prepaginación, 317-318 pura, 285 tamaño de página, 318-319 y rendimiento, 287-289 Paginador, 283 Páginas: compartidas, 263-264 definición, 255 residentes en memoria, 284 PAM (pluggable authentication modules), 708 Paquete de solicitud de E/S (IRP), 734 Paquetes, 102, 571, 707 Paridad distribuida con entrelazado de bloque, 428 Partición(es), 253, 345, 373-375 de arranque, 419 de tamaño fijo, 253 en bruto (sin formato), 373, 422 raíz, 374 Particionar discos, 418 Pasarela, 570 Paso de mensajes, 86 asincrono, 91 síncrono, 91 Paso de testigo, 572, 609-610 PCB. Véase Bloque de control de proceso PCI, bus, 450 PCS (process-contention scope, ámbito de contienda del proceso), 154 PDA. Véase Asistente personal digital PDE (page-directory entries), 727 Peor ajuste, estrategia de, 254 Pérdida de datos, tiempo medio de, 425 Perfiles, 655 Perfiles móviles, 754 Períodos, 655 Permisos, 365 Persistencia de la visión, 652 Peterson, solución de, 174-175 PFF (page-fauit frecuency), 309 Phishing, 512 PIC (position-independent code), 696 Pid (identificador de proceso), 81 Pila, algoritmo de, 297 Pilas, 41, 74 PIN (personal Identification number), 539 PIO (programmed l/O, E/S programada), 314, 457 Pipe, mecanismo, 705 Pipes con nombre, 752

820

índice

Pistas de disco, 408 Planificación: algoritmos de planificación de disco, 412-417 C-SCAN, 416 FCFS, 413 LOOK, 416 SCAN, 415 selección, 416-417 SSTF, 413-415 apropiativa, 139-140 basada en prioridades, 638 con cuota proporcional, 644-645 cooperativa, 139 CPU. Véase Planificación de la CPU de disco: CineBlitz, 663 en sistemas multimedia, 658-659 de hebras, 137,154-155 de procesos: en Linux, 684-688 planificación de hebras y, 137 de trabajos, 15 E/S, 464-465 en Linux, 684-688 multiprocesamiento simétrico, 688 planificación de procesos, 684-686 sincronización del kemel, 686-688 en Pthread, 645, 646 en Windows XP, 718-719, 758-760 no serie, 201 por prioridad en finalización de plazo, 644 f por prioridad monótona en tasa, 642-644 serie, 201 Planificación de la CPU, 15 acerca de, 137-138 algoritmos de, 142-151 criterios, 140-141 evaluación de, 161-165 implementación de, 165 planificación FCFS, 142-143 planificación mediante colas multinivel, 148-150 planificación mediante colas muliinivel realimentadas, 150-151 planificación por prioridades, 145-146 planificación por tumos, 146-148 planificación SJF, 143-145 apropiativa, 139-140 despachador, papel del, 140 en sistemas de tiempo real, 641-645 con cuota proporcional, 644-645 planificación en Pthread, 645 por prioridad en finalización de plazo, 644 por prioridad monótona en tasa, 642-644 en sistemas multimedia, 658 en sistemas multiprocesador, 151-153 mecanismos multihebra simétricos, 153 métodos, 151-153 y afinidad del procesador, 152 y equilibrado de carga, 152-153 modelos para, 161-165 análisis de redes de colas, 163 e implementación, 165

modelo determinista, 162-163 simulaciones, 164-165 planificador a corto plazo, papel del, 138 y ciclo de ráfagas de CPU y de E/S, 138-139 Planificación de sistemas multiprocesador, 151-153 ejemplos de: Linux, 160-161 Solaris, 156-158 Windows XP, 158-160 mecanismos multihebra simétricos, 153 métodos, 151-152 y afinidad del procesador, 152 y equilibrado de carga, 152 Planificador a corto plazo (planificador de la CPU), 79,138 Planificador de E/S con límite de temporización, 703 Planificador de procesos, 77-78 a corto plazo, 79 a largo plazo, 79 a medio plazo, 80 Planificador de trabajos, 79 Planificadores, 79-80 Platos (discos), 407 PnP, gestor, 737-738 Polimórfico, virus, 520 Política, 51 de descarga de páginas (Linux), 693 de escritura diferida, 592 de escritura durante el cierre, 592 de grupo, 755 de seguridad, 540 Portabilidad, 716 Portales, 29 Posesión de la capacidad, 494 Posicionamiento, tiempo de (discos), 408 POSIX, 713, 715 ejemplo de sistema IPC, 93-93 en Windows XP, 741 PPTP, protocolo, 751 Practicidad, 3 Prepaginación, 317-318 Preparada, estado de hebra (Windows XP), 719 Preparado, estado, 75 Prestaciones: asignación de espacio de disco, 384-386 de Windows XP, 715-716 rendimiento con almacenamiento terciario, 438-442 coste, 440-442 fiabilidad, 440 velocidad, 438-440 rendimiento en sistemas de E/S, 475-478 Primer ajuste, estrategia de, 254 Principio del mínimo privilegio, 484-485 Prioridad dinámica, 658 estática, 658 fija (Solaris), 157 paginación con, 325 Privada, clave, 529 Problema de la cena de los filosófos, 185-186, 189-190 Problema de los lectores-escritores, 183-185 Problema del barbero dormilón, 207 Problema del búfer limitado, 181-182

índice

Procedimientos de acuerdo, 625-626 Procesadores de comunicaciones, 564 Procesadores frontales, 475 Procesamiento distribuido, mecanismos de, 751-752 Procesamiento por lotes, archivos de, 339 Proceso del sistema (Windows XP), 739 Proceso, objeto (Windows XP), 720 Procesos, 15 componentes, 74 comunicación entre. Véase Comunicación interprocesos concepto, 73-74 contexto del, 80, 682-683 cooperativos, 86 definición, 73 despachados, 79 en Linux, 683-684 en primer plano, 148 en segundo plano, 148 en Windows XP, 757 entorno de, 682 estado, 75 fallidos, 626 hebras ejecutadas por, 76-77 hijo, 725 independientes, 86 limitados por E/S y limitados por la CPU, 80 migración de, 562-563 monohebra, 113 multihebra. Véase Multihebra operaciones sobre los, 81-86 creación, 81-85 terminación, 85-86 ' padre, 81, 725 periódicos, 655 pesados, 113 planificación de, 77-81 programas y, 20, 74, 75 trabajos y, 74 y cambios de contexto, 80-81 Programa de arranque, 419, 521 Programa de control, 5 Programa, archivos de, 334 Programas: de arranque, 6, 64 de usuario (tareas de usuario), 73,694 del sistema, 49-50 informáticos. Véase Programas de aplicación y procesos, 74, 75. Véase también Programas de aplicación Programas de aplicación, 3 desinfección de, 544-545 procesamiento en varios pasos de, 246 procesos y, 19 utilidades del sistema, 49-50 Promedio exponencial, 144 Protección, 361-364, 483-507 archivos, 334 control de acceso para, 362-363 de E/S, 468-469 de memoria, 252 de sistemas de archivos, 361-365 de virus, 545-546 dominio de, 485-489

821

estructura, 486-487 MULTICS, ejemplo, 488-489 UNIX, ejemplo, 487-488 en entorno paginado, 261-263 en sistemas informáticos, 24-25 matriz de acceso como modelo de, 489-493 control de acceso, 495-496 implementación, 493-495 objetivos de la, 483-484 permisos, 365 principio del mínimo privilegio, 484-485 retroimplementado, 364 revocación de derechos de acceso, 496-497 seguridad y, 509 servicio del sistema operativo, 37 sistemas basados en capacidades, 497-500 Hydra, 498-499 sistema CAP de Cambridge, 499-500 sistemas basados en el lenguaje, 500-505 imposición de reglas basadas en compilador, 500-503 Java, 503-505 tratamiento de errores, 468 Protocolo(s): basados en marcas temporales, 203-204 de bloqueo en dos fases, 202 de bloqueo, 202-203,613-616 de confirmación en dos fases (2PC), 610-612 de confirmación, 610 de control de transmisión (TCP), 575 de datagramas de usuario (UDP), 575 de encaminamiento, 570 de herencia de prioridad, 195, 641 de mayoría, 614 de montaje, 397 de nivel de transporte (TCP), 533 de resolución de direcciones (ARP), 580 de transporte en tiempo real (RTP), 660 en redes Windows XP, 750-753 ligero de acceso al directorio (LDAP), 358, 755 preferencial, 614-615 sin memoria del estado, 662 Proxy, cortafuegos, 547 Proyecto, 158 Prueba de penetración, 540 PTBR (page-table base register), 260 Pthread, planificación en, 645, 646 Pthreads, 118 planificación, 154-155 sincronización en, 197 FTLR (page-table length register), 263 Pública, clave, 529 Puerta trasera, 460,514 Puertos, 314, 450 Pulí migration, 152 Puntero de archivo, 337 Puntero de entrada de pila, 516-517 Puntero de posición actual del archivo, 335 Punto de montaje, 354, 749 Puntos de cancelación, 124 Puntos de comprobación, 200 Puntos de desalojo, 639 Push migration, 152

822

índice

R RAID (redundant arrays of inexpensive disks), 423-432 estructuración, 424 matriz, 424 mejora de la fiabilidad, 424-425 mejoras en las prestaciones, 425 niveles, 426-431 problemas, 432 Raíz del índice, 743 Raíz, partición, 374 RAM (random-access memory), 7 RAM no volátil (NVRAM), 9 caché, 425 Rango de tiempo real (planificadores Linux), 684 Ranuras de página, 423 RBAC (role-based access control), 495 RC 4000, sistema operativo, 773 Reasignación de direcciones, 245-247 Reasignación, 245 Recolección de memoria, 61, 353 Reconfiguración, 576-577 Recorte web, 28 Recuento, 388 Recuperación: comprobación de coherencia, 392 copia de seguridad y restauración, 393-394 de archivos y directorios, 392 de fallos, 577 de interbloqueos, 235-236 mediante terminación de procesos, 235 por apropiación de recursos, 235 < Windows XP, 744-745 Recursos, compartición de, 558 Red de área de almacenamiento (SAN), 14, 411, 412 de área extensa (WAN, wide-area network), 15, 25, 564565 de área local (LAN, local area network), 13, 25, 563-564 de área metropolitana (MAN, metropolitan-area net­ work), 25 de área pequeña; 25 dispositivo de, 462, 702 inalámbrica, 28 inicio de sesión de, 358 parcialmente conectada, 566 privada virtual (VPN), 533, 751 Redes. Véase también Red de área local (LAN); Red de área extensa (WAN) amenazas, 520-525 cuestiones de diseño, 577-579 de área metropolitana (MAN), 25 de área pequeña, 25 definición, 25 ejemplo, 579-581 en Linux, 705-707 en Windows XP, 749-756 Active Directory, 755 dominios, 754-755 interfaces, 750 procesamiento distribuido, mecanismo de, 751-753 protocolos, 750-751

redirectores y servidores, 753-755 resolución de nombres, 756 estructura de comunicaciones, 567-572 contienda, 572 estrategias de conexión, 571 estrategias de encaminamiento, 569-570 estrategias de paquetes, 570-571 nombrado y resolución de nombres, 567-569 protocolos de comunicaciones, 572-575 robustez, 575-577 seguridad, 512 tipos de, 563 topología, 565-567 Redirectores, 753-754 Reducción de escala (doivnsizing), 559 Redundancia, 424. Véase también RAID Reed-Solomon, códigos, 428 Reentrante, código (código puro), 263 Referencia de archivo, 743 Referencia, bits de, 299 Referencia, cadena de, 293 Regiones de memoria virtual, 692 Registrador de pulsaciones de tecla, 520 Registro(s), 41, 50, 738 base, 244, 245 base de la tabla de páginas (PTBR), 260 base del archivo, 743 de controladores, módulo (Linux), 679-680 de direcciones de memoria, 247 de escritura anticipada, 198-199 de instrucciones, 8 de lectura anticipada, 198-199 de longitud de la tabla de páginas (PTLR), 263 de reubicación, 247 límite, 244, 245 lógicos, 342 maestro de arranque, 419 para tablas de páginas, 259-260 Regla de planificación, 759 Regla del 50 por ciento, 254 Relación de confianza, 755 cruzada, 755 transitiva, 755 unidireccional, 755 Relativo, nombre de ruta, 349 release(), operación, 337 Relleno de ceros bajo demanda, técnica, 290 Reloj, algoritmo del, 299 Reloj de la CPU, 244 Reloj lógico, 606 Relojes, 463-464 Remoto, sistema de archivos, 356-359 Rendezvons, 91 Reparación, tiempo medio de, 424 Replicación, 430 de archivos (sistemas de archivos distribuidos), 597 Reposicionamiento (dentro de archivos), 335 Representación de datos externa (XDR), 100 Representación de un proceso en Linux, 77 Reproducción local, 652 Reproducción, ataques de, 510 Reproductor de medios, 661

índice

Reserva de dispositivos, 467-468 de sectores, 420 de recursos, 657-658 en caliente, discos de, 430 Resolución de conflictos, módulo (Linux), 680-681 Resolución, 319 de enlaces, 351 de nombres, 567-569 y tamaño de página, 318 Responsabilidad (servicios del sistema operativo), 37 Restauración: de datos, 392-393 del estado, 80 Restaurar el sistema (Windows XP), 738 Resumen de mensajes (valor hash), 530 Retardo, 656 Retención y espera, condición de (interbloqueos), 224-225 Retrollamada, 600 Reubicación, registro de, 247 Revocación de derechos de acceso, 496-497 RMI. Véase Invocación de métodos remotos Robo de ciclos, 458 Robo de servicio, 510 Robustez, 575-577 Roles, 495 ROM. Véase Memoria de sólo lectura RSX, sistema operativo, 777 RTF (rich text format), 545 R-timestamp, 203 RTP (real-time transport), protocolo, 660 f Ruptura de la confidencialidad, 510 Ruptura de la disponibilidad, 510 Ruptura de la integridad, 510 Ruta de búsqueda, 348 Rutina de servicio de interrupciones, mitad inferior, 687 Rutina de servicio de interrupciones, mitad superior, 687 Rutina de tratamiento de suprallamada, 127 RW (lectura-escritura), formato, 21

Salida de datos, registro de, 452 Salvaguarda del estado, 80 SAN (storage-area network), 14, 411, 412 SATA (serial ATA) buses, 409 SCAN (ascensor), algoritmo de planificación, 415, 659 SCAN circular (C-SCAN), algoritmo de planificación, 416 SCOPE, sistema operativo, 777 Script kiddies, 517 SCS (system-contention scope, ámbito de contienda del sis­ tema), 154 SCSI (small computer-systems interface), 10 buses, 409 destinos, 411 iniciador, 411 Sección de datos (del proceso), 74 de entrada, 173 de salida, 173 de texto (del proceso), 74 objeto, 727 restante, 173

>

823

Sección crítica, problema de la, 173-174 Peterson, solución de, 174-175 y semáforos, 178-182 e interbloqueos, 181-182 implementación, 180-181 inanición, 181-182 utilización, 179 y sincronización hardware, 175-178 Secreto maestro (SSL), 534 Secreto premaestro (SSL), 534 Sector de arranque de la partición, 371 Sector de disco, 408 Sectores de reserva, 748 Secuencia segura, 227 Secuenciales, dispositivos, 460 Secuenciamiento automático de trabajos, 767 Secuestro de sesión (hijacking), 511 Secundaria, memoria, 286 Segmentación, 269-271 definición, 269 hardware, 270-271 Intel Pentium, ejemplo, 271-275 método básico, 269-270 Segmentos, tabla de, 270 Segunda oportunidad, algoritmo de sustitución de páginas (algoritmo del reloj), 299 Segundo sistema de archivos extendido (ext2fs), 698-700 Seguridad. Véase también Amenazas relacionadas con los programas; Protección; Autenticación de usuario amenazas del sistema y de la red, 520-525 denegación de servicio, 524-525 escaneo de puertos, 524 gusanos, 521-524 autenticación de usuario, 535-539 biométrica, 539 contraseñas, 536-539 clasificaciones de, 547-549 como problema, 509-513 cortafuegos, 546-547 criptografía como herramienta de, 525-535 cifrado, 526-533 implementación, 533-534 SSL, ejemplo, 534-535 de los tipos (java), 504 en Linux, 707-709 autenticación, 707-708 control de acceso, 708-709 en sistemas informáticos, 24 en Windows XP, 549-550, 715 implementación de, 539-546 auditoría, 546 contabilización, 546 detección de intrusiones, 541-545 evaluación de la vulnerabilidad, 540-541 política de seguridad, 540 protección frente a virus, 545-546 registro, 546 mediante la oscuridad, 541 niveles de, 511-512 protección y, 509 servicio del sistema operativo, 37 Windows XP, 745

824

índice

Seguro, sistema, 509 Semáforos, 178-182 binario, 179 contador, 179 definición, 178 e inanición, 181-182 e interbloqueos, 181-182 implementación de monitores usando, 190-191 implementación, 180-181 utilización, 179 Windows XP, 720 Semántica: de archivos compartidos inmutables, 360 de coherencia, 359-360 de copia, 466 de sesión, 360 Semilla, 538 Señales: Linux, 704 UNIX, 110,124-125 Serialización, 200-202 de objetos, 103 Servicio de información de red (NIS), 358 Servicio del archivo de registro, 745 Servicio remoto, mecanismo de, 594 Servicios de archivos con memoria del estado, 594-595 Servicios de archivos sin memoria del estado, 594-595 Servicios del sistema operativo, 35-37 Servidor de cluster, 598 Servidores, 4 blade, 13 definición, 585 en SSL, 533-534 Sesión de archivo, 360 Sesión, semántica de, 360 Sesiones de comunicaciones, 571 Shells, 37,108-110 Signaturas, 542 Simétrico, cifrado, 527-528 Simulaciones, 164 Sin conexión, mensajes, 571 Sin desalojo, planificación, 138 Sin disco, cliente, 588 Sin formato, disco, 302, 373 Sin formato, particiones, 422 Sincronización de procesos acerca de, 171-173 ejemplos: Java, 193 Linux, 196-197 Pthreads, 197 Solaris, 194-195 Windows XP, 195-196 monitores, 186-193 implementación usando semáforos, 190-191 reanudación de procesos dentro de, 191-193 solución al problema de la cena de los filósofos, 189-190 utilización, 187-189 problema de la cena de los filosófos, 185-186,189-190 problema de la sección crítica, 173-174 Peterson, solución de, 174-175

solución hardware, 175-178 problema de los lectores-escritores, 183-185 problema del búfer limitado, 182-183 semáforos para, 178-182 y transacciones atómicas, 197-204 modelo del sistema, 197-198 puntos de comprobación, 199-200 recuperación basada en registro, 198-199 transacciones concurrentes, 200-204 Sincronización, 91. Véase también Sincronización de procesos Síncrono, dispositivo, 460 Sistema archivos del, 348 basado en la Web, 30-31 cliente, 28 común de archivos Internet (CIFS), 358 de archivos de proceso, /proc (Linux), 700-702 de archivos de red (NFS). VéaseNFS de descomposición binaria (Linux), 689 de detección de intrusiones, 542 de nombres de dominio (DNS), 358,568 de prevención de intrusiones, 542 en ejecución, 64 entre iguales, 30 integrado, 634 operativo de red, 26, 559-561 tolerante a fallos, 577 Sistemas de archivos, 333, 369-371 básico, 370 • creación de, 345-346 de red (NFS), 395-400 en niveles, 370 extendido, 371 implementación de, 371-377 montaje, 373 particiones, 373-375 sistemas virtuales, 375-377 Linux, 696-702 lógico, 370 montaje de, 354-355 orientados a transacciones y basados en registro, 393-395 problemas de diseño con, 370 remotos, 356-359 WAFL, 400-402 Sistemas de bases de datos, 197 Sistemas de información distribuidos (servicios de denomi­ nación distribuidos), 358 Sistemas de mano, 27-28 Sistemas de protección basados en capacidades, 497-500 Hydra, 498-499 sistema CAP de Cambridge, 499-500 Sistemas de protección basados en el lenguaje, 500-505 imposición de reglas basadas en compilador, 500-503 Java, 503-505 Sistemas de seguridad crítica, 634 Sistemas de servidor de archivos, 28 Sistemas de un solo procesador, 11,137 Sistemas distribuidos, 25-26, 555-583 definición, 557 sistemas operativos de red, 559-561 sistemas operativos distribuidos, 561-563 ventajas de los, 557-559

índice

Sistemas en tiempo real, 26-27, 633-650 características no necesarias en, 636 características, 634-636 definición, 633 estrictos, 634, 658 huella, 635 implementación, 637-641 kemels apropiativos, 638-639 minimización de la latencia, 639-641 planificación basada en prioridades, 638 no estrictos, 634, 658 planificación de la CPU, 641-645 traducción de direcciones, 636-637 VxWorks, ejemplo, 645-648 Sistemas fuertemente acoplados, 13-14 Sistemas informáticos: almacenamiento en, 7-9 amenazas, 520-525 arquitectura sistemas de un solo procesador, 11-13 sistemas en cluster, 13-14 sistemas multiprocesador, 11-13 de propósito especial, 26-28 sistemas de mano, 27-28 sistemas embebidos en tiempo real, 26-27 sistemas multimedia, 27 estructura de E/S, 9-11 funcionamiento de, 6-7 gestión de almacenamiento, 20-24 almacenamiento en caché, 22-23 gestión del almacenamiento masivo, 21 sistemas de E/S, 23-24 gestión de memoria, 19-20 gestión de procesos, 19 gestión del sistema de archivos, 20-21 interactivo, 15 protección en, 24-25 seguridad en, 24 seguridad, 510 sistemas de propósito general, 26-28 sistemas de mano, 27-28 ^ sistemas embebidos en tiempo real, 26-27 sistemas multimedia, 27 .sistemas distribuidos, 25-26 tradicionales, 28-29 Sistemas mecánicos microelectrónicos (MEMS), 435 Sistemas multimedia, 27, 651-667 características, 653 CineBlitz, ejemplo, 663-665 compresión, 654-655 gestión de red, 660-663 kemels en, 655-657 planificación de disco, 657-660 planificación de la CPU, 657 Sistemas multiprocesador (sistemas paralelos, sistemas fuertemente acoplados), 11-14 Sistemas operativos, 1 asignador de recursos, 5 características, 3 controlados mediante interrupciones, 16 definición, 3, 5-6 distribuidos, 561-563

825

en tiempo real, 26-27 estructura, 14-16, 52-57 en niveles, 53-55 microkemels, 55-57 módulos, 56-57 simple, 53 funcionamiento, 3-6 huésped, 60 implementación, 52 interfaz de usuario, 4-5, 37-39 mecanismos, 51 objetivos del diseño, 50-51 operaciones del: modo, 16-18 y temporizador, 18 pioneros, 765-771 E/S solapada, 769-771 sistemas informáticos compartidos, 766-769 sistemas informáticos dedicados, 765-766 políticas, 51 red, 25 seguridad en, 512 servicios proporcionados, 35-37 vista del sistema, 5 Sistemas paralelo, 11-14 SJF, algoritmo de planificación, 143-145 SMB (server-message-block), 750 SMP. Véase Multiprocesamiento simétrico Sniffing(husmeai), 536 Sobreasignación (de memoria), 290 Sobrepaginación, 305-309 causa de, 305-307 definición, 305 frecuencia de fallos de página, estrategia, 309 modelo del conjunto de trabajo, 307-308 SOC (system-on-chip, sistema en un chip), estrategia, 635 Socket, 97-99 interfaz, 462 TCP, 97 TCP orientados a conexión, 97 UDP, 97 UDP sin conexión, 97 Software, interrupción, 456 Software, objetos, 485 Solaris: ejemplo de planificación, 156-158 gestión del espacio de intercambio, 423 memoria virtual en, 324-325 sincronización en, 194-195 Sólo escritura, dispositivos de, 460 Sólo lectura, discos de, 434 Sólo lectura, dispositivos de, 460 Sondeo, 452-453 Soporte de idioma nacional (NLS), 717 Soporte de lenguajes de programación, 50 Soporte internacional, 717 Sostenido, ancho de banda, 438 Spooling, 770-771 Spyioare, 513 SSL 3.0, 534-535 SSTF, algoritmo de planificación, 413-415 Stream, módulos, 473

índice

STREAMS, mecanismo, 473-475 Stub, rutinas, 752 Stubs, 102, 249 Subarchivo de datos, 341 Subarchivo de recursos, 341 Subsistema de E/S, 23 kernel, 6, 464-470 procedimientos supervisado . por, 470 Subsistemas de entorno, 716 Subsistemas de protección (Windows XP), 717 Suceso, objeto (Windows XP), 720 Sucesos, 195 Sucesos, ordenación de, 605-607 Sucio (o de modificación), bit, 292 Sujeto de servidor (Windows XP), 549 Sujeto simple (Windows XP), 549 Suma de comprobación, 580 Superbloque, 372 Superbloque, objeto, 376, 696 Suplantación, 547 Suprallamadas, 127 Sustitución basada en prioridades, algoritmo de, 306 Sustitución de páginas, 290 -3 0 2 . Véase también Asignación de m arcos algoritm o, 293 algoritm os de búfer de páginas, 301 global y ¡ocal, 304 m ecanism o básico, 291-2 9 4 sustitución de páginas basada en contador, 300 sustitución de páginas FIFO, 29 4 -2 9 5 sustitución de páginas LRU, 29 6 -2 9 8 ■ sustitución de páginas m ediante aproxim ación LRU, 298-300 sustitución óptim a de páginas, 296 y aplicaciones, 301 Sustitución de sectores, 420 Sustitución óptima de páginas, algoritmo, 296

T T abla de páginas, 2 5 5 -2 5 9 , 285., 727 con correspondencia directa, 264 en cluster, 267 hardw are para alm acenar, 2 59-261 hash, 266 invertidas, 267-268, 320 Tabla(s), 280 de archivos abiertos de cada proceso, 372 de archivos abiertos, 336 de asignación de archivos (FAT), 382 de contenidos del volum en, 345 de despacho de interrupciones (W indow s XP), 721 de encam inam iento, 569 de montaje, 375, 471 de objetos, 725 de segmentos, 270 global de archivos abiertos, 372 global de descriptores (GDT), 272 hash, 377-378 local de descriptores (LDT), 272 m aestra de archivos, 372 Tam año de página, 3 1 8 -3 1 9

J-

Tareas: caducadas (Linux), 684 Linux, 682-683 VxW orks, 645

Tarjetas de control, 44, 767, 768 Tarjetas de E/S con control maestro del bus, 457 Tasa de acierto, 261 de fallos de página, 288 de procesam iento, 141 de transferencia, 656 TCB (trusted Computer base), 548 TCP (transmission control protocol), 575 TCP/IP, conjunto de protocolos, 751 TDI (transport driver interface), 750 Técnica basada en coordinadores múltiples (control de con­ currencia), 614 Técnica de precodificación, 90 Tecnología hiperhebra, 153 telnet, 559 Temporizador, objeto, 720 Temporizadores, 462-463 de intervalo program able, 462 variable, 18 Tenex, sistema operativo, 777 Terciario, almacenamiento. Véase Alm acenamiento terciario Terminación: de procesos, 85-86, 235 en cascada,

86

Terminada, estado de hebra (Windows XP), 719 Terminado, estado, 75 Testigo, 572, 609 Testigo de acceso de seguridad (Windows XP), 549 Texto, archivos de, 334 THE, sistema operativo, 772-773 Tiempo: com partido (m ultitarea), 15 de acceso efectivo, 287 de carga, 247 de com pilación, 246 de ejecución, 141,247 de espera, 141 de respuesta, 15,141 efectivo de acceso a m em oria, 261 m edio de pérdida de datos, 425 medio de reparación, 424 medio entre fallos, 424 real, clase de, 158 Tipo abstracto de datos, 335 Tipos de objetos, 376, 724 TLB (translation look-aside buffer). Véase Búfer de traduc­ ción directa alcance del, 319-320 fallo de, 260

-Tolerancia a fallos, 12, 578, 745-748 Topología de red, 565-567 Torvalds, Linus, 671 Trabajos, procesos y, 74 Traducción de nombres de ruta, 399-400 Tramas, 571 T ran saccion es 197. Véase también Transacciones atóm icas abortadas, 198

índice

anuladas, 198 confirmadas, 198 definición, 700 en Linux, 700 en sistemas de archivos con estructura de registro, 393-395 Transacciones atómicas, 1 7 6 ,1 9 7 -2 0 4 concurrentes, 2 0 0 -2 0 4 y protocolos basados en m arcas tem porales, 20 2 -2 0 3 y protocolos de bloqueo, 20 2 -2 0 3 y serialización, 200-2 0 2 modelo del sistema, 197 -1 9 8 registro de escritura anticipada, 1 9 8 -1 9 9 y puntos de com probación, 19 9 -2 0 0 Transare DFS, 598 Transferencia de datos dirigida por interrupción, 314 Transferencia remota de archivos, 5 60-561 Transformaciones de caja negra, 528 Transición, estado de hebra (Windows XP), 719 Transmisión de flujos (stream ing), 652 Transparencia, 57 7 -579, 58 6 -5 8 7 Tratamiento de señales, 1 1 0 ,1 2 4 -1 2 5 definidas por el usuario, 124 predeterm inadas, 124 Triple DES, 528 Triplemente indirecto, bloque, 384 Tripwire, sistema de archivos, 544 Túnel, virus, 520 twofish, algoritmo, 528

U Ubicación de archivo, 334 Ubicación, independencia de, 587 Ubicación, transparencia de, 587 UDP (user datagram protocol), 575 UFD (user file directory), 347 UFS (UNIX file system), 371 UI (user interface), 3 6 -3 7 UID efectivo, 25 uid root (Linux), 708 UNC (unifomi naming convention), 752 ' UNC, proveedor múltiple (MUP), 753 UNICODE, 717 Unidad central de procesamiento. Véase CPU Unidad componente, 586 Unidad de ejecución de instrucciones, 740 Unidad de gestión de memoria (MMU, memory-management unit), 247 -2 4 8 , 728 Unidades lógicas, 411 Unidifusión, 660-661 UNIX, sistema operativo: conm utación de dominio en, 48 7 -4 8 8 intercambio en, 251 permisos en, 365 semántica de coherencia, 360 señales, 1 1 0 ,1 2 4 -1 2 5 shell y función historial (proyecto), 108-111 sistema de archivos (UFS), 371 y Linux, 737 U sados, objetos, 317, 691 USB (universal serial bus), 409 U suario(s), 4 -5 , 356

cuentas de, 549 m ovilidad de, 397

Utilidad, almacenamiento de, 431 Utilidades del sistema, 4 9 -5 0 , 67 6 -6 7 7 Utilización de recursos, 4

V Vaciar, 260 VAD (virtual address descriptors), 731 Válido-inválido, bit, 262 Valor de tiempo real (Linux), 160 Valor normal (nice) (Linux), 160, 685 Variable automática, 515 Variable, clase, 158 VDM. Véase M áquina DOS virtual Vector: de argum entos, 682 de bits (m apa de bits), 386 de entorno, 682 de interrupciones, 7, 454 p rogram a, 521

Velocidad angular constante (CAV), 410 Velocidad de operaciones: para dispositivos de E /S , 459, 460

Velocidad de transferencia (discos), 408, 409 Velocidad lineal constante (CLV), 410 Velocidad relativa, 173 Ventanas de explorador emergentes, 514 vfork() (fork para memoria virtual), 290 VFS (virtual file system), 3 7 5 -3 7 7 , 696-698 Víctima, marco, 292 Virtual, dirección, 247 Virus, 5 1 8 -5 2 0 , 54 5 -5 4 6 cifrado, 520 de código fuente, 520 encubierto, 520 lanzador de, 518 multiparte, 520 polimórfico, 520 Vista, 727

VMS, sistema operativo, 777 VMware, 60 vnodo, 376 núm ero de (NFS V4), 599

Volumen, bloque de control de, 371 Volúmenes, 345, 599 copias ocultas de, 749

von Neumann, arquitectura de, 8 VPN (virtual prívate network), 533, 751 VxWorks, 64 5 -6 4 8

W WAFL, sistema de archivos, 40 0 -4 0 2 WAN. Véase Red de área extensa WebDAV, protocolo, 751 Win32, biblioteca de hebras de, 118-121 Windows 2000, 714, 717 Windows NT, 713-714 Windows XP, 7 13-764 altas prestaciones, 71 5 -7 1 6 ampliabilidad, 716 com patibilidad con aplicaciones, 715

827

828

índice

Windows XP (Cont.) componentes del sistema, 717-739 executive. Véase Windows XP executive kemel, 717-722 nivel de abstracción hardware, 717 conexión de red, 749-756 Active Directory, 755 dominios, 754-755 interfaces, 750 procesamiento distribuido, mecanismos de, 751-753 protocolos, 750-751 redirectores y servidores, 753-754 resolución de nombres, 756 ejemplo de hebras, 128,129 ejemplo de planificación, 158-160 ejemplo de sistema IPC, 95-96 Windows de 16 bits, 740 Windows de 32 bits, 740-741 fiabilidad de, 715 historia, 713-714 interfaz de programación, 756-763 acceso a los objetos del kemel, 756 compartición de objetos entre procesos, 756-757 comunicación interprocesos, 760-761 gestión de memoria, 761-763 gestión de procesos, 757-760 memoria virtual en, 323-324 portabilidad, 716 principios de diseño, 714-717 seguridad, 715 sincronización en, 195-196 sistema de archivos, 742-749 compresión y cifrado, 748 copias ocultas de volúmenes, 749 diario de cambios, 749 gestión de volúmenes y tolerancia a fallos, 745-746 NTFS, árbol B+, 743-744 NTFS, estructura interna, 742-744 NTFS, metadatos, 744 puntos de montaje, 749 recuperación, 744-745

seguridad, 745 subsistema de seguridad, 741-742 subsistemas de entorno, 739-742 inicio de sesión, 741-742 MS-DOS, 739-740 POSIX, 741 seguridad, 741-742 Win32, 741 versiones de sobremesa, 714 Windows XP executive, 722-739 arranque, 738-739 gestor de caché, 734-736 gestor de E/S, 733-734 gestor de memoria virtual, 726-731 gestor de objetos, 722-726 ■ gestor de procesos, 731-732 gestores plug-and-play y de administración de energía, 737-738 llamada a procedimientos locales, 732-733 monitor de referencia de seguridad, 737 Registro, 738 Windows, intercambio en, 251 Winsock, 752 Witness, 226 World Wide Web, 357 WORM (escritura una vez, lectura muchas veces), formato, 21

WORM (write-once, read-many-times), discos, 434 W-timestamp, 203

X XDR (extemal data representation), 100 XDS-940, sistema operativo, 771-772 Xerox, 38 XML, cortafuegos, 547

z Zombi, sistemas, 524 Zona desmilitarizada (DMZ), 546 Zonas (Linux), 688

* Otro m om ento decisivo en la rolución de los sistem as operativos Los sistemas operativos con huella pequeña, como los utilizados en los dis­ positivos de mano que emplean los bebés de dinosaurio de la portada, representan sólo una de las múltiples aplicaciones avanzadas que podrá encontrar el libro Fundam entos de sistem as operativos, séptim a edición de Silberschatz, Galvin y Gagne. Al mantenerse actualizado, preservando la relevancia y adaptándose a las necesidades didácticas más recientes, este texto fundamental continúa siendo el libro de referencia para cursos de sistemas operativos. Esta séptima edición no sólo presenta los sistemas más recientes y relevantes, sino que también los analiza más en profundidad para presentar los conceptos fundamentales que han permanecido constantes a lo largo de la evolución de los sistemas operativos actuales. Con esta fuerte base conceptual, los estudiantes pueden comprender con mayor facilidad los detalles relacionados con cada sistema específico.

N ovedades • Tratamiento más detallado de la perspectiva del usuario en el Capítulo 1. • Aumento del material de diseño de todos los elementos de un sistema operativo. • Un nuevo capítulo sobre sistemas de tiempo (¡MBb real y sistemas embebidos (Capítulo 19). • Un nuevo capítulo sobre sistemas multimedia (Capítulo 20). • Material adicional sobre seguridad y protección. • Material adicional sobre programación distribuida. • Nuevos ejercicios al final de cada capítulo. Nuevos proyectos de programación al final de cada capítulo. • Nuevo tratamiento de los aspectos didácticos, centrado en el estudiante con el fin de mejorar el proceso de aprendizaje.