Newsgroup: it.comp.lang.visual-basic
Titolo: [.Net 1.1] RealTime e Garbage Collection

Ciao a tutti.
Da qui a breve dovrò sviluppare in .Net un programma RealTime che dovrà
controllare una linea di produzione.
Per far ciò dovra dialogare in RealTime in rete (socket) e/o in seriale
(RS232) con protocolli proprietari o meno.
Quello che mi spaventa è il Garbage Collection che quando gli gira blocca il
processo, anche per qualche secondo, per fare pulizia degli oggetti morti.
Se mi blocco il mio processo mentre sto facendo qualcosa di critico in
RealTime (sempre) è un grosso grosso problema.
Volevo chiedere è:
1) Ma il  garbage Colletion blocca tutti i processi .Net quando opera o no?
2) Blocca tutti i Thtread o solo quello principale?
3) C'e' modo di farlo andare in modo che non blocchi in modo secco
l'esecuzione del programma?
Ciao e Grazie
Ettore Maronese, il Mes chiede consiglio

 l'esecuzione del programma?
Se per una richiesta successiva la mememoria scarseggia, generalmente,
viene chiamato ad operare il GC.
Il GC lavora in un thread separato ad alta priorità, quindi blocca quello
in esecuzione.
Se vuoi forzare l'esecuzione:
GC.Collect()
GC.WaitForPendingFinalizers()
Il primo forza l'esecuzione, il secondo blocca il thread in esecuzione.
Se digiti System.GC.
dopo il punto si presentano i metodi che puoi utilizzare con il GC
Ave
giuseppeD
---
CCR
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 processo, anche per qualche secondo, per fare pulizia degli oggetti morti.
Beh... fare progetti in vero realtime in Windows (che non è realtime) è 
sempre un rischio... ma che te lo dico a fare?
Questo dovresti ben saperlo :)
Ciao 

 in esecuzione.
mmmm...io ho sempre saputo che GC lavora come thread a priorità dinamica....
Di solito lavora a bassa priorità (in condizioni normali) e si attiva quando 
il processore non è impegnato.
Man mano che la memoria diminuisce , il thread della GC aumenta di priorità.
E ricordati che se lavori con variabili tipi di valore non dovresti avere 
problemi di GC, perchè vengono allocati sullo stack e non sull'heap (che è 
riservato a variabili tipi di riferimento e che viene gestito dalla GC 
attraverso il CLR , sullo stack hai solo il puntatore a tale oggetto.)
Sperando di non aver scritto grosse fesserie (son andato a memoria)...
Umbe 

 attraverso il CLR , sullo stack hai solo il puntatore a tale oggetto.)
I tipi di riferimento e i puntatori sono allocati nella memoria dello
stack, e la memoria è liberata all'uscita dell'area di visibilità o
oggetto=nothing.
Non mi risulta che l'area di stack è controllata dal GC.


 Non mi risulta che l'area di stack è controllata dal GC.
O hai sbagliato la parola "riferimento" o c'è qualcosa in contrasto con il 
concetto di "indeterministico".
Ciao. 

 Non mi risulta che l'area di stack è controllata dal GC.
no..no..i dati associati ad un tipo di VALORE vengono allocati sullo stack 
(e qui GC non c'entra), mentre una variabile di tipo riferimento è presente 
SIA sullo stack che sull'heap. Sull'heap c'e' l'oggetto vero e proprio (i 
suoi dati e viene gestito da GC), mentre sullo stack hai il puntatore 
all'oggetto che è sull'heap (e come detto prima GC con l'heap nun ci 
azzecca). Paradossalmente (mica tanto poi se ci pensi) potresti avere un 
oggetto allocato sull'heap ma non piu' il puntatore sullo stack per 
gestirlo.
Umbe

Zanna ha scritto:



Venia
I tipi di calore. cioè i ValueType


 I tipi di calore. cioč i ValueType
ROFTL....anche la mia cagnona ha dei tipi di calore...... ;-)
Umbe 

 no..no..i dati associati ad un tipo di VALORE vengono allocati sullo stack 
Venia,
nello stack ci sono i ValueType.


Umbe ha scritto:


Spengo il pc e vado a casa,
mi sa che č meglio.
giuseppeD


 ha scritto nel messaggio
news:4381c...@x-privat.org...

