Si se realizan operaciones de subprocesos múltiples en subprocesos sin liberar el bloqueo, ¿no tiene ninguna ventaja sobre el subproceso único?
Las bibliotecas de interfaz gráfica de usuario como Android, Swing y MFC utilizan un mecanismo de cola de mensajes de un solo subproceso para procesar mensajes, como interfaces de dibujo, respuestas a eventos, etc. En este diseño, cada tarea pendiente se encapsula como un mensaje y se agrega a la cola de mensajes. La cola de mensajes es segura para subprocesos (la cola de mensajes en sí misma garantiza que los mensajes no se pierdan en la competencia de subprocesos múltiples mediante bloqueos y otros mecanismos). Cualquier subproceso puede agregar mensajes a la cola, pero solo el subproceso principal (subproceso de la interfaz de usuario) puede aceptarlos). mensajes de él y ejecutar la función de respuesta del mensaje, lo que garantiza que solo el hilo principal pueda realizar estas operaciones.
Existe un problema con el mecanismo de cola de mensajes de un solo subproceso: es imposible tener operaciones que consuman mucho tiempo y sean computacionalmente intensivas en la función de respuesta de mensajes, porque cuando el subproceso principal intenta procesar tales operaciones, No se puede procesar el trabajo pendiente en la cola de mensajes. Para otros mensajes de dibujo y mensajes de eventos (el hilo principal solo recibirá el siguiente mensaje en la cola después de procesar un mensaje), no habrá respuesta a las pulsaciones de teclas o clics, y habrá. No hay respuesta a los clics.
Sin embargo, existe una solución perfecta para este problema. Podemos iniciar otro hilo de trabajo en la función de respuesta del mensaje para realizar operaciones a largo plazo, de modo que el mensaje se procese después de que se inicie el hilo, y el hilo principal Puede recibir el siguiente mensaje, y luego el hilo principal y los hilos de trabajo que no han completado las tareas informáticas se ejecutarán uno al lado del otro en el programador del sistema operativo. En este momento, el sistema operativo programa el subproceso principal y los subprocesos de trabajo que no han completado las tareas informáticas para que se ejecuten en paralelo (el algoritmo de programación garantiza que los dos subprocesos se ejecuten al mismo tiempo o en paralelo sin favorecer a un subproceso).
Generalmente, una vez completada la tarea que requiere mucho tiempo, debemos actualizar la interfaz para mostrar los resultados del cálculo. Dado que la interfaz no se puede actualizar directamente en el hilo de trabajo, algunas personas pueden llamar a unirse en la respuesta del mensaje. La función espera. Una vez que el hilo completa la actualización de la interfaz, inicia el hilo. Esto en realidad es equivalente a ejecutar la tarea que requiere mucho tiempo directamente en el hilo principal, porque la unión en la función de respuesta del mensaje en realidad la ejecuta el hilo principal. Esto equivale a colocar tareas de larga duración directamente en el hilo principal para su ejecución, porque la unión en la función de respuesta al mensaje es en realidad la unión en el hilo principal y la acumulación de mensajes no se procesará. La forma correcta de manejarlo es cambiar la tarea que requiere mucho tiempo a un mecanismo de notificación asincrónico, es decir, el hilo de trabajo agrega un mensaje a la cola de mensajes para notificar al hilo principal que la tarea que requiere mucho tiempo se ha completado, de modo que el hilo principal no necesita investigar activamente la tarea después de iniciar el progreso del hilo de trabajo, me notificará cuando se complete la tarea."
Los métodos comunes para que los hilos de trabajo agreguen mensajes al hilo principal. La cola de mensajes es la siguiente:
l Android: Acitvity.runOnUiThead, Handler. post, AsyncTask
l Swing: invokeLater
l Win32, MFC: usuario personalizado. mensajes, PostMessage en hilos de trabajo
l Swing: SwingUtilities.
p>