1Programacin ConcurrenteConceptos bsicos

Por Jos M Toribio VicenteUniversidad de Valladolid

edited by jsmBarcelona, Espaa. 7/11/2000

Comunicaciones entre procesos

En este captulo vamos a intentar explicar los conceptosbsicos necesarios para entender el significado de loshilos y la programacin multihilo. Se explican, de formagenrica, los conceptos de sistema operativo, proceso,paralelismo, concurrencia y comunicacin ysincronizacin de procesos. Para una explicacin msdetallada se puede consultar cualquier libro sobreconceptos de sistemas operativos como puede ser[TAN93].

Concepto de Sistema Operativo

La definicin de sistema operativo es complicada,aunque todos los usuarios de computadoras tienencierta experiencia con l. Su definicin se basa en las dosfunciones principales que realiza:

Sistema operativo como mquina extendida: La funcin delsistema operativo es presentar al usuario el equivalentede una mquina extendida o mquina virtual que seams fcil de programar que el hardware subyacente, deforma que se le oculten caractersticas de bajo nivelrelacionadas con el manejo de los discos, lasinterrupciones, cronmetros, control de memoria, etc.

Sistema operativo como controlador de recursos: La funcin delsistema operativo es proporcionar una asignacinordenada y controlada de los procesadores, memorias ydispositivos de E/S para los distintos programas quecompiten por ellos. Es decir, el sistema operativo seencarga de llevar un registro de la utilizacin de losrecursos, dar servicio a las solicitudes de recursos,contabilizar su uso y mediar entre las solicitudes enconflicto de los distintos programas y usuarios.Los sistema operativos han ido evolucionando a lo largode los aos. La evolucin de los sistemas operativos haestado ligada con la arquitectura de las mquinas en lasque se ejecutan :

La primera generacin (1945-1955): Las primerascomputadoras empleaban vlvulas y su programacin serealizaba directamente mediante conexiones o lenguajemquina. No existan lenguajes de programacin, nisistemas operativos.

La segunda generacin (1955-1965): Las computadoras seconstruan empleando transistores. Los programas seescriban en un lenguaje de programacin (Ensambladoro Fortran) para despus pasarlo a tarjetas perforadas. Sedesarrollaron los primeros sistemas de procesamientopor lotes, que consistan en agrupar una serie de trabajosen un lote y pasrselos a la computadora para suresolucin de forma secuencial, uno tras otro. Lasgrandes computadoras de esta poca se dedicaban alclculo cientfico y de ingeniera. Los sistemas

operativos ms habituales eran FMS (Fortran MonitorSystem) e IBSYS, el sistema operativo de IBM para la7094 (la computadora ms conocida de la poca).La tercera generacin (1965-1978): La aparicin de loscircuitos integrados a pequea escala favoreci laproduccin de mquinas ms potentes, de dimensionesms reducidas, y de menor precio. Se desarrollaronfamilias de computadoras, como el sistema 360 de IBM,con el fin de lograr la compatibilidad entre las distintasmquinas de la familia, y poder emplear los mismosprogramas, incluso el sistema operativo, en toda lafamilia. Esto origin un sistema operativo monstruoso,el OS/360, que contena miles de errores, y requeracontinuas revisiones que arreglaban una serie de errores,introduciendo muchos otros. Se generaliz la tcnica demultiprogramacin, que consista en dividir la memoriaen varias partes, con un trabajo distinto en cada una.Mientras un trabajo esperaba por E/S, otro podaemplear la CPU, lo cual mejoraba la utilizacin de lamquina. Para aislar cada una de las particiones seempleaba un hardware especial. Se invent la tcnica despooling (Simultaneous Peripheral Operation On Line,Operacin simultnea y en lnea de perifricos), que seemple para las entradas y salidas. Sin embargo, aunquelos sistemas operativos de esta poca eran adecuadospara los clculos cientficos y el procesamiento de datoscomerciales, seguan siendo esencialmente sistemas deprocesamiento por lotes. A pesar de ello comenzaronlos primeros desarrollos de sistemas de tiempocompartido, variante de la multiprogramacin, como elsistema CTSS del MIT. Un diseo posterior de sistemade estas caractersticas fue MULTICS (MULTiplexedInformation and Computing Service) cuyo objetivo eraproporcionar una mquina para cientos de usuariosempleando tiempo compartido. MULTICS fue unsistema que fracas y se abandon. Durante esta poca,se desarrollaron la familia de minicomputadoras DECPDP-1 hasta PDP-11. Ken Thompson escribi unaversin especial de MULTICS para un usuario en unaPDP-7, que ms tarde dara origen a UNIX.

