Newsgroup: it.comp.os.linux.development
Titolo: pthreads e allocazione dinamica dei thread

Salve a tutti,
sto studiando pthreads, e mi sono imbattuto nel problema dell'allocazione 
dinamica del lavoro.
Spiego: sto facendo (per esercizio) un programma che fa il blurring di 
un'immagine: l'immagine viene divisa in N parti e lanciata su M thread, ogni 
thread puo' lavorare una o piu' parti. Non c'e' alcuna dipendenza dei dati 
in scrittura, non ho bisogno di lock.
Finora ho schedulato staticamente (fork-join), in pratica un loop che lancia 
gli M thread, ognuno prende un tot di parti (calcolate a seconda del numero 
identificativo di thread).
Ora, volevo provare a schedulare dinamicamente: ogni thread si prende una 
parte, quando ha finito prende un altra parte e cosi' via, fino alla fine 
del lavoro.
Domanda: come faccio? :)
Quale schema posso usare?
Thx,
Pleg 

 Quale schema posso usare?
   Secondo me per questa versione un minimo di locking occorre: un elenco
di "parti" da elaborare, un mutex per proteggere l'elenco e quando un
thread finisce la sua parte, acquisisce il lock, estrae l'elemento
successivo, lo rilascia e fa il calcolo... Se non ci sono altri elementi da
elaborare esce...
   Cosi` dovrebbe funzionare anche senza usare un thread supervisore...
Saluti...
-- 
                          |
\|/ ____ \|/   \ ||_|     | ...fascisti su Marte,
"@'/ ,. \`@"    \|| |     | rosso pianeta bolscevico
/_| \__/ |_\ Vax Headroom | e traditor...
   \__U_/                 |

   Cosi` dovrebbe funzionare anche senza usare un thread supervisore...
Cioe' una cosa del tipo:
master: crea un elenco dei chunk da elaborare
master: fork N thread
master: join
thread: acquisisce lock sull'elenco, cerca un chunk da elaborare, rilascia 
il lock; se non ce n'e' esce, se no elabora il chunk
Sembra abbastanza pulito...?
Pleg 

 Sembra abbastanza pulito...?
   Si, con la differenza che, se non ne hai bisogno per motivi altri, subito
dopo la creazione degli altri thread, metterei anche il "master" a
lavorare, per esempio chiamando esplicitamente la funzione di inizio del
thread. In questo modo il "master" sarebbe praticamente equivalente ad uno
qualsiasi degli altri, con la sola differenza che, all'uscita della
funzione (quindi senza pthread_exit esplicito), troverebbe una join di
tutti gli altri ad aspettarlo :)
Questo intendevo per "dovrebbe funzionare anche senza usare un thread
supervisore"...
-- 
                          |   
\|/ ____ \|/   \ ||_|     |   Sono aperte le gare di lancio del
"@'/ ,. \`@"    \|| |     |   cavalletto...
/_| \__/ |_\ Vax Headroom |   ISCRIVETEVI NUMEROSI !
   \__U_/                 |

 supervisore"...
Nice :)
Pleg 



Uno schema abbastanza semplice e che non richiede lock, è di usare una 
variabile atomica.
Supponendo di suddividere l'immagini in parti uguali, ciascun thread, ad 
ogni giro, incrementa la variabile atomica, e se questa è > N, termina.
Vedi 
http://en.wikipedia.org/wiki/Fetch-and-add
Purtroppo non esiste una interfaccia standardizzata a questa funzionalità.
Questa risorsa potrebbe esserti utile, dal punto di vista hardware
http://chandlerc.net/llvm_atomics.html
Alcuni compilatori, come GCC, supportano le operazioni atomiche come 
builtins:
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
Ciao  Manlio Perillo

 variabile atomica.
[cut]
Ma che differenza c'e'? Alla fine anche il lock e' un'istruzione atomica, 
no?
Pleg 

> il lock; se non ce n'e' esce, se no elabora il chunk
Ehm... un'altra domandina che mi sono accorto ora di non sapere: dato che il 
numero di chunk e' variabile e determinato a runtime, come faccio (in C) ad 
allocare un array dinamico all'interno della struct che devo passare ai 
thread?
Pleg 

Never mind... e' tardi e sono fuso...
Pleg 

 Pleg
Ciao  Manlio

 ai thread?
   calloc/free sono tuoi amici... Ma a questo punto mi sa che ti occorre una
studiata prima al K&R e poi alle manpage relative...
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Siamo in missione 
"@'/ ,. \`@"    \|| |     |   per conto di Dio !
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |         Jake Blues

 origine, atomica non lo č.
Certo, intendevo che _il lock_ e' un'istruzione atomica.
Pleg 

 studiata prima al K&R e poi alle manpage relative...
Niente, mi ero scordato che i thread vedono lo stesso memory space...
Pleg