Manual de Programación en OS/2 - Comunicación entre procesos

El primer procedimiento para intercambiar datos consiste en combinar un bloque de memoria compartida con un semáforo que se encargue de evitar que ambos procesos accedan a la vez al bloque. Cuando uno quiere leer o grabar datos, borra el semáforo, accede, y lo libera (post). Si ya estaba ocupado el bloque, el proceso es detenido hasta que el semáforo se libera. Todo lo necesario para trabajar con esto ya se ha visto en las páginas anteriores.

Cauces

Otra manera de intercambiar información son los cauces (pipes). En OS/2 existen dos tipos: con nombre (named pipes) y sin nombre (unnamed pipes).

Los cauces son vistos por el programador como un fichero más, en el que, o bien puede leer, o bien escribir. La cuestión es que un extremo pertenece a un thread y el otro a otro distinto, y si uno de ellos escribe en ese fichero (recordemos que el sistema de archivos de OS/2, al igual que el de cualquier otro S.O., consigue que no sepamos diferenciar cuando trabajamos con un fichero de disco, con un cauce, o con la pantalla), cuando el otro lea, encontrará los datos grabados. Podríamos definirlo como una tubería (la cual es otra de las traducciones que he encontrado en algunos libros) que conecta los dos threads, y que se maneja con las mismas ordenes que el sistema de ficheros: DosRead, DosWrite y DosClose.

Cuando creamos una unnamed pipe, el sistema nos devuelve dos handles o indicativos: uno para lectura y otro para escritura. El thread que creó el cauce debe quedarse con uno, y enviar el otro al otro thread. Para ello puede usar un pequeño bloque de memoria compartida, definiendo claramente como acceder a ella. Dado que los demás threads van a acceder solo en lectura, no haría falta incluir un semáforo.

Los cauces tienen una opción muy interesante (y útil), que consiste en la posibilidad de duplicar handles. Usando la llamada DosDupHandle, se pueden crear dos handles para un mismo cauce. Lo interesante es que se puede dar no solo el siguiente número libre, sino el que se quiera. Haciendo esto, se puede asignar a un cauce el valor 0 y a otro el 1, y redirigir así la entrada y salida estandar (STDIN y STDOUT) del programa en curso. Esto es precisamente lo que hace el interprete de comandos de OS/2 para hacer la redirección desde la línea de comandos.



En las versiones 1.x de OS/2 solo existian estos cauces; sin embargo, su potencia quedaba ligeramente oscurecida por el hecho de tener que usar memoria compartida para pasar un handle al otro thread. Para evitarlo, se añadieron en OS/2 2.0 y superiores las named pipes, o cauces con nombre (denominación horrible a mas no poder. Espero sugerencias para una posible traducción). En estos, al crearlos se les asigna un nombre del tipo \PIPE\un_nombre. Dentro de un_nombre puede ir cualquier cadena. Ejemplos válidos son \PIPE\EJEMPLO, \PIPE\CURSO\OS2\EJEMPLO_DE_PIPE. Cuando un thread cualquiera quiere acceder a ese cauce, solo tiene que referirse a él por dicho indicativo. Esto resulta mucho más cómodo, pues basta con fijar durante la programación el nombre que se le va a dar, y no hace falta pasarlo de forma dinámica en cada ejecución. Sin embargo, además de crearlo, es necesario que el proceso servidor lo haga disponible a los clientes.



Para que un cliente acceda a una named pipe, tiene que usar DosOpen, usando como nombre de fichero el nombre de la pipe. El segundo parámetro es un puntero a una variable de tipo HPIPE, que contendrá un handle que podremos usar con DosRead, DosWrite y DosClose para manejar la pipe. El tercer parámetro contendrá un puntero a un ULONG, en el cual se almacenará la causa por la que no se ha podido abrir la pipe (es mejor usar los códigos de error que se devuelven de la forma normal en vez de éste valor). El cuarto parámetro contiene la longitud del buffer que se reservará. Es conveniente que tenga un tamaño más bien grande. El resto de parámetros son particularizaciones para las pipes de los parámetro normales de DosOpen.

Se debe tener cuidado al definir las named pipes. Hay que tener en cuenta que el servidor tiene ciertos privilegios que el cliente no tiene, como por ejemplo disponer de un semáforo que le indique cuando hay datos en el cauce. Un cliente tendría que hacer una espera activa en el caso de querer estar siempre disponible a través de ese cauce. Por otro lado, cualquier cliente se puede conectar a una pipe, por lo que el servidor no puede saber (en principio) quien le está reclamando el servicio. Al revés sí ocurre, pues todo cliente sabe quien es el servidor de un cauce determinado por el nombre de éste.



