Newsgroup: it.comp.os.linux.sys
Titolo: Linux supporta i threads ?

Sembrera' una domanda idiota ma mi e' venuto un dubbio visto che un tipo
ha cercato di convincermi del contrario e lui era pienamente convinto che
linux nn supporta i threads e li emula in qualche modo..
Federico

 linux nn supporta i threads e li emula in qualche modo..
E "native threads" che cosa vuol dire allora ?
Davide


ma chi č, tuo cuggino ? :-)

Federico ha scritto:

ha ragione lui, per ora è così: per ora ci si limita a dei task a metà 
strada tra processi e thread. Ci sta lavorando IBM 
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!



Mai sentito parlare dei posix thread?
No eh? figurati....
Cmq linux č native thread...
Quello che forse non č propriamente parallelizzato č lo schedule del kernel del
multitasking, ma questo con il thread non c'entra nulla...
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://www.kbytesystem.fasturl.it
 ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

.
Non c'e' bisogno che mi mandiate al diavolo. Io sono convinto della cosa,
solo ke come ha scritto maya questo tipo asseriva ke linux crea + task per
"emulare" i thread. Siccome i task vengono creati per davvero, volevo
capire effettivamente cone funzionava il sistema..

Federico wrote:

Che io sappia ci sono i supporti per tutti e due i tipi di thread:
quelli gestiti dal kernel ( man 2 clone ), ed i cosidetti green thread, 
ovvero quelli gestiti a livello applicativo ( a la solaris ). Questi ultimi 
sembrerebbero più efficenti. Anche se non supportano il prerilascio

strada tra processi e thread. Ci sta lavorando IBM 
Ma anche no. ti confondi. thread e task non sono la stessa cosa.
-- 
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

"Federico" <fede...@sevuoimandarmiuanmailchiedime.lo> ha scritto nel
messaggio
news:pan.2002.09.04.21...@sevuoimandarmiuanmailchiedime.lo...

In effetti da un certo punto di vista avete ragione entrambi. Per quello
che so, linux supporta i thread, ma in maniera non completa; infatti
al posto di creare più thread per ogni processo, crea un nuovo processo
per ogni thread, ma solo per quanto riguarda l'area codice: l'area dati
viene condivisa dai processi. In aggiunta a questo, all'apertura del
primo thread avvia un processo aggiuntivo per il controllo dei thread.
Questo è almeno quello che so e che succede programmando in c
e usando le librerie thread e l'opzione di compilazione -lpthread
Ciao, Nym
~~~~~~~~~~~~~~~~~~~ Fabrizio (Nym) ~~~~~~~~~~~~~~~~~~~
 
n...@cyberfast.org
 - ICQ #35864683 - 
n...@fastwebnet.cjb.net
 
www.cyberfast.org
 - FAQ: 
http://faq.cyberfast.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 primo thread avvia un processo aggiuntivo per il controllo dei thread.
Si`, pero` Linux usa il copy-on-write, quindi se non si cambia il
codice del programma che viene forkato come thread, anche l'area codice
rimane condivisa, e l'unica cosa che succede e` la creazione di una
nuova entry nella lista dei processi.
L'unica cosa negativa credo sia il tempo di swap tra thread che e`
uguale a quello tra processi, quindi viene fatto un save/restore dello
stato del processo anche per i thread, mentre se fossero veri thread
non sarebbe necessario, ma onestamente non so come venga
risolto/attenuato/ignorato questo "problema".
Bye.

 e usando le librerie thread e l'opzione di compilazione -lpthread
Un thread è una implementazione particolare della programmazione concorrenziale
parallela.
Il fatto che i posix thread (quelli che hai provato tu sono i posix thread)
creino un unovo processo per ogni thread, ciò non vuol dire che sono thread a
metà.
L'unica obbiezione che si può fare sui thread riguardano i kernel threads che
senza la patch per il peemptive applicata non godono di una vera e propria
parallelizzazione in quanto lo schedule non è ottimizzato allo scopo.
-- 
| /
| \Byte - Andrea Briganti - kbytesys(at)
libero.it
http://www.kbytesystem.fasturl.it
 - ICQ: 40872731


 ha scritto nel messaggio
news:ala2uh$1ob1p8$1...@ID-94575.news.dfncis.de...


 uguale a quello tra processi,
No, se "current->mm_struct == prev->mm_struct" allora non viene toccato
niente e lo switch tra thread e' molto piu' veloce di quello tra 
processi tradizionali.
-- 
Lorenzo

 vuol dire che sono thread a metŕ.
no, abbiate pazienza. Thread creati a quella maniera non sono thread, 
sono processi. E servono un sacco di capriole per farli funzionare come 
lo standard POSIX richiede, e NON ci credo che non avendo pensato il 
kernel sin dall'inizio per il multithreading l'accrocchio attuale di 
usare piů processi monchi sia la soluzione migliore
Domandina: se faccio seteuid da un thread, come reagiscono gli altri? 
Altra domandina: se un thread locka un file con fcntl, che pid risulta 
essere il proprietario del lock?


 che sono thread a metą.
All'ora ti illusto una cosa interessante:
 - apro due thread (PID 6678 e PID 6679, 6680 per il gestore)
 - dal secondo thread effettuo una fork: secondo te quale dovrebbe
   essere il corretto risultato?
Adesso ti dico quello che succede:
 - a seguito della fork viene creato un nuovo processo (PID 6681),
   che eredita tutto soltanto dal thread che l'ha creato; la situazione č
   come se il thread fosse un processo a se stante ed esegui una fork
 - mando al PID 6681 un segnale di uscita dall'altro thread xché ha
   esaurito il suo compito (il processo creato dal thread 2 č fatto per
   servire il thread 1)
 - il 6681 diventa uno zombie
 - chiamo la wait* sempre dal thread per liberare il residuo di memoria,
   ma ciņ non funziona xché il primo thread non č il padre di quel
   processo!!! (per risolvere devo mandare un segnale all'altro thread
   per fargli lanciare la wait*)
Bene detto questo se fossero veri thread, ciņ vorrebbe dire che esistono
entrambi in un processo e di esso ne sono parte; quando si esegue
una fork() dovrebbe essere il processo contenente i due thread a fare
la fork, non uno dei due thread. Infine essendo i due thread parte dello
stesso processo, il processo creato con la fork, dovrebbe essere
controllabile da entrambi i thread indifferentemente
Magari dico stronzate, ma a mio parere un meccanismo di questo
tipo non rappresenta il corretto funzionamento dei thread; quindi
a mio parere linux non supporta in questo modo completamente i
thread, ma, diciamo, li "emula" al meglio.
Se poi per tornare al discorso linux generale e non posix thread
conosci altri tipi di thread che non soffrono di questo problema...


 indifferentemente 
bravo! eccone uno che ha capito il problema. E voglio infierire: per i 
thread wait() e connessi *NON* servono. Si possono creare joined, ok, 
ma si devono anche poter creare detached


 ok,  ma si devono anche poter creare detached
Forse hai frainteso... il wait e per attendere la terminazione di un
figlio vero e proprio, ma creato da uno dei due thread


Nym wrote:
[/bin/snip --all]
Scopiazzo e appiccico questo interessante coso pescato giusto giusto 
qualche minuto fa dalla lkml e scritto da ingo molnar...
Che poi stringi stringi vuol dire "stiamo lavorando sui threads"...
byez...
<Ingo>
the attached patch (against BK-curr) is another step to have better
threading support under Linux, it implements the sys_exit_group() system
call.
it's a straightforward extension of the generic 'thread group' concept,
which extension also comes handy to solve a number of problems when
implementing POSIX threads.
POSIX exit() [the C library function] has the following semantics: all
thread have to exit and the waiting parent has to get the exit code that
was specified for the exit() function. It also has to be ensured that
every thread has truly finished its work by the time the parent gets the
notification. The exit code has to be propagated properly to the parent
thread even if not the thread group leader calls the exit() function.
Normal single-thread exit is done via the pthread_exit() function, which
calls sys_exit().
previous incarnations of Linux POSIX threads implementations chose the
following solution: send a 'thread management' signal to the thread group
leader via tkill(), which thread goes around and kills every thread in the
group (except itself), then calls sys_exit() with the proper exit code.
Both old libpthreads and NGPT use this solution.
this works to a certain degree, unless a userspace threading library uses
the initial thread for normal thread work [like the new libpthreads],
which 'work' can cause the initial thread to exit prematurely.
At this point the threading library has to catch the group leader in
pthread_exit() and has to keep the management thread 'hanging around'
artificially, waiting for the management signal. Besides being slightly
confusing to users ('why is this thread still around?') even this variant
is unrobust: if the initial thread is killed by the kernel (SIGSEGV or any
other thread-specific event that triggers do_exit()) then the thread goes
away without the thread library having a chance to intervene.
the sys_exit_group() syscall implements the mechanism within the kernel,
which, besides robustness, is also *much* faster. Instead of the threading
library having to tkill() every thread available, the kernel can use the
already existing 'broadcast signal' capability. (the threading library
cannot use broadcast signals because that would kill the initial thread as
well.)
as a side-effect of the completion mechanism used by sys_exit_group() it
was also possible to make the initial thread hang around as a zombie until
every other thread in the group has exited. A 'Z' state thread is much
easier to understand by users - it's around because it has to wait for all
other threads to exit first.
and as a side-effect of the initial thread hanging around in a guaranteed
way, there are three advantages:
  - signals sent to the thread group via sys_kill() work again. Previously
    if the initial thread exited then all subsequent sys_kill() calls to
    the group PID failed with a -ESRCH.
  - the get_pid() function got faster: it does not have to check for tgid
    collision anymore.
  - procps has an easier job displaying threaded applications - since the
    thread group leader is always around, no thread group can 'hide' from
    procps just because the thread group leader has exited.
  [ - NOTE: the same mechanism can/will also be used by the upcoming
      threaded-coredumps patch. ]
there's also another (small) advantage for threading libraries: eg. the
new libpthreads does not even have any notion of 'group of threads'
anymore - it does not maintain any global list of threads. Via this
syscall it can purely rely on the kernel to manage thread groups.
the patch itself does some internal changes to the way a thread exits: now
the unhashing of the PID and the signal-freeing is done atomically. This
is needed to make sure the thread group leader unhashes itself precisely
when the last thread group member has exited.
(the sys_exit_group() syscall has been used by glibc's new libpthreads
code for the past couple of weeks and the concept is working just fine.)
	Ingo
</Ingo>
-- 
Emanuele "SKULL" Balla
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)