Newsgroup: it.comp.os.dibattiti
Titolo: [Forse OT] MultiThreading

Linux gestisce i Threads,ad es come Win2k o Os/2 ?
Non vorrei sbagliare ma mi pareva fossero stati dei cambiamenti con
l'ultimo kernel.
Non so nemmeno se la domanda e' corretta ma del resto sono un
principiante di questi argomenti....:)
--

 l'ultimo kernel.
Forse per i kernel thread, non mi pare per
gli user thread.
bye,
-- 
  Piergiorgio Sartor

"Ermete" <que...@non.funge> ha scritto nel messaggio
news:3D352E...@non.funge...

Windows gestisce i thread a livello di kernel.
Per quanto riguarda Unix/Linux io sono rimasto alla situazione nella quale
il kernel non gestisce i thread e tale gestione e' lasciata a package
esterni; sarei grato se chi ne sa piu' di me di linux potesse postare la
situazione dei kernel correnti.
Ciao, Davide :)



Linux ha sempre supportato il multithreading ma in stile posix, in modo diverso
da quello di windows.
Per il kernel forse tu ti riferisci alla preempive... che pių che dare il
multithread ne ottimizza lo schedule riducendo i tempi di latenza (a livello
kernel)
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://www.kbytesystem.fasturl.it
 ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

da quello di windows.
e li gestisce anche meglio :)
[almeno quello che mi è successo con un portscanner scritto in Java e
eseguito su Linux e Win in locale
--
Rhymes (
rhy...@myself.com
)
Brainbench Certification:
Language: Java 1, Score: 3.29, Date: 2001-10-02 
http://www.brainbench.com/transcript.jsp?pid=2435730


Gestisce meglio in che senso? Potresti essere + chiaro?
Ciao, Davide :)

Gestisce meglio in che senso? Potresti essere + chiaro?
ho provato il sorgente scritto da me di un Portscanner e l'ho eseguito
con la medesima JVM (sun 1.3) sia su Linux che su Windows e sul primo
s'è rivelato estremamente + veloce... ma può essere un caso


 l'ultimo kernel.
si spera
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 s'è rivelato estremamente + veloce... ma può essere un caso
Io non ho nessun dato per decretare se linux e' meglio di win nella gestione
dei thread; in ogni caso l'ipotesi di una superiorita' di linux penso che
non sorprenda nessuno.
Cmq mi sembra che java non sia lo strumento migliore per testare le
prestazioni del SO se non altro perche' l'applicazione java non chiama
direttamente le primitive di sistema. Le prestazioni dell'applicazione sono
influenzate anche dalle prestazioni della jvm ( PS: non hai eseguito
l'applicazione con la medesima jvm ma con due jvm differenti anche se
entrambe aggiornate alla versione 1.3 di java)
Ciao, Davide :)

 Quelli che Lainucs chiama thread sono dei processi handicappati
Puoi spiegarci i motivi di questa affermazione?
Grazie.
[cut]
Ciao, Davide :)


AFAIK i thread *per definizione* sono processi handicappati.
Alessandro.

entrambe aggiornate alla versione 1.3 di java)
ovvio per medesima intendevo dire "del medesimo produttore"


 AFAIK i thread *per definizione* sono processi handicappati.