La cuarta generacin (1978-1991): Se desarrollaron loscircuitos integrados del tipo LSI y VLSI (Very LargeScale Integracin) que contenan miles y hasta millonesde transistores en un centmetro cuadrado, lo queabarat los costes de produccin. Se invent de estaforma el microprocesador, que permita a un usuariotener su propia computadora personal. Los sistemasoperativos desarrollados han ido siendo cada vez msamigables, proporcionando entornos grficos de trabajo.Los sistemas operativos ms difundidos en estos aoshan sido MS-DOS de Microsoft funcionando en loschips de Intel, y UNIX funcionando en todo tipo demquinas (especialmente con chips RISC). A mediadosde los 80, aparecen las primeras arquitecturas concomputadoras en paralelo que emplean memoriacompartida o distribuida, y hardware vectorial, as como

2los primeros sistemas operativos de multiproceso,lenguajes y compiladores especiales para estos sistemas.

La quinta generacin (1990- ): La tecnologa del procesoparalelo comienza a madurar y se inicia la produccin demquinas comerciales. Los sistemas MPP (MassivelyParalell Processing) son los sistemas paralelos en los quese vuelca la investigacin. El desarrollo progresivo de lasredes de computadoras, y la idea de la interconexin ycomparticin de recursos, ha promovido el desarrollode sistemas operativos de red y sistemas operativosdistribuidos. En los primeros, el usuario es conscientede la existencia de otras mquinas a las que puedeconectarse de forma remota. Cada mquina ejecuta supropio sistema operativo local y tiene su propio grupode usuarios. En cambio, en un sistema operativodistribuido, el usuario percibe el sistema como un todo,sin conocer el nmero de mquinas, ni su localizacin,de esta forma los usuarios no son conscientes del lugardonde se ejecuta su programa, ni donde se encuentransus archivos fsicamente; todo ello es manejado deforma automtica por el sistema operativo. Los sistemasoperativos de red no tienen grandes diferencias respectoa los sistemas operativos de un solo procesador, ya queslo necesitan una serie de caractersticas adicionalesque no modifican la estructura esencial del sistemaoperativo. En cambio, los sistemas operativosdistribuidos necesitan una serie de modificaciones demayor importancia, ya que esencialmente se diferenciande los sistemas centralizados en la posibilidad decmputo en varios procesadores a la vez.La organizacin de los sistemas operativos ha idoevolucionando tambin, al igual que lo ha ido haciendoel hardware. Se pueden distinguir una serie deorganizaciones muy relacionadas con la poca de cadasistema operativo:

1) Estructura monoltica: Los primeros sistemasoperativos tenan una organizacin o estructuramonoltica. No posean estructura alguna. El sistemaoperativo constaba de una serie de procedimientos.,cada uno de los cuales puede llamar al resto cuando seanecesario. Cada procedimiento del sistema tiene unainterfaz bien definida. Los servicios que proporciona elsistema operativo se solicitan colocando los parmetrosen lugares bien definidos (registros o pila), para despusejecutar una instruccin especial de trampa, una llamadaal ncleo o una llamada al supervisor. Esta instruccincambia la mquina del modo usuario al modo supervisor(o modo kernel), y transfiere el control al sistemaoperativo.

As una estructura simple para un sistema monolticosera la siguiente:

a) Un programa principal que realiza una llamada alprocedimiento de servicio solicitado.

b) Un conjunto de procedimientos de servicio querealizan las llamadas al sistema.

c) Un conjunto de procedimientos de utilidad queayudan al procedimiento de servicio.

Figura 2-1 Estructura simple de un sistema operativomonoltico2) Estructura en capas: Es una generalizacin del modelomostrado en la figura anterior. Se trata de organizar elsistema operativo como una jerarqua de capas, cada unaconstruida sobre la anterior. Un ejemplo de estaestructura es el sistema operativo THE, desarrollado enHolanda por E.W. Dijkstra y un grupo de estudiantes en1968.

5 El operador4 Programas de usuario3 Gestin de entrada/salida2 Comunicaciones operador/proceso1 Gestin de memoria y disco0 Asignacin del procesador y multiprogramacin

