Los nodos y los analizadores de proceso de mensajes deben funcionar en un entorno de múltiples instancias y múltiples hebras. Puede haber muchos objetos de nodo u objetos de analizador que tengan, cada uno de ellos, muchos elementos de sintaxis, y puede haber muchas hebras que ejecuten métodos en estos objetos. El diseño de intermediario de mensajes garantiza que un objeto de mensaje y los objetos que pertenecen al mismo los utilice únicamente la hebra que recibe y procesa el mensaje a través del flujo de mensajes.
Una instancia de un nodo de proceso de flujo de mensajes es compartida y utilizada por parte de todas las hebras que dan servicio al flujo de mensajes en el que está definido el nodo. En el caso de los analizadores, una instancia de un analizador es utilizada exclusivamente por una sola hebra de flujo de mensajes.
Una extensión definida por el usuario debe adherirse a este modelo, y debe evitar utilizar datos o recursos globales que requieran semáforos para serializar el acceso a través de las hebras. Dicha serialización puede ocasionar atascos del rendimiento.
Las funciones de implementación de una extensión definida por el usuario deben ser reentrantes, y las funciones que invoquen dichas funciones también deberán ser reentrantes. Todas las funciones de programa de utilidad de una extensión definida por el usuario son completamente reentrantes.
Aunque una extensión definida por el usuario pueda generar hebras adicionales si es necesario, es esencial que la misma hebra devuelva el control al intermediario al completarse una función de implementación. De lo contrario, se pondrá en peligro la integridad del intermediario y se producirán resultados imprevisibles.
El siguiente ejemplo de flujo de mensajes le ayudará a comprender algunas de las consideraciones de trabajo con hebras que debe tener en cuenta al diseñar e implementar sus nodos propios definidos por el usuario. En él se considera el ejemplo de un nodo de entrada definido por el usuario.
Un flujo de mensajes puede configurarse para ejecutarse en un conjunto de hebras. Esto se determina mediante el número de nodos de entrada del flujo de mensajes y el valor de la propiedad additionalInstances del flujo de mensajes. Estos dos elementos determinan la capacidad máxima de la agrupación de hebras que el flujo de mensajes puede utilizar. Por lo tanto, si el flujo de mensajes tiene requisitos de proceso específicos que impongan la utilización de una sola hebra, debe asegurarse de que esto se cumpla.
El hecho de permitir al intermediario iniciar copias adicionales del flujo de mensajes en hebras independientes, utilizando la propiedad additionalInstances, es la manera más eficaz de impedir que la cola de entrada se atasque. No obstante, la creación de hebras independientes permite el proceso paralelo de los mensajes de la cola de mensajes; por lo tanto, sólo debe utilizar esta propiedad cuando el orden en que se procesan los mensajes no sea importante.
Las hebras se crean como resultado de la construcción y operación del nodo de entrada. Una hebra permanece activa o desocupada en la agrupación de hebras, y las hebras desocupadas permanecen en la agrupación hasta que un nodo de entrada las envía o hasta que el intermediario se cierra.
La figura siguiente ilustra la asignación de hebras en un flujo de mensajes.
Asignación de hebras en un flujo de mensajes
Inicialmente, se reclama la hebra (Thread) 1 (A), la cual espera a recibir mensajes. Cuando llega un mensaje (B), Thread 1 propaga el mensaje y envía Thread 2. Thread 2 recibe un mensaje inmediatamente (C) y los propaga, y luego envía Thread 3, la cual espera a recibir un mensaje (D). Thread 1 se completa (E), y vuelve a la agrupación de hebras. A continuación, Thread 3 recibe un mensaje (F), envía Thread 1 y propaga el mensaje. Thread 1 espera ahora a que llegue un mensaje a la cola (G).
Vale la pena observar el punto marcado con la letra H. En esta instancia del flujo de mensajes, Thread 1 adquiere un mensaje, pero como todas las demás hebras están activas en ese momento, no puede realizar el envío. El mensaje se propaga.
Una vez propagado este mensaje, Thread 2 se completa (I), recibe un nuevo mensaje de la cola y propaga este nuevo mensaje. A continuación, Thread 3 se completa (J), y vuelve a la agrupación. Seguidamente, Thread 2 se completa también (K). Dado que Thread 1 no ha realizado el envío, al completarse (L) no puede regresar a la agrupación de hebras aun cuando no haya ningún mensaje en la cola, así que espera a que llegue un mensaje a la cola.
Conceptos relacionados
Nodos de entrada definidos por el usuario
Tareas relacionadas
Creación de un nodo de entrada en C
Referencia relacionada
cniDispatchThread
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
as01460_ |