per definizione di chi? la Single Unix Specification, a proposito di 
thread, dice, con una chiarezza incredibile:
"Threads
This defines interfaces and functionality to support multiple flows of 
control, called _threads_, within a process."
[...]
E in queste due righe l'intero concetto di thread č esaurito. Niente 
dispute sul sesso degli angeli, come il cosa significhi "processo" o il 
perchč un thread non possa essere visto come "processo leggero"
Ma segnalo ancora (man page di pthread_create):
"[...]
The thread is created executing _start_routine_ with _arg_ as its sole 
argument. If the _start_routine returns_, the effect is as if there was 
an implicit call to pthread_exit() using the return value of 
_start_routine_ as the exit status. Note that the thread in which 
main() was originally invoked differs from this. When it returns from 
main(), the effect is as if there was an implicit call to exit() using 
the return value of main() as the exit status."
[...]"
e ancora (man page di pthread_exit):
"[...]
The process exits with an exit status of 0 after the last thread has 
been terminated. The behaviour is as if the implementation called 
exit() with a zero argument at thread termination time.
[...]"
e ancora (fork):
"[...]
A process is created with a single thread. If a multi-threaded process 
calls fork(), the new process contains a replica of the calling thread 
and its entire address space [...]"
e infine (exec):
"[...]
A call to any exec function from a process with more than one thread 
results in all threads being terminated and the new executable image 
being loaded and executed. [...]"
Mi sembra molto chiaro cos'č un processo e cosa un thread in Unix. Non 
leggo nessuno di quegli abominevoli termini, come "lightweight process" 
e simili, che servivano e servono solo a giustificare implementazioni 
del multithreading scadenti, malamente ritagliate dal modello esistente 
basato sui processi a thread singolo


 Puoi spiegarci i motivi di questa affermazione?
loro li chiamano thread. Ma sono processi. Hanno un pid, hanno delle 
relazioni figlio-genitore, serve fare una wait su ognuno o finiscono 
per diventare zombie. Non oso immaginare cosa succeda se uno di questi 
"thread" chiama fork() o exec(). Insomma: poca lungimiranza. Vedi 
Windows invece: i processi vengono creati normalmente *senza thread*, 
ed è possibile aggiungerne quanti se ne vuole in seguito. Questo basta 
a disambiguare completamente il significato di processo e quello di 
thread


 si spera
ahi Intravedo bagliori di flamessssssssss......
Qui' si incendia anche per molto meno.
--

 perchč un thread non possa essere visto come "processo leggero"
Uhm, ma vi sono un po' di problemi, relativi
alla condivisione delle risorse, che la
suddetta definizione non chiarisce, ovviamente.
Tali problemi rendono un po' piu` fosco il
concetto di thread, cosa viene ereditato, cosa
e` modificabile, etc.
Ad es. se un task apre un file e poi genera un
po' di thread, questi possono chiudere il file?
Secondo il concetto "rigoroso" di thread si, sarebbe
possibile, solo un pazzo lo farebbe, ma e` possibile.
Altri pensano che non debba essere possibile, quindi
concepiscono il thread con l'idea che possa chiudere
il file, ma solo localmente.
E cosa succede se il genitore chiude il file?
I thread figli si trovano con file chiuso o no?
Come vedi, a seconda delle risposte che dai, o
ti trovi con dei thread "puri", ma pericolosissimi,
oppure ti ritrovi con qualcosa di molto simile ad
un semplice (si fa per dire) multitasking.
Bisogna decidere cosa serve e cosa si vuole fare.
Per es. su pSOS, analizzando bene le cose, non
esistono task, ma solo thread... Eppure lo
chiamano multitasking, non multithreading.
bye,
-- 
  Piergiorgio Sartor

 thread
Effettivamente il kernel di linux supporta solo i processi (almeno cosi' mi
risulta); la gestione dei thread e' lasciata a librerie esterne che,
ovviamente, non possono far altro che implementare i thread utilizzando cio'
che il kernel mette a disposizione e cioe' i processi. In effetti e'
assolutamente verosimile che i thread linux siano dei processi linux in
tutto e per tutto con la sola aggiunta di poter condividere un'area di
memoria.
Per quanto riguarda windows l'unico modo per ottenere un flusso di
esecuzione parallelo all'interno di uno singlolo programma e' quello di
usare i thread ed e' quindi abbastanza ovvio che la gestione dei thread sia
stata ottimizzata.
Ciao , Davide :)


E questo chiude il discorso ;-)
Alessandro.

 s'č rivelato estremamente + veloce... ma puň essere un caso