Una generalizacin avanzada del concepto de capas serealiz en el sistema operativo MULTICS, que seorganiz en anillos concntricos. Los anillos interioresson los de mayores privilegios.

3) Estructura de mquinas virtuales: El origen de estaestructura se encuentra en el sistema operativoCP/CMS, que despus se llam VM/370, diseado parael sistema 360/370 de IBM. Es un sistema de tiempocompartido que proporciona multiprogramacin y unamquina extendida con una interfaz ms agradable queel propio hardware, separando estas dos funciones deforma clara.Figura 2-3 Estructura del sistema operativo VM/370 con CMS.

El sistema posee un monitor de mquina virtual quese ejecuta en el hardware y realiza la multiprogramacin,proporcionando varias mquinas virtuales, no como

mquinas extendidas, sino como copias exactas delhardware simple, con su estructura de modo ncleo ymodo usuario, sus interrupciones, etc. al igual que lamquina real. De esta forma cada mquina virtual, porser idntica a la real, puede ejecutar cualquier sistemaoperativo que funcione directamente sobre el hardware,pudiendo tener varios sistemas operativos funcionandoal mismo tiempo. CMS (Conversational MonitorSystem) es un sistema interactivo monousuario que solaejecutarse sobre cada mquina virtual.

Al emplear este tipo de organizacin se logra una mayorsencillez de diseo, flexibilidad y facilidad demantenimiento.

4) Estructura Cliente/Servidor: La tendencia actual en eldiseo de sistemas operativos es la de mover la mayorcantidad de cdigo posible hacia capas superiores, conel objetivo de conseguir un ncleo reducido del sistemaoperativo, un microncleo o microkernel. Se trata deimplementar la mayora de las funciones del sistema enprocesos de usuario, lo que descarga al ncleo yaumenta la seguridad del sistema. Se implementa unmodelo cliente/servidor para la resolucin de lasllamadas al sistema. As, si un proceso de usuario

3(proceso cliente) desea leer un bloque de archivo, envauna solicitud a un proceso servidor que realiza la tarea y

devuelve la respuesta. El ncleo slo se encarga de lacomunicacin entre cliente y servidor.Figura 2-4 Estructura Cliente/Servidor de un sistemaoperativo.

El modelo cliente/servidor es tambin muy utilizado enel diseo de los nuevos sistemas operativos distribuidos,ya que los mensajes que se envan entre procesospueden ser locales o remotos, pero la abstraccin para elcliente es la misma, pues l no conoce el tipo dellamada, slo sabe que enva una solicitud y recibe unrespuesta.

Concepto de Proceso

El concepto central de todo sistema operativo es elproceso: abstraccin de un programa en ejecucin.Todo lo dems se organiza en relacin a este concepto.

Los ordenadores modernos realizan varias tareas almismo tiempo. Por ejemplo, mientras se ejecuta unprograma de usuario, el ordenador puede estar leyendodel disco e imprimiendo un documento en la impresora.En un sistema de multiprogramacin, la CPU alterna deun programa a otro, ejecutando cada uno durantemilisegundos, y conmutando a otro inmediatamente, detal forma que al usuario se le proporciona ciertasensacin de ejecucin paralela, como si el ordenadorrealizase varias tareas al mismo tiempo. Aunque,estrictamente, la CPU ejecuta en un determinadoinstante un solo programa, durante un segundo puedehaber trabajado con varios de ellos, dando unaapariencia de paralelismo. Es en estos casos cuando setiende a hablar de seudoparalelismo, indicando la rpidaconmutacin entre los programas en la CPU,distinguindolo del paralelismo real de hardware, dondese realizan clculos en la CPU a la vez que operan losdispositivos de E/S. Ya que es complicado controlar lasdistintas actividades paralelas, los diseadores desistemas emplean el modelo de procesos para facilitar lautilizacin del paralelismo.

Segn este modelo, todo el software de la computadorase organiza en procesos secuenciales, o simplementeprocesos. Un proceso es un programa en ejecucin,incluyendo los valores del contador de programa (PC),registros y variables del programa. Conceptualmente,cada proceso tiene su propia CPU virtual. En realidad,lo que sucede es que la CPU fsica alterna entre losdistintos procesos. Esta alternancia rpida es lo que sellama multiprogramacin.

