[C/C++] I/O Asincrono

[misterx]

non avendo molto tempo a disposizione per approfondire vi chiedo lumi circa la crittura di file in modo asincrono che coinvolge le API di windows.

Più che altro vorrei delle certezze di stare scrivendo realmente in modo asincrono.

Nel mio programma ho due thread A e B i quali usano la mutua esclusione per evitare che se A sta producendo dati, B non può usarli.

Nel momento in cui A li ha prodotti, B vi accede ed è B che ciclandoli deve scriverli su disco ma non deve rimanere in attesa delle scritture stesse, questo per non perdere tempo.

Da quanto ne ho capito se deve usare la funzione CreateFile() e WriteFile() tirando in ballo la struttura OVERLAPPED ma un esempio funzionale mi sarebbe di grande aiuto.


grazie infinite

[misterx]

se volessi poi anche verificare la differenza tra scrittura su disco sincrona ed asincrona come si dovrebbe agire?

grazie

[!fazz]

da quel poco che mi ricordo, la scrittura su windows è sempre asincrona se non specificato il contrario tanto che in c++ si usava il flush per forzare la scrittura su disco

[misterx]

Originariamente inviato da !fazz

da quel poco che mi ricordo, la scrittura su windows è sempre asincrona se non specificato il contrario tanto che in c++ si usava il flush per forzare la scrittura su disco

ciao,
vuoi dire che eventuali ritardi non sono dovute a scritdel ture su disco?

Pensavo che usando le funzioni della libreria standard C le scritture fossero sincrone ed un thread di conseguenza è costretto ad attendere una risposta prima di continuare.

[Mettiu_]

Salve a tutti (primo post per me)!

Originariamente inviato da misterx

Pensavo che usando le funzioni della libreria standard C le scritture fossero sincrone ed un thread di conseguenza è costretto ad attendere una risposta prima di continuare.

Quello che dici è giusto (secondo me) nel senso che le scritture (e le letture) sono sincrone se non diversamente specificato. La questione è che, pur essendo sincrone, vengono bufferizzate cioè il SO effettua l'operazione in RAM e solo in seguito (quando lo ritiene opportuno) allinea il contenuto sul disco. Nel caso del multithreading e delle operazioni sincrone è sempre il SO che garantisce ad ogni thread di vedere una copia allineata e consistente. Il problema potrebbe nascere se fai operazioni asincrone e hai bisogno di sapere che l'operazione precedente sia finita prima di procedere con la successiva... ma non mi sembra questo il tuo caso, ho capito bene? Cioè tu vuoi scrivere dei dati e non ti importa di quando verranno veramente salvati su disco giusto?

[misterx]

Originariamente inviato da Mettiu_

Salve a tutti (primo post per me)!


Quello che dici è giusto (secondo me) nel senso che le scritture (e le letture) sono sincrone se non diversamente specificato. La questione è che, pur essendo sincrone, vengono bufferizzate cioè il SO effettua l'operazione in RAM e solo in seguito (quando lo ritiene opportuno) allinea il contenuto sul disco. Nel caso del multithreading e delle operazioni sincrone è sempre il SO che garantisce ad ogni thread di vedere una copia allineata e consistente. Il problema potrebbe nascere se fai operazioni asincrone e hai bisogno di sapere che l'operazione precedente sia finita prima di procedere con la successiva... ma non mi sembra questo il tuo caso, ho capito bene? Cioè tu vuoi scrivere dei dati e non ti importa di quando verranno veramente salvati su disco giusto?

ciao,
hai capito perfettamente.
Ho un thread produttore che fa la scansione di un certo numero di sensori ed un thread consumatore che nel momento in cui si accorge che un dato sensore ha cambiato il suo stato, scrive alcuni dati su disco.
Il mio problema è che lavorando in termini di millisecondi, si nota un certo ritardo, a volte, ed altre nò intorno ai 50 ms o poco più.

Tale ritardo credo sia dovuto proprio alle scritture su disco date dal fatto che quando il thread consumatore scrive su disco, attende la completa scrittura prima di continuare il suo lavoro.

Da qui il problema di scrivere dati su disco in modo asincrono in modo che il thread consumatore continui indistrurbato il suo lavoro senza attese.

[Mettiu_]

Se i dati da scrivere sono pochi non ti conviene usare l' I/O asincrono perchè è vero che il consumatore torna subito disponibile ma è anche vero che gestire un I/O sovrapposto da parte del SO comporta comunque un overhead che nel caso di piccoli moli di dati non si ammortizza. Per provare ad avere tempi di scrittura quantomeno deterministici potresti flushare i tuoi dati su disco dopo ogni scrittura sincrona e vedere se almeno così ottieni tempi costanti. Se non li ottieni (o sono comunque troppo alti), probabile che hai esigenze di real-time troppo spinte per essere risolte così...

Documentazione MSDN: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

[misterx]

Originariamente inviato da Mettiu_