Che sia la VM che va meglio su Linux che su Windows non viene in mente vero?
Deve per forza essere colpa di Windows, siete tutti brutti e cattivi 8-).
Battute a parte il tuo NON mi sembra un test dei piů seri.
Saluti
Massimo


Certo ci sono troppe variabili esterne, ad esempio oltre oltre alla jvm,
anche la gestione del networking.
Alessandro.


Magari sono un po' OT pero' questa mi risulta essere il motivo
per cui i sistemi Microsoft sono basati sul threading e non
sul forking.
Sembra che Microsoft che nei primi anni ottanta sviluppava
un sistema chiamato Xenix che poi vendette a SCO, dovette
firmare un contratto nel quale dichiarava che nei suoi
sistemi operativi non avrebbe utilizzato il forking dei
processi che e' appunto tipico dei sistemi Unix/Posix.
Per questo Microsoft ha dovuto utilizzare un sistema alternativo,
il threading, che pero' introduce una marea di problematiche
nella gestione della memoria (nel forking ogni processo ha il
suo spazio riservato, nel threading tutti i processi accedono
alla stessa area di memoria).
Saluti,
Gianluca

 gli user thread.
Nel  2.5 stanno  facendo un  merge del  codice di  supporto per  i NGPT,
quindi e` in arrivo una gestione ibrida dei thread.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Non capisco tutta questa eccitazione per il Multitasking: 
io sono anni che leggo in bagno.

Battute a parte il tuo NON mi sembra un test dei piů seri.
e chi lo ha mai detto
--
Rhymes
rhy...@myself.com
" ride or die "

anche la gestione del networking.
Gią probabilmente č anche colpa dello stack TCP di Linux che _forse_ č
migliore di quello di Win2K


La storie è:
OS/2 --> sviluppato da IBM usando l'esperienza dei mainframe e doveva
svilupparlo assiema a MS infatti la versione 1.3 l'hanno fatta insieme
NT/2K --> sviluppando da MS quando ha rotto con IBM accapparandosi tecnici
Digital che facevano sistemi per mainframe su base unix il quale è passato
poi a Compaq ed ora ad HP
Linux --> porting di uno dei tanti Unix su architettura x86
Una cosa OS/2 usa un concetto molto particolare della virtual machine
senzaltro molto più robusto e già 10 anni fa nella prima versione a 32 bit
faceva girare una moltitudine di applicazione che rimanevano perfettamente
separate come se fossero su macchine diverse e questo con un DX4 100 e senza
tanti GHz.
Ciao
Sèvero
"Piergiorgio Sartor" <sar...@sony.de.REMOVE.THIS> ha scritto nel messaggio
news:3D3521EF...@sony.de.REMOVE.THIS...


test ha scritto:

sě, sennň m'arrabbio e vi picchio sulla testa con la mazza da croquet e 
vi inibisco la crescita


 thread "puri", ma pericolosissimi,
i thread puri esistono per questo


 (nel forking ogni processo ha il suo spazio riservato,
nay. E' condiviso e copy-on-write
[1] il codice sorgente di testfork:
#include <ddk/ntddk.h>
#include <sys/types.h>
#include <windows.h>
#include <unistd.h>
#include <errno.h>
int mymain(int argc, char ** argv)
{
 int testvar = 0;
 ULONG retval;
 switch(fork())
 {
  case -1:
  {
   int saveErrno = errno;
   NtRaiseHardError(saveErrno, 0, 0, 0, 1, (ULONG)&retval);
   NtTerminateThread(NtCurrentThread(), saveErrno);
  }
  case 0:
  {
   DbgPrint("child: pid %d, parent pid %d\n", getpid(), getppid());
   DbgPrint("child: testvar %d\n", testvar);
   testvar = 1;
   DbgPrint("child: testvar %d\n", testvar);
   ExitProcess(0);
  }
  default:
  {
   DbgPrint("parent: pid %d, parent pid %d\n", getpid(), getppid());
   DbgPrint("parent: testvar %d\n", testvar);
   sleep(10);
   DbgPrint("parent: testvar %d\n", testvar);
   ExitProcess(0);
  }
 }
 return (0);
}
Un pout-pourri di funzioni native di NT, funzioni Win32 e chiamate POSIX
standard, che miracolosamente funziona. Ora non ricordo perchè la main
si chiama "mymain", quindi non chiedetelo a me :-P


 i thread puri esistono per questo
E molta gente pensa che siano una stupidata,
proprio per questo.
Non dico che non siano necessari, in alcuni casi
sono un'ottima soluzione, ma non vanno certo
bene per sistemi a scopo generale, sono troppo
pericolosi, allo stesso livello come consentire
di bloccare gli irq in user mode.
bye,
-- 
piergiorgio

 io sono anni che leggo in bagno.
LOL! Bellissima :)
-- 
Lorenzo

 Linux --> porting di uno dei tanti Unix su architettura x86
Assolutamente sbagliato!!!

 vostro. Il multithreading non è Windows, è informatica
Il fatto e' che Windows che non e' informatica :-)
Comunque il tuo e' un commento gratuito.
Per me questa non e' una guerra di religione, non e' certo il forking
o il non forking che mi fara' scegliere di usare Microsoft, la mia era
una nota 'storica', se vogliamo.
Ciao,
Gianluca

 E molta gente pensa che siano una stupidata, proprio per questo.
spiacente, ma non accetto critiche sul concetto di thread. Esistono, 
hanno un loro senso, hanno un loro scopo, e nient'altro puň prendere il 
loro posto


 la mia era una nota 'storica', se vogliamo.
e io ti dico che è una bufala, perchè Windows "forka! forka! forka! 
forka! dio bono come forka Windows!" [1]. Quel log lo dimostra, un 
dumpbin -exports %SystemRoot%\System32\psxdll.dll | findstr "fork" lo 
dimostra, l'esistenza di Interix lo dimostra
[1] s/forka/pompa/ e s/Windows/il Pippero/


 loro posto
Che niente possa prendere il loro posto non
e` in discussione, quello che su cui si
questiona e` se abbiano senso.
O meglio se abbiano senso "assoluto", cioe`
che la distinzione "task" e "pure thread"
sia l'unica che abbia senso, magari ci si
potrebbero mettere anche i "safe thread".
Comunque non te la prendere con me, riporto
solo diversi punti di vista...
bye,
-- 
piergiorgio