Si la CPU conmuta entre procesos, no es probable queun proceso que se vuelva ejecutar lo haga en las mismascondiciones en que lo hizo anteriormente. Por lo tanto,los procesos no se pueden programar con hiptesisimplcitas a cerca del tiempo. El resultado de un procesodebe ser independiente de la velocidad de clculo y delentorno en que se encuentre, de tal forma que seareproducible.

La diferencia entre proceso y programa es sutil, perocrucial. El programa es el algoritmo expresado en unadeterminada notacin, mientras que el proceso es laactividad, que tiene un programa, entrada, salida yestado. Una CPU puede compartirse entre variosprocesos empleando un algoritmo de planificacin, quedetermina cuando se debe detener un proceso enejecucin para dar servicio a otro distinto.

Normalmente los sistemas operativos modernosdiseados con una filosofa de kernel, y que emplean elconcepto de proceso, ofrecen alguna forma de crear ydestruir los procesos dinmicamente. En UNIX lacreacin de procesos se realiza mediante la llamada alsistema fork, la cual crea una copia idntica del procesoque hace la llamada (proceso padre), tras la cual elproceso hijo sigue su ejecucin en paralelo con elproceso padre. El padre puede crear nuevos hijos, aligual que el propio hijo, que puede crear nuevos hijosconvirtindose en padre en relacin a ellos. Se estableceas una relacin jerrquica de dependencia padre-hijo(rbol de procesos).

Cada proceso es una entidad independiente, con sucontador de programa y su estado interno. Los 3estados bsicos en que puede encontrarse un procesoson:

1) En ejecucin (RUNNING): El proceso estutilizando la CPU en el instante dado.

2) Listo (READY): El programa est en condicin deser ejecutado (pasar al estado En Ejecucin) pero no loest ya que se est ejecutando otro procesotemporalmente en la CPU.

3) Bloqueado (SUSPEND): El proceso no se puedeejecutar ya que se encuentra a la espera de un evento

externo, incluso aunque la CPU se encuentre libre.Figura 2-5. Estados bsicos de un proceso.

En el modelo de procesos conviven procesos de usuariocon procesos del sistema. La parte del sistema operativoencarga de realizar la conmutacin entre procesos, y deesta forma repartir la utilizacin de la CPU, es elplanificador, el cual tiene una enorme importancia en elfuncionamiento ptimo del sistema.

El modelo de procesos se implementa en el sistemaoperativo mediante una tabla de procesos, con unaentrada por cada proceso. Cada entrada contieneinformacin sobre el estado del proceso, el contador deprograma (PC), el puntero de pila (SP), la asignacin dememoria, el estado de los archivos abiertos, informacincontable, informacin sobre la planificacin del proceso,y otros datos a conservar al producirse el cambio decontexto de proceso. En general son datos sobre laadministracin del proceso, la administracin dememoria y la administracin de archivos.

4A continuacin se presentan los campos ms habitualesque suelen encontrarse en la tabla de procesos en elncleo de un sistema operativo ([BAC86] y [TAN93]):

La ilusin de varios procesos ejecutndoseconcurrentemente en una sola CPU con variosdispositivos de E/S se realiza de la siguiente forma:

Cada clase de dispositivo (discos duros, discos flexibles,reloj, terminal) tiene asociado una zona de memoria quese llama vector de interrupcin, la cual contiene ladireccin del procedimiento de servicio de lainterrupcin. Cuando se produce una interrupcin, elcontador de programa y la palabra de estado del procesoactual en ejecucin son enviados a la pila por elhardware de la interrupcin. Entonces, la mquina saltaa la direccin indicada en el vector de interrupcincorrespondiente. Esto es lo que realiza el hardware.

El procedimiento de servicio de la interrupcin guardalos registros en la entrada de la tabla de procesoscorrespondiente al proceso activo, se elimina lainformacin depositada por el hardware en la pila y sellama a la rutina que procesa la interrupcin.

- Despus se debe encontrar el proceso que inici lasolicitud y que estar a la espera de la interrupcin.Normalmente dicho proceso estar en estado debloqueado, por lo que debe ser despertado, para lo cualse pasa al estado listo, y a continuacin se llama alplanificador.

- El planificador se encargar de decidir qu procesopasa a ejecutarse a continuacin segn el algoritmo deplanificacin implementado.

- Se inicia el proceso activo seleccionado por elplanificador.

