108 Capitulo 4 Procesos + Unilo de nticleo s6to tiene una estructura de datos y una pila. La conmutacion centre hilos del nticleo no requiere modificar informaci6n de acceso a la memoria, y por ende es relativamente répida, + Un LWP contiene un bloque de control de proceso con datos de registros, informa~ ign de contabilidad e informacién de memoria. Por consiguiente, la conmutacién entre LWP requiere un trabajo apreciable y es relativamente lenta, ‘* Unhilo en el nivel de usuario slo necesita una pila y un contador de programa: no requiere recursos del niicleo. EI néicleo no interviene en la planificacién de e tos hilos; por tanto, la conmutacion entze ellos es répida, Podria haber miles de estos hilos en el nivel de usuario, pero lo tnico que el nticleo ve son los LWP del proceso que apoyan esos hilos. 4.6 = Comunicaci6n entre procesos regen (Gar susladeiones. La mejor forma de proveer la comunicacién entre procesos es ‘mediante un sistema de mensajes. Hay muchas formas diferentes de definir [os sis- temas de mensajes. Estos sistemas también tienen otras ventajas, como se vers en el capitulo 16. CCabe sefialar que los esquemas de comunicacién por memoria compartida y por transferencia de mensajes no son mutuamente exclusivos, y podrian utilizarse si- multéneamente dentro de un mismo sistema operative © incluso dentro de un ‘mismo proceso, 4.6.1 Estructura basica Los mensajes que un proceso envia pueden ser de tamaio fijo 0 variable. Si sélo es posible enviar mensajes de tamaito fijo, la implementacién fisica es sencilla. Sin embargo, esta restriccién dificulta la tarea de programacién. Por otro lado, los men- sajes de tamafo variable requieren una implementacién fisica més. compleja, aunque simplifican la tarea de programacién, 46 Comunicacin entre procesos 109 Silos procesos Py Q quieren comunicars,deberén envarse menses para ello debe exist un enlace de comuniccin entre ellos Este enlace se puede tnghoneng de diversas maneras, Agu no nos interes implementacn ies delle ae poli sermon comport urbe de ara ou gue vee EGpfle 15) sino ls problemas desu implementacin gis, ae dein, como ous propia des lgicas, Las sigulentes son algunas pregunlan bases ue debon eee para nimplementacion + Como se establecen fs enlaces? + [Un enlace puede estar asocaco a mis de dos proceso? + [Cudntos enlaces puede haber entre cada par de procesos? * {Que capa tee un enlace? Es dei el eae tne eps de uf? De + Que tomato tienen los mensajes? cE enlace puede dar cabida a mensajes deta mato variable o6lo de tamano fo? hbamensis de + enlace es unidirecional bidireccional? Es decir si existe un enlace entre Py & clos menses pueden ur sso en un cteaion liga sods PQ) en ‘Ademas ay varios métodos para implementarlogleamente un enlace y las ope- raciones de enviar/recibir: : , : En el resto de la seccién, examinaremos més a fondo estos tipos de sistemas de mensajes. 4.6.2 Asignaci6n de nombres Los procesos que desean comunicarse deben tener una forma de referirse unos a otros. Se puede usar comunicacisn directa © comunicacién indirecta, como veremos en las dos subsecciones siguientes,110 Capitulo 4 Procesos 4.6.2.1 Comunicacién directa En a disciplina de comunicacién directa, cada proceso que desea comunicarse de ‘he nombrar explicitamente el destinatario o el remitente de ta comunicacién, ‘este esquema, se definen las primitivas enviar y recibir como sigue: cenviar(P, mensaje). Enviar un mensaje al proceso P. (Q, mensaje). Recibir un mensaje del proceso Q. Un enlace de comunicacién en este esquema tiene las propiedades siguientes: + Se establece automsticamente un enlace entre cada par de procesos que desean comunicarse. Los procesos s6lo necesitan conocer la identidad del otro para co- *+ Un enlace se asocia a exactamente dos proceso. + Entre cada par de procesos s6lo existe un enlace. + Elenlace puede ser unidireccional, pero suele ser bidireccional Como ilustracién, presentaremos una solucién al problema de productores y consumidores. Para que los procesos productores y consumidores puedan ejecutar- se de forma concurrente, permitimos al productor producir un elemento mientras ‘el consumidor esté consumiendo otro elemento, Cuando el productor termina de generar un elemento, envia ese elemento al consumidor. El consumidor obtiene di- cho clemento por medio de la operacién recibir. Si un elemento todavia no se ha producido, el proceso consumidor debe esperar hasta que se produce. EIPFORESO! productorse define as: repeat producir un elemento en sign enviar(consuomidorssigp); until false; El proceso consumidor se define ast repeat recibir(productorssige); consumir el elemento que est en sige until false; 46 Comunicacion entre procesos 111 Este esquema exhibe una simetria de direccionamiento; es decir, los procesos tan- to emisor como receptor necesitan nombrar al otro para comunicarse. Una variante de este esquema utiliza asimetria de direccionamiento, Sélo el emisor nombra al destinatario; el destinatario no esté obligado a nombrar al emisor. En este esquema, las primitivas enviar y recibir se definen como sigue: + enviar(P, mensaje). Enviar un mensaje al proceso P. + recibirlid, mensaje). Recibir un mensaje de cualquier proceso; se asigna a la varia- ble id el nombre del proceso con el que hubo comuunicacién. La desventaja de ambos esquemas (simétrico y asimétrico) es la limitada modu- laridad de las dlefiniciones de proceso que se obtienen. Para cambiar el nombre de tun proceso podria ser necesario examinar todas las demas definiciones de proce- 808. Hay que hallar todas las referencias al nombre antiguo a fin de poder cambiarlas al nuevo. Esta situacion no es deseable desde el punto de vista de la compilacién separada, 4.6.2.2 Comunicacién indirecta Con Ja comunicacién indirecta, los mensajes se envfan a, y se reciben de, buzones (también llamados puertos), Un buz6rj puede eonsiderarse en abstracto como un ob- jeto en el que los procesos pueden colocar mensajes y del cual se pueden sacar mensajes, Cadalbiliz6ntiene uta identificaciOn tinica. En este esquema, un proceso se puede comunicar con otto a través de varios buzones distintos. (BSI pFOSeS68 ‘puetlen|comunicarse|s6lo'sicomparten lun buz6n. Las primitivas enviar y recibir se definen como sigue: enviar(A, mensaje). Enviar un mensaje al buz6n A, recibir(4, mensaje). Recibir un mensaje del buzén A. En este esquema, un enlace de comunicacién tiene las propiedades siguientes: *+ Seestablece un enlace entre un par de procesos sélo si tienen un buzin compartido, + Unenlace puede estar asociado a mas de dos procesos, * Entre cada par de procesos en comunicacién puede haber varios enlaces distin- tos, cada uno de los cuales corresponderd a un buzén, ‘+ Los enlaces pueden ser unidireccionales o bidireccionales. Supongamos ahora que los procesos P1, P2 y P3 comparten el buz6n A. El proce- so Pl envia un mensaje a A, y P2 y P3 ejecutan cada uno un recibir de A. ;Cudl Proceso recibird el mensaje que P1 envi6? Esta cuestién puede resolverse de varias112 Capitulo 4 Procesos + No permitir que un enlace esté asociado a mas de dos procesos. + No permitir que mas de un proceso ejecute una operacion recibir a la ve7. + Permitir al sistema escoger arbitrariamente cual proceso recibird el mensaje (es decir, P2.0 P3, pero no ambos, recibiré el mensaje). El sistema podria identificar el receptor al emisor UADUAN UCAS EEE Ap ICaAGIGS UN PHREH MCSE. En el primer caso (es decir, si el buzén esté unido a, 0 detinido como parte de, el proceso), SR TO® chtre el propietario (que sélo puede recibir mensajes a través de este buz6n) y el usuario del buzdn (que s6lo puede enviar mensajes al buzén). HAlSstO que cadal BU 26n tiene un propietario tinico, no puede haber confusién respecto a quién debe RelbiPUTEMENcajooNViado=restebuZHN. Cuando un proceso que posee un buzén termina, el buzén desaparece. Cualquier proceso que envie subsecuentemente un mensaje a ese buzGn deberd ser notificado de que el buz6n ya no existe (por medio de manejo de excepciones, que se describe en la secci6n 4.6.4) Hay varias formas de designar el duefio y los usuarios de un buz6n dado, Una posibilidad es permitir que un proceso declare variables de tipo buzén. El proceso que declara un buzén es el dueio de ese buzdn. Cualquier otro proceso que conoz- cael nombre de dicho buzén podra usar. Por otro lado, un buz6n propiedad del sistema operativo tiene existencia propia; es independiente y no esta unido a ningiin proceso especitico. BUSiSteiia OPEraLiNO! cestablece un mecanismo que permite a un proceso: Crear un buz6n nuevo ‘* Enviar y recibir mensajes a través del buzén * Destruir un buzén El proceso que crea un buzén nuevo es, por omisidn, su dueRo. Inicialmente, el due- foes el tinico proceso que puede recibir mensajes a través de este buz6n. Sin ccnbasye. la propiedad y el privilegio de recibir se pueden transferir a otros proce- Sosiporiiiedio de lamadas al sistema apropiadas, Desde luego, esta posibilidad podria dar lugar ala existencia de miiltiples receptores para cada buz6n. Los pro- esos también podrian compartir un buzdn a través del recurso de creacién de procesos. Por ejemplo, si el proceso P crea el buzén A, y luego crea un nueva pro ces0 Q, Py Q podrian compartir el buz6n A. Puesto que todos los procesos con derecho de acceso a un buzén podrian terminar en algiin momento, podria suceder que después de cierto tiempo un buzén va no esté accesible a ningtin proceso. F cs caso, el sistema operativo deberd recuperar el espacio uilizado para el buz6n. tsta tarea podria requerir alguna forma de recoleccin de basura (vase la Sec. 103.5), ‘en [a que ocurre una operacién independiente para buscar y liberar memoria que yano se esté usando. in entre process. 113 4.6.3 Uso de buffers Uneenlace tiene cierta capacidad que determina el mimero de mensajes que pueden residir en él temporalmente. Esta propiedad puede visualizarse como una cola de ‘mensajes unida al enlace. Basicamente, hay tres formas de implementar una cola se- mejante. + Capacidad cero: La cola tiene como longitud maxima 0; el enlace no puede tener mensajes esperando en él, En este caso el emisor deberé esperar hasta que el des- tinatario reciba el mensaje. Los dos procesos deben sincronizarse para que pueda me transferencia de mensaje, Esta sincronizacén se denomina ence (rendezvous). + Capacidad limitada: La cola tiene una longitud finita n; es decir, cuando més n ‘mensajes pueden residir en ella. Sila cola no esté llena cuando se envia un men- saje nuevo, éste se coloca en la cola (se copia el mensaje o bien se mantiene un untero a él) yel emisor puede continuar su ejecucién sin esperar. Sin embargo, el enlace tiene una capacidad finita; si esta leno, el emisor deberd esperar hasta que haya espacio libre en la cola ‘+ Capacidad ilimitada: La cola tiene una longitud potencialmente infinita; en ella puede esperar cualquier cantidad de mensajes. El emisor nunca espera El caso de capacidad cero recibe también el nombre de sistema de mensajes sin buf- forsslos otros casos ofrecer atmacenamiente automatico en buffers. Cabe seftalar que, en los casos de capaciclad coro, UV >ROeSS@ IiGISsi5eisi Si inEn saje legs 0 no a su destino después de llevar a cabo la operacién enviar. Si esta informacién es crucial para el célculo, el emisor deberd comunicarse explicitamente con el receptor para averiguar si este tiltimo recibié el mensaje. Por ey mplo, supe ‘amos que ef proceso P envia un mensaje al proceso Q y sélo puede continuar st ejecucién después de haberse recibido el mensaje. EI proceso P ejecuta la secuencia enviar, mensaje); recibir(Q, mensaje); El proceso Q ejecuta enviar(P, mensaje); recibir(?, “confirmacién”); Se dice que tales procesos se comunican asincrénicament. Fay casos especiales que no dire e i Vy eciales que no encajan directamente en ninguna de las categorias que hemos descrito: * 7114 Capitulo 4 Procesos + Fl proceso que envfa un mensaje nunca espera. Sin embargo, si el receptor no ha recibido el mensaje antes de que el proceso emisor envie otro mensaje, el prime- fOISeIpeRdens La ventaja de este esquema es que no es necesario copiar mds de luna vez los mensajes grandes. La desventaja principal es que la tarea de progra- ‘macién se vuelve més dificil. Uosiproeesosinecesitan sincronizarsetexplicitamente para asegurar que no se pierdan los mensajes y también que el emisor y el recep- tor no manipulen el buffer de mensajes simulténeamente. + Bl proceso que envia un mensaje espera hasta recibir una respuesta, Este esque- iia(seladoptojentelisistemavoperativoytnt, en el que los mensajes fetieh UN tamario fijo (ocho palabras). Un proceso P que-envia un:mensajesse-bioquea-has- ta que el proceso receptor ha recibido el mensaje y ha devuelto una respuesta de ‘ocho palabras empleando la primitiva rply(Pemensa). EI mensaje de respuesta se escribe sobre el buffer del mensaje original. La Gnica diferencia entre las primi- tivas send y reply es que un send hace que el proceso emisor se bloquee, mientras que reply permite que tanto el proceso emisor como el receptor conti- niien de inmediato su ejecucisn. Este método de comunicacién sincrénico puede expandirse facilmente para tener un sistema de llamada a procedimientos remotos (RPC, remote procedure eal) con to das las de la ley. Los sistemas RPC se basan en la percepcién de que una llamada {una subrutina o procedimiento en un sistema monoprocesador acta exacta- ‘mente como un sistema de mensajes en el que el emisor se bloquea hasta que WEEIBSTGRATESPUESTA. E| mensaje es entonces como una llamada a una subrutina, yet mensaje de retorno conten el valor de la subrutina calcula, El siguiente 150 légico es que procesos concurrentes puedan invocarse mutuamente como ibrutinas empleande RFC. De hecho, vemos en cl capitulo 16 que se pueden usar RPC entre procesos que se ejecutan en computadores distintos, con lo cual varios computadores pueden colaborar para beneficio mutuo. 4.6.4 Condiciones de excepcién {Los sistemas de mensajes son ttiles sobre todo en los entomnos distribuidos, donde los procesos podrian residir en diferentes sitios (méquinas). En un entorno asi, la probabilidad de que ocurra un error durante la comunicacién (y el procesamiento) Slfnticho miaVoH qUE(EN Minjentornolde"una/solaimaquina. En este ultimo caso, los mensajes por lo regular se implementan en memoria compartida. Si ocurre una fa- Ila, todo el sistema falla. En un entorno distribuido, en cambio, los mensajes se transfieren por lineas de comunicacidn,y el fallo de un sitio (0 enlace) no causa ne- cesariamente el fallo de todo el sistema, Cuando ocurre un fallo en un sistema, sea centralizado o distribuido, el sistema debe intentar recuperarse del error (manejar la condicién excepcional). Comentare- ‘mos brevemente algunas condiciones excepcionales que un sistema debe manejar ene contexto de un esquema de mensajes. 46 Comunicacisn entre procesos 115, 4.6.4.1 El proceso termina Elemisor o el receptor podria terminar antes de que se procese un mensaje. Esta si- tuacién deja mensajes que nunca se recibirén © procesos esperando mensajes que nunca se enviardn. Aqui consideraremos dos casos |. Un proceso receptor P podria esperar un mensaje de un proceso Q que ya termi- 16. Si no se toman medidas, P se bloqueara eternamente. En este caso, cl sistema podria terminar P, o bien notificar a P que Q terminé. 2. El proceso P podria enviar un mensaje a un proceso Q que ya terminé. Con el.es- quema de colocacién automatica en buffs, no hay problema; P simplemente continuaré su ejecuci6n, Si P necesita saber que Q process su mensaje, debers programar explicitamente una confirmacién. $i no se usan buffers, P se bloques- ra etermamente. Como en el caso 1, el sistema podria terminar P 0 bien avisarle que Q ya termins 4.6.4.2 Mensajes perdidos Un mensaje del proceso P al proceso Q podria perderse en la red de comunicacién, 4 causa de un fallo de hardware o de la linea de comunicaciones. Hay tres métodes bésicos para enfrentar este stcescr 1. El sistema operativo tiene la obligacién de detectar este suceso y retransmit el mensaje. 2. Bl proceso emisor tiene la obligacién de detectar este suceso y retransmi mensaje, si desea hacerlo, 3. Elsistema operativo tiene la obligacién de detectar este suceso; luego avisa al pro- ‘es0 emisor que el mensaje se perdi6. El proceso emisor decide qué quiere hacer. No siempre es necesatio detectar los mensajes perdidos. De hecho, algunos pro- tocolos de red especifican que los mensajes no son confiables, mientras que otros garantizan la contiabilidad (véase el Cap. 15). El usuario debe especificar (esto es, notifcar al sistema, o bien programar este requisito él mismo) que debe realizarse tal deteccién, {Cémo detectamos la pérdida de un mensaje? El método de deteccién mas co- iin es emplear tiempos Iinite o plazos. Cuando se envia un mensaje, siempre se devuelve un mensaje de respuesta para confirmar la recepcién del mensaje. El si. {ema operative © un proceso puede entonces especificar un intervalo de tiempo durante el cual esperaré la llegada del mensaje de acuse de recibo. 51 S@iveRice bate plazo antes cle que llegue la confirmacién, el sistema operativo (0 el proceso) pod suponer que el mensaje se perdi y volverd a enviarlo, Sin embargo, es posible que no se haya perdido el mensaje, y s6lo haya tardado un poco més de lo esperado en viajar por la red. En este caso, podriamos tener mailtiples copias del mismo men-116 Capitulo 4 Procesos Debe haber un mecanismo para distinguir entre los dife- ‘SHEETGPOSTAEUMINSAHES. Este problema se estudiars con mayor detalle en el capitulo 16. 4.6.4.3 Mensajes alterados (por ejemplo, a causa de ruido en el canal de comunicaci6n). Este caso es similar al de tun mensaje perdido. Por lo regular, el sistema operativo retransmitiré el mensaje original. ‘verificacién, paridad v CRC) para detectar este tipo de errores. 4.6.5 Un ejemplo: Mach Como ejamplo de sistema operativo basdo en menses, consieremos ssa Mach, cfeado en la Camegie Mellon University Enitio de Mach apoya la re Cian destrucién de multiples teas que sn silanes a proces pro Henen tnulpes fos de conto. La mayor parte dela comuniaciones en Mach eu ns es tos los Tamas al stoma y foc a transerenci de nfrmacin ete ‘aes eealiza con ene, Los mensajes nvian ay se etben de buzones, que selaman pros en Mach Inco fas lemadas al sistema se efectan por mensajes, Cuando crea una re tambien aeccan dostouzonesespecls burn Kernel el buzan Noi nice utes elbuzén Kernel para cominicarse con l area, y ena notificacones ela ocurrencia de suzesos al puerto Noli. Slo se necesita tes Hamada ls tna paralatrasterenia de mensjes. La llamada meg send envia un mensaje uh hans Tos mensses eeeben por eo de mses, a RPC se eeatan me Santee, que envia un mensaje y espera exactamente un merase de rtorno delemison, La llamada al sistema port_allocie crea un buzéin nuevo yasigna espacio paras cola de mensajes El tamaroindxim por omision ce eta cla es de ocho mensajes La taea que cea el busin esl duefa de ese buz6n. El propietaro tambien tene accede recepcin al buzén, Solovuna trea 3a ver puede ser dueia de un buzsn O rectir dv peo estos derechos se pueden transfert aottas tate si se desea Elburbn tone ua cla de mensaje qu niialmente ets vacia,Conforme se en- win mens al busin, se copan en Todos hs eas teen i mia rived, Mach garntiza que multiples mensajes del mismo emisor se encolarén Boj unrégimen ce prmero que leg, primero que sal (FIFO, fist, ston), pe tone garetiza un erdenamientoabsclito, Por gjempo, ls mensajes enviados por dos enisores se podran encolar en cualquier orden Los menses on sf concisten en una cabecera de longitud fia, seguida de una porcién de datos de longitu variable. La cabecera ince a longitud del mensaje Fidos nombres de buzon, Cuanio se envia un mensaje, Uno de eos nombres es el 4.6 Comunicacién entre procesos 117 del buzén al que se esté enviando el mensaje. Por Io regular, el hilo emisor espera tuna respuesta; el nombre del buz6n del emisor se pasa a la tarea receptora, la cual podré usarlo como “remitento” para devolver mensajes. La parte variable de un mensaje es una lista de elementos de datos con tipo. Ca- da entrada de la lista tiene un tipo, un tamafo y un valor. El tipo de los objetos especificados en el mensaje es importante, ya que se pueden enviar objetos defini- dos por el sistema operative, como derechos de propiedad 0 de acceso para recepcién, estados de tareas y segmentos de memoria. Las operaciones de enviar y recibir en sf son muy flexibles. Por ejemplo, cuando se cenvia un mensaje a un buzén, éste podria estar lleno, $i no es asf, el mensaje se copia en el buz6n y el hilo continta. Si el buzén esté lleno, el hilo emisor tiene cuatro opciones: 1. Esperar indefinidamente hasta que haya espacio en el buz6n. 2. Esperar cuando mas n milisegundos, 3. No esperar; regresar de inmediato. 4, Poner temporaimente el mensaje en caché. Se le puede dar un mensaje al sistema ‘operativo para que lo conserve aunque el buz6n al que se esté enviando esté lle- no. Cuando el mensaje se pueda poner en el buzén, se enviard un mensaje de vuelta al emisor. Cada hilo emisor sélo puede tener un mensaje pendiente envia- do a un buz6n leno, en un momento dado, La tiltima opcién esté diseftada para tareas servidoras como un controlador de im- presora de Iineas. Después de terminar de atender una solicitud, es posible que {ales tareas necesiten enviar una respuesta tinica a la tarea que solicité el servicio, pero también deben continuar con otras solicitudes de servicio, aunque el buzén de respuesta de un cliente estéIleno, La operacién de recibir debe especificar de qué buzén 0 conjunto de buzones se dlesea recibir un mensaje. Un conunto de buzones es una coleccién de buzones, decla rados por la tarea, que se pueden agrupar y tratar como un solo buzén para los fines de la tarea. Los hilos de una tarea solo pueden recibir de un buzén o conjunto de bus zones para el cual esa tarea tenga acceso de recepci6n, La llamada al sistema port_status devuelve el namero de mensajes que hay en un buzdn dado, La opera- cién de recibir intenta recibir de (1) cualquier buzén de un conjunto de buzones, © (2) un buzén especifico (nombrado). Si no hay mensajes esperando ser recibidos, 1 hilo receptor podria esperar, esperar cuando més x milisegundos, 0 no esperar. El sistema Mach se disen especialmente para sistemas distribuidos, que estudia- remos en los capitulos del 15 al 18, pero también es apropiado para sistemas _monoprocesador. El principal problema con los sistemas de mensajes generalmen- te ha sido el bajo desempeno debido a que primero se copia el mensaje del emisor al buz6n, y luego del buz6n al receptor. El sistema de mensajes de Mach trata de evitar las operaciones de doble copiado utilizando técnicas de gestién de memoria virtual (Cap. 9), Basicamente, Mach establece una correspondiencia entre el espacio de direcciones que contiene e! mensaje del emisor y el espacio de direcciones del re- ceptor. El mensaje en sf nunca se copia realmente. Esta técnica de manejo de