[C] Thread e I/O

[Unrue]

Ciao a tutti,
vorrei fare una domanda teorica sui thread, quindi diciamo che non devo postare codice. Ho scritto C nel titolo solo perché sto usando i POSIX thread. Dunque, ho un programma multithread che si occupa di leggere e scrivere su disco. In particolare, ho un server che si mette in attesa, ogni volta che arriva una richiesta attiva un thread che si occupa di scrivere o leggere a seconda della richiesta che perviene.

Premesso che in un sistema multitasking, ogni thread viene eseguito un "pò per volta" in base alle priorità e allo scheduler del sistema operativo, nel caso che un thread faccia I/O su disco come si comporta lo scheduler? Interrompe comunque il thread e passa ad un altro dopo un tot di tempo oppure considera l'operazione di lettura/scrittura atomica? Se vale il primo caso, non è allora molto dispendioso questo meccanismo? in quanto il disco farebbe continui salti avanti e indietro per recuperare/scrivere dati in dovendo servire richieste random ed in più interrompibili? Qualcuno mi sa dare spiegazioni in merito? Grazie in anticipo!

[Unrue]

Uppo questa mia vecchia richiesta nella speranza che qualcuno mi sappia rispondere.

[cdimauro]

Quando un thread chiama una funzione di I/O che non è in grado di servire subito la richiesta (perché, ad esempio, non è in cache e deve leggere dal disco), il thread viene messo in stato di attesa e la CPU passa a un altro thread e/o processo secondo le regole dello scheduler.

[Unrue]

Originariamente inviato da cdimauro

Quando un thread chiama una funzione di I/O che non è in grado di servire subito la richiesta (perché, ad esempio, non è in cache e deve leggere dal disco), il thread viene messo in stato di attesa e la CPU passa a un altro thread e/o processo secondo le regole dello scheduler.

Ciao cdimauro

Si questo mi torna. Però le funzioni di I/O sono interrompibili dallo scheduler?

[cdimauro]

Certamente. Si tratta pur sempre di istruzioni che vengono eseguite dalla CPU, e lo scheduler le può interrompere in qualunque momento.

E', comunque, possibile per il kernel e a volte delle periferiche, disabilitare gli interrupt per brevissimi intervalli di tempo per non interrompere delle operazioni delicate.

[nuovoUtente86]

Se ho ben inteso la domanda chiedi se le operazioni di I/O venagno eseguite in maniera serializzata. Il risultato finale si, anche se sui sistemi multiprogrammati possono essere ottimizzate per una migliore risposta hardware.

[cionci]

Originariamente inviato da nuovoUtente86

Se ho ben inteso la domanda chiedi se le operazioni di I/O venagno eseguite in maniera serializzata. Il risultato finale si, anche se sui sistemi multiprogrammati possono essere ottimizzate per una migliore risposta hardware.

Dipende cosa intendi per "serializzata"...due richieste dello stesso thread ho la garanzia che vengano serializzate.
Se lancio due thread in due istanti diversi che vanno a scrivere alla stessa posizione del file, non ho alcuna garanzia su quale dei due mi vada a scrivere prima sul disco.
Se lancio due thread, uno mi va a scrivere ed uno a leggere alla stessa posizione del file, anche qui il risultato è imprevedibile, indipendentemente da quale lancio prima o dopo.

[Unrue]

Originariamente inviato da cdimauro

Certamente. Si tratta pur sempre di istruzioni che vengono eseguite dalla CPU, e lo scheduler le può interrompere in qualunque momento.

E', comunque, possibile per il kernel e a volte delle periferiche, disabilitare gli interrupt per brevissimi intervalli di tempo per non interrompere delle operazioni delicate.

Ok. Ma quindi in questo caso, il multithread non è dannoso? Essendo le richieste di I/O random su disco, se per di più la singola lettura/scrittura è interrotta non peggioro notevolmente le prestazioni rispetto al servire le richieste una per volta? La testina del disco fa un sacco di salti.

[cionci]

A minimizzare lo spostamento della testina in realtà ci dovrebbe pensare lo scheduler.
Prima che il file arrivi sul disco nella sua locazione ce ne sono di passaggi
Prima di tutto le scritture vengono salvate nel journal, poi lo scheduler si occupa di selezionare le scritture secondo il suo algoritmo.

[cdimauro]

E' normale che sia così, e a livello applicativo puoi fare poco e niente (a meno che non sai già quali accessi farai).

I s.o. moderni hanno meccanismi per cercare di ridurre l'impatto degli accessi casuali, monitorando le richieste in attesa e cercando di schedularle in modo da minimizzare lo spostamento delle testine.

