[c#]Eseguire molti thread può portare svantaggi?

[MonsterMash]

Sto sviluppando un programma in cui potenzialmente possono venire aperti tantissimi thread (centinaia, forse addirittura migliaia), ciascuno eseguirà un'operazione, solitamente abbastanza semplice, e poi morirà.
Una situazione del genere può portare a svantaggi di qualche genere?

Grazie a tutti.

Ciao

[oregon]

Beh ... sicuramente potresti avere un peggioramento delle performance, piuttosto che il miglioramento che credi ... specialmente con poche CPU/Core disponibili ...

Ma andrebbe testato ...

Che ci fai con migliaia di thread?

[MonsterMash]

Originariamente inviato da oregon
Beh ... sicuramente potresti avere un peggioramento delle performance, piuttosto che il miglioramento che credi ... specialmente con poche CPU/Core disponibili ...

Ma andrebbe testato ...

Che ci fai con migliaia di thread?

Non sarò io a creare i migliaia di thread .
La libreria che sto facendo permetterà di generare blocchi funzionali da connettere tra loro, ed ogni blocco, quando riceve un input, apre un thread e calcola il proprio output. E il numero dei blocchi utilizzabili è virtualmente infinito. Considerato l'ambito in cui dovrà essere utilizzata però è molto difficile che possano essere generati più di qualche centinaia di blocchi. Per tenermi largo ho detto migliaia.

L'utilizzo dei thread è stato necessario perchè senza avrei dovuto eseguire sequenzialmente il calcolo degli output di ogni blocco, e mi sarei trovato a non poter eseguire parallelamente il calcolo su due blocchi che ricevono un input in contemporanea. In definitiva avrei avuto un'esecuzione asimmetrica, con parte della catena con output sempre aggiornati, e parte della catena con output sempre più vecchi.

[oregon]

Vale quello che ti ho detto e che ti ho chiesto ... anche se non li crei tu, che ci fai con tutti quei thread (per dirla diversamente, cosa fa il programma con tutti questi calcoli paralleli)?

[MonsterMash]

Originariamente inviato da oregon
Vale quello che ti ho detto e che ti ho chiesto ... anche se non li crei tu, che ci fai con tutti quei thread (per dirla diversamente, cosa fa il programma con tutti questi calcoli paralleli)?

Ripeto che si tratta di blocchi programmabili a piacimento. Io ho implementato solo alcune funzioni base (blocco sommatore, moltiplicatore, ritardatore, guadagno, duplicatore, etc, etc), ma è possibile estendere la libreria implementando nuove operazioni. Poi il come e il perchè verrà usato il tutto dipende unicamente dall'utilizzatore.

L'obiettivo per il momento sarà fare una struttura che prenda N input da N sensori di natura diversa, li elabori secondo operazioni che li porti ad essere confrontabili tra loro, e che poi effettui il data-fusion. Poichè il numero, il tipo e la sensibiltà dei sensori, oltre all'ambiente in cui verranno piazzati, può variare parecchio, la libreria è aperta e configurabile. Il numero ed il tipo delle operazioni da effettuare su ogni input generato dai sensori dipende da mille fattori, per cui i blocchi che eseguono queste operazioni possono essere aggiunti, eliminati, spostati, modificati, etc, il tutto runtime.

Il problema è che, ripeto, ognuno di questi blocchi (o per essere esatti, ogni porta di input di ciascun blocco) da' vita ad un nuovo thread nel momento in cui riceve un input da elaborare. Per cui mi chidevo, dato che non ho ancora avuto modo di fare test sulle prestazioni e sull'utilizzo di risorse, se tutto questo porti a svantaggi di qualche genere (pensavo anche ad un eventuale sovraccarico dello scheduler del SO, che potrebbe andare in tilt, consumare troppa memoria, rallentare il processo, o altro di simile. Anche considerato che si tratta di una libreria che, ahime', girerà sotto windows).

[oregon]

Certo, avrai bisogno di una macchina abbastanza performante ... Pero' non credo avrai problemi di "tilt" (ovviamente, dopo un certo limite, con qualsiasi sistema operativo, li avresti ...).

La cosa migliore e' un test pratico.

[riccardone]

Se non hai bisogno di particolari features da impostare sui vari thread (es. assegnare priorità diverse da quella di default) puoi usare la classe threadpool che per operazioni brevi è più efficente. In generale, per default non ci sono più di 25 thread in esecuzione contemporaneamente sulla stessa cpu anche se ne hai fatti partire 100. Mano a mano che finiscono i primi entrano in gioco quelli in attesa in coda. Altra considerazione, se hai molti thread cpu intensive in esecuzione contemporaneamente, ti ritrovi con il computer impiantato. Meglio pochi thread che sfruttano in maniera più efficente la cpu magari con alta priorità. Occhio poi che se i thread dipendono tra di loro, il procedimento di sincronizzazione e di lock potrebbe diminuire i vantaggi del multithreading.