[C#] Threading (funzioni obsolete)

sabato 07 febbraio 2009 - 12.54

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

mciasco Profilo | Newbie

7 messaggi | Data Invio: sab 7 feb 2009 - 12:54

Sto facendo alcune prove con il threading in .Net in C#. Non capisco perchè le funzioni suspend() e resume() sono marcata "deprecated". Come linea guida msdn (e anche il debugger di Visual Studio) indica di "utilizzare altre strutture per la sincronizzazione dei thread, come Monitor, Semafori e Mutex".
Ma che c'entrano monitor & co. con il fatto di sospendere e riavviare un thread? Perchè dovrei scomodare queste strutture tipicamente per la concorrenza?

Tra l'altro parallelamente notavo che come struttura principe per il threading viene consigliato il BackgroundWorker che però fornisce solo i metodi per avviare e abortire un thread. Niente suspend e resume.

Sono perplesso.

Jeremy Profilo | Guru

1.527 messaggi | Data Invio: sab 7 feb 2009 - 13:01

Devi usare la classe Thread che trovi sotto il namesapce System.Threading.....

System.Threading.Thread newthread=new System.Threading.thread();
newthread.start

Facci sapere....
Ciao

mciasco Profilo | Newbie

7 messaggi | Data Invio: sab 7 feb 2009 - 15:38

Si sto già usando la classe Thread. Però non capisco perchè le funzioni suspend() e resume() sono deprecate. O meglio, capisco il problema di fondo (chimare una suspend() su un thread potrebbe bloccare indefinitamente delle risorse concorrenti e quindi altri thread), ma non capisco perchè definirle "deprecated". Se voglio usarle le uso a mio rischio e pericolo no? Potenzialmente tutto è "deprecated" allora...

Poi il discorso sul BackgroundWorker è che Microsoft lo indica come classe preferibile per implementare thread asincroni in background. Però non permette di sospendere il thread associato. Sempre per il problema del "deprecated" immagino.

Morale della favola... non sembra essere fornita una metodologia ufficiale per sospendere e ripristinare thread in .Net.

pigi78 Profilo | Newbie

17 messaggi | Data Invio: sab 7 feb 2009 - 15:56

Ciao.

Provengo dal mondo Java e penso che le scelte fatte da MS siano molto simili.
Intanto suppongo che "deprecared" sia necessario non tanto per indicare "può causare problemi", quanto "nelle prossime versioni del framework potrebbe non essere più disponibile". Sottolineo il "suppongo" poichè questa era la linea guida in Java ma mi pare di aver letto qualcosa di simile anche lato .NET

Perchè fare questo in un metodo che "ferma" un thread? Semplice: quando lo richiami non sai cosa stia facendo il Thread e gli scateni un evento, anzi una eccezione. Pertanto potresti trasformare l'oggetto "sospeso" in qualcosa di inconsistente.

Perchè consigliano di usare i semafori o similari? Beh, ti faccio un esempio semplice per capire meglio.

Supponi di avere un thread che ogni 5 secondi legge un file ed aggiorna un DB. Per gran parte del tempo il thread dovrebbe essere fermo (5 sec) e per poco tempo aggiorna il DB. Se tu lanci un metodo com'era il suspend, chi ti garantiva che il programma fosse nel periodo di attesa? Ok, probabilmente lo sarebbe stato, ma potrebbe anche capitare che il suspend arrivasse nel periodo di aggiornamento generandoti una eccezione. A quel punto ti saresti dovuto preoccupare di gestirla e scegliere cosa fare coi dati del db che stavi aggiornando... Ti posso garantire che non è cosa cemplice.

Con il semaforo, invece, tutto si semplifica.
Il thread, quando è in sleep (5sec) libera il semaforo. Allo scadere del tempo, blocca il semaforo, aggiorna il db e poi libera il semaforo prima di entrare in sleep di nuovo.
Se lo devi "sospendere" ti basta bloccare il semaforo che lui usa. Se lo fai nei 5 secondi di sleep del thread, la chiamata a WaitOne esce subito e blocca il thread. Se invece il thread sta aggiornando il db, ne attende la fine e poi ti restituisce il controllo.
In entrambi i casi il thread è stato sospeso (se liberi il semaforo riparte) e non hai dovuto controllare nessuna eccezione.

Questo è il motivo per cui quei netodi sono considerati deprecati... Alla fine risultano più pericolosi che altro. Ogni thread lavora a modo suo, pertanto è importante che sia il programmatore a decidere "quando può essere fermato"...

Spero sia chiara la spiegazione

Jeremy Profilo | Guru

1.527 messaggi | Data Invio: sab 7 feb 2009 - 15:59

Prova a dare un occhio a questo link:

http://lia.deis.unibo.it/Courses/RetiLA/RetiLA_04-05/materiale/lezioni/threadjx2.pdf

Facci sapere...
Ciao

mciasco Profilo | Newbie

7 messaggi | Data Invio: sab 7 feb 2009 - 16:22

Si scusate... non intendevo dire che non ha senso definirli deprecated quei due metodi. Comprendo perfettamente la pericolosità di fare una suspend() su un thread quando non si sa bene cosa stia facendo in quel momento. Però, come è ovvio in questi casi, deprecated sta a significare che nelle prossime release del framework è facile che spariscano.
Ora, questo ha senso se effettivamente esiste già un metodo alternativo e considerato sicuro o comunque preferibile per sospendere i thread, ma non mi pare che .Net lo indichi.
Indicare genericamente di usare Monitor e Semafori è come dire "spara con il cannone ai passeri". Potrei voler sospendere un thread ed essere sicuro del suo comportamento. Quindi perchè indicarmi che quelle funzioni sono "deprecated" quando non mi si fornisce una valida alternativa?

mciasco Profilo | Newbie

7 messaggi | Data Invio: dom 8 feb 2009 - 17:34

Tra l'altro ora noto anche che le funzioni Abort() e Interrupt() che sostanzialmente hanno l'effetto di fermare un thread non sono "deprecated" come Suspend() e Resume(), però mi pare che la pericolosità di stoppare un thread in esecuzione sia identica a quella di sospenderlo.

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !