Newsgroup: it.comp.dotnet
Titolo: Sospendere un thread

Ciao a tutti,
ho una interfaccia
interface IEventRaiser
{
	event EventHandler MyEvent;
}
questa interfaccia viene iniettata in una classe:
class EventWaiter
{
	protected IEventRaiser er;
	public EventWaiter(IEventRaiser er)
	{
 
this.er
 = er;
	}
	public void Wait() { ... }
}
il metodo Wait() deve in pratica "aspettare" il verificarsi dell'evento 
er.MyEvent. Ho provato a implementare la cosa così:
public Wait() {
	var evt = new ManualReserEvent(false);
	this.er.MyEvent += (s, e) => { evt.Set(); }
	evt.WaitOne();
}
Ora, credo che a lungo andare (i.e. diverse istanze di EventWaiter) 
l'uso massiccio di WaitHandle possa degradare le performance. Avevo 
pensato allora di passare a Thread.Suspend()/Resume().
Cosa ne pensate?
Ciao e grazie,
Giulio

 di passare a Thread.Suspend()/Resume().
Non temere dregradi, va benissimo usare gli eventi.
Se l'evento è locale al tuo processo, puoi usare la versione Slim che 
probabilmente ricorderai dalla mia sessione.
Inoltre ti suggerisco caldamente di usare WaitHandle.WaitAny 
specificando un array di handle:
- il primo handle è un altro evento, di quit, per poter chiudere 
'gracefully' il thread nel caso l'utente voglia interrompere tutto
- il secondo è quello che ti serve come waiter (quello che hai 
postato).
Ciao
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 - il secondo è quello che ti serve come waiter (quello che hai postato).
  Già fatto. :-)
Ciao,
Giulio
-- 

 assembly/namespace?
Trovate! :-)
Era il "Task" che mi sfuggiva (e visto che sto lavorando sul fx3.5 
l'intellisense non mi aiutava nemmeno... :-)).
Ciao,
Giulio
-- 


okappa.... usa fx 4.0 se puoi perché è una rivoluzione :)
diversamente, e se proprio non puoi fare diversamente, leggi qui come 
procurarti una versione unsupported:
http://blogs.msdn.com/b/pfxteam/archive/2009/11/19/9925951.aspx
Se usi i task puoi evitare il proliferare inutile di thread che 
appesantirebbero la macchina senza dare effettivi vantaggi.
Come dicevo l'altro giorno:
- se ogni task è grossomodo sotto i 500ms puoi lasciare lo scheduler di 
default e creare un task per ogni 'unit of work'
- se il task può impiegare più tempo, il meccanismo automatico di 
starving detection farebbe partire più thread di quelli effettivamente 
necessari. Di conseguenza puoi risolvere in uno di questi modi:
 * SetMaxThreads per evitare di andare oltre una soglia da te 
stabilita. Questo però impatta su tutto il thread pool del tuo 
processo. Per capirci non farlo mai dentro 
asp.net
 * Scheduler custom. Abbastanza semplice da scrivere e puoi decidere tu 
la logica che preferisci per lanciare nuovi thread
In ogni caso pensare a 'task' è vitale per strutturare in modo organico 
la logica multithreading.


 default e creare un task per ogni 'unit of work'
Il problema è che i miei task possono avere durata anche di 10 minuti! :-)
Ti spiego qual è il problema "generale" così magari mi puoi/potete dare 
qualche parere più mirato. Ho un demone che gira sempre (ultimamente ho 
sempre a che fare con questa roba :-p), ogni tanto carica da una rubrica 
delle schede di alcuni dipendenti e per ognuna di queste lancia il 
seguente job:
- prende il numero di telefono del dipendente
- mandagli un SMS
Alla ricezione del SMS, il dipendente apre la sua applicazione 
Acme.MyApp e preme un bottoncino "Sms ricevuto". La pressione del 
bottoncino scrive qualcosa su un database del server dove gira il demone.
Il problema sta tutto qui: l'oggetto che rappresenta il Job deve 
rimanere "su" finché nn rileva "tramite polling" una variazione dello 
stato del db, a meno dell'occorrenza di un certo timeout (partendo 
dall'assunto per cui ogni job deve prendere un thread).
Quale può essere una strategia corretta per implementare una cosa del 
genere?
Grazie,
Giulio
-- 

 job deve prendere un thread).
[...]
Invece di far rimanere su un task per ogni sms, io farei girare un 
thread secco che fa polling di qualsaisi risposta agli sms.
Facendo una query sul db puoi facilmente vedere quali sono gli sms che 
hanno avuto una risposta ma che non sono ancora stati processati.
Li peschi in blocco, li iteri (magari ce n'è uno solo), e infine li 
smisti a chi li deve processare.
Ciao


 okappa.... usa fx 4.0 se puoi perché è una rivoluzione :)
ardisco intromettermi in un 3D fuor della mia portata, 
inquieto per la suddetta dichiarazione ... in che senso 
rivoluzione ? Codice scritto per i framework precedenti deve 
essere riscritto ? Cambia la struttura dei namespace e 
simili ? O soltanto vengono aggiunte funzionalità e/o 
migliorate le performance ?
ciao
Soviet


 le performance ?
no, no ferma :)
La compatibilità con le tecnologie precedenti c'è tutta.
Ci sono alcune cose (per esempio workflow foundation) che sono state 
riscritte ed è caldamente suggerito di passare alle novità (ma le 
vecchie funzionano come prima).
Quelle a cui alludevo sono le novità, soprattutto per quanto riguarda 
il topic in oggetto.
Le nuove parallel libraries sono di fontamentale importanza e hanno un 
approccio radicalmente diverso (rivoluzionario) rispetto a quanto si è 
sempre fatto lavorando direttamente con i thread.
E poi le novità nel linguaggio, in wcf, wpf, .... insomma tutte novità 
che possono veramente farti scrivere parecchio codice in meno.


 thread secco che fa polling di qualsaisi risposta agli sms.
Ci credi se ti dico che stavo muovendo verso questa soluzione proprio ora?
:-D
Ciao,
Giulio
-- 

 :-D
Ottimo :)