Se i dati da scrivere sono pochi non ti conviene usare l' I/O asincrono perchè è vero che il consumatore torna subito disponibile ma è anche vero che gestire un I/O sovrapposto da parte del SO comporta comunque un overhead che nel caso di piccoli moli di dati non si ammortizza. Per provare ad avere tempi di scrittura quantomeno deterministici potresti flushare i tuoi dati su disco dopo ogni scrittura sincrona e vedere se almeno così ottieni tempi costanti. Se non li ottieni (o sono comunque troppo alti), probabile che hai esigenze di real-time troppo spinte per essere risolte così...

Documentazione MSDN: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

se fosse determinabile il ritardo forse raggiungerei l'ottimo!
A questo punto dovrei abbandonare le funzioni della libreria standard per usare quelle messe a disposizione da windows ?

Non ho conoscenze nella programmazione real-time purtroppo.

Però: se dovessi mandare in esecuzione n volte il medesimo programma per catturare n sensori da n fonti differenti cosa comporterebbe nei vari ritardi scrivendo e "flushando" ogni volta ?

Avrei in esecuzione n processi e 2n thread e forse non me ne dovrei occupare in quanto ci penserebbe windows?

In questo caso è meglio scrivere dati in modo asincrono?

[Mettiu_]

Originariamente inviato da misterx

se fosse determinabile il ritardo forse raggiungerei l'ottimo!

Il determinismo non credo lo si possa ottenere perchè dipende da troppe cose non direttamente controllabili (carico del sistema in un certo momento, politiche di scheduling, ecc...).

Originariamente inviato da misterx

Però: se dovessi mandare in esecuzione n volte il medesimo programma per catturare n sensori da n fonti differenti cosa comporterebbe nei vari ritardi scrivendo e "flushando" ogni volta ?

Avrei in esecuzione n processi e 2n thread e forse non me ne dovrei occupare in quanto ci penserebbe windows?

In questo caso è meglio scrivere dati in modo asincrono?

Comporterebbe che ad ogni scrittura il SO va sul disco a scrivere e, poichè questo è unico, non può parallelizzare le scritture ma dovrà farle comunque sequenzialmente, senza grossi vantaggi teoricamente. In altri casi può decidere di accumulare un pò di dati e poi scriverli tutti in un colpo solo migliorando l'efficienza (secondo lui). Se però il tuo problema è che non tolleri latenza cioè non tolleri che passi troppo tempo da quando il dato è a disposizione del consumatore a quando questo è disponibile sul file (scritto), allora bisogna capire bene quali sono i parametri che vuoi ottimizzare. E' più importante avere scritto un dato prima possibile a partire da quando questo è stato reso disponibile dal produttore o è meglio migliorare l'efficienza del disco scrivendo più dati in un colpo solo (e quindi aspettandone un certo numero)? Se questi dati arrivano solo "ogni tanto" (rispetto ai tempi della cpu) io farei delle scritture sincrone con flush e mi rimetterei subito in attesa di nuovi dati (il file lo apri una volta sola all'inizio del programma e lo chiudi una volta sola alla fine)...

[misterx]

diciamo che il mio problema maggiore è conoscere con precisione tutte le tempistiche. Se la scrittura su disco sottrae un certo tempo devo tenerne conto ma dovrei sapere con precisione quanto tempo spendo per tale operazione in modo da poterlo sottrarre/sommare al tempo di variazione di stato dei vari sensori.

Già poter dire che flush()+scrittura=50 ms sempre sarebbe un'ottima soluzione.

#include <stdio.h>

int main()
{
   char miastringa[40];
   FILE *stream = fopen("miofile.txt","a");
   printf("Inserisci meno di 40 caratteri -> ");
   fscanf(stdin, "%s", miastringa);
   fprintf(stream, "La mia stringa e' : %sn", miastringa);
   fflush(stream);
   fclose(stream);
}

però anche in questo caso devo attendere la scrittura ed è ancora windows a decidere credo. E quindi quando richiamola fflush() potrei determinare il tempo speso scrivendo:

t1=tempo_start()
fflush()
t2=tempo_end()

tempo_totale=t2-t1;

Sempre che i due tempi mi vengano calcolati al momento della chiamata; ma se anche qui windows interviene in modo random allora non c'è soluzione.

[marco.r]

Originariamente inviato da misterx

ciao,
hai capito perfettamente.
Ho un thread produttore che fa la scansione di un certo numero di sensori ed un thread consumatore che nel momento in cui si accorge che un dato sensore ha cambiato il suo stato, scrive alcuni dati su disco.
Il mio problema è che lavorando in termini di millisecondi, si nota un certo ritardo, a volte, ed altre nò intorno ai 50 ms o poco più.

Tale ritardo credo sia dovuto proprio alle scritture su disco date dal fatto che quando il thread consumatore scrive su disco, attende la completa scrittura prima di continuare il suo lavoro.

Da qui il problema di scrivere dati su disco in modo asincrono in modo che il thread consumatore continui indistrurbato il suo lavoro senza attese.

