[VB.NET 2005] Modificare una form da un thread separato

[Dave83]

Ho realizzato una piccola applicazione che fa una scansione di un range di IP locale e che fornisce in ouput dei risultati (per ora su un file di testo). In questa applicazione ho messo una progressbar in modo da capire quando manca al termine della scansione.
Il problema è che questa scansione la faccio in multithread, in modo da non dover aspettare la risposta del primo IP per interrogare il secondo.

Quindi uso il metodo ThreadPool.QueueUserWorkItem per richiamare il metodo (contenuto in una classe) che mi farà la scansione del singolo IP. Il problema è che poi non riesco ad aggiornare il valore della progressbar dal metodo, in quanto nel framework2 è stato aggiunto un controllo che in fase di debug segnala queste operazioni come errori, ma in realtà se sì lancia il file .exe a parte il tutto funziona perfettamente. Come posso ovviare a questo problema?
In rete ho letto di usare l'oggetto BackgroundWorker, ma in realtà questo oggetto non lavora in multithread, in quanto gli ip vengono scansionati uno alla volta e il tutto risulta molto più lento.


Qualcuno ha un'altra soluzione?

[gugoXX]

Originariamente inviato da Dave83

Ho realizzato una piccola applicazione che fa una scansione di un range di IP locale e che fornisce in ouput dei risultati (per ora su un file di testo). In questa applicazione ho messo una progressbar in modo da capire quando manca al termine della scansione.
Il problema è che questa scansione la faccio in multithread, in modo da non dover aspettare la risposta del primo IP per interrogare il secondo.

Quindi uso il metodo ThreadPool.QueueUserWorkItem per richiamare il metodo (contenuto in una classe) che mi farà la scansione del singolo IP. Il problema è che poi non riesco ad aggiornare il valore della progressbar dal metodo, in quanto nel framework2 è stato aggiunto un controllo che in fase di debug segnala queste operazioni come errori, ma in realtà se sì lancia il file .exe a parte il tutto funziona perfettamente. Come posso ovviare a questo problema?
In rete ho letto di usare l'oggetto BackgroundWorker, ma in realtà questo oggetto non lavora in multithread, in quanto gli ip vengono scansionati uno alla volta e il tutto risulta molto più lento.

Qualcuno ha un'altra soluzione?

Va benissimo usare un'insieme di thread per ottenere quello che stai cercando.
Il problema e' che non si puo' cambiare nulla della UI di una Form al di fuori del Thread della form stessa.
Questo per problemi di concorrenza, in quanto i metodi della Form non sono Thread Safe. Per questo motivo e' sufficiente far richiamare la tua funzione di aggiornamento dal Thread della Form stessa, e c'e' un modo molto semplice di farlo.
Posto il codice C# perche' quello VB.net non lo conosco.

Supponi che la tua funzione di aggiornamento sia questa

   private void SetLabelText(int number)
   {
      label.Text = number.ToString();
   }

Allora sara' sufficiente modificare il codice come segue

   private delegate void SetLabelTextDelegate(int number);
   private void SetLabelText(int number)
   {
      // label.Text = number.ToString();
      // Do NOT do this, as we are on a different thread.

      // Check if we need to call BeginInvoke.
      if (this.InvokeRequired)
      {
         // Pass the same function to BeginInvoke,
         // but the call would come on the correct
         // thread and InvokeRequired will be false.
         this.BeginInvoke(new SetLabelTextDelegate(SetLabelText), 
                                          new object[] {number});

         return;
      }

      label.Text = number.ToString();
   }

Questo codice si legge cosi:
Ogni volta che viene chiamata questa funzione (da parte di un tuo thread) la funzione stessa si chiede se per caso il contesto e' quello della Form (this.InvokeRequired). se si e' nel contesto della form tutto ok e procede come prima, altrimenti si chiede alla form di richiamare una funzione in modo asincrono, all'interno del thread della form stessa (BeginInvoke)
Ovviamente il codice da eseguire in modo asincrono e' la funzione stessa, chiamata via delegate.

http://www.codeproject.com/KB/cpp/begininvoke.aspx

[Dave83]

Ti ringrazio, seguendo l'esempio da te citato e adattandolo al mio progetto funziona perfettemente

[Dave83]

Un altro problema.
Come faccio a capire quando tutto il pool di thread è terminato (per chiudere ad esempio una connessione che uso nei thread)?

Tra l'altro mi serve fare questa cosa sotto forma di servizio (ovviamente non ci sarà più la progressbar) e nei servizi a quanto pare i metodi invoke e simili non ci sono

[gugoXX]

Originariamente inviato da Dave83

Un altro problema.
Come faccio a capire quando tutto il pool di thread è terminato (per chiudere ad esempio una connessione che uso nei thread)?

Tra l'altro mi serve fare questa cosa sotto forma di servizio (ovviamente non ci sarà più la progressbar) e nei servizi a quanto pare i metodi invoke e simili non ci sono

Per la prima puoi fare una cosa tipo (scrivo al volo, quasi pseudocodice)

using (TcpConnection myTcpConnection=qualcosa)
{
  List<Thread> thlist=new List<Thread>();
  loop
  {
    Thread th=new Thread(new ParametrizedThreadStart(MyTcpConnection));
    thlist.Add(th);
    th.Start();
   }

   foreach(Thread in thlist)
   {
       th.Join();
   }

}

In pratica con un thread del servizio che funge da coordinatore, e ciascun thread che accetta in input almeno la connessione, qui una TcpConnection;
All'uscita dei Thread la connessione viene distrutta da sola.
Resta che bisogna assicurarsi della robustezza dei Thread, altrimenti se anche solo uno di questi entra in deadlock l'applicazione si ferma.

Per la seconda invece e' un po piu' difficile.
Innanzitutto devi decidere se dotare il tuo servizio anche di una form, che potrebbe essere la strada piu' facile ma e' anche la piu' brutta.
Normalmente un servizio non ha una UI perche' potrebbe addirittura funzionare anche quando nessun utente e' loggato alla macchina.
Per questo motivo questa strada e' normalmente considerata "sporca", ed occorre fare tanti controlli per evitare eccezioni.

La strada migliore sarebbe quella di dotare la tua soluzione anche di un progetto Form, il quale all'inizio deve cercare fra i servizi della macchina quello con il nome giusto, usando la System.ServiceProcess che dovrai aggiungere alle risorse della Form (PS: Il nome di un servizio viene dato nell'altro progetto che dovresti avere, ovvero l'installer del servizio).
Da mi vengono in mente varie.
O cerchi di registrare la tua form sul servizio ed instauri un dialogo locale tra la form ed il servizio stesso. Per fare cio' potresti implementare la ExecuteCommand sul servizio (non solo quindi start, stop, etc.), che fornisce funzionalita' di comandi custom da mandare al servizio stesso. Non so se si riesce ad inventare qualcosa come "passare al servizio un delegate, oppure un handle generico", per fare in modo di gestire una callback, ovvero che la nostra form possa venire chiamata quando sul servizio succede qualcosa.

Oppure puoi gestire tutto con il .net remoting, che ti permetterebbe di monitorare e comandare il tuo servizio anche da un'altra macchina, non per forza quella locale. Sarebbe un vero e proprio servizio, inteso come qualcosa che serve a qualcuno, che prescinde da molte cose (tranne dall'esistenza della rete).

Ma scusa, sei sicuro comunque che non ti basti fare un'applicazione normale, magari di quelle che risiedono solo sulla taskbar? Se veramente richiede che l'output sia in forma grafica non vedo perche' non possa essere cosi'.