[C] Scrittura concorrente in file

[Unrue]

Salve,
mi domandavo come fare per far scrivere contemporaneamente a più processi nello stesso file binario. Ho provato a dire ad ogni processo di scrivere nel file posizionando il puntatore con fseek, solo che ogni volta ovviamente il file viene sovrascritto dall'ultimo processo che arriva. Grazie.

[andbin]

Originariamente inviato da Unrue

mi domandavo come fare per far scrivere contemporaneamente a più processi nello stesso file binario. Ho provato a dire ad ogni processo di scrivere nel file posizionando il puntatore con fseek, solo che ogni volta ovviamente il file viene sovrascritto dall'ultimo processo che arriva. Grazie.

Far scrivere a più processi sullo stesso file ma in punti diversi non credo che sia un problema (dovrei comunque verificare bene).
Mentre invece il problema esiste sicuramente per scritture contemporanee nello stesso punto.
In ogni caso sarebbe meglio fare un lock del file (o di una parte del file, se è possibile), fare le modifiche, e poi togliere il lock.
Comunque quando passa di qui qualcuno più esperto sull'argomento, saprà dirti sicuramente meglio.

[Johnn]

Non consideratemi esperto, ma non si avrebbero problemi anche nella scrittura contemporanei in punti diversi per il fatto che non sarebbe più coerente la posizione?

Io avrei detto di usare i semafori, o comunque un qualsiasi strumento di mutua esclusione.

[Unrue]

Originariamente inviato da Johnn

Non consideratemi esperto, ma non si avrebbero problemi anche nella scrittura contemporanei in punti diversi per il fatto che non sarebbe più coerente la posizione?

Io avrei detto di usare i semafori, o comunque un qualsiasi strumento di mutua esclusione.

In che senso non sarebbe più coerente la posizione?

[Unrue]

Originariamente inviato da andbin

Far scrivere a più processi sullo stesso file ma in punti diversi non credo che sia un problema (dovrei comunque verificare bene).
Mentre invece il problema esiste sicuramente per scritture contemporanee nello stesso punto.
In ogni caso sarebbe meglio fare un lock del file (o di una parte del file, se è possibile), fare le modifiche, e poi togliere il lock.
Comunque quando passa di qui qualcuno più esperto sull'argomento, saprà dirti sicuramente meglio.

In realtà a me va bene anche che scriva uno per volta, ovviamente in punti diversi.

[andbin]

Originariamente inviato da Johnn

Non consideratemi esperto, ma non si avrebbero problemi anche nella scrittura contemporanei in punti diversi per il fatto che non sarebbe più coerente la posizione?

La posizione all'interno del file è legata al "handle" (o descrittore, come vuoi chiamarlo) aperto dal processo. Non è una cosa "globale"

Originariamente inviato da Johnn

Io avrei detto di usare i semafori, o comunque un qualsiasi strumento di mutua esclusione.

No ... come farebbero le applicazioni A (sviluppata da Tizio) e B (sviluppata da Caio) a sapere che per accedere, in modo esclusivo, ad uno stesso file, si devono usare dei semafori, mutex o altro???

[recoil]

esattamente come devono avvenire le scritture? devi posizionarti in un punto preciso o basta che tu scriva alla fine del file ogni volta?

[71104]

in Win32 esiste l'overlapped I/O, che supporta già da solo tutta la sincronizzazione necessaria a risolvere il problema.

EDIT - no scusate, non vorrei aver detto una boiata, controllo meglio...
EDIT2 - boh, non è che sia esplicitato molto bene, ma mi pare di aver capito che se una lettura overlapped avviene contemporaneamente a una scrittura overlapped, i dati letti non sono "inconsistenti"; mentre se le due non operazioni fossero overlapped i dati letti potrebbero essere inconsistenti.

[andbin]

Originariamente inviato da 71104

in Win32 esiste l'overlapped I/O, che supporta già da solo tutta la sincronizzazione necessaria a risolvere il problema.

L'overlapped I/O è solo .... un I/O asincrono (le funzioni ritornano subito e il risultato ... successivamente). Non ha nulla a che fare con la concorrenza nella scrittura o con il locking.

[71104]

Originariamente inviato da andbin

L'overlapped I/O è solo .... un I/O asincrono (le funzioni ritornano subito e il risultato ... successivamente). Non ha nulla a che fare con la concorrenza nella scrittura o con il locking.

credo che la sincronizzazione per evitare l'inconsistenza delle operazioni di I/O sia una conseguenza dell'implementazione dell'overlapped I/O, ma in effetti è meglio non farci affidamento. per definizione l'unica garanzia che ti da' l'overlapped I/O è il poter ricevere in un secondo momento la notifica di terminazione di operazioni lunghe.

[Unrue]

Originariamente inviato da recoil

esattamente come devono avvenire le scritture? devi posizionarti in un punto preciso o basta che tu scriva alla fine del file ogni volta?

No, in un punto preciso, devo scriverci una matrice.

[Unrue]

Ho scritto questo:

