Newsgroup: it.comp.os.linux.development
Titolo: Re: preemptive??

 writes:
L> Scusate ragazzi, ma se io voglio sviluppare un'applicazione
L> multithreading su un pc con linux/ubuntu, mi devo aspettare che il
L> multithreading sia preeptive o non-preemptive?  Leggendo un po' in
L> questo NG mi sembra di capire che dipende da come č stato compilato
L> il kernel.... ma da dove posso capirlo?
Credo che gią fare una cosa  del tipo creare due thread che sparano un
carattere su  stdio E  FANNO SUBITO LA  FLUSH (oppure unsano  la write
invece che stdio.h)  dovrebbe farti capire se ti  č arrivato il kernel
di  uno   di  quei  vendor   commerciali  che  a  quanto   pare  usano
implementazioni non  preemptive per ovviare a problemi  di OpenLDAP e,
probabilmente, dell'implementazione di AWT in Java...
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg

 Ubuntu, potrebbe girare con un kernel preeptive?
Stai facendo confusione: il kernel Linux è preemptive dal giorno zero.
Questo vuol dire che ogni processo può essere interrotto (quando ha
esaurito il suo timeslice, quando c'è un processo a priorità più alta,
...).
Tu ti stai confondendo con il kernel 'preemptible'; fino al 2.4 quando
il codice del kernel in esecuzione (e.g. una syscall, oppure uno dei
thread del kernel) non poteva essere interrotto (se non da un interrupt,
ma l'esecuzione tornava comunque al kernel) a meno che non cedesse
volontariamente la CPU (e.g. attesa di I/O).
Dal 2.6 è possibile rendere il kernel preemptible (interrompibile);
anche il codice kernel può essere forzatamente interrotto in caso di
bisogno (modulo chiaramente le varie primitive di sincronizzazione).
Luca
-- 
"Ricorda sempre che sei unico, esattamente come tutti gli altri".

 multithreading sia preeptive o non-preemptive? Leggendo un po' in questo
Scusate se devio il discorso, ma non ho capito una cosa.
Con i nuovi processori multi-core ha ancora senso, sotto Linux, 
programmare in multithread o conviene "tornare" al multiprocess?
In pratica le librerie/kernel che vedono diversi thread riescono a 
parallelizzarli su diversi core o si rischia di sfruttare un solo core e 
lasciare inattivi gli altri?
Grazie.

 lasciare inattivi gli altri?
Li vedono per fortuna :)
Su solaris mi era toccato settare lo SCOPE_SYSTEM nei settings del 
pthread, su linux sembra che i thread NTPL si distribuiscano sui 
processori senza problemi (a patto di avere un kernel smp che li vede :) ).
--
Bye,
  Gabry

 
http://en.wikipedia.org/wiki/NPTL
In particolare:
getconf GNU_LIBPTHREAD_VERSION
Su Debian Etch mi restituisce:
NPTL 2.3.6
Saluti Manlio Perillo



Ma questo non distrugge il caching?
Ciascun core ha una cache L1 separata.
Cercando in rete ho trovato questo:
http://www.eecs.harvard.edu/~margo/papers/usenix05/paper.pdf
Manlio Perillo

 Ciascun core ha una cache L1 separata.
Si, ma i processori moderni contengono una logica di cache snooping che 
permette di invalidare un dato in cache se e' nella cache dell'altro 
processore ed e' stato modificato, cio' ovviamente non danneggia il 
caching del codice stesso, che solitamente "cachato" solo in lettura.
Comunque un thread idle gira tipicamente x 10msec o piu' se non ci sono 
altri thread idle che gli richiedono la CPU (e se lo scheduler non e' 
settato oltre i 100hz :) ), in questo lasso di tempo i vantaggi della 
cache vengono usati ampliamente.
Tieni conto che se un'applicazione multithread accede PESANTEMENTE in 
scrittura alla stessa zona di memoria da piu` thread tipicamente il 
collo di bottiglia sara` nel meccanismo di locking piu` che nel flush di 
parte della cache stessa.
---
Bye,
  Gabry

   Gabry
Manlio Perillo

 Ma dove diavolo posso reperire queste informazioni???
sched_setscheduler(2) e dintorni.
Luca
-- 
Let me make your mind, leave yourself behind
Be not afraid

 interrompeva.
Non conosco vxworks, ma quello che descrivi si chiama "cooperative" 
multitasking, e se un task di priorita` maggiore lo interrompe significa 
che c'e` anche poco controllo da parte del S.O., oppure che e` un S.O. 
(hard) realtime.
Per esempio in AmigaOS, S.O. soft-realtime, i task di pari priorita` 
vengono eseguiti in preemption, mentre quelli di priorita` inferiore 
possono non essere mai eseguiti. In pratica hai una coda di preemption per 
ogni livello di priorita`. Infatti task come il controllo del mouse sono a 
priorita` piu` alta degli altri, in modo da reagire istantaneamente.
In Linux non esiste la priorita` ma solo il niceness, che da` piu` o meno 
possibilita` di essere mandato in esecuzione alla preemption. In questo 
modo nessun task dovrebbe andare in starving, fatto salvo quello che ha 
spiegato Kronos coi nuovi kernel. Infatti a macchina molto carica puo` 
capitare che il mouse "scatti" anche mettendo X con niceness bassa.
Bye.

 ceduto la palla a un task con priorità inferiore.
Rileggi la mia definizione di preemptive ;) Implica solo che il kernel
può interrompere un processo in modo arbitrario. Le regole secondo le
quali l'interruzione viene fatta possono chiaramente variare in base
alle esigenza (ad esempio "penalizzare" i processi a priorità più bassa
ma permettere loro di girare in ogni caso - quello che fa Linux di
default). Per inciso la tua descrizione dello schedule di vxworks
corrisponde a quello che fa Linux per i processi SCHED_FIFO.
Luca
-- 
"Accadono cose che sono come domande. Passa un minuto, oppure anni, e
 poi la vita risponde."

 fatto salvo quello che ha spiegato Kronos coi nuovi kernel.
Ni. Un kernel preemptible può migliorare la latenza, ma è ortogonale
alle regole di preemption dei processi in userspace.
Luca
-- 
"La Via prosegue senza fine."
	Bilbo Baggins - Il Signore degli Anelli - J.R.R. Tolkien