[Unrue]

Ok, grazie ad entrambi

[nuovoUtente86]

Originariamente inviato da cionci

Dipende cosa intendi per "serializzata"...due richieste dello stesso thread ho la garanzia che vengano serializzate.
Se lancio due thread in due istanti diversi che vanno a scrivere alla stessa posizione del file, non ho alcuna garanzia su quale dei due mi vada a scrivere prima sul disco.
Se lancio due thread, uno mi va a scrivere ed uno a leggere alla stessa posizione del file, anche qui il risultato è imprevedibile, indipendentemente da quale lancio prima o dopo.

Mi riferivo alla serializzazione delle Syscall e quindi della scrittura/lettura fisica:
se il thread A scrive sulla posizione x
e dopo B scrive ancora su x,
sul disco le operazioni saranno serializzate(sicuramente se la politica è FCFS ), poi se a livello logico ciò sia corretto o meno, dipende ovviamente dall' implementazione e dalla gestione programmatica della concorrenza.

[cionci]

Sì però non c'è alcun vincolo sulla sequenza con cui vengono chiamate le syscall dato l'ordine in cui vengono attivati i thread. Quindi se questa cosa è vincolante conviene serializzare le scritture già dal programma. Magari usando un thread che si occupa di "consumare" le scritture prodotte dagli altri thread.

[nuovoUtente86]

Originariamente inviato da cionci

Sì però non c'è alcun vincolo sulla sequenza con cui vengono chiamate le syscall dato l'ordine in cui vengono attivati i thread. Quindi se questa cosa è vincolante conviene serializzare le scritture già dal programma. Magari usando un thread che si occupa di "consumare" le scritture prodotte dagli altri thread.

Perfettamente d' accordo, anche perchè io nell' esempio ho ipotizzato l' utilizzo di uno scheduler "fifo" e di scrittura su medesima posizione, ma non è detto (anzi i sistemi operativi dovrebbero ottimizzare l' accesso) che sia cosi.

[Teo@Unix]

Anche io ho affrontato da poco l'argomento, al di là di tutte le considerazioni, ditemi se sbaglio, ho trovato interessante come la politica di scheduling del processore cambia a seconda degli obiettivi del sistema operativo, che sia batch, interactive o real-time.
Quindi a mio parere, occorre anche tenere in considerazione la politica di default del sistema.

Come dice cdimauro,

I s.o. moderni hanno meccanismi per cercare di ridurre l'impatto degli accessi casuali, monitorando le richieste in attesa e cercando di schedularle in modo da minimizzare lo spostamento delle testine.

Nello specifico delle op. di I/O su disco, che sono enormemente più lente rispetto a operazioni fatte direttamente in memoria,
la CPU ne tiene conto durante la gestione dei processi.
I processi chiamati "compute-bound" ai quali la CPU dedica molto tempo sono appunto quelli con pochi I/O e molta elaborazione.
I processi "I/O bound" l'opposto.
Quindi la CPU dedicherà maggior tempo ai primi, in quanto sarebbe stupido aspettare un dato che arriva dall'hard disk o da un'altra periferica.

Insomma un ottimo algoritmo di scheduling tiene conto di tutte queste cose.

Si dovrebbe parlare anche di priorità e valore di cortesia dei processi in quanto la CPU è influenzata da queste nel compito di gestione.

[DanieleC88]

Originariamente inviato da Teo@Unix

...

Comunque, la CPU di suo non tiene conto di niente, è sempre lo scheduler a dover tenere conto dei singoli aspetti più o meno rilevanti per il sistema.

[Teo@Unix]

bè si, dovevo esprimermi meglio, intendevo lo scheduler.
La CPU poverina, esegue e basta.

[nuovoUtente86]

In ogni caso lo scheduler della CPU e quello del disco sono indipendenti: potrebbero agire in sinergia ma anche no.

[cionci]

Originariamente inviato da Teo@Unix

Anche io ho affrontato da poco l'argomento, al di là di tutte le considerazioni, ditemi se sbaglio, ho trovato interessante come la politica di scheduling del processore cambia a seconda degli obiettivi del sistema operativo, che sia batch, interactive o real-time.

Non stavamo parlando dello scheduler della CPU, ma dello scheduler delle scritture. Date N scritture su disco si occupa di ordinarle secondo un algoritmo. In questo algoritmo si terrà conto di:
- timestamp di arrivo
- peso della lettura
- distanza dalla posizione del journal (seek time)

[nuovoUtente86]

Solitamente viene data alta priorità alle operazioni sull' area di swap.