Estas acciones se realizan constantemente en el sistema,as pues, se debe intentar optimizar al mximo y reducirel tiempo empleado en esta tarea. Otras veces el cambiode proceso activo se debe a una interrupcin temporal,ya que normalmente un proceso activo tiene unquantum de tiempo asignado, de tal forma que trashaber consumido ese tiempo de ejecucin, el proceso esdesalojado de forma similar a la explicada para elmanejo de una interrupcin. En realidad, lo que seproduce es una interrupcin del reloj (que es peridica).

Al proceso explicado se le suele llamar cambio decontexto o context-switch, ya que lo que en realidadocurre es que se pasa de ejecutar un proceso a ejecutarotro, todo de una forma transparente y rpida.

Paralelismo y concurrencia

Parece claro que a pesar de los avances tecnolgicosconseguidos en los ltimos aos, la tecnologa del silicioest llegando a su lmite. Si se quieren resolverproblemas ms complejos y de mayores dimensiones sedeben buscar nuevas alternativas tecnolgicas. Una deestas alternativas en desarrollo es el paralelismo.Mediante el paralelismo se pretende conseguir ladistribucin del trabajo entre las diversas CPUdisponibles en el sistema de forma que realicen el

trabajo simultneamente, con el objetivo de aumentarconsiderablemente el rendimiento total.Para que dos programas se puedan ejecutar en paralelose deben verificar ciertas condiciones, que se presentana continuacin:

- Sea Ii el conjunto de todas las variables de entradanecesarias para ejecutar el proceso Pi.- Sea Oi el conjunto de todas las variables de salidageneradas por el proceso Pi.Las condiciones de Bernstein para dos procesos P1 y P2son las siguientes:

1. I1 O2 = 2. I2 O1 = 3. O1 O2 =

Si se cumplen las tres condiciones entonces se dice queP1 y P2 pueden ser ejecutados en paralelo y se denotacomo P1 || P2. Esta relacin de paralelismo esconmutativa (P1 || P2 ==> P2 || P1) pero no estransitiva (P1 || P2 y P2 || P3 =/=> P1 || P3).

Las condiciones de Bernstein aunque definidas paraprocesos son extrapolables al nivel de instrucciones.

Para conseguir un buen nivel de paralelismo esnecesario que el hardware y el software se diseenconjuntamente.

Existen dos visiones del paralelismo:

- Paralelismo hardware: Es el paralelismo definido por laarquitectura de la mquina.

- Paralelismo software: Es el paralelismo definido por laestructura del programa. Se manifiesta en lasinstrucciones que no tienen interdependencias.

El paralelismo se presenta, a su vez, en dos formas:

- Paralelismo de control: Se pueden realizar dos o msoperaciones simultneamente. Se presenta en lospipelines y las mltiples unidades funcionales. Elprograma no necesita preocuparse de este paralelismo,pues se realiza a nivel hardware.

- Paralelismo de datos: Una misma operacin se puederealizar sobre varios elementos simultneamente.

En relacin al paralelismo hardware, Michael Flynnrealiz la siguiente clasificacin de arquitecturas decomputadores:

SISD (Single Instruction stream over a Single Data stream): Esla arquitectura de las mquinas secuencialesconvencionales de un slo procesador.

SIMD (Single Instruction stream over a Multiple Data stream):Es la arquitectura de las computadoras con hardwarepara proceso vectorial.

MISD (Multiple Instruction stream over a Single Data stream):Es la arquitectura de las computadoras que poseen unconjunto de procesadores que ejecutan diferentesinstrucciones sobre los mismos datos.

5MIMD (Multiple Instruction stream over a Multiple Datastream): Es la arquitectura ms genrica para loscomputadores paralelos, ya que es aplicable a cualquiertipo de problema, al contrario que las dos anteriores.

Existen ocasiones en las que se confunde el trminoconcurrencia con el trmino paralelismo. Laconcurrencia se refiere a un paralelismo potencial, quepuede o no darse. Existen dos formas de concurrencia:

- Concurrencia implcita: Es la concurrencia interna alprograma, por ejemplo cuando un programa contieneinstrucciones independientes que se pueden realizar enparalelo, o existen operaciones de E/S que se puedenrealizar en paralelo con otros programas en ejecucin.Est relacionada con el paralelismo hardware.

- Concurrencia explcita: Es la concurrencia que existecuando el comportamiento concurrente es especificadopor el diseador del programa. Est relacionada con elparalelismo software.

Es habitual encontrar en la bibliografa el trmino deprograma concurrente en el mismo contexto que el deprograma paralelo o distribuido. Existen diferenciassutiles entre estos conceptos:

- Programa concurrente: Es aqul que define acciones quepueden realizarse simultneamente.

- Programa paralelo: Es un programa concurrentediseado para su ejecucin en un hardware paralelo.

- Programa distribuido: Es un programa paralelo diseadopara su ejecucin en una red de procesadoresautnomos que no comparten la memoria.

El trmino concurrente es aplicable a cualquierprograma que presente un comportamiento paraleloactual o potencial. En cambio el trmino paralelo odistribuido es aplicable a aquel programa diseado parasu ejecucin en un entorno especfico.

Cuando se emplea un solo procesador para la ejecucinde programas concurrentes se habla depseudoparalelismo.

Programacin concurrente es el nombre dado a lasnotaciones y tcnicas empleadas para expresar elparalelismo potencial y para resolver los problemas decomunicacin y sincronizacin resultantes. Laprogramacin concurrente proporciona una abstraccinsobre la que estudiar el paralelismo sin tener en cuentalos detalles de implementacin. Esta abstraccin hademostrado ser muy til en la escritura de programasclaros y correctos empleando las facilidades de loslenguajes de programacin modernos.

El problema bsico en la escritura de un programaconcurrente es identificar qu actividades puedenrealizarse concurrentemente. Adems la programacinconcurrente es mucho ms difcil que la programacinsecuencial clsica por la dificultad de asegurar que elprograma concurrente es correcto.

Caractersticas de la concurrencia

Los procesos concurrentes tienen las siguientescaractersticas [BEN82]:

Indeterminismo: Las acciones que se especifican en unprograma secuencial tienen un orden total, pero en unprograma concurrente el orden es parcial, ya que existeuna incertidumbre sobre el orden exacto de ocurrenciade ciertos sucesos, esto es, existe un indeterminismo enla ejecucin. De esta forma si se ejecuta un programaconcurrente varias veces puede producir resultadosdiferentes partiendo de los mismos datos.

Interaccin entre procesos: Los programas concurrentesimplican interaccin entre los distintos procesos que loscomponen:

- Los procesos que comparten recursos y compiten porel acceso a los mismos.

- Los procesos que se comunican entre s paraintercambiar datos.

En ambas situaciones se necesita que los procesossincronicen su ejecucin, para evitar conflictos oestablecer contacto para el intercambio de datos. Lainteraccin entre procesos se logra mediante variablescompartidas o bien mediante el paso de mensajes.Adems la interaccin puede ser explcita, si aparece enla descripcin del programa, o implcita, si aparecedurante la ejecucin del programa.

Gestin de recursos: Los recursos compartidos necesitanuna gestin especial. Un proceso que desee utilizar unrecurso compartido debe solicitar dicho recurso, esperara adquirirlo, utilizarlo y despus liberarlo. Si el procesosolicita el recurso pero no puede adquirirlo en esemomento, es suspendido hasta que el recurso estdisponible. La gestin de recursos compartidos esproblemtica y se debe realizar de tal forma que seeviten situaciones de retraso indefinido (esperaindefinidamente por un recurso) y de deadlock (bloqueoindefinido o abrazo mortal).

Comunicacin: La comunicacin entre procesos puede sersncrona, cuando los procesos necesitan sincronizarsepara intercambiar los datos, o asncrona, cuando unproceso que suministra los datos no necesita esperar aque el proceso receptor los recoja, ya que los deja en unbuffer de comunicacin temporal.Problemas de la concurrencia.

Los programas concurrentes a diferencia de losprogramas secuenciales tienen una serie de problemasmuy particulares derivados de las caractersticas de laconcurrencia:

Violacin de la exclusin mutua: En ocasiones ciertasacciones que se realizan en un programa concurrente noproporcionan los resultados deseados. Esto se debe aque existe una parte del programa donde se realizandichas acciones que constituye una regin crtica, esdecir, es una parte del programa en la que se debegarantizar que si un proceso accede a la misma, ningnotro podr acceder. Se necesita pues garantizar laexclusin mutua.

6Bloqueo mutuo o Deadlock: Un proceso se encuentra enestado de deadlock si est esperando por un suceso queno ocurrir nunca. Se puede producir en lacomunicacin de procesos y ms frecuentemente en lagestin de recursos. Existen cuatro condicionesnecesarias para que se pueda producir deadlock:

Los procesos necesitan acceso exclusivo a los recursos.Los procesos necesitan mantener ciertos recursosexclusivos mientras esperan por otros.Los recursos no se pueden obtener de los procesos queestn a la espera.Existe una cadena circular de procesos en la cual cadaproceso posee uno o ms de los recursos que necesita elsiguiente proceso en la cadena.

Retraso indefinido o starvation: Un proceso se encuentra enstarvation si es retrasado indefinidamente esperando unsuceso que puede no ocurrir nunca. Esta situacin sepuede producir si la gestin de recursos emplea unalgoritmo en el que no se tenga en cuenta el tiempo deespera del proceso.

Injusticia o unfairness: Se pueden dar situaciones en las queexista cierta injusticia en relacin con la evolucin de unproceso. Se deben evitar estas situaciones de tal formaque se garantice que un proceso evoluciona y satisfacesus necesidades sucesivas en algn momento.

Espera ocupada: En ocasiones cuando un proceso seencuentra a la espera por un suceso, una forma decomprobar si el suceso se ha producido es verificandocontinuamente si el mismo se ha realizado ya. Estasolucin de espera ocupada es muy poco efectiva,porque desperdicia tiempo de procesamiento, y se debeevitar. La solucin ideal es suspender el proceso ycontinuar cuando se haya cumplido la condicin deespera.

Comunicacin entre Procesos

En muchas ocasiones es necesario que dos procesos secomuniquen entre s, o bien sincronicen su ejecucin detal forma que uno espere por el otro. La comunicacinentre procesos se denota como IPC (InterProcessCommunication).

A veces los procesos comparten un espacio dealmacenamiento comn (un fichero, una zona dememoria, etc.) en la que cada uno puede leer o escribir.Los problemas surgen cuando el acceso a dicha zona noest organizado, sino que es ms o menos aleatorio oms bien dependiente de las condiciones de la mquina.A estas situaciones se las denomina condiciones decompetencia. Se deben solucionar las condiciones decompetencia, esto es, garantizar que slo accede unproceso al mismo tiempo a la zona compartida. Elobjetivo es garantizar la exclusin mutua, una forma degarantizar que si un proceso utiliza una variable, archivocompartido o cualquier otro objeto compartido, losdems procesos no pueden utilizarlo.

Otra forma ms abstracta de plantear el problema espensar que normalmente un proceso realiza su tareaindependientemente, pero a veces necesita acceder a unaserie de recursos compartidos con otros procesos o biendebe llevar a cabo acciones crticas que pueden llevar aconflictos. A esta parte del programa se la llama seccin

crtica. Se debe evitar, pues, que dos procesos seencuentren en su seccin crtica al mismo tiempo.

La condicin de la exclusin mutua, no es suficientepara evitar todos los conflictos que se pueden producirentre procesos paralelos que cooperan y emplean datoscompartidos. Existen cuatro condiciones que se debencumplir para obtener una buena solucin:

Garantizar la exclusin mutua: Dos procesos no debenencontrarse al mismo tiempo en su seccin crtica.

Indeterminacin: No se deben hacer hiptesis a cerca de lavelocidad o el nmero de procesadores, durante laejecucin de los procesos.Ninguno de los procesos que se encuentran fuera de suseccin crtica puede bloquear a otros procesos.

Evitar el retraso indefinido: Ningn proceso debe esperareternamente a entrar en su regin crtica.Existen varias soluciones para garantizar estosprincipios. As para garantizar la exclusin mutuatenemos las siguientes opciones:

Desactivar las interrupciones: Consiste en desactivar todaslas interrupciones del proceso antes de entrar a la regincrtica, con lo que se evita su desalojo de la CPU, yvolverlas activar a la salida de la seccin crtica. Estasolucin no es buena, pues la desactivacin de lasinterrupciones deja a todo el sistema en manos de lavoluntad del proceso de usuario, sin que exista garantade reactivacin de las interrupciones.

Emplear variables de cerradura: Consiste en poner unavariable compartida, una cerradura, a 1 cuando se va aentrar en la regin crtica, y devolverla al valor 0 a lasalida. Esta solucin en s misma no es vlida porque lapropia cerradura es una variable crtica. La cerradurapuede estar a 0 y ser comprobada por un proceso A,ste ser suspendido, mientras un proceso B chequea lacerradura, la pone a 1 y puede entrar a su regin crtica;a continuacin A la pone a 1 tambin, y tanto A como Bse pueden encontrar en su seccin crtica al mismotiempo. Existen muchos intentos de solucin a esteproblema:

