file condivisi[info generica]

[nuovoUtente86]

Per sviluppo di progetto futuro vorrei capire una cosa:
quando 2 programmi chiamano lo stesso file il SO ne carica 2 copie in ram oppure ne da unacondivisa.
Da quello che ricordo Unix fa cosi

ogni processo ha la propria tabella dei file aperti con i propri offset sul file,ma a copia del file dovrebbe essere unica

esempio
processo1....tabellaFile1 file nella cella 1
processo2....tabellaFile2 file nella cella 1

correggettemi se non è cosi..ovviamente ho fatto una semplificazione.....Ovviamente in sola lettura nn si pongono problemi e in scrittura se ho ben capito il sistema si occupa della gestione delle concorrenza

In windows non ho idea di cosa avvenga.

Dalle prove che ho fatto con un semplice .txt ogni finestra ha la copia con il testo al momento dell' apertura e dopo il lavoro le modifiche che rimangono sono le ultime.

Vorrei ben capire appunto cosa avviene...con un file aperto da piu programmi e se devo essere io programmatore a preoccuparmi o sarà il sistema

[nuovoUtente86]

up

[wingman87]

Ma al di là di come gestisce i file il SO, il tuo problema quale sarebbe? Che due programmi devono scrivere cose diverse nello stesso file? Che entrambi devono aggiungere dati in fondo al file?

[nuovoUtente86]

Mi interessa capire prima come i sistemi gestiscono l' accesso ai file per capire come meglio eseguire le operazioni sui file...
Si potrebbero verificare differenti situazioni..magari un programma accedein lettura mentre l' altro scrive...ecc..ecco perchè magari mi servirebbe una spiegazione o un link dove si parla della gestione dei file da parte del sistema.

[wingman87]

Capisco, comunque penso che il file venga caricato in memoria ogni volta che viene chiesto, quindi se due processi diversi aprono lo stesso file dovrebbe essere caricato 2 volte. Dico questo perchè mi sembra la cosa più logica, e poi dal tuo test sembra essere proprio così, almeno se ho capito bene il tipo di test che hai fatto.. Io avrei fatto un test di questo genere:
-Faccio aprire lo stesso file in modalità append ai due processi
-Scrivo qualcosa sul file con il primo processo e chiudo il file
-Scrivo qualcosa di più corto con il secondo processo e chiudo
A sto punto se il file contiene quello che hanno scritto entrambi i processi (la seconda scrittura dovrebbe aver sovrascritto in parte la prima), significa che il file è stato copiato un'unica volta in RAM, altrimenti...

[nuovoUtente86]

però nel tuo test bisogna cmq tenere in considerazione che l' offset in append ti dovrebbe venir restituito al momento dell' apertura,per cui sia che il file sia caricato in doppia copia sia in condivisa verrebbe cmq sovrascritto.

esempio processo A apre file in append offset 1
processo B apre in append offset 1
A scrive arriva in offset 10 e chiude
B scrive il suo offset è sempre 1 per cui dovrebbe sovrascrivere ugualmente almeno che il SO nn applichi qualche funzionalità

[nuovoUtente86]

In pratica unix gestisce cosi:i vari processi utilizzano la medesima copia,se ad esempio un programma scrive in append e un' altro fa la stessa richiesta il sistema si occupa dell' aggiornamento dell' indice su entrambi i processi in modo da evitare sovrascritture.
Invece per i processi padre-figlio si ha anche condivisione dell' offset sul file.per windows non ho trovato nulla.

[nuovoUtente86]

Quello che vorrei capire e se devo preoccuparmi io della gestione della concorrenza o lo fa il sistema.
Poniamo un esempio di un .txt

file testo= ciaociaociaociao

processo a=apre file
processo b=apre file

processo a=modifica ciaociaociao in canecanecane
processo b=legga file.....ma cosa legge "ciaociaociao" o "canecanecane"?

[andbin]

processo a=apre file
processo b=apre file

processo a=modifica ciaociaociao in canecanecane
processo b=legga file.....ma cosa legge "ciaociaociao" o "canecanecane"?Ammesso che il processo a scriva completamente ciò che ha mandato in output sul file (ricordati che le funzioni di I/O standard sono bufferizzate) e che il processo b legga dal file appena dopo che il processo a ha scritto, allora il processo b legge "canecanecane".

[nuovoUtente86]

Però se si fa una semplice prova con un .txt aprendolo da blocco note o da word in 2 istanze ognuno mantiene una propria copia indipendente.
Tu ritieni invece che la copia sia condivisa.....oppure intendevi una cosa del genere

metodo
File =new File()

thread a legge file
thread b legge file
..........
a scrive file




in questo caso ovviamente è condiviso.

[andbin]