Anche quella di cygwin, o sbaglio?
Alessandro.




 leggeri, secondo altri no.
c'č chi li implementa entrambi, e lascia che sia il programmatore a 
scegliere. Con questo ragionamento, il linguaggio C non esisterebbe


 scegliere. Con questo ragionamento, il linguaggio C non esisterebbe
Infatti, hanno inventato Java per quello... :-)
Comunque sia, non e` proprio allo stesso livello,
debuggare un sistema "pure thread" e` un incubo,
se c'e` qualcosa che non va, non te la cavi piu`
tra i salti da un thread all'altro.
Naturalmente dipende sempre dal problema e dalla
applicazione, come ho gia` detto pSOS, per esempio,
e` _solo_ thread, e su certe CPU si puo` pensare
che sia solo pure thread...
bye,
-- 
piergiorgio

 ho gia` detto pSOS, per esempio, e` _solo_ thread,
è real-time?


 è real-time?
Yep, almeno cosi` dicono loro...
bye,
-- 
piergiorgio

No, deve sostituire TUTTO!!!! :-)
ma per favore! :)


Il 19 lug 2002, Raziel battendo sulla sua tastiera scrisse:

Mi pare preciso, in realtà... forse solo linux che è "ispirato" a minix, 
ma non copiato. 
-- 
Renato "Hitman" Salzano | 
http://spazioinwind.iol.it/hitman/
GdG #6 - Mexico 86 Fan #2 - VFNCL counter - Transbassista dei 2ofSpades
"You think the way you live is okay / Your simple posin’ will save the day
 You think we don’t see / That you’re running" - Rockstar, N*E*R*D

 ma per favore! :)
