Lavorare con i thread

[bonmario]

P.S. Qualcuno sa dirmi come valutare come impostare il n° massimo di thread contemporanei? Ho provato con 20 ed il PC sembra reggere, ma siccome il programma dovrà girare anche su altri PC più o meno potenti, volevo evitare di sovradimensionare tale numero.

Ciao a tutti,
vorrei riproporre la domanda qui sopra citata ... c'è una qualche regola da seguire quando si fanno girare più thread contemporaneamente, per stabilirne il numero massimo? Qualcosa in base alla memoria, al n° di core o altro?

Grazie in anticipo, Mario

[Stilgar]

Oddio, quando sganci un thread dovresti "fregartene" del numero massimo di questi attivi.
Devi delegare al Sistema operativo questo genere di rogne ... altrimenti dovresti tenere conto anche degli altri processi. Non lavorando in DOS ... dove avevi il controllo completo della macchina e non era multi process ... diventa una regola assurda quella che mettresti in piedi.
In generale prova a vederli come Workers ...
Di quanti ne hai bisogno veramente?
Un server web sgancia un thread (vedi apache che funziona decentemente) per ogni client che si connette. Se ci dovessimo fissare con un numero massimo di workers, non potresti andare oltre un certo numero di connessioni nello stesso momento. Server veramente limitare il numero di connessioni?
La regola che seguo io (in Java) è : cosa mi serve sincrono e cosa mi serve asincrono.
In questo modo evito di gestire con i thread i bottoni (... non ditemi che è una cagata.... lo so anche io ... ma spiegatelo voi ad un ingegnere fresco di laurea ... d'altra parte io sono solo perito industiale ...).
Tieni conto che un processo è un thread, quindi il numero minimo lo sai a priori 1 :p
Il numero massimo è in base alle tue esigenze.
Al massimo puoi fare un programmino che faccia inchiodare il processore con un uso massivo di thread che non facciano IO (altrimenti li rendi sincroni sul disco).
Non so ... calcolo massiccio ... mi viene in mente il fattoriale per semplicità di implementazione. Vuoi far fare il calcolo del Pgreco ...
Lo trovo in esercizio accademico, non molto utile nella vita di tutti i pc ... ops giorni

Stilgar

[bonmario]

Il dubbio mi è venuto per il tipo di programma che sto facendo. Praticamente, data in input il percorso di una directory, cerco tutti gli mp3 contenuti e li ricodifico lanciando un eseguibile esterno.
Se ad esempio la directory contiene 1000 mp3, mi sembrava assurdo lanciare 1000 thread di ricodifica contemporanei. Così li lancio 10 alla volta e, appena ne termina uno, lancio il successivo.


Ciao, Mario

[Stilgar]

Ok, hai diviso il numero di operaziononi potenzialmente ammazza PC in più thread.
Nulla di sbagliato nel tuo approccio, anzi. Uso intelligente dello strumento.
A questo posso (se permetti) aggiungere un consiglio, dare questa "dimensione" in mano all'utente. Aggiungere un grado di libertà.
In moltri spider web trovi la possbilità di mettere il numero di download contemporanei. (Alla fine sono thread... capiamoci).
Se il tuo programma dovesse girare con una macchina rapida, con dischi veloci, magari un 20 thread che convertono in parallelo non sarebbe male.
Ma sbattendo contro un disco USB, magari a 3600 giri, su USB 1.0, magari 10 thread sono tantini.
La mia era solo la solita considerazione da menagramo

Stilgar

[bonmario]

Ottima idea !!! Devo rivedere qualcosina nell'approccio, ma penso che lasciar scegliere il n° di thread all'utente sia fattibile.

Grazie ancora, Mario

[bonmario]

Ti allego un pool scritto di fretta e furia.
Ti posso solo garantire che compila. L'idea è deleare a lui il fatto di gestire i thread.
Ho scoperto con mio sommo disappunto che la properties Terminated è stata nascosta ...  il pool introduce una classe Thread che assomiglia vagamente a quella Java.

Lo start e lo stop sono delegati al monitor
Prova a buttarci un occhio, per farti un'idea

Ciao, in queste sere avevo un po' di tempo e stavo riguardando il tuo post che ho quotato.
Facendo un po' di ricerche, ho scoperto per caso l'esistenza del componente "multithreadprocs" che si trova in "lazarus/components/multithreadprocs" che, da quel che ho capito, dovrebbe fare lo stesso lavoro che fa il pool che mi hai allegato.

Qualcuno di voi ha mai usato il "multithreadprocs"?

Ciao, Mario

[bonmario]

Ciao a tutti,
vorrei riproporre la domanda qui sopra citata ... c'è una qualche regola da seguire quando si fanno girare più thread contemporaneamente, per stabilirne il numero massimo? Qualcosa in base alla memoria, al n° di core o altro?

Grazie in anticipo, Mario

Oggi avevo un po' di tempo, ed ho fatto un programma di prova.
I test li ho fatti sul mio PC che ha 4 processori, ognuno dei quali ha 2 core.
Il programma lancia la ricodifica di 25 brani mp3.
LA prima volta ho fatto in modo che lanciasse le ricodifiche una alla volta, poi 2 in parallelo, poi 3 in parallelo, e così via fino ad 8 in parallelo. Ogni prova l'ho ripetuta per 5 volte e l'ho fatta girare con il PC completamente dedicato a questo test, in modo da non avere "interferenze".
Questo è il risultato:

Codice: [Seleziona]

N° di processi in parallelo:  1    -  Tempo impiegato: 04 Minuti,  58 Secondi,  524 Millesimi
N° di processi in parallelo:  1    -  Tempo impiegato: 04 Minuti,  58 Secondi,  232 Millesimi
N° di processi in parallelo:  1    -  Tempo impiegato: 04 Minuti,  57 Secondi,  116 Millesimi
N° di processi in parallelo:  1    -  Tempo impiegato: 04 Minuti,  57 Secondi,  524 Millesimi
N° di processi in parallelo:  1    -  Tempo impiegato: 04 Minuti,  57 Secondi,  826 Millesimi
N° di processi in parallelo:  2    -  Tempo impiegato: 02 Minuti,  36 Secondi,  312 Millesimi
N° di processi in parallelo:  2    -  Tempo impiegato: 02 Minuti,  36 Secondi,  578 Millesimi
N° di processi in parallelo:  2    -  Tempo impiegato: 02 Minuti,  36 Secondi,  798 Millesimi
N° di processi in parallelo:  2    -  Tempo impiegato: 02 Minuti,  36 Secondi,  596 Millesimi
N° di processi in parallelo:  2    -  Tempo impiegato: 02 Minuti,  37 Secondi,  401 Millesimi
N° di processi in parallelo:  3    -  Tempo impiegato: 02 Minuti,  20 Secondi,  980 Millesimi
N° di processi in parallelo:  3    -  Tempo impiegato: 02 Minuti,  17 Secondi,  397 Millesimi
N° di processi in parallelo:  3    -  Tempo impiegato: 02 Minuti,  17 Secondi,  180 Millesimi
N° di processi in parallelo:  3    -  Tempo impiegato: 02 Minuti,  18 Secondi,  647 Millesimi
N° di processi in parallelo:  3    -  Tempo impiegato: 02 Minuti,  19 Secondi,  700 Millesimi
N° di processi in parallelo:  4    -  Tempo impiegato: 02 Minuti,  03 Secondi,  885 Millesimi
N° di processi in parallelo:  4    -  Tempo impiegato: 02 Minuti,  05 Secondi,  175 Millesimi
N° di processi in parallelo:  4    -  Tempo impiegato: 02 Minuti,  04 Secondi,  278 Millesimi
N° di processi in parallelo:  4    -  Tempo impiegato: 02 Minuti,  04 Secondi
N° di processi in parallelo:  4    -  Tempo impiegato: 02 Minuti,  04 Secondi,  119 Millesimi
N° di processi in parallelo:  5    -  Tempo impiegato: 02 Minuti,  03 Secondi,  859 Millesimi
N° di processi in parallelo:  5    -  Tempo impiegato: 02 Minuti,  03 Secondi,  208 Millesimi
N° di processi in parallelo:  5    -  Tempo impiegato: 02 Minuti,  04 Secondi,  753 Millesimi
N° di processi in parallelo:  5    -  Tempo impiegato: 02 Minuti,  04 Secondi,  946 Millesimi
N° di processi in parallelo:  5    -  Tempo impiegato: 02 Minuti,  02 Secondi,  560 Millesimi
N° di processi in parallelo:  6    -  Tempo impiegato: 02 Minuti,  03 Secondi,  999 Millesimi
N° di processi in parallelo:  6    -  Tempo impiegato: 02 Minuti,  04 Secondi,  768 Millesimi
N° di processi in parallelo:  6    -  Tempo impiegato: 02 Minuti,  03 Secondi,  663 Millesimi
N° di processi in parallelo:  6    -  Tempo impiegato: 02 Minuti,  04 Secondi,  220 Millesimi
N° di processi in parallelo:  6    -  Tempo impiegato: 02 Minuti,  05 Secondi,  486 Millesimi
N° di processi in parallelo:  7    -  Tempo impiegato: 02 Minuti,  02 Secondi,  739 Millesimi
N° di processi in parallelo:  7    -  Tempo impiegato: 02 Minuti,  03 Secondi,  209 Millesimi
N° di processi in parallelo:  7    -  Tempo impiegato: 02 Minuti,  02 Secondi,  989 Millesimi
N° di processi in parallelo:  7    -  Tempo impiegato: 02 Minuti,  02 Secondi,  726 Millesimi
N° di processi in parallelo:  7    -  Tempo impiegato: 02 Minuti,  03 Secondi,  070 Millesimi
N° di processi in parallelo:  8    -  Tempo impiegato: 02 Minuti,  04 Secondi,  747 Millesimi
N° di processi in parallelo:  8    -  Tempo impiegato: 02 Minuti,  05 Secondi,  210 Millesimi
N° di processi in parallelo:  8    -  Tempo impiegato: 02 Minuti,  04 Secondi,  562 Millesimi
N° di processi in parallelo:  8    -  Tempo impiegato: 02 Minuti,  04 Secondi,  128 Millesimi
N° di processi in parallelo:  8    -  Tempo impiegato: 02 Minuti,  04 Secondi,  374 Millesimi

Praticamente ci sono stati miglioramenti da 1 a 4 processi in parallelo. Da lì, fino ad arrivare ad 8 non è cambiato nulla, io invece mi aspettavo di avere miglioramenti fino ad 8 ...

Ciao, Mario

[nomorelogic]

spero di non dire delle boiate ma, a memoria, mi risulta che i processori dual core, per essere sfruttati in tutta la loro potenza di calcolo, devono eseguire algoritmi scritti per sfruttare l'elaborazione parallela (in modo da ovviare all'uso dei bus e cache che dovrebbero essere condivisi tra i 2 core).