- El algoritmo de Dekker

- El algoritmo de Peterson

- La instruccin hardware TSL : Test & Set Lock.

Las soluciones de Dekker, Peterson y TSL son correctaspero emplean espera ocupada. Bsicamente lo querealizan es que cuando un proceso desea entrar en suseccin crtica comprueba si est permitida la entrada ono. Si no est permitida, el proceso se queda en un buclede espera hasta que se consigue el permiso de acceso.Esto produce un gran desperdicio de tiempo de CPU,pero pueden aparecer otros problema como la esperaindefinida.

Una solucin ms adecuada es la de bloquear o dormirel proceso (SLEEP) cuando est a la espera de undeterminado evento, y despertarlo (WAKEUP) cuandose produce dicho evento. Esta idea es la que emplean lassiguientes soluciones:

7Semforos: Esta solucin fue propuesta por Dijkstra[DIJ65]. Un semforo es una variable contador quecontrola la entrada a la regin crtica. Las operaciones P(o WAIT) y V (o SIGNAL) controlan, respectivamente,la entrada y salida de la regin crtica. Cuando unproceso desea acceder a su seccin crtica realiza unWAIT(var_semaf). Lo que hace esta llamada es, sivar_semaf == 0 entonces el proceso se bloquea, sinovar_semaf = var_semaf -1. Al finalizar su regin crtica,libera el acceso con SIGNAL(var_semaf), que realizavar_semaf = var_semaf + 1. Las acciones se realizan deforma atmica, de tal forma que mientras se realiza laoperacin P o V ningn otro proceso puede acceder alsemforo. Son el mecanismo ms empleado pararesolver la exclusin mutua, pero son restrictivos y nototalmente seguros (depende de su implementacin),aunque son empleados en ocasiones para implementarotros mtodos de sincronizacin.

Regiones crticas condicionales: Esta solucin fuepropuesta por Hoare [HOA74] y Brinch Hansen[BRI75] como mejora de los semforos. Consiste endefinir las variables de una regin crtica como recursoscon un nombre, de esta forma la seccin crtica seprecede con el nombre del recurso que se necesita yopcionalmente una condicin que se debe cumplir paraacceder a la misma. Es un buen mecanismo, pero nosuele ser soportado por la mayora de los lenguajes deprogramacin.

Monitores: Esta solucin tambin fue propuesta porBrinch Hansen [BRI75] y Hoare [HOA74]. Un monitores un conjunto de procedimientos, variables yestructuras de datos que se agrupan en un determinadomdulo. Los procesos pueden llamar a losprocedimientos del monitor cuando lo deseen pararealizar las operaciones sobre los datos compartidos,pero no pueden acceder directamente a las estructurasde datos internas del monitor. Su principal propiedadpara conseguir la exclusin mutua es que slo unproceso puede estar activo en un monitor en cadamomento.

Paso de mensajes o transferencia de mensajes: Es sinduda, el modelo ms empleado para la comunicacinentre procesos. Para la comunicacin se emplean lasprimitivas SEND (para enviar un mensaje) y RECEIVE(para poner al proceso a la espera de un mensaje). Suventaja es que se puede emplear para la sincronizacinde procesos en sistemas distribuidos. La comunicacinpuede ser sncrona o asncrona. Empleando mensajes sepueden implementar semforos o monitores, yviceversa.

En los sistemas operativos tradicionales al crear unnuevo proceso (llamada fork en UNIX), lo que enrealidad suele hacer el sistema es realizar una copiaexacta del padre en el hijo (operacin de clonacin).Tenemos, entonces, dos procesos iguales.

La ineficiencia aparece cuando el proceso padre es de untamao considerable, y el proceso hijo slo se crea pararealizar una pequea tarea y despus finalizar suejecucin, ya que es necesario volcar todo el contenidodel proceso padre en el proceso hijo. Adems, comopadre e hijo son dos procesos totalmenteindependientes (salvo esa relacin padre-hijo), sucomunicacin o comparticin de datos es complicada ypoco eficiente. Por ltimo, cuando se produce el cambio

de contexto entre padre e hijo, la mayora de los datosno cambian, con lo que otro tipo de gestin podraoptimizar este tipo concreto de cambio de contexto.Los hilos se emplean, en parte, para resolver y optimizareste tipo de situaciones.