Confusione di problema di sincronizzazione di thread

Question

Mi fa confuso quando ho letto l'articolo di Zarko Gajic oggi:

"multithread Delphi Database Interroga"

Articolo URL: http://delphi.about.com/od/kbthread/a/query_threading.htm

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

Con il codice della procedura "TCalcThread.Execute", Perché il seguente codice non deve essere inserito nel metodo Synchronize() per ru n?

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

Questi codici funzionano con i componenti VCL e sono correlati agli aggiornamenti dell'interfaccia utente. A mia conoscenza, queste operazioni dovrebbero essere utilizzate per sincronizzare il thread ed essere eseguite dal thread principale. La mia conoscenza ha il difetto?

Answer 1

Questo è un caso raro in cui si sta beneficiando dal fatto che Windows sta eseguendo la sincronizzazione dei thread per te. Il motivo è che per una listbox gli oggetti vengono manipolati usando SendMessage con messaggi specifici del controllo. Per questo motivo, ogni chiamata SendMessage assicura che il messaggio venga elaborato dallo stesso thread su cui è stato creato il controllo, in particolare il thread principale.

Come ho già detto, questo è un caso raro. Inoltre sta causando un cambio di thread per ognuna di queste tre chiamate, il che peggiorerà le prestazioni. Stai ancora meglio usando Synchronize per forzare quel blocco di codice da eseguire nel thread principale a cui appartiene. Garantisce inoltre che se inizi a lavorare con un controllo che non utilizza internamente SendMessage, non verrai morso.

Answer 2

Infatti. Forse l'esempio non è problematico perché non ci sono modifiche all'interfaccia utente durante l'esecuzione del thread. Ma le cose dell'interfaccia utente devono sempre verificarsi all'interno del thread dell'interfaccia utente.

Le uniche differenze che vedo tra la sincronia e le istruzioni non sono Sync'ed:

• la non sincronia sono metodi non no-params modo che il programma sarà più dificile a scrivere:)
• il metodo Sync'ed sta aggiornando un TLabel che non è un TControl (se non ricordo i miei giorni Delphi) in modo che utilizza direttamente tela ...

Ma comunque: interfaccia utente è toccato da un unico filo . Sempre. Una volta volevo aggiornare un TTreeBox all'interno di un thread (niente parallelismi o aggiornamenti incrociati, semplicemente un thread separato) ed era una cosa molto brutta (errori casuali) ...