il thread lanciato non necessariamente è stato scritto con un algoritmo che possa sfruttare l'elaborazione parallela e, in questo caso, le operazioni sono sempre sequenziali e non c'è modo di far passare parte del carico del lavoro al secondo core.

probabilmente se guardi i grafici di utilizzo dei core mentre lanci il tuo programma, dovresti vedere 8 core ma funzionanti solo la metà.

[bonmario]

Stasera provo a guardarci con Windows. In linux in effetti, mi fa vedere i grafici di 4 core e non di 8 ...

Ciao, Mario

[bonmario]

Ciao,
mi collego a questo per non aprire una nuova discussione apposta ...
Ho un mega lapsus ....
In un programma, nel form principale valorizzo una TStringList con circa 2.000 righe.
Fatto questo, lancio una decina di thread in parallelo, ed ognuno di questi scorre quella TStringList per leggere gli elementi. La TStringList del form principale, viene quindi usata da tutti i thread, ma solo in lettura.

Questo può creare problemi? Mi conviene andare sul sicuro e duplicare la TStringList per passarla come parametro ad ogni Thread in modo che ognuno usi la propria?

Grazie in anticipo Mario

[Stilgar]

Solo lettura no.
Ma verifica di non modificare mai la lista finché in uso parallelo.
Stilgar