Però se si fa una semplice prova con un .txt aprendolo da blocco note o da word in 2 istanze ognuno mantiene una propria copia indipendente.Certo ma perché si caricano in memoria il file .... quando fai Salva, riscriveranno il testo sul file. :mbe:

[nuovoUtente86]

Certo ma perché si caricano in memoria il file .... quando fai Salva, riscriveranno il testo sul file. :mbe:

quindi ne caricano 2 copie distinte?anche UNix fa cosi?

[andbin]

quindi ne caricano 2 copie distinte?anche UNix fa cosi?Ehm ... qui non c'entra per niente il sistema operativo. C'entra solo il modo in cui le applicazioni trattano i file. È chiaro che per un editor di testo la cosa migliore è caricare il file in memoria (e se il file è molto grosso magari può utilizzare dei file temporanei come "swap"). Poi quando uno fa "Salva", allora l'editor scrive sul file.
Non vuol dire che ci sono 2 copie distinte del file.

[nuovoUtente86]

Ehm ... qui non c'entra per niente il sistema operativo. C'entra solo il modo in cui le applicazioni trattano i file. È chiaro che per un editor di testo la cosa migliore è caricare il file in memoria (e se il file è molto grosso magari può utilizzare dei file temporanei come "swap"). Poi quando uno fa "Salva", allora l'editor scrive sul file.
Non vuol dire che ci sono 2 copie distinte del file.

Quindi in ram esiste solo una copia ma le modifice restano in buffer finche' l' applicazione o le applicazioni vengono chiuse?
Cioè apro una finestra notepad e apro file1.txt
apro un' altra finestra e apro file1.txt....il sistema operativo carica nuovamente in ram una copia del file1.txt oppure restituisce alla seconndo finestra di notepad un riferimento al file gia aperto?

[andbin]

Quindi in ram esiste solo una copia ma le modifice restano in buffer finche' l' applicazione o le applicazioni vengono chiuse?
Cioè apro una finestra notepad e apro file1.txt
apro un' altra finestra e apro file1.txt....il sistema operativo carica nuovamente in ram una copia del file1.txt oppure restituisce alla seconndo finestra di notepad un riferimento al file gia aperto?Una applicazione semplice come Notepad credo che faccia una cosa del genere: apre un file ed ottiene un handle al file, determina quanta memoria è necessaria, alloca memoria sufficiente, carica il file in memoria poi chiude il file.
È chiaro che 2 istanze di Notepad saranno completamente indipendenti! Quindi handle diversi, memoria diversa, ecc....

[nuovoUtente86]

Una applicazione semplice come Notepad credo che faccia una cosa del genere: apre un file ed ottiene un handle al file, determina quanta memoria è necessaria, alloca memoria sufficiente, carica il file in memoria poi chiude il file.
È chiaro che 2 istanze di Notepad saranno completamente indipendenti! Quindi handle diversi, memoria diversa, ecc....

Ma teoricamente bufferizzando le operazioni di scrittura si potrebbe anche condividere il file oppure no?

[andbin]

Ma teoricamente bufferizzando le operazioni di scrittura si potrebbe anche condividere il file oppure no?Qui si sta andando un po' fuori dal seminato .... come si suol dire.

Quando si dice che le operazioni di I/O sono "bufferizzate" (ad esempio usando le funzioni standard di libreria del "C") è perché c'è un sistema di buffering tale per cui l'applicazione scrive dei dati ma non necessariamente essi vengono immediatamente scritti fisicamente sul file. Ed è necessario fare un esplicito "flush" o chiudere il file. Questo buffering è relativo al singolo handle del file.

Un file è una risorsa condivisibile, nel senso che più processi possono effettivamente accedere contemporaneamente allo stesso file.

[nuovoUtente86]

Qui si sta andando un po' fuori dal seminato .... come si suol dire.

Quando si dice che le operazioni di I/O sono "bufferizzate" (ad esempio usando le funzioni standard di libreria del "C") è perché c'è un sistema di buffering tale per cui l'applicazione scrive dei dati ma non necessariamente essi vengono immediatamente scritti fisicamente sul file. Ed è necessario fare un esplicito "flush" o chiudere il file. Questo buffering è relativo al singolo handle del file.

Un file è una risorsa condivisibile, nel senso che più processi possono effettivamente accedere contemporaneamente allo stesso file.

Ma le va a scrivere sulla copia condivisa eventualmente in ram oppure su una struttura dati esterna al file?

[andbin]

Ma le va a scrivere sulla copia condivisa eventualmente in ram oppure su una struttura dati esterna al file?Qui si sta parlando di particolari molto "interni" del sistema operativo (che certamente variano da un sistema all'altro).

Se vuoi fare riferimento a Windows, per cortesia leggi <qui> (http://msdn2.microsoft.com/en-us/library/aa364218.aspx) e <qui> (http://msdn2.microsoft.com/en-us/library/aa364451.aspx).