La confusión de problema de sincronización de subprocesos

Question

Me hace confundido cuando leí el artículo de Zarko Gajic hoy:

"Base de datos multiproceso Delphi Realiza consultas" URL

artículo: http://delphi.about.com/od/kbthread/a/query_threading.htm

Sourecode: http://delphi.about.com/library/weekly/code/adothreading.zip

Con el código del procedimiento "TCalcThread.Execute", ¿Por qué no se debe colocar el siguiente código en el método Synchronize() para ru ¿norte?

Line 173: ListBox.Clear; 
Line 179: ListBox.Items.Insert(......); 
Line 188: ListBox.Items.Add('*---------*'); 
Line 195: TicksLabel.Caption := 'Ticks: ' + IntToStr(ticks); 

Estos códigos están funcionando con los componentes de VCL, y están relacionados con las actualizaciones de la interfaz de usuario. En mi conocimiento, estas operaciones se deben utilizar sincronizar hilo, y ejecutado por el hilo principal. ¿Mi conocimiento tiene el defecto?

Answer 1

Este es un caso raro en el que se está beneficiando del hecho de que Windows está haciendo la sincronización del hilo por usted. La razón es que para un cuadro de lista, los elementos se manipulan utilizando SendMessage con el control de mensajes específicos. Debido a esto, cada llamada de SendMessage se asegura de que el mensaje sea procesado por el mismo hilo en el que se creó el control, especialmente el hilo principal.

Como dije, este es un caso raro. También está causando un cambio de hilo para cada una de esas tres llamadas, lo que degradará el rendimiento. Aún así, es mejor utilizar Synchronize para forzar que ese bloque de código se ejecute en el hilo principal al que pertenece. También garantiza que si comienza a trabajar con un control que no utiliza internamente SendMessage, no lo picarán.

Answer 2

De hecho. Tal vez la muestra no sea problemática porque no hay cambios en la UI mientras se está ejecutando el subproceso. Pero las cosas de la interfaz de usuario siempre tienen que ocurrir dentro del hilo de la interfaz de usuario.

Las únicas diferencias que veo entre el sync'ed y las instrucciones no son sync'ed:

• la sync'ed no son métodos que no hay-params lo que el programa será más dificil de escribir:)
• el método sync'ed está actualizando un TLabel que no es un TControl (si no recuerdo mis días de Delphi) por lo que utiliza directamente la lona ...

Pero de todos modos: la interfaz de usuario es tocado por un solo hilo . Siempre. Una vez que quise actualizar un TTreeBox dentro de un hilo (sin paralelismo ni actualizaciones cruzadas, simplemente un hilo separado) y fue algo muy malo (errores aleatorios) ...