PDA

View Full Version : [.Net 4.0]Operazioni Thread Safe (winforms)


RaouL_BennetH
10-10-2010, 21:15
Ciao a tutti :)

Sto lavorando con l'entity framework ed ho dei problemi (credo i classici...) a gestire determinate operazioni.

Attualmente il progetto è di tipo WinForms.

Il problema che ho è il seguente:

Ho il classico form contenente alcune caselle di input ed una griglia.

Durante l'inserimento/modifica dei dati , ho un semplice form di attesa, e dopo l'inserimento/modifica la mia griglia deve aggiornarsi.

Attualmente il codice è questo:


//context è il mio EntityModel

public MyForm()
{
InitializeComponent();
base.SaveClicked += new ButtonClickHandler(SaveEntity);
base.UpdateClicked += new ButtonClickHandler(UpdateEntity);
context = new EFHelper();
validator = new InputValidator();
}

private void MyForm_Load(object sender, EventArgs e)
{
//popolo la griglia
GridRefresh();
}

void GridRefresh()
{
var result = (from contratti in context.Categoria_Contratti
select contratti).ToList();
contrattiBindingSource.DataSource = result;
}

private void SaveEntity()
{
context.AddToCategoria_Contratti(contratto);
context.SaveChanges();
GridRefresh();
}



In questo caso, tutto va bene e non ci sono problemi.

Io invece volevo strafare e mi sono incasinato...



public class Worker()
{
private BackGroundWorker bw;
private FormWait wf;

public void WorkAsync()
{
wf = new FormWait();
wf.Show();
bw = new BackGroundWorker();
bw.DoWork += new DoWorkEventHandler(bw_DoWork);
bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bw_RunWorkerCompleted);
bw.RunWorkerAsync();
}

private void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
wf.Close();
}

private void bw_DoWork(object sender, DoWorkEventArgs e)
{
devo_far_partire_un_metodo_che_qui_non_conosco
}



In parte ci sono anche riuscito con qualche bruttura:


public delegate void ProvaChiamata();
public ProvaChiamata metodoInvocato;

//nel bw_DoWork...
metodoInvocato();


Per quanto riguarda l'inserimento dei dati, la mia SaveEntity diventa quindi:



private void SaveEntity()
{
Worker worker = new Worker();
worker.metodoInvocato = delegate()
{
context.AddToCategoria_Contratti(contratto);
context.SaveChanges();
GridRefresh();
};
worker.WorkAsync();
}



Bene.. cioè, male, l'inserimento me lo effettua, ma quando deve aggiornare la griglia mi solleva l'eccezione di: "Operazione cross-thread non valida: è stato eseguito l'accesso al controllo 'gridView' da un thread diverso da quello da cui è stata eseguita la creazione"

banryu79
11-10-2010, 08:37
...
Bene.. cioè, male, l'inserimento me lo effettua, ma quando deve aggiornare la griglia mi solleva l'eccezione di: "Operazione cross-thread non valida: è stato eseguito l'accesso al controllo 'gridView' da un thread diverso da quello da cui è stata eseguita la creazione"
Suppongo (perchè la piattaforma .NET non la conosco ma so che è single-threaded) che il problema è dato dal fatto che stai accedendo ad un oggetto della GUI (gridView) da un thread diverso dallo specifico thread dedicato.

Prova a cercare informazioni specifiche in merito, oppure incrocia le dita, magari un utente .Net informato passa di qua, ti legge e decide di risponderti.

gugoXX
11-10-2010, 08:45
E' davvero tanto che non uso Winforms, e soprattutto ancora di piu' che non lo uso senza pattern come MVC.
Ad occhio pero' direi che dovresti chiamare la UpdateGrid dal thread che ha creato la finestra.

BeginInvoke( new Action( ()=>GridRefresh() ) ,null, null);

O qualcosa di simile, sto scrivendo al volo.
Magari
BeginInvoke( GridRefresh ,null, null);
viene compilata ed e' piu' leggibile.

Kralizek
11-10-2010, 08:49
se sei in .net-4 e vuoi parallelizzare il tuo lavoro, perchè non usare la TPL?

ecco un bel tutorial da cui prendere spunto: http://blogs.msdn.com/b/csharpfaq/archive/2010/06/01/parallel-programming-in-net-framework-4-getting-started.aspx

