BeOSmAn's Blooog

A la hora de desarrollar un sistema operativo, después de haber planificado la gestión de memoria y la gestión de procesos e hilos, le toca el turno a la comunicación entre los distintos procesos, IPC en inglés, imprescindible para el funcionamiento del sistema.

Para la comunicación a bajo nivel (en el kernel) entre hilos existen varias técnicas que se pueden resumir en:

• Memoria compartida: Varios procesos, aunque en espacios de memoria distintos, comparten una zona de la misma donde leen y escriben los datos a compartir. La ventaja es que se pueden compartir grandes cantidades de datos y es un sistema muy rápido y sin problemas para lecturas. En cambio, existe el problema de la sincronización del acceso cuando varios procesos tienen que escribir en la misma zona de memoria simultáneamente.
• Paso de mensajes: Es un sistema donde, mediante canales compartidos entre los procesos, éstos leen y escriben para comunicarse. Se suele implementar mediante sockets, pipas y FIFO‘s aunque hay más tipos de implementación. La ventaja es que las lecturas y escrituras son síncronas por lo que no hay problemas de lectura y escritura simultáneas. El problema es que la cantidad de datos a comunicar puede estar limitada.

El sistema operativo BeOS y su sucesor, Haiku, han implementado una solución muy elegante: por un lado, como los sistemas compatibles con POSIX tiene la compartición de memoria; por otro lado, implementó dos técnicas adicionales:

• El paso de mensajes entre hilos directamente mediante las funciones send_data(...) y receive_data(...) con el inconveniente de que las funciones son síncronas y después de enviar el primer mensaje, hasta que no se lee no se puede enviar otro.
• El paso de mensajes mediante puertos. Los puertos son el homólogo a los sockets pero entre procesos y mucho más rápidos. Existe un elemento común entre dos hilos llamado “puerto” a través del cual los procesos se comunican mediante las funciones write_port(...) y read_port(...). La ventaja de esto es que el puerto puede tener un buffer por lo que, hasta que no se llene, las llamadas a estas funciones son asíncronas.

Con estas dos técnicas, se consigue tanto la comunicación entre procesos como la sincronización entre distintos hilos gracias a que las llamadas a las funciones de lectura y escritura son síncronas.

Debido a que este tipo de comunicación, aunque muy rápida, es bastante complicada de aplicar, sobre todo porque los datos pasados entre los distintos procesos no tienen tipo, son flujos de bytes, se han implementado otras técnicas de comunicación, pero estas a nivel de aplicación, es decir, no es el proceso el que responde, sino la aplicación completa mediante una API dedicada a ello.

Algunos ejemplos de estas implementaciones son RPC, MPI, COM, DCOM, DDE, OLE, CORBA, ICE, D-Bus, DCOP, MBUS, RMI, Sockets, Doors, OpenBinder, etc.

En esta lista hay que destacar OpenBinder. OpenBinder es una implementación de un nuevo tipo de comunicación entre procesos. Este proyecto nació con lo que iba a ser la siguiente versión de BeOS, la 6, aunque posteriormente maduró dentro de Palm al ser esta empresa la que compró los derechos sobre BeOS.

OpenBinder está un nivel por encima del resto de implementaciones de comunicación entre procesos. Y digo un nivel por encima porque esta API proporciona una comunicación, por decirlo de alguna forma, a nivel de componentes, es decir, los componentes del sistema operativo, incluyendo los componentes de la interfaz gráfica (ventas, botones, etc.) son clases que heredan de clases de OpenBinder, con lo que cualquier componente es susceptible de comunicarse con cualquier otro. Este sistema inicialmente implica bastante complejidad, pero está optimizado para ser muy rápido y, además, lo que se pretende con él es poder hacer aplicaciones, especialmente GUI‘s como las X, que sean distribuidas de forma transparente para el desarrollador.

OpenBinder no merecería más atención que la del resto de sistemas si no fuese porque esta tecnología está implementada dentro del sistema operativo Android, dejando de lado el resto de sistemas. Esto es cuanto menos curioso, ya que el resto de tecnologías están ampliamente probadas y esta, quizá, sea la más nueva. Pero aquí es donde se ve lo que gasta Google en I+D; no se conforma con lo que hay, quiere lo mejor (según ellos, claro).

Y ya puestos, se pueden empezar a hacer conjeturas: por ejemplo, los dispositivos Android completos podrían estar en la nube de Google, no sólo los datos que manejan, por lo que tu teléfono móvil o tu ordenador podrá ayudar a Google a procesar sus propios datos.

Ahora hay que esperar un poco más a que salga Chorme OS para ver qué sistemas de comunicación tiene y saber si esta teoría será real o una simple paranoia mía .