2012-07-25 7 views
10

Necesito un consejo en la codificación adecuada:¿Buena codificación? (Bucles de mensajes múltiples)

Estoy trabajando en un programa donde se usan múltiples conexiones en serie. Cada línea de comunicación tiene un controlador que funciona como una capa de abstracción. Entre el controlador y el puerto serie, se inserta un protocolo para envolver los datos en paquetes, listos para la transferencia. El protocolo se ocupa de entregas fallidas, reenvío, etc. Para garantizar que la GUI no se bloquee, cada línea de conexión (protocolo y puerto serie) se crea en una cadena separada. El controlador es manejado por el hilo principal, ya que tiene controles en la GUI.

Actualmente, cuando creo los hilos, he elegido crear un bucle de mensajes sobre ellos (Application.Run()), por lo que en lugar de sondear buffers y ceder si no funciona, simplemente invoco el hilo (BeginInvoke) y lo uso el bucle de mensaje como un búfer. Esto actualmente funciona bien, y no hay problemas serios hasta el momento.

Mi pregunta es ahora: ¿Es esta "buena codificación", o debería usar un bucle while en la banda de rodadura y ser buffers de sondeo en su lugar ?, o una tercera cosa?

Me gustaría mostrar el código, pero hasta el momento se trata de varios miles de líneas de código, así que sea específico si necesita ver alguna parte del código. :)

Gracias.

Respuesta

4

El uso de bucles de mensajes en cada hilo está perfectamente bien; Windows está optimizado para este escenario. Tiene razón para evitar el sondeo, pero es posible que desee examinar otros diseños basados ​​en eventos que sean aún más eficientes, por ejemplo, preparar un paquete para transferir y llamar al SetEvent para notificar a un hilo que está listo, o semáforo y cola segura para hilos como Martin James sugiere.

+0

No realmente, no. WM_COPYDATA está bien para comunicarse entre procesos. No tiene sentido usarlo para comunicarse entre hilos dentro de un proceso. Es mucho más fácil/simple pasar los objetos de buffer/blob/whatever por puntero, ej. lanzando el * Buffer al mensaje.lParam, PostMessage() ing y casting en el 'otro extremo'. –

+0

Las colas de mensajes de Windows están optimizadas para comunicar hilos de GUI. No son óptimos para comunicarse desde subprocesos GUI a subprocesos de trabajo que no son GUI. Incluso una simple cola productor-consumidor no optimizada basada en semáforos es aproximadamente cuatro veces más rápida que una WMQ. En la mayoría de las aplicaciones, el rendimiento de la cola P-C normalmente no es un problema de todos modos. –

+0

Estoy de acuerdo en ambos puntos en realidad. Editaré WM_COPYDATA; No estaba pensando claramente. En cuanto a la cola de mensajes, es una solución generalizada basada en eventos. Dependiendo de los requisitos de su aplicación, otros modelos podrían ser mejores. – tenfour

1

No estoy 100% seguro de lo que está haciendo aquí, pero, con un poco de 'llenado en' no suena mal :)

Cuando la aplicación está en reposo, (no hay comunicaciones), es Uso de CPU 0%?

¿Su aplicación está libre de sueño (0)/sueño (1), o similar, los circuitos de votación?

¿Funciona con una latencia razonablemente baja?

Si las respuestas son tres 'SÍ', que debe estar bien :)

Hay unos pocos, (muy pocos!), Los casos en que los resultados de votación, etc., es una buena idea, (por ejemplo., Cuando la frecuencia de eventos en los hilos es tan alta que la señalización de cada evento de progreso a la GUI lo abrumaría), pero sobre todo, es solo un diseño deficiente.

+0

El objetivo de este programa es controlar de 1 a 4 (hasta ahora) cuadros, cada uno con un Arduino. Cada Arduino está conectado a E/S digitales de un sistema simulador. Los sistemas simuladores paralelos necesitan una caja pr. simulador. Los simuladores forman parte de la I + D en la empresa donde trabajo. El programa de Windows tiene la capacidad de reprogramar los pines Arduino en el tiempo de ejecución, junto con leer/escribir los estados alto/bajo de los pines. – Anders

+0

Triple SÍ desde aquí ... Traté de cambiar el código para ser un sondeo de buffer, con thread.yields si no hay datos, y eso hizo que el programa carezca de un poco, así que supongo que estoy bien con los bucles de mensajes :) – Anders

+0

Bueno, Es posible que haya utilizado colas ligeramente diferentes, etc., pero si su aplicación es lo suficientemente eficiente, responde rápidamente y no se cuelga, ¿a quién le importa :)) –

Cuestiones relacionadas