¿Las colas de mensajes están obsoletas en Linux?

Question

He estado jugando con colas de mensajes (System V, pero POSIX debería estar bien también) en Linux recientemente y parecen perfectas para mi aplicación, pero después de leer The Art of Unix Programming no estoy seguro de si realmente son un buena elección.

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

La capa superior paso de mensajes de System V IPC ha caído en gran parte fuera de uso. La capa inferior, que consiste en memoria compartida y semáforos, todavía tiene aplicaciones significativas bajo circunstancias en las que se necesita hacer un bloqueo de exclusión mutua y compartir datos globales entre procesos que se ejecutan en la misma máquina. Estas instalaciones de memoria compartida de System V se convirtieron en la API de memoria compartida POSIX, compatibles con Linux, BSD, MacOS X y Windows, pero no con MacOS clásicos.

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

Las instalaciones System V IPC están presentes en Linux y otros Unix modernos. Sin embargo, como son una característica heredada, no se ejercitan con mucha frecuencia. Todavía se sabe que la versión de Linux tiene errores a partir de mediados de 2003. A nadie parece importarle lo suficiente como para solucionarlos.

son las colas de mensajes System V aún con errores en las versiones más recientes de Linux? No estoy seguro si el autor quiere decir que las colas de mensajes POSIX deberían estar bien?

Parece que los sockets son el IPC preferido para casi cualquier cosa (?), Pero no veo cómo sería muy simple implementar colas de mensajes con sockets o algo más. ¿O estoy pensando demasiado complejo?

No sé si es relevante que esté trabajando con Linux incorporado?

Answer 1

Personalmente soy bastante aficionado a las colas de mensajes y creo que son posiblemente el IPC menos utilizado en el mundo de Unix. Son rápidos y fáciles de usar.

Un par de reflexiones:

• Algo de esto es sólo una moda. Las cosas viejas se vuelven nuevas de nuevo. Agregue un dopaje brillante en las colas de mensajes y pueden ser las novedades y las novedades del próximo año. Mire Google Chrome utilizando procesos separados en lugar de hilos para sus pestañas. De repente, la gente está encantada de que cuando una pestaña se bloquea no baje todo el navegador.

• La memoria compartida tiene algo así como un halo He-man. No es un programador "real" si no está exprimiendo el último ciclo de la máquina y los MQ son marginalmente menos eficientes. Para muchas aplicaciones, si no para la mayoría, es totalmente absurdo, pero a veces es difícil romper una mentalidad una vez que se afianza.

• Los MQ realmente no son apropiados para aplicaciones con datos ilimitados. Mecanismos orientados a la corriente como tuberías o enchufes son simplemente más fáciles de usar para eso.

• Las variantes del Sistema V realmente han caído en desgracia. Como regla general, vaya con las versiones POSIX de IPC cuando pueda.

Answer 2

No he usado cola de mensajes POSIX porque siempre quiero dejar abierta la opción de distribuir mis mensajes en una red. Con esto en mente, puede mirar una interfaz de paso de mensajes más robusta como zeromq o algo que implementa AMQP.

Una de las cosas buenas de 0mq es que cuando se utiliza desde el mismo espacio de proceso en una aplicación multiproceso, utiliza un mecanismo de copia cero sin bloqueos que es bastante rápido. Aún así, puede usar la misma interfaz para pasar mensajes a través de una red también.

Answer 3

Sí, creo que las colas de mensajes son adecuadas para algunas aplicaciones. Las colas de mensajes de POSIX proporcionan una interfaz más agradable, en particular, le permite asignar nombres a las colas en lugar de a los ID, lo que es muy útil para el diagnóstico de fallas (hace que sea más fácil ver cuál es cuál).

Linux le permite montar las colas de mensajes posix como un sistema de archivos y verlos con "ls", elimínelos con "rm" que es bastante útil también (System V depende de los comandos "ipcs" e "ipcrm" torpes))

Answer 4

mayores inconvenientes de la cola de mensajes POSIX:. cola de mensajes

• POSIX no lo convierten en un requisito sea compatible con select() (funciona con select() en Linux, pero no en el sistema Qnx)
• Tiene sorpresas.

Unix Datagram socket realiza la misma tarea que POSIX message queue. Y el socket de Datagram de Unix funciona en la capa de socket. Es posible usarlo con select()/poll() u otros métodos IO-wait. Usar select()/poll() tiene la ventaja cuando se diseña un sistema basado en eventos. Es posible evitar el bucle ocupado de esa manera.

Hay sorpresa en la cola de mensajes. Piense en mq_notify(). Se usa para obtener un evento de recepción. Parece que podemos notificar algo sobre la cola de mensajes. Pero en realidad se está registrando para notificaciones en lugar de notificar nada.

Más sorpresa sobre mq_notify() es que tiene que ser llamado después de cada mq_receive(), lo que puede provocar una carrera de condición (cuando algún otro proceso de llamada/hilo mq_send() entre la llamada de mq_receive() y mq_notify()).

Y tiene un conjunto completo de con su propia definición que es redundante y en algunos casos no concuerda con la especificación del método socket open(),send(),recv() and close().

No creo que la cola de mensajes se deba utilizar para la sincronización. eventfd y signalfd son adecuados para eso.

Pero tiene soporte en tiempo real. Tiene características de prioridad.

Messages are placed on the queue in decreasing order of priority, with newer messages of the same priority being placed after older messages with the same priority. 

¡Pero esta prioridad también está disponible para el socket como datos fuera de banda!

Finalmente, para mí, la cola de mensajes POSIX es una API heredada. Siempre prefiero el socket Unix Datagram en lugar de la cola de mensajes POSIX.