void scrivi_file(float**matrice_trasposta_locale,int lx,int dim_mat,int me)
    {  
      struct flock fl;
      int fd;
      off_t offset;
      int ris;
      fl.l_type= F_WRLCK;  /* tipo di lock*/
      fl.l_whence = SEEK_SET; /* offset */
      fl.l_start  = 0;        /* Offset per l_whence         */
      fl.l_len    = 0;        /* length, 0 = to EOF           */
     fl.l_pid    = getpid(); /* our PID                      */
	  
	  
	  fd = open("home/gabriele/Desktop/output", O_WRONLY);  //fd è il Descrittore del file
	  
	  
	  fcntl(fd, F_SETLKW, &fl);  // Attendi per avere il lock
	  lseek(fd, dim_mat*lx*me*sizeof(float),fl.l_whence);
      int i;
      int j;
      
      
      for(j=0;j<lx;j++)
      	{ 
              for(i=0;i<dim_mat;i++)
      	        {   
                         printf(" Sono arrivato  : %d \n",me);
      			ris=write(fd,&matrice_trasposta_locale[i][j],1);
      		printf("Valore :  %2.1f da %d \n ",matrice_trasposta_locale[i][j],me);
      		printf("Risultato: %d \n",ris);		 
      		}
      	}
      		
      fl.l_type   = F_UNLCK;  
      fcntl(fd, F_SETLK, &fl);
      
     
    
    }

La cosa strana è che le scritture avvengono a video correttamente, ma nel file non scrive,infatti la write ritorna sempre -1

[andbin]

Originariamente inviato da Unrue

La cosa strana è che le scritture avvengono a video correttamente, ma il file non c'è!!

Verifica bene la documentazione di open()!

fd = open("home/gabriele/Desktop/output", O_WRONLY | O_CREAT);

Mettendo solo O_WRONLY, la open fallisce se il file non esiste già. Con O_CREAT, se non c'è, lo crea.

[Unrue]

Grazie del suggerimento,però open continua a ritornarmi -1 Sono sotto Linux, forse c'è un problema di permessi per scrivere nella cartella?

[andbin]

Originariamente inviato da Unrue

Grazie del suggerimento,però open continua a ritornarmi -1 Sono sotto Linux, forse c'è un problema di permessi per scrivere nella cartella?

Beh, verifica bene il path! Visto così suppongo che debba essere:

/home/gabriele/Desktop/output

[Unrue]

Ma por... vero . Adesso il primo processo che arriva apre il file e ci scrive,però gli altri che vengono dopo ritornano -1 sempre alla open. L'attesa per prendere il lock la fa la fcntl con F_SETLKW, non capisco.. Sembra che gli altri non attendano di prendere il lock ed escano subito.

[Unrue]

Ho capito perchè: il primo processo crea il file. Ma tale file non ha permessi di scrittura. Ho provato a metterci un file vuoto ed a dare tutti i permessi in scrittura e lettura ed adesso tutti ci scrivono,strano però..

[andbin]

Stavo leggendo adesso la documentazione di fcntl(). F_GETLK, F_SETLK e F_SETLKW sono definiti "Advisory locking". Vuol dire che non gestiscono un reale blocco "forzato" sul file. Vanno bene solo quando i processi "cooperano" insieme, cioè sanno di dover lavorare su un file comune e quindi effettuano questo tipo di lock.

Per dirla in breve: apri un file di testo con la open(), fai il lock e poi prova, da un altro prompt, a fare echo "blabla" > file. Vedrai che la echo scrive sul file. Tu pensi: ma l'ho bloccato!! Sì ma echo non "coopera" e non usa fcntl per fare il lock.

In definitiva: usare F_GETLK, F_SETLK e F_SETLKW non ti para il sedere da qualunque altro processo che vuole scrivere sul file.

[Johnn]

Originariamente inviato da andbin

La posizione all'interno del file è legata al "handle" (o descrittore, come vuoi chiamarlo) aperto dal processo. Non è una cosa "globale"

No ... come farebbero le applicazioni A (sviluppata da Tizio) e B (sviluppata da Caio) a sapere che per accedere, in modo esclusivo, ad uno stesso file, si devono usare dei semafori, mutex o altro???

Premetto che non ho tanto tempo, quindi post frettoloso.

La prima parte mi convince, parzialmente però quando ho tempo mi documenterò meglio, comunque ok.

La seconda, come anche è ripetuto nell'ultimo post, non l'ho capita: nel senso che motivo c'è di essere cautelati da scritture di processi non previsti? Non mi pare sia richiesto da Unrue. Se si volesse così, penso si debba pensare su due livelli: uno di mutua esclusione e un altro di controllo di accesso al file (permessi?).

[beppegrillo]

Originariamente inviato da Johnn

Premetto che non ho tanto tempo, quindi post frettoloso.

La prima parte mi convince, parzialmente però quando ho tempo mi documenterò meglio, comunque ok.

Su Os *unix, la cosa è gestita mediante due tabelle, una di tipo globale in cui vi sono fisicamente i dati e l'altra di tipo utente che recupera le informazioni da quella globale e ne possiede di proprie (ad. es offset)
Per questo motivo se esegui scritture con processi diversi, non apriranno due volte lo stesso file, ma ciascun vedrà il file come proprio.