# chiarimento sulla USE "threads"

## rivent

Ciao a tutti!

Volevo chiedervi se mi potere spiegare a cosa serve la use flag: threads.  

(premetto che so cosa sono i threads )

Mi chiedevo:  se non metto questa use flag, le applicazioni non useranno i threads e funzioneranno in monothread? 

nel mio make.conf ho messo al use "nptl" ( threads nativi)  ma molti pacchetti usano la use threads

 :Rolling Eyes: 

----------

## comio

 *rivent wrote:*   

> Ciao a tutti!
> 
> Volevo chiedervi se mi potere spiegare a cosa serve la use flag: threads.  
> 
> (premetto che so cosa sono i threads )
> ...

 

In generale quando fai un sever (tipo apache) hai due scelte: fare un monothread che risponde molto velocemente alle risposte, oppure farle multithread per ridurre la latenza di risposta (ma incrementando il costo di esecuzione).

Alcuni pacchetti offrono di scegliere l'una o l'altra modalità... tutto qui!

ciao

----------

## cloc3

 *comio wrote:*   

> fare un monothread che risponde molto velocemente alle risposte, oppure farle multithread per ridurre la latenza di risposta

 

 :Question: 

scusa, sto provando a rileggerti, ma temo che ti sei involontariamente contraddetto un po'...

posso chiederti di ripetere?

----------

## comio

 *cloc3 wrote:*   

>  *comio wrote:*   fare un monothread che risponde molto velocemente alle risposte, oppure farle multithread per ridurre la latenza di risposta 
> 
> scusa, sto provando a rileggerti, ma temo che ti sei involontariamente contraddetto un po'...
> 
> posso chiederti di ripetere?

 

Sì, effettivamente sono stato poco chiaro. In un mono thread, il thread deve accettare, eseguire e ritornare il risultato molto velocemente dato che è bloccante. Se non si può garantire che il tempo di elaborazione sia corto, allora si può usare il threading per avere latenza bassa nella risposta alla chiamata (ma non necessariamente nell'esecuzione!). Usando più thread (cosa costosa) in generale i tempi di esecuzione si allungano (anche perché ho più richieste), ma il client vede il tempo di creazione della connessione mediamente più basso. Notate che multithread  non significa più veloce in senso assoluto, ma se si valuta "la media" in ogni istante di tempo si avranno tannte risposte quante sono le richieste (fatte da altri): ovviamente al tempo X rispondo a chi ha chiesto nel tempo X-1 ma accetto le richieste a cui darò risposta al tempo X+1.

ciao

----------

## rivent

grazie del chiarimento!   :Wink: 

nel caso di  un sistema desktop, conviene abilitala o no   :Question: 

nello specifico, stavo per emerge amarok e vedo che usa la use theads.  Conviene metterla o no?

----------

## xveilsidex

 *comio wrote:*   

>  *cloc3 wrote:*    *comio wrote:*   fare un monothread che risponde molto velocemente alle risposte, oppure farle multithread per ridurre la latenza di risposta 
> 
> scusa, sto provando a rileggerti, ma temo che ti sei involontariamente contraddetto un po'...
> 
> posso chiederti di ripetere? 
> ...

 

Forse ricordo male ma in facoltà ricordo di aver sentito che il s.o. crea appositamente i thread proprio per alleggerire il lavoro non per pagarli in "maniera costosa" infatti il s.o. crea i thread al posto di creare un processo atomico che esegua altre rikieste! inoltre dipende di che thread si sta parlando.. Se sono thread a livello utente allora possono essere bloccanti nel caso in cui i thread vengano gestiti con lo skema MOLTi : 1  cioè molti thread livello utente 1 livello kernel  xrò se è molti  : molti il problema non si pone in maniera eccessiva! il vantaggio dei thread a livello utente è ke sn piu' veloci rispetto ai thread del livello nucleo ma ke possono creare unblocco in caso di skema molti :1 ! Mentre, i thread a livello kernel sn piu' lenti ma nn sn bloccanti! infine creare un thread al posto di un singolo nuovo processo ke esegua altre richieste è vantaggioso perchè i thread simulano solamente un cambio di contesto computazionale al passaggio da un thread all'altro e quindi nn " perdono la cpu"  mentre se si crea un nuovo processo ogni volta si deve piu' volte effettivamente cambiare contesto computazionale e quindi si ha molta perdita di cicli di cpu creando quel fenomeno noto come DISPATCH LATENCY!  Spero di essere stato +/- kiaro!

----------

## rivent

Si, forse si è perso il punto della mia domanda...

non era una domanda su cosa sono i thread, 

il centro della questione era sapere se effettivamente compilando senza use "thread", i programmi funzionano tutti in monothread.

----------

## comio

 *xveilsidex wrote:*   

> 
> 
> Forse ricordo male ma in facoltà ricordo di aver sentito che il s.o. crea appositamente i thread proprio per alleggerire il lavoro non per pagarli in "maniera costosa" infatti il s.o. crea i thread al posto di creare un processo atomico che esegua altre rikieste! inoltre dipende di che thread si sta parlando.. Se sono thread a livello utente allora possono essere bloccanti nel caso in cui i thread vengano gestiti con lo skema MOLTi : 1  cioè molti thread livello utente 1 livello kernel  xrò se è molti  : molti il problema non si pone in maniera eccessiva! il vantaggio dei thread a livello utente è ke sn piu' veloci rispetto ai thread del livello nucleo ma ke possono creare unblocco in caso di skema molti :1 ! Mentre, i thread a livello kernel sn piu' lenti ma nn sn bloccanti! infine creare un thread al posto di un singolo nuovo processo ke esegua altre richieste è vantaggioso perchè i thread simulano solamente un cambio di contesto computazionale al passaggio da un thread all'altro e quindi nn " perdono la cpu"  mentre se si crea un nuovo processo ogni volta si deve piu' volte effettivamente cambiare contesto computazionale e quindi si ha molta perdita di cicli di cpu creando quel fenomeno noto come DISPATCH LATENCY!  Spero di essere stato +/- kiaro!

 

Non sto parlando di thread leggero (propriamente detto thread) e thread pesante/processo. Parlo della differenza su avere o meno concorrenza su un server. Giusto per dare una risposta summa:

con thread attivato: il pacchetto è compilato con il supporto per i thread (solitamente pthread) 

con thread disattivato: il pacchetto è compilato come monothread oppure con concorrenza implementato tramite task kernel (syscall clone).

Nell caso di disattivato... chi fa il programma deve dirti cosa succede in compilazione!

ciao

luigi

----------

## rivent

 *comio wrote:*   

> 
> 
> Non sto parlando di thread leggero (propriamente detto thread) e thread pesante/processo. Parlo della differenza su avere o meno concorrenza su un server. Giusto per dare una risposta summa:
> 
> con thread attivato: il pacchetto è compilato con il supporto per i thread (solitamente pthread) 
> ...

 

questa è la risposta che volevo

grazie!

----------

