[C#] utilizzare i thread

[kappa85]

Ciao,
ho sviluppato un piccolo software ad utilità personale (windows form application) che sposta dei file all'interno di una macchina; considerate che ogni esecuzione movimenta (tra backup e copie) circa 3GB di file, per cui l'esecuzione dura circa un paio di minuti, anche perchè ci sono diverse funzioni di controllo sull'esistenza dei file, delle cartelle, e elaborazioni sui nomi dei file.

Quello che succede è che durante l'esecuzione la gui rimane bloccata, e talvolta il programma va in "not responding" (infatti il log che ho aggiunto alla gui si blocca), salvo poi tornare operativa alla conclusione dell'esecuzione, e in quella occasione anche il log si popola con le operazioni svolte.
Ho dato un occhio ai thread ma non ho capito come usarli. Il mio programma in sostanza fa tutto quello che deve fare nella funzione "button_click" la quale chiama 3-4 funzioni di supporto per i controlli e la copia dei file. Qualcuno mi sa aiutare?

Grazie

[[Kendall]]

Non programmo in c#, ma sembrerebbe un problema legato alle funzioni che hai scritto per la copia dei file. Nel senso che loro evidentemente entrano in un loop interno per gestire le loro cose e se ne escono solo dopo aver completato il tutto. In questa maniera l'applicativo non riprende più in mano il controllo del loop (quello generato da lui stesso e che permette all'applicazione di rimanere in esecuzione) che verrà ristabilito alla fine della copia. A quel punto l'applicazione avvierà il refresh delle finestre che mostreranno a quel punto tutte le manipolazioni compiute fin lì. Così di primo acchito, non conoscendo il c# e non avendo di fronte a me il codice del tuo programma, ti direi di predisporre all'interno del loop delle tue funzioni di copia dei comandi per il refresh della/e schermate della gui.

[kappa85]

;37104878']Non programmo in c#, ma sembrerebbe un problema legato alle funzioni che hai scritto per la copia dei file. Nel senso che loro evidentemente entrano in un loop interno per gestire le loro cose e se ne escono solo dopo aver completato il tutto. In questa maniera l'applicativo non riprende più in mano il controllo del loop (quello generato da lui stesso e che permette all'applicazione di rimanere in esecuzione) che verrà ristabilito alla fine della copia.

Direi che il problema è proprio questo.

;37104878']
ti direi di predisporre all'interno del loop delle tue funzioni di copia dei comandi per il refresh della/e schermate della gui.
Nella gui c'è una listbox che uso come log, e immediatamente dopo la funzione "File.Copy" (che viene ripetuta molte volte) scrivo sulla listbox una riga di log e ne faccio il refresh. Tuttavia sul log non appare nulla e la gui rimane bloccata. Solo al termine il log si popola con tutte le righe scritte nelle varie iterazioni. Cosa sbaglio?

[banryu79]

Cosa sbaglio?
Ciao, programmo in Java, ma il problema, almeno concettualmente, è il medesimo.
In pratica la funzione di callback da te definita e invocata dal GUI framework in risposta all'evento di click sul bottone viene eseguita dallo stesso thread che si occupa anche di aggiornare lo stato dei componenti grafici.
Questo thread ciclicamente pesca gli eventi grafici da una coda e li processa: se ora deve eseguire la tua funzione che lo tiene occupato per 2 minuti, non sarà più libero di aggiornare la grafica, con il risultato che hai esperito.

La soluzione è, al click del bottone, quella di creare un altro thread a cui far eseguire le tue funzioni, per lasciare libero il thread del GUI framework.
Eventuali aggiornamenti ai componenti grafici dovranno comunque essere fatti eseguire dal thread del GUI framework e non dal tuo thread.

Probabilmente nell'ambiente .NET ci saranno strumenti/classi apposite per velocizzare e automatizzare tutto questo, prova a leggere la documentazione e/o attendi il passaggio di qualche .Nettiano :)

[mrwinch]

E' un classico quando un operazione "pesante" non è eseguita in multithreading: implementa un thread che esegua la tua funzione oppure metti sotto thread le operazioni ripetitive. Qual'è il problema con CreateThread?

[kappa85]

Ok, ho creato un thread nell'evento click del bottone e ho delegato l'esecuzione della funzione "go" dove ho messo tutto il codice che deve effettuare il lavoro. Mi manca però il punto seguente:


Eventuali aggiornamenti ai componenti grafici dovranno comunque essere fatti eseguire dal thread del GUI framework e non dal tuo thread.


Come posso fare questo se le modifiche agli elementi grafici sono strettamente legate alle esecuzioni del mio thread di lavoro?

[Dânêl]

Ciao,
il c#, per situazioni del genere, mette a disposizione il backgroundWorker (http://msdn.microsoft.com/it-it/library/c8dcext2%28v=vs.80%29.aspx) che ti consente di eseguire una funzione in un thread separato e di aggiornare la GUI in modo estremamente semplice

[banryu79]

Come posso fare questo se le modifiche agli elementi grafici sono strettamente legate alle esecuzioni del mio thread di lavoro?
Ad esempio in Swing (un GUI framework Java) l'API del framework stesso ti permette di "pubblicare" le operazioni che mutano lo stato dei componenti grafici nella coda degli eventi, così poi l'apposito thread li può processare. Questo come maccanismo "base".
Poi c'è anche qualcosa di più raffinato, tipo la classe SwingWorker.

Per .NET non saprei, attendi lumi dai .Nettiani (vedi Dânêl, che ti ha suggerito di usare un backgroundWorker, immagino sia l'analogo in .NET di SwingWorker).

[Kralizek]

se vuoi qualcosa di piú strutturato, puoi leggerti questa serie di post ed adattarli al tuo caso

http://blogs.msdn.com/b/csharpfaq/archive/2010/06/01/parallel-programming-in-net-framework-4-getting-started.aspx

(per .net 4 e visual studio 2010)

[gugoXX]

Qui invece poco strutturato, ma se devi fare cose semplici va bene.



public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
Action eseguoInBackground = Copio;
eseguoInBackground.BeginInvoke(null, null);
}

private void Copio()
{
ToggleWait(true);
try
{
// Qui copi i file
Thread.Sleep(5000);
}
finally
{
ToggleWait(false);
}
}

private void ToggleWait(bool shouldWait)
{
SynchExec(() =>
{
button1.Enabled = !shouldWait;
Cursor = shouldWait ? Cursors.WaitCursor : Cursors.Arrow;
});
}

private void SynchExec(Action act)
{
if (InvokeRequired)
BeginInvoke(act);
else
act();
}
}


Se invece che Winform sei in WPF e usi MVVM allora la parte con SynchExec sparisce ed e' ancora piu' semplice.
Dai thread in background non occorre piu' sincronizzare con il Thread della finestra, dato i binding del WPF sincronizzano internamente