[Win32] Scritture concorrenti su file

[fero86]

salve a tutti, ho una domanda da fare... ho esplorato da cima a fondo nella libreria MSDN tutta la documentazione relativa all'I/O sui files, cioé questa sezione: http://msdn.microsoft.com/en-us/libr...29(VS.85).aspx

ma non sono riuscito a capire una cosa fondamentale: nel caso di I/O sincrono (quindi non overlapped) e di scritture concorrenti su uno stesso file da parte di processi diversi, o per meglio dire attraverso HANDLEs diversi, i vari blocchi scritti sono ordinati?? oppure il caching causa un potenziale disordinamento?

quello che mi interessa capire fondamentalmente é se il caching:
1) avviene per file;
2) avviene per HANDLE;
3) avviene per processo;
4) l'interfaccia Win32 non specifica questo dettaglio che viene lasciato quindi all'implementazione sottostante, ad esempio al kernel NT o all'FSD sottostante.

questa differenza é molto importante perché:
nel caso 1) i vari blocchi di dati scritti vengono automaticamente ordinati nella cache, che funziona da coda;
nei casi 2) e 3) i blocchi scritti potrebbero essere disordinati perché ciascuno viene effettivamente scritto sul file solo quando la cache da cui proviene viene flushata, e quindi i blocchi restano ordinati secondo l'ordine in cui vengono flushate le caches;
nel caso 4) é una bella rottura di scatole.

volevo saperlo giusto per sapersi regolare quando si scrive un programma che girerá su piu processi e dovrá accedere concorrentemente agli stessi files in scrittura

so bene che Vista introduce il file system transazionale che elimina questo e dozzine di altri problemi, ma spesso e volentieri di questi tempi il target é ancora XP.

grazie a tutti dei vostri pareri, specialmente mi farebbe piacere ricevere eventuali link a pagine di MSDN che mi sono sfuggite!

[fero86]

aggiungo un dettaglio che ho dimenticato di specificare: tutta questa questione ha senso solamente quando si parla di scritture di buffers la cui dimensione non supera quella di un settore: in caso contrario infatti la WriteFile non é atomica per contratto, e quindi i dati scritti in contemporanea vengono disordinati indipendentemente dal caching.

[DanieleC88]

http://msdn.microsoft.com/en-us/libr...50(VS.85).aspx
http://msdn.microsoft.com/en-us/libr...18(VS.85).aspx

Ti conviene aprire i file con FILE_FLAG_NO_BUFFERING (eventualmente, anche FILE_FLAG_WRITE_THROUGH). Attento agli accessi non bufferizzati, ci sono restrizioni sulla quantità di byte a cui puoi con una operazione (leggi il primo link).

ciao

[fero86]

Originariamente inviato da DanieleC88

http://msdn.microsoft.com/en-us/libr...50(VS.85).aspx
http://msdn.microsoft.com/en-us/libr...18(VS.85).aspx

ti ringrazio, ma quei link sono stati i primi che ho letto quando mi sono posto il problema
non mi sembra che rispondano alla mia domanda sul caching; c'é giusto un'affermazione d'interesse secondo la quale il caching viene operato "per file object" e quindi questo cosa significa? esiste un file object in tutto il sistema per ciascun file, oppure uno per processo oppure uno per HANDLE?

Ti conviene aprire i file con FILE_FLAG_NO_BUFFERING (eventualmente, anche FILE_FLAG_WRITE_THROUGH). Attento agli accessi non bufferizzati, ci sono restrizioni sulla quantità di byte a cui puoi con una operazione (leggi il primo link).

due domande:
1) e volendo aprirlo invece senza quei due flag per motivi di performance? MSDN spiega che per scritture piccole e frequenti conviene usare il caching.
2) cosa cambia aggiungendo anche FILE_FLAG_WRITE_THROUGH? non sono riuscito a capirlo.

[DanieleC88]

Non sapevo, nel caso te li ho postati.
Be' sinceramente sono un po' in dubbio anche io su questo "file object" di cui si parla, personalmente l'avevo interpretato come un identificatore del file a cui fanno capo i vari HANDLE... ma è una mia interpretazione. In questo caso ti andrebbe bene ed avresti la risposta al punto 1). Per il punto 2), serve ad evitare che restino i metadati "appesi" e va a scrivere immediatamente tutto su disco.

[fero86]

Originariamente inviato da DanieleC88

Non sapevo, nel caso te li ho postati.
Be' sinceramente sono un po' in dubbio anche io su questo "file object" di cui si parla, personalmente l'avevo interpretato come un identificatore del file a cui fanno capo i vari HANDLE... ma è una mia interpretazione. In questo caso ti andrebbe bene ed avresti la risposta al punto 1). Per il punto 2), serve ad evitare che restino i metadati "appesi" e va a scrivere immediatamente tutto su disco.

riporto su questa discussione per dire che ho trovato la soluzione. si, era come dicevi tu: il file object é unico su tutto il sistema ed é quello a cui fanno capo tutti gli HANDLE aperti su uno stesso file, indipendentemente dal processo che li apre.
questa pagina esplica chiaramente la terminologia:
http://msdn.microsoft.com/en-us/libr...85(VS.85).aspx

di conseguenza il buffering avviene per file e la cache funziona da coda che ordina tutti i bytes scritti concorrentemente anche prima di qualsiasi flush; un flush da parte di un processo flusha anche i bytes scritti da altri processi.

mi resta solo da verificare se il file pointer viene tenuto per file object o per HANDLE, ma adesso non mi va e comunque sospetto decisamente la prima, che significa che un processo tra una scrittura e un'altra potrebbe ritrovarsi il file pointer magicamente spostato in una posizione che non si aspetta; d'altra parte sarebbe sempre buona pratica aprire un file senza FILE_SHARE_WRITE quando lo si apre con GENERIC_WRITE.