Newsgroup: it.comp.programmare.win32
Titolo: Aprire un file in RAM

Ciao a tutti,
ho un'applicazione (A) scritta in C/C++ da me che genera un file di dati 
che viene poi letto da un'altra applicazione (B) di cui ho solo i binari 
(ambiente Windows XP).
Il file viene creato su disco fisso da (A), la quale poi lancia (B) 
passandogli come parametro il percorso del file appena creato.
Dato che si tratta di un processo iterativo in cui (A) e (B) vengono 
svolti più volte (anche qualche migliaia), vorrei spostare suddetto file 
in RAM, in modo da ridurre i tempi di elaborazione e, soprattutto, 
salvare l'HD.
Sulle vecchie versioni di Win (fino al 98 sicuro, poi in qualche modo 
anche sul 2000) c'era la possibilità di creare un ramdisk, a tutti gli 
effetti gestibile con un HD. Su WinXP pare sia invece necessario 
utilizzare tools di terze parti a pagamento. La spesa non è eccessiva 
(dai 50$ circa) ma prima vorrei esplorare altre vie.
Ritengo che sia necessario agire a livello di sistema operativo, ma 
magari si può fare in qualche altro modo con qualche libreria C/C++.
Avete qualche idea a riguardo?
Grazie per l'aiuto
Saluti
Libra

 salvare l'HD.
Se tale accesso è veloce (come immagino) probabilmente il file verrà 
scritto realmente pochissime volte, verrebbe infatti fatto tutto in 
cache, automaticamente.
-- 
A)bort, R)etry, P)ee in drive door
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 cache, automaticamente.
Cosa intendi per accesso veloce? non ho parametri per valutare, tieni 
presente che l'applicazione scritta da me deve scrivere dai 350 ai 500 
valori sul file, che poi deve essere chiuso e riaperto dall'altra 
applicazione. Tutto questo per parecchie volte.
Quando lancio l'applicazione, io sento l'HD frullare a 1000....
Grazie comunque per la risposta
Libra

 
Le operazioni di scrittura su file (a meno di non richiedere 
espressamente di non usare la cache) sono fatte in cache.
Le successive operazioni di lettura sono fatte in cache, se il dato è 
già presente in memoria, o su disco quando il dato non è presente in 
memoria.
Il SO, poi, scrive i dati su disco quando più gli aggrada.
Le regole che utilizza per valutare quando scrivere? diverse (non ti so 
dire l'ordine poichè ci sono diversi fattori che concorrono):
- Quantità di dati in cache (scrivere 1Mb in un unico blocco è più 
veloce che 10 scritture da 100Kb)
- Memoria libera (se serve memoria per altri scopi, la cache può essere 
svuotate, quindi le scritture diventano effettive)
- Età dei dati (se i dati risiedono nella cache per troppo tempo, 
leggasi anche come "cache invariata per troppo tempo", questi vengono 
scritti)
- Operazioni esplicite di flush (non richiede ulteriori spiegazioni)
- Spegnimento del SO (ovvio, mi pare)
- (qui non ne sono sicuro, probabilmente dipende dal SO) chiusura del 
file (quando chiudi il file, le modifiche devono essere effettive)
In pratica, come dice Due di Picche, se il file non viene ricreato da 
zero ogni volta, rimane quasi sempre in memoria.
Rileggendo bene il tuo post iniziale, però, mi viene in mente che forse 
il continuo frullare del tuo disco possa essere dovuto più 
all'esecuzione dei due processi A e B alternata più volte, piuttosto che 
dalla lettura/scrittura del file.
Che tipo di applicazioni sono (A) e (B)? Nel senso di Cosa fanno? quanto 
sono grandi? (la tua applicazione è stata compilata in modalità release 
o debug?)
Prova ad indagare anche in questo senso (magari facendo in modo che il 
file non venga mai modificato e quindi testare solamente le fasi di 
"esecuzione A" "esecuzione B" "B legge il file")
Luca

 "esecuzione A" "esecuzione B" "B legge il file")
