¿Por qué la mayoría de los marcos de IU tienen un solo hilo?

Por ejemplo, Java Swing y la IU de Android usan un solo modelo de subprocesos donde un solo subproceso de interfaz de usuario es responsable de actualizar toda la interfaz de usuario. ¿Qué hizo que los diseñadores del framework eligieran un modelo de hilo sobre el otro?

¿No le daría el modelo de IU de múltiples hebras un mayor rendimiento, aunque a costa de una mayor complejidad? Me doy cuenta de que este último es un gran problema porque los errores relacionados con hilos son desagradables, pero me pregunto si hay otras ventajas para el modelo de un solo subproceso que no sea la simplicidad.

¿Qué hizo que los diseñadores del framework eligieran un modelo de hilo sobre el otro?

De la boca del caballo :

AWT se expuso inicialmente como una biblioteca Java de subprocesos normal. Pero cuando el equipo de Java analizó la experiencia con AWT y con los callejones sin salida y las razas con las que la gente se había encontrado, comenzamos a darnos cuenta de que estábamos haciendo una promesa que no podíamos cumplir.

Este análisis culminó en una de las revisiones de diseño para Swing en 1997, cuando revisamos el estado de la AWT y la experiencia general de la industria, y aceptamos la recomendación del equipo Swing de que Swing solo debería admitir el multihilo muy limitado.

(Lea todo el artículo, explica la decisión en gran detalle y afirma que los mismos problemas y el eventual cambio a un modelo de subproceso único ya se habían producido antes en Xerox PARC, el lugar donde casi todo lo que consideramos moderno en CS era inventado hace 30 años)

¿No le daría el modelo de IU de múltiples hebras un mayor rendimiento, aunque a costa de una mayor complejidad?

Absolutamente no, porque dibujar la GUI y procesar las acciones del usuario (que es todo lo que debe hacer el hilo de la interfaz de usuario) no será el cuello de botella en ninguna aplicación sana en 2D.

¿No le daría el modelo de IU de múltiples hebras un mayor rendimiento, aunque a costa de una mayor complejidad?

No en la mayoría de los casos, y esa complejidad adicional haría más daño que bien la gran mayoría del tiempo. También debe darse cuenta de que el marco de la interfaz de usuario también debe tratar con el modelo de sistema operativo subyacente. Claro, podría funcionar alrededor del modelo y abstraerlo del progtwigdor, pero simplemente no vale la pena en este caso.

La cantidad de errores causados ​​por varios subprocesos que actualizan la interfaz de usuario ad hoc superaría con creces lo que en su mayor parte sería una ganancia de rendimiento sin sentido (si hubiera ganancias, el enhebrado viene con una sobrecarga asociada debido al locking y la sincronización, puede en realidad empeorar la actuación la mayor parte del tiempo).

En este caso, es mejor usar múltiples hilos explícitamente y solo cuando sea necesario. La mayoría de las veces en una UI desea todo en un hilo y no gana mucho si utiliza varios hilos. Las interacciones de UI casi nunca son un cuello de botella.

No, probablemente no. Al menos no cuando intentas ejecutar los hilos en la CPU. En la GPU ya hay un montón de parallel processing en diversas formas. No tanto por el simple trabajo de GUI, sino por el 3D elegante (sombreado, reflections, etc.)

Creo que se trata de prevención de interlocking.

Los componentes de Swing no se consideran seguros para subprocesos y no tienen que serlo debido a este subproceso de despachador de eventos. Si la interfaz de usuario tenía varios subprocesos, toda la aplicación tendría que depender de que cada componente se comportara de manera segura para la ejecución de subprocesos y, si no existía, los lockings podrían surgir en situaciones poco claras.

Entonces, es solo más seguro.

No solo eso, sino que el mismo diseño ha sido elegido por Windows Forms (& .Net), GTK, Motif y varios otros. Me pregunto si las API subyacentes del sistema operativo con las que interactuarían habrían forzado a Java a tomar esta decisión. Ciertamente, SWT es forzado a esta situación por Windows Forms.

Para obtener más información, “EDT” es un buen lugar para comenzar http://en.wikipedia.org/wiki/Event_dispatching_thread

Para .NET, el equivalente de SwingWorker se conoce como BackgroundWorker.

Esto se debe a la naturaleza de una aplicación de interfaz de usuario.

Debe leer la entrada (mouse o teclado), enviar los eventos, dejarlos procesar y luego dibujar la pantalla nuevamente.

Intente hacerlo en proceso de múltiples hilos.