Microsoft Update sotto test

Re: Mah... [parte 2]
un kernel thread (thread per brevità) non è nient'altro che "un pezzo di programma" (perdona la definizione informale) con un suo stack ed un copia dei registri e del program counter relativa al suo contesto di esecuzionecaratteristica saliente del thread è che opera nel contesto di un processo avendo quindi libero accesso allo spazio di indirizzamento ed alle risorse assegnate a quel processostoricamente con il termine processo ci si è sempre riferiti a quanto detto precedentemente (spazio indirizzamento e risorse) più le caratteristiche del thread (programma, stack, registri e PC), oggi con i sistemi multi-threaded si tende sempre più a considerare il processo come un contenitore logico a cui vengono associati lo spazio di indirizzamento, le risorse ed uno o più thread (con thread principale si intende il primo thread creato all'esecuzione del processo che eventualmente può creare gli altri thread)più thread che condividono lo stesso processo hanno libero accesso alla memoria assegnata al processo stesso (questo non è vero tra processi differenti!) e possono quindi utilizzare primitive meno onerose per arbitrarne l'accesso quali interlocking, critical sections e spinlocksqueste primitive sono meno onerose perche' sono implementate in user modela differenza in termini di prestazioni tra questi metodi di arbitraggio è uno dei punti fondamentaliin ogni caso thread di processi diversi possono comunicare tra loro tramite IPC e possono arbitrare l'accesso alle risorse tramite le primitive offerte dal kernella messa in esecuzione dei thread sulle cpu è governata dallo scheduler del sistema operativo che opera in kernel mode ed è un'operazione (detta di context switching) che consuma parecchi cicliin alcuni sistemi operativi effettuare il context switching tra thread dello stesso processo è significativamente meno oneroso che effettuarlo tra thread di processi diversi, con altri sistemi operativi la differenza è meno marcatain ogni caso questo è un altro punto fondamentale per quanto riguarda le prestazionioltre al processo ed al kernel thread c'è anche lo user thread (fiber per brevità)una fiber è "un pezzo di programma" che opera nel contesto di un kernel thread (quindi in ultima istanza nel contesto di un processo o thread primario) e ne condivide le risorsepiù fiber possono operare nel contesto dello stesso thread e in un processo ci possono essere più thread ognuno con le sue fiberdato che fiber e thread condividono tutti lo stesso spazio processo, possono avvalersi anche le fiber delle primitive di sincronizzazione leggerela messa in esecuzione di una fiber non viene gestita tramite lo schedulatore in kernel mode del sistema operativo, ma tramite uno schedulatore implementato in user mode dallo stesso processo che ospita i thread che a loro volta ospitano le fiber (come minimo il thread primario ed una o più fiber)l'operazione di context switch dei thread viene sempre fatta dallo schedulatore in modalità kernel, ed ha un certo costo, quella delle fiber essendo in user mode ha un costo minorele fiber devono volontariamente rilasciare l'uso del processore ad un'altra fiber (modello cooperativo) mentre i thread vengono interrotti dal sistema operativo (modello preemptive) in base all'algoritmo dello schedulatoreil pro delle fiber, oltre al costo minore di context switching, è quello di poter implementare un algoritmo di schedulazione più efficiente sia per particolari esigenze, che per sfruttare al meglio il tempo allocato al thread che le ospitail contro è che un la fiber potrebbe non rilasciare mai il processore bloccando di fatto la coda dello schedulatore (user mode) del thread a cui appartienedetto tutto questo torniamo a quanto affermi:
Forse non ti sei accorto che si parlava di 2
processori i quali a usare la "shared memory"
honno un pochino piu' di problemi se non usano
meccanismi di sincronizzazione legati a semafori
e mutex (esattamente come per i processi).i meccanismi di sincronizzazione di un'area di memoria condivisa non dipendono in alcun modo dal numero di processori, semplicemente dal fatto che la condivisione avvenga tra thread dello stesso processo o tra thread di processi differentia livello hardware esulano dal contesto della nostra discussione perché la coerenza viene mantenuta a meno del sistema operativo e dalla sua architettura single o multi threaded(tra l'altro ci sarebbe da spendere anche due parole per la prossimità di zone di memoria usate per le variabili e le strategie per far si che finiscano nelle cache lines)
Del resto la shared memory non e' una novita',
non e' una trovata particolrmente "furba" e la si
usa alla grande anche tra processi diversipagando lo scotto della comunicazione interprocesso che costa di più della condivisione tra thread dello stesso processoma, ovviamente, tutto dipende dal tipo di applicazione
(volendo) quindi non si capisce bene il vantaggio
del thread!che puoi usare delle primitive più leggere per la sincronizzazioneche costa meno il context switchingma il punto fondamentale è dove e come usarlouna soluzione può essere fatta da diversi moduli e non è detto che sia sensato fare un singolo processo con tanti thread quanti sono i moduli, come non è detto che sia sensato fare tanti processi quanti sono i moduliil punto è capire l'interdipendenza tra i vari moduli ed i requisiti di condivisione delle risorse da parte dei vari modulila soluzione potrebbe essere realizzata mappando i moduli in più processi alcuni dei quali con un singolo thread, alcuni con più thread ed infine alcuni con più fibers per alcuni threadun ottimo esempio è un rdbms: processi differenti per servizi integrati tra loro (es. l'engine, full-text, data mining, olap) e più thread per i processi (es. nell'engine un pool di thread serve le connessioni, un thread si occupa dei checkpoint, uno di svecchiare la cache dei dati ecc. ecc.)per contro c'é tutta una classe di applicazioni che si prestano meglio ad essere suddivise in tante unità dello stesso processo da distribuire su cluster di elaboratori