Premessa: Scrivo la risposta, ci metto 15 minuti.. poi dico.. faccio un
"copia" cosi' se si inchioda ho tutto salvato nella clipboard, faccio Send,
SI INCHIODA "Guarda Fuori Espresso", apro un notepad, faccio incolla...
nulla... ... ... eccomi a riscrivere da capo l'email... chissà se me la
ricodo... :((
Rispondo qui a tutti sperando di non offendere i buon giuseppeD e Umbe
nell'altro thread ^_^
Zanna: lo so... lo so... Winzoz ed il RealTime non è che vadano molto
daccordo :)  Diciamo che per programmi RealTime ma non Time Critical Winzoz
va ancora bene (o meglio, te lo fai andare bene), alla fine nella maggior
parte dei casi anche se il programma RealTime subisce ritardi di 200mSec va
bene uguale, ma se sti ritardi arrivano a 2 secondi le cose cambiano.
giuseppeD e Umbe:
Il funzionamento dello stack, dei tipi riferimento, dell'heap, dei tipi
valore (e mettiamoci dentro pure i puntatori e la loro aritmetica) fanno già
parte del mio bagaglio culturale; sono comunque felice che il mio post sia
stata spunto per divulgare ulteriormente questi argomenti, spesso
sconosciuti ai programmatori novelli (e non).
X Tutti:
Come detto non ho ancora iniziato a fare prove pratiche col RealTime e
protocolli seri, e dato che dovro' svilupparne prossimamente ho veramente
paura di picchiarci pesantemente la testa e farmi parecchio male.
Quello che ho notato è che il Garbrage riesce a bloccarmi un applicativo
anche per 2...5 secondi, e se 250mSec di ritardo può ancora starci, 2
secondi sono troppi per un RealTime.. non ne parliamo di 5.
Mi premerebbe sapere se qualcuno ha già fatto applicativi "RealTime" e/o
Protocolli  in .Net, se ha avuto problemi co Garbrage e che ne è uscito.
Per esempio i seguenti dubbi mi attanagliano:
- Se ho un mio programma RealTime che gira ed un secondo programma (non mio
o mio) scritto in .Net inizia ad allocare oggetti come un pazzo, obbligando
il Garbrage ad intervenire con alta priorità, che ne è del mio RealTime? Già
se si avvia un secondo programma .Net il sistema (.net) viene stressato sia
come processore che come l'heap, se poi ci si mette anche il Grabrage sono
fritto..
- E se pongo le procedure che non possono subire ritardi oltre i 250mSec
(RealTime/Protocolli) in Thread separati ad altissima priorità? E'
possibile? è possibile stare più alti della massima priorità assumibile dal
Garbrage?
- C'e' qualche altro modo per far si che un RealTime non collassi quando al
Garbrage vengono strani pruriti?
Grazie a Tutti quanti,
Ciao
Ettore Maronese, il Mes
http://www.it-lang-vb.net
   << Il Migliore
Evitate di applicare il rasoio di Occam: "Pluralitas non est ponenda sine
necessitate", perchè significa rifugiarsi nella pigrizia.
PS: IL MSG NON MI E' VENUTO UGUALE UGUALE A QUELLO CHE HO PERSO COL CRASH,
MA CI HO PROVATO :-/

 Garbrage vengono strani pruriti?
Posto che ne so (molto) meno di chi ti ha già risposto, e che non ho esperienze pratiche in merito...
1. La documentazione sul GC è sempre stata, è (e, probabilmente, sarà sempre) lacunosa per non dire reticente. La mia personale opinione è che nessuno (neanche in Microsoft) sappia esattamente cosa possa fare, e quando;
2. Da quello che ho capito, dubito che un thread managed possa avere priorità maggiore o uguale a quella del GC che, dopotutto, è (parte del) framework;
3. E se il tuo thread salva-realtime diventasse un processo, scritto magari in linguaggio non-managed? Sporco sporchissimo (anche perché ti metti nelle mani dell'accoppiata windows+framework per l'ipc...), ma io farei così. Soprattutto se lo scopo di quel thread fosse una cosa tipo "evita che il nocciolo superi i 1000 gradi", cioè con basse esigenze di comunicazione col resto dell'applicazione.

 Garbrage vengono strani pruriti?
sinceramente non lo so.
il giorno che lo scopriro` prendero` in considerazione .net.
allo stato attuale preferisco scrivere in c++.
-- 
ciao, hal

 
ma il metodo dispose non fa scaricare immediamenta la memoria invece 
della close?

 close?
Mi puoi riscrivere in modo comprensibile questa domanda?
Ciao 

 secondi sono troppi per un RealTime.. non ne parliamo di 5.
La mia esperienza in .Net è ancora scarsa, però un GC che gira per 2 secondi 
inchiodando il tutto mi lascia un po' perplesso...
Significa che hai la memoria satura di oggetti da distruggere... sicuro di 
averli disposti *tutti*?
Per qualche delucidazione sul funzionamento prova a dare un'occhiata qui:
http://www.microsoft.com/italy/msdn/eventi/webcast/passati/Framework.mspx
In particolare
"Gestione della memoria e delle risorse in .NET"
e
".NET: ambiente di esecuzione"
Ciao 

 nell'altro thread ^_^
Figurati...ci mancherebbe altro....ti leggo da troppo tempo e i tuoi 
consigli spesso mi sono stati di grande aiuto...
[CUT]

Io ho paura che con .Net non si sia fatto un passo in avanti in termini 
prestazionali ( ma ancora non lo conosco in tutte le sue sfumature per dirti 
che effettivamente è così).
Ergo, se già con VB6 il realtime era una chimera, con .Net la cosa si è 
allontanata ulteriormente.
A mio avviso ha ragione il buon Hal...è inutile che ce la giriamo...se ci 
sono delle applicazioni timecritical, ci vuole C++.
Umbe 

 ".NET: ambiente di esecuzione"
Questo lo sevo ancora vedere.
Ciao
Ettore Maronese, il Mes
PS: Scusate i ritardi nelle risposte.. siamo alle solite, il server News
che usavo non mi fa più postare, troppi post dal mio IP :(((  [grazie a
pale per il link a 
newsland.it
]


 allo stato attuale preferisco scrivere in c++.
Haimè ho preso la decisione di scrivere in .Net. VB6 lo sto man manoi
abbandonando.
il C++ è troppo oneroso, già con .Net i tempi di sviluppo si sono
tripolicati rispetto a VB6 per il solo fatto che non puoi fare modifiche
al codice durante il Debug; il C++ aggiunge il problema che è facile che
un errore ti mandi in crask il processo intero, ed in definitiva i tempi
di sviluppo sono ancora più lunghi.
Attenzione che so ben programmare in C++ e so quel che vale!
Ciao
Ettore Maronese, il Mes
PS: Scusate i ritardi nelle risposte.. siamo alle solite, il server News


 quindi da li a poco il GC interviene, ed interviene pesantemente.
Allora riformulo la domanda.
Sei sicuro che il blocco sia opera del GC?
Mi pare piů che altro il classico problema di risorse scarse o del fatto che
la compilazione di un metodo avviene alla sua prima chiamata e non alla
partenza dell'app.
Ciao
--
Reporting tool: 
http://www.neodatatype.net

 partenza dell'app.
No sono sicuro sia il GC.
Me lo fa dedurre il fatto che le prime volte che l'ho visto accadere ho
provato ad inseguirlo, a vedere dove capitava, ma continuava a spostarsi
da una funzione a un'altra, da un form all'altro.
C'e' una cosa importante che non ho detto, ovvero che mi succede solo
quando lancio il programma in Debug. Se (pur avento tutti il sistema di
sviluppo apert) lancio l'eseguibile (compilato in modo debug) il blocco
non avviene, o de avviene non lo si rileva.
Ciao
Ettore Maronese, il Mes
(ps: che ne dici di andare il 18 dicembrea a Modena a mangiare con Pal e
la combricola?)
PS: Scusate i ritardi nelle risposte.. siamo alle solite, il server News
che usavo non mi fa più postare, troppi post dal mio IP :(((  [grazie a
pal per il link a 
newsland.it
]


 la combricola?)
Beh, questo mi sembra un problema su cui ci si può riflettere ;)
Volentieri, se non saltano fuori problemi con quella data.
Ciao 

 No sono sicuro sia il GC.
Per essere sicuro che è il GC,
costruisci una classe aggiungendo il metodo finalize. Nel metodo un 
debug.writeline o altra operazione che segnali che il GC finalizza la 
classe.
La istanzi due o tre volte all'inizio.
Appena entra in funzione il GC finalizzerà la classe.
Così saprai se il GC è in funzione in quel momento.
Ricordo che liberata la memoria, il GC compatta l'area occupata dagli 
oggetti e li sposta, quindi modifica la direzione dei puntatori che si 
trovano nello stack.
Ave
giuseppeD
---
CCR