2009-06-26 12 views
5

Estoy leyendo datos de múltiples puertos serie. En este momento estoy usando un controlador de señal personalizado (al configurar sa_handler) para comparar y activar subprocesos según la información del descriptor de archivo. Estaba buscando una salida para tener subprocesos individuales con manejadores de señal únicos, en este sentido, descubrí que se debe utilizar la llamada al sistema seleccionada.Seleccionar() llamada al sistema en hilos?

Ahora he siguientes preguntas:

  1. Si estoy usando un hilo (Qt), entonces ¿Dónde pongo el selecto llamada al sistema para supervisar el puerto serie?
  2. ¿Es seguro el hilo de la llamada al sistema de selección?
  3. ¿Es una CPU intensiva porque hay muchas cosas que suceden en mi aplicación, incluida la actualización de la GUI?

Por favor, no importa, si encuentra estas preguntas ridículas. Nunca he usado ese mecanismo para la comunicación serial.

Respuesta

7

El POSIX specification (select) es el lugar para buscar la definición select. Yo personalmente recomiendo poll - tiene una mejor interfaz y puede manejar cualquier cantidad de descriptores, en lugar de un límite definido por el sistema.

Si entiendo correctamente, está despertando hilos según el estado de ciertos descriptores. Una mejor forma sería tener cada subproceso con su propio descriptor y llamarse a sí mismo. Verá, seleccionar no modifica el estado del sistema, y ​​siempre que use variables locales de subprocesos será seguro. Sin embargo, definitivamente querrá asegurarse de no cerrar un descriptor del que depende un hilo.

El uso de select/poll con un tiempo de espera deja la "espera" en el lado del kernel, lo que significa que el hilo generalmente se pone a dormir. Mientras el hilo está durmiendo, no está utilizando ningún tiempo de CPU. Un ciclo while/for en una llamada select sin tiempo de espera por otro lado le dará un uso de CPU más alto a medida que gira constantemente en el circuito.

Espero que esto ayude.

EDIT: También, select/poll puede tener resultados impredecibles cuando se trabaja con el descriptor mismo en varios subprocesos.La razón simple de esto es que el primer subproceso puede ser despertado porque el descriptor está listo para la lectura, pero el segundo subproceso tiene que esperar al siguiente siguiente "disponible para la lectura".

Siempre y cuando no esté select en el mismo descriptor en múltiples hilos, no debería tener un problema.

+0

Información de Gud !! Una pregunta ... ¿Cómo sabe el hilo que debe activarse si el socket fd está listo para realizar una operación de lectura/escritura? ¿Kernel interfiere con el hilo? –

+0

@SumitTrehan El kernel activa el hilo ya que pone el hilo en estado ejecutable, es decir, el hilo se ejecutará tan pronto como tenga tiempo de CPU. – Medicine

0

Es una llamada al sistema; debería ser seguro para subprocesos, creo.

No hice esto antes, pero estaría bastante sorprendido, si no fuera así. El nivel de uso intensivo de la CPU select() depende, en mi opinión, del número de identificadores de archivos que está esperando. select() se usa principalmente, para esperar que un número (> 1) de identificadores de archivos esté listo.

También se debe mencionar que select() no se debe utilizar para sondear los identificadores de archivo, por razones de rendimiento. El uso normal es: usted tiene su trabajo hecho y puede pasar algún tiempo hasta que suceda lo siguiente. Ahora suspende su proceso con select y deja que se ejecute otro proceso. select() normalmente suspende el proceso activo. Cómo funciona esto junto con los hilos, ¡no estoy seguro! Yo pensaría que todo el proceso (y todos los hilos) están suspendidos. Pero esto podría estar documentado. También podría depender (en Linux) si usa subprocesos de sistema o subprocesos de usuario. El kernel no conocerá User-Threads y, por lo tanto, suspenderá todo el proceso.

+0

Esto realmente no es una buena respuesta. Mucho trabajo de adivinación ... ¿Qué es un "hilo de usuario" de todos modos? –

Cuestiones relacionadas