astorcas
11-10-2010, 09:10
E' davvero tanto che non uso Winforms, e soprattutto ancora di piu' che non lo uso senza pattern come MVC.
Ad occhio pero' direi che dovresti chiamare la UpdateGrid dal thread che ha creato la finestra.

BeginInvoke( new Action( ()=>GridRefresh() ) ,null, null);

O qualcosa di simile, sto scrivendo al volo.
Magari
BeginInvoke( GridRefresh ,null, null);
viene compilata ed e' piu' leggibile.

Si io direi una cosa del genere:


public delegate void InvokeDelegate();

void GridRefresh()
{
if(contrattiBindingSource.InvokeRequired){
BeginInvoke(new InvokeDelegate(GridRefresh));
}
else{
var result = (from contratti in context.Categoria_Contratti
select contratti).ToList();
contrattiBindingSource.DataSource = result;
}
}


In questo modo è il metodo stesso a gestire le chiamate da thread esterni o esegue direttamente il codice se la chiamata arriva dal thread principale.

Ho messo il delegato InvokeDelegate ma sono quasi certo che ce ne sia uno con la stessa firma, se lo trovi usa quello :)

EDIT: Non serve creare un delegate apposta (InvokeDelegate nel mio caso), ne esiste uno già bello e pronto: MethodInvoker

RaouL_BennetH
11-10-2010, 10:56
Innanzitutto, grazie a tutti per le risposte :)

@gugoXX e @astorcas

Sebbene leggermente diversi, i vostri suggerimenti funzionano entrambi :ave:

e quindi vi chiedo:

ma è per qualsiasi tipo di controllo che ci sono queste limitazioni o soltanto per quelli che hanno un legame con una base dati ?


@Kralizek
Se l'eseguibile finale dovrà girare anche su pc con processori vecchio "stile", single core, posso comunque prendere in considerazione l'approfondire TPL ?

Grazie a tutti :)

RaouL.

astorcas
11-10-2010, 11:13
qualsiasi controllo ha bisogno di essere aggiornato dallo stesso thread da cui è stato creato. Per verificare che ci si si trovi in un caso o nell'altro ogni controllo può far affidamento alla proprietà InvokeRequired (infatti la trovi proprio nella classe Control).
Il "pattern" è sempre il solito, almeno io uso sempre il solito.



public voiid NomeFunzione()
{
if(controlloDaModificare.InvokeRequired)
{
BeginInvoke(new MethodInvoker(NomeFunzione));
}
else
{
//Corpo del metodo che modifica il controllo
}

}



In pratica questo si traduce in:
"Sono il thread principale?"

Si? Allora modifico direttamente (vado nell'else)

No? Allora chiedo al thread principale di farlo per me (quindi quando il codice girerà nel thread principale andrà di nuovo nell'else)

Ecco ti ho esposto, più o meno, il mio punto di vista :)

Kralizek
11-10-2010, 11:28
@Kralizek
Se l'eseguibile finale dovrà girare anche su pc con processori vecchio "stile", single core, posso comunque prendere in considerazione l'approfondire TPL ?


diciamo che la parallelizzazione serve solo in parte a gestire multi core. nella maggior parte dei casi serve per comunicare al SO i tempi morti e come gestirli aumentando l'efficienza dell'uso del processore quando ti viene assegnato.

Per fare un esempio:

mettiamo che fare una query al database significa compiere queste operazioni:
- inoltro del comando al server
- esecuzione del comando (eseguito sul server)
- reperimento dei risultati dal server

e che devi eseguire 4 query bene o male indipendenti tra di loro. nella programmazione classica ti troveresti ad aspettare la query n-1 prima di poter eseguire la query n.

usando un minimo di parallelismo, anche su un processore single-core, tu comunichi al sistema operativo che nei tempi morti (ad es l'esecuzione del comando) può iniziare a preparare il comando della seconda query ed inoltrarlo al database e mettersi in attesa del risultato.

spero di essere stato chiaro ;)

RaouL_BennetH
12-10-2010, 09:47
@Kralizek: il concetto è chiarissimo :)

@astorcas: non per ripetermi ma.... il concetto è chiarissimo :D


Grazie mille ragazzi !

RaouL.