Se il thread consumatore ci mette troppo a scrivere nelle occasioni in cui il S.O. deve fare il flush dei buffer, probabilmente fai prima a cambiare il metodo di comunicazione tra i due thread. Se, come mi sembra di ricordare, utilizzi una memoria condivisa tra i due thread, con accesso sincronizzato, i ritardi del consumatore si ripercuotono nel produttore.
Devi ricorrere ad un metodo diverso che faccia da buffer e accumuli i dati in eccesso nelle occasioni in cui il consumatore si prende indietro.
Non so di preciso sotto windows, ma alternative dovresti averne piu' di una (socket, pipe e forse anche altro)

[Mettiu_]

Originariamente inviato da misterx

diciamo che il mio problema maggiore è conoscere con precisione tutte le tempistiche. Se la scrittura su disco sottrae un certo tempo devo tenerne conto ma dovrei sapere con precisione quanto tempo spendo per tale operazione in modo da poterlo sottrarre/sommare al tempo di variazione di stato dei vari sensori.

però anche in questo caso devo attendere la scrittura ed è ancora windows a decidere credo. E quindi quando richiamola fflush() potrei determinare il tempo speso scrivendo:

t1=tempo_start()
fflush()
t2=tempo_end()

tempo_totale=t2-t1;

Sempre che i due tempi mi vengano calcolati al momento della chiamata; ma se anche qui windows interviene in modo random allora non c'è soluzione.

Ho provato fare una cosa del genere sul mio pc per vedere se ne esce fuori un calcolo sensato:

#include <stdlib.h>
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	SYSTEMTIME start, end;

	FILE* fp = fopen("prova.dat", "w+");
	
	char* text = "Questo è un testo di prova da scrivere sul file";
	if(fp == NULL)
		exit(-1);

	GetSystemTime(&start);
	fprintf(fp, text);
	fflush(fp);
	GetSystemTime(&end);
	
	printf("Ora avvio scrittura: %dsec %dmilliSec", start.wSecond, start.wMilliseconds);
	printf("\nOra fine scrittura: %dsec %dmilliSec", end.wSecond, end.wMilliseconds);
	printf("\nTempo impiegato per la scrittura: %d\n", end.wMilliseconds - start.wMilliseconds);
        fclose(fp);
	system("PAUSE");
	return 0;
}

L' output prodotto è:

Ora avvio scrittura: 16sec 614milliSec
Ora fine scrittura: 16sec 615milliSec
Tempo impiegato per la scrittura: 1ms

Ti sembra possibile? E' realistico come tempo?

[misterx]

Originariamente inviato da Mettiu_

Ho provato fare una cosa del genere sul mio pc per vedere se ne esce fuori un calcolo sensato:

#include <stdlib.h>
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	SYSTEMTIME start, end;

	FILE* fp = fopen("prova.dat", "w+");
	
	char* text = "Questo è un testo di prova da scrivere sul file";
	if(fp == NULL)
		exit(-1);

	GetSystemTime(&start);
	fprintf(fp, text);
	fflush(fp);
	GetSystemTime(&end);
	
	printf("Ora avvio scrittura: %dsec %dmilliSec", start.wSecond, start.wMilliseconds);
	printf("\nOra fine scrittura: %dsec %dmilliSec", end.wSecond, end.wMilliseconds);
	printf("\nTempo impiegato per la scrittura: %d\n", end.wMilliseconds - start.wMilliseconds);
        fclose(fp);
	system("PAUSE");
	return 0;
}

L' output prodotto è:

Ora avvio scrittura: 16sec 614milliSec
Ora fine scrittura: 16sec 615milliSec
Tempo impiegato per la scrittura: 1ms

Ti sembra possibile? E' realistico come tempo?

ciao,
gran bella prova
Se ripetuto almeno un migliaio di volte ripete il medesimo valore allora sarebbe attendibile.
Però proverei anche lanciando diverse istanze dello stesso programma per vedere cosa accade, quindi si ritroverebbe a lavorare su n file simultaneamente.

[Mettiu_]

Originariamente inviato da misterx

ciao,
gran bella prova
Se ripetuto almeno un migliaio di volte ripete il medesimo valore allora sarebbe attendibile.
Però proverei anche lanciando diverse istanze dello stesso programma per vedere cosa accade, quindi si ritroverebbe a lavorare su n file simultaneamente.

Anche se fai un while da 10000 e stampi su file, le varie durate sono sempre 0-1 ms! Mai al di sopra.

[!fazz]

occhio che windows e real time non vanno per nulla d'accordo

[misterx]

Originariamente inviato da Mettiu_

Anche se fai un while da 10000 e stampi su file, le varie durate sono sempre 0-1 ms! Mai al di sopra.

e se esegui simultaneamente 10 volte lo stesso programma?

[misterx]

Originariamente inviato da !fazz

occhio che windows e real time non vanno per nulla d'accordo

lo stavo pensando, difatti se scrivo

t1=timer_start
fflush()
t2=timer_end

facendo t2-t1 di sicuro il tempo è corretto però non so quando windows mi stampa il risultato in quanto anch'esso, le sue righe di codice, è soggetto a ritardi che si riflettono poi sul thread consumatore



http://msdn.microsoft.com/it-it/libr...27.aspx#ID0EGC

http://msdn.microsoft.com/en-us/libr...bedded.5).aspx