Pentiti e convertiti, miscredente!!! :-)
Guarda, non c'e` giorno che passi, che
non legga, senta cose tipo: applicazioni
X in Java.
Dove X sta per:
1) automotive
2) TV
3) web (boh?)
4) elettrodomestici vari
5) Telefoni cellulari
6) Stampanti
7) WC
...
bye,
-- 
piergiorgio

Pentiti e convertiti, miscredente!!! :-)
Brainbench Certification:
Language: Java 1, Score: 3.29, Date: 2001-10-02 
http://www.brainbench.com/transcript.jsp?pid=2435730
:-)


 No, deve sostituire TUTTO!!!! :-)
Forte! Un altro monopolio (fosse almeno uno standard).

 
http://www.brainbench.com/transcript.jsp?pid=2435730
Ah, un discepolo, dunque, che pero`
non vuole diffondere il verbo... :-)
Piuttosto, bel posto Treviglio, ci sono
stato una volta.
Conosco anche qualcuno da quelle parti.
bye,
-- 
piergiorgio

 Forte! Un altro monopolio (fosse almeno uno standard).
Guarda, non mi toccare Java, che
se continua cosi` mi tocchera`
persino impararlo...
bye,
-- 
piergiorgio

 Guarda, non mi toccare Java, che
Salutami Swing e buon divertimento :o)

 Salutami Swing e buon divertimento :o)
Certo, magari anche Sting...
bye,
-- 
piergiorgio

Conosco anche qualcuno da quelle parti.
Non vorrai mica perseguitarmi vero? Hai già il monopolio del NG :)
[devo dire una cosa: in questo NG mi diverto un casino anche se spesso
non riesco a stare dietro alla mole di post...e ovviamente non tutti
gli argomenti mi interessano...ma può (raramente) capitare che la mia
cultura non sia all'altezza di certi argomenti :]


persino impararlo...
??????????????
Mi fai tutta la ramanzina e non lo conosci? Non sarai mica come
Maya...che fa pubblicità a ReactOS :))


Certo, magari anche Sting...
di certo meglio di Swing


 Maya...che fa pubblicità a ReactOS :))
Chi e` Maya? Chi e` ReactOS? :-)
bye,
-- 
piergiorgio

 cultura non sia all'altezza di certi argomenti :]
Naaa, non credo.
bye,
-- 
piergiorgio

Naaa, non credo.
Beh il thread sul Multitasking mi ha un pò spiazzato :)


Non si capiva la sottile ironia?
No pensavo fossi un programmatore-guerrafondaio ;-)


 Beh il thread sul Multitasking mi ha un pò spiazzato :)
Anche a me ;-)
bye,
-- 
piergiorgio

 di certo meglio di Swing
Si vede che non conosci SWT :)
www.eclipse.org
Ciao !
--
|  
http://digilander.iol.it/iccp/
 ( FAQ di ICCP )  U.I.N. Icq : 41710019
|  
http://digilander.iol.it/videocdpsx
 ( Crea Video CD per PSX )
|  
http://setiathome.ssl.berkeley.edu/stats/team/team_7422.html
|  
http://www.utenti.org

Si vede che non conosci SWT :)
io intendevo che Sting (il cantante) č meglio di Swing (la libreria :)
--
Rhymes (
rhy...@myself.com
)
http://www26.brinkster.com/rhymes
" ride or die "

 ragazze (belle) a Treviglio non ne vedo... :)
no dai qualcuna carina c' è ;-)

no dai qualcuna carina c' è ;-)
?


 scegliere. Con questo ragionamento, il linguaggio C non esisterebbe
Credo che sia Sun a permettere su Solaris sia i kernel thread che user.
--
Luigi Mantellini
Per il pessimista il bicchiere è mezzo vuoto,
per l'ottimista è mezzo pieno,
per un ingegnere è semplicemente sovradimensionato rispetto l'uso.