[bonmario]

Ok, grazie.
No, l'ho valorizzata tutta prima apposta, per poi usarla solo in lettura.

L'ho chiesto perché un paio di minuti prima di uscire dal lavoro, ho notato un comportamento "strano", ma non ho avuto il tempo di verificarne il motivo.
Poi, mentre tornavo a casa, ripensandoci, mi è venuto il dubbio che magari non solo la scrittura creava problemi, ma anche la lettura.

Comunque, meglio così, domani avrò una possibile causa in meno da verificare !!!

Grazie, Mario

[Stilgar]

Visto che lavori in parallelo, di solito è considerata una buona pratica generale  (non sapendo com'è organizzato il codice la menziono per completezza) semaforizzare gli accessi paralleli a risorse condivise. (L'esempio a scuola era la stampante ad aghi che mescolava caratteri e spazi di due processi in stampa... ma si parla di accesso diretto alla pnt con tutto l'onere dell'invio dei dati... ora credo sia vetusto come esempio 😂😂😂 anche se la vecchia panasonic mi ha dato molte soddisfazioni in stampa grafica giocando con il controllo dell'interlinea).
Una sezione critica è più che sufficiente per l'accesso alla memoria.
In alternativa potresti verificare se il thread n ha lo slot di esecuzione attivo e procedere alla lettura. È più spartano come controllo e meno sicuro.
Se hai problemi con la strada che stai seguendo ricordati le sezioni critiche. 😉

Stilgar

[bonmario]

Perfetto, grazie, Mario

[bonmario]

Scusate, ma ci sto girando intorno da mezz'ora ...
Sempre nello stesso programma di ieri, nel form principale ho una TMemo che uso come "log".

All'interno dei singoli thread ho questo codice:

Codice: [Seleziona]

  procedure TMyThread.ThreadAggiungiLog(WrkTestoLog: String);
  begin
    TestoLog:=WrkTestoLog;
    Synchronize(@SincronizzaLog);
  end;



  procedure TMyThread.SincronizzaLog;
  begin
    if VFPrimo then begin
      VFPrimo:=False;

      Form1.AggiungiLog('');
      Form1.AggiungiLog('     ' + 'Verificare il sorgente ' + ParmNomeFileNew);
    end;
    Form1.AggiungiLog(TestoLog);
  end;

Questo "metodo per emettere i log" l'ho già usato in altri programmi, e funziona correttamente.
Qui però i messaggi che aggiungo al log vengono mischiati tra di loro.

Ricordo male io o la "Synchronize" serve proprio per fermare tutti gli altri thread mentre si sta facendo qualche operazione particolare?

Grazie, Mario