Un detalle importante es que las unnamed pipes son unidireccionales. Esto es, si se quiere intercambiar datos en ambos sentidos, son necesarios dos cauces, no se puede usar el mismo. El sentido de la comunicación lo decide el que cree el cauce, al enviar uno u otro handle. En el caso de named pipes, por el contrario, el creador puede determinar si la comunicación va del servidor al cliente, al revés, o en ambos sentidos.

Colas

Los cauces no siempre son la solución ideal. En muchos casos necesitamos poder tratar elementos separados en vez de una secuencia de bytes, y además puede ser necesario que se organicen de forma distinta a la clásica FIFO (First In First Out, el primero en entrar es el primero en salir). Incluso puede ser necesario eliminar elementos antes de que los lean los destinatarios. Para esto se crearon las colas.

Una cola es similar a un cauce con nombre (named pipe), pero en vez de escribirse bytes en ella, se escriben secuencias de longitud variable que son tratadas como elementos independientes. Por ejemplo, si en un cauce introduzco la secuencia Esto es una prueba, puedo leer solo la primera letra, o las dos primeras, o unas cuantas, pero la frase será tratada como un conjunto de elementos separados. En una cola, sin embargo, sería tratada siempre como un solo elemento. Cuando el proceso lee de la cola, leerá la frase completa, y no podrá leer solo un trozo, o incluso pegarlo a otro elemento introducido depués.

Por otro lado, la ordenación de los elementos en las colas es definible por el usuario. Así, puede ser FIFO (First In First Out, el primero en entrar es el primero en salir), LIFO (Last In First Out, el último en entrar es el primero en salir), o bien por prioridades. Un ejemplo del primer tipo de colas sería una cola de un cine: el primer espectador que llega será el primero en obtener la entrada, y así sucesivamente. Un ejemplo del segundo tipo de colas sería una pila de revistas. Cuando pongo una nueva, la añado en la cima, y cuando cojo una, cojo la que está arriba de todo: la última en llegar es la primera en salir. Por último, un ejemplo de una cola con prioridad podría ser una recepción oficial. No importa el orden en que lleguen los dignatarios; estos siempre saldrán en orden descendente de rangos: primero el presidente invitado, luego el del país, luego ministros, etc. Y si mientras salen, llega algún rezagado, todos los de rango inferior le cederán su sitio.

Las colas se denominan, como viene siendo habitual, con un nombre propio, que es de la forma \QUEUES\nombre_de_la_cola, con nombre_de_la_cola un nombre que la define.

Dado que las colas no trabajan con secuencias de bytes individuales sino con mensajes discretos, no usan las llamadas del sistema de archivos, sino que disponen de su propio conjunto de instrucciones para leer y escribir en ellas.



Solo el proceso que crea la cola tiene la capacidad de eliminarla o de purgar (borrar) sus elementos, así como de leer de ella; sin embargo, cualquier otro proceso puede tener acceso a ella en el sentido de escribir. Aún más interesante resulta el hecho de que es posible saltarse el orden normal de la cola y leer un elemento situado en una posición concreta. Así mismo, es posible hacer una lectura síncrona, en la cual se espera hasta que aparezca un elemento (si no habia ninguno) o bien una lectura asíncrona, usando un semáforo, en la cual se pueden seguir haciendo operaciones y resincronizar cuando se desee, de forma similar a los temporizadores. Sin embargo, hay algunas restricciones en este caso: el semáforo debe ser abierto por todos los procesos que llaman a DosWriteQueue para añadir un elemento a la cola.

También es posible buscar en la cola un elemento concreto y examinarlo, pero sin eliminarlo de la cola. Además podemos saber el número de elementos que contiene la cola.



El trabajo con colas es distinto que con los cauces. En los primeros, definimos una ristra de bytes que deben ser enviados a los procesos. Aquí, sin embargo, nos limitamos a enviar un puntero, el cual será el que le llegue a los demás en el orden adecuado. Los datos a enviar son almacenados en zonas de memoria compartidas.

Para verlo más claro, veamos como haríamos para enviar varios mensajes a través de una cola:

• En primer lugar, necesitamos definir una serie de bloques de memoria compartidos, dando acceso a ellos al proceso dueño de la cola, si es necesario.
• En segundo lugar, almacenamos el primer mensaje en uno de los bloques, y lo escribimos en la cola dando como puntero del mensaje el que apunta a dicho bloque.
• El proceso dueño, cuando reciba el mensaje de la cola, recibirá únicamente el puntero a éste, accediendo realmente en el bloque de memoria compartida.
• Cuando se ha terminado con la cola, se libera ésta y los bloques de memoria compartida.

Vemos, por tanto, que la cola no transmite realmente los mensajes, sino simplemente el orden en que se debe acceder a ellos, pues estos están siempre accesibles a todos los procesos por estar en memoria compartida.

Dado que la asignación de bloques de memoria es un proceso relativamente lento, la mejor solución consiste en subasignar bloques de memoria, uno para cada mensaje, dentro de un bloque mayor de memoria compartida.