Proverò a ripetere i test estraendo i tempi di lettura da parte di (B).
Se è vero che prende i dati dalla cache, allora ho poche speranze di 
migliorare drasticamente le prestazioni attraverso un ram disk, ma forse 
avrei più chanches di salvaguardare l'HD (swap a parte, ovviamente...)
Grazie e saluti
Libra

Libra ha scritto:

Ti posso consigliare una procedura che dovrebbe assicurarti il meno
overhead possibile.
(A) lancia (B) passandogli un handle di finestra (che è la finestra di
A).
(B) una volta avviato passa la sua handle ad (A) ed in questo modo
possono comunicare tramite messaggi standard.
Per lo scambio dei dati usa un file mappato in memoria.
Poiché i messaggi di windows sono sincroni non hai nemmeno bisogno di
un mutex.
Quindi (A) scrive sul file mappato, imposta un flag di lock per evitare
di rovinarli ed invia un messggio a (B).
(B) legge i dati e, in caso li copi in una propria area, risponde ad
(A) (altrimenti quando ha terminato) il quale resetta il proprio flag.
Se (A) deve usare poi i dati elaborati usa una parte del file mappato e
altri flag.
Naturalmente (B) ha la stessa vita di (A) (che alla chiusura invia un
messaggio di terminazione a (B).
Spero sia chiaro
Ciao

logicMind ha scritto:
<snip>
scusa, ho notato solo ora che di (B) non hai i sorgenti :-(

 scusa, ho notato solo ora che di (B) non hai i sorgenti :-(
potresti comunque usare un file mappato da (A) mantendolo sempre
aperto, ma non viene garantita la coerenza se usato poi con le normali
ReadFile() e WriteFile().
Oppure da (A) non chiudi mai il file se non all'uscita.
Ma penso che l'attività dell'hd dipenda soprattutto dal continuo avvio
del programma (B).
Controlla se non offra un altro modo per interagire.

 Controlla se non offra un altro modo per interagire.
Purtroppo credo non ci siano altri modi.
L'ideale sarebbe stato poter avviare (B) da (A) passandogli la matrice 
direttamente come parametro nella riga di comando ma non è un'opzione 
prevista.
Grazie
Libra


Prova a creare il file con una chiamata all'API "CreateFile", impostando 
i flag "FILE_ATTRIBUTE_TEMPORARY" e "FILE_FLAG_DELETE_ON_CLOSE" nel 
parametro "dwFlagsAndAttributes".
Quando hai scritto tutti i dati (chiamando "WriteFile"), lancia subito 
il programma B, e solo dopo che avrà terminato, chiudi il file 
(chiamando "CloseHandle").
Facci sapere.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 parametro "dwFlagsAndAttributes".
[...]
Qui non ti seguo: sono API di windows quelle da te citate? non ho 
esperienza in questo campo.
Saluti
Libra

 
Con questo metodo, bisogna stare attenti ai permessi di accesso 
(lettura/scrittura). la CreateFile deve essere data con entrambi i 
permessi, e bisogna vedere se il processo (B) non cerchi di impostare un 
accesso esclusivo.
LP


CreateFile,  ReadFile, WriteFile, CloseHandle.
Sì, sono API di Windows per la gestione dei file. Rispetto alle fopen, 
fread, fwrite e fclose (che in ambiente Win32 non fanno altro che 
mascherare le API) ti mettono a disposizione maggiori parametri.
guarda MSDN per maggiori dettagli.
FILE_FLAG_DELETE_ON_CLOSE e FILE_ATTRIBUTE_TEMPORARY, sono dei flag che 
vanno usati nella CreateFile (ti rimando sempre a MSDN)
LP

 magari si può fare in qualche altro modo con qualche libreria C/C++.
Forse si può fare in qualche modo sfruttando le librerie NetBIOS/NetBEUI,
ma non ho idea di come.
-- 
asd

 Hai cercato bene?
Evidentemente no a quanto pare :-)
Quello su codeguru sembra essere ciò che fa al caso mio, speriamo sia 
stabile. Hai qualche esperienza con questo sw?
Grazie mille
Saluti
Libra