Discussion :

[qouify]

salut à vous,
est ce que c'est sûr d'avoir deux threads qui écrivent concurrement dans un même fichier si le fichier est protégé par un mutex?
par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
char * p1_id = "proc1";
char * p2_id = "proc2";
FILE * f = fopen("data", "a");
pthread_mutex_t lock;
void p1() {
   pthread_mutex_lock(&lock);
   fwrite(p1_id, 5, 1, f);
   pthread_mutex_unlock(&lock);
}
void p2() {
   pthread_mutex_lock(&lock);
   fwrite(p2_id, 5, 1, f);
   pthread_mutex_unlock(&lock);
}

p1 et p2 sont appelées par deux processus différents. est ce que c'est correct?

merci

[Franck.H]

est ce que c'est sûr d'avoir deux threads qui écrivent concurrement dans un même fichier si le fichier est protégé par un mutex?

Bin oui carrément plus sûr que de ne pas utiliser le thread

p1 et p2 sont appelées par deux processus différents. est ce que c'est correct?

Tu veux surement dire "par deux thread" différents, il ne faut pas confondre thread et processus, si cétait par deux processus différents, tu serais alors passé par un fork() (sous linux du moins)


A savoir que s'il faut que les écritures se fassent dans un ordre précis, tu peux également utiliser la synchronisation avec pthread_cond_wait et pthread_cond_signal

[qouify]

ok merci pour l'info. oui effectivement je voulais parler de threads et non de processus.

sinon autre question sur les entrées sorties. est ce que vous savez si les écritures avec fwrite sont synchrones ou si les données sont bufferisées pour être écrites en blocs?

si par exemple un thread écrit en fin de fichier et l'autre lit en début, est ce que dès que j'ai fait le fwrite les données sont lisibles?

[Franck.H]

Heu il me semble que la fonction fwrite est bufferisée, du moins elle passe par un tampon et n'écrit donc pas directement dans le fichier.

[qouify]

ah mais ca m'arrange pas du tout ça.
et est ce qu'il y a un moyen de forcer fwrite (ou avec une autre fonction) à vider son buffer après chaque appel?

[Franck.H]

ah mais ca m'arrange pas du tout ça.
et est ce qu'il y a un moyen de forcer fwrite (ou avec une autre fonction) à vider son buffer après chaque appel?

Je ne saurais t'en dire plus pour le moment désolé, d'ailleurs je ne sais même s'il y a une corrélation entre le buffer de frwite et l'impact sur l'écriture comme tu le mentionne.... je pense que le mieux serait de tester l'affaire et là encore, il se peut que le comportement de ce genre de fonction change suivant l'implémtenation

[EDIT]

D'après une recherche rapide il se trouve être le cas où l'écriture des données par fwrite se fait après fermeture du flux par fclose... voir: http://www.developpez.net/forums/arc...hp/t-2598.html

[/EDIT]

[qouify]

ok merci. je m'en vais tester tout ça.

[souviron34]

[EDIT]

D'après une recherche rapide il se trouve être le cas où l'écriture des données par fwrite se fait après fermeture du flux par fclose... voir: http://www.developpez.net/forums/arc...hp/t-2598.html

[/EDIT]

Faux... ça dépend de la taille du buffer tampon et des données à écrire....

ça écrit au fur et à mesure d'abord si on suit d'un fflush, ensuite si le tampon est rempli...

[Franck.H]

Faux... ça dépend de la taille du buffer tampon et des données à écrire....

ça écrit au fur et à mesure d'abord si on suit d'un fflush, ensuite si le tampon est rempli...

Ok merci de la précision C'est une fonction que j'utilise que trop peu donc j'était pas trop sûr

[Emmanuel Delahaye]

ah mais ca m'arrange pas du tout ça.
et est ce qu'il y a un moyen de forcer fwrite (ou avec une autre fonction) à vider son buffer après chaque appel?

fflush() est fait pour ça.

[valefor]

si par exemple un thread écrit en fin de fichier et l'autre lit en début, est ce que dès que j'ai fait le fwrite les données sont lisibles?

Sans parler de bufferisation, si tu te demandais si tu pouvais faire un read juste après un write, je pense que la réponse est oui, tu récupère bien ce que tu viens d'écrire même si ce n'est pas encore écrit physiquement.

[souviron34]

Sans parler de bufferisation, si tu te demandais si tu pouvais faire un read juste après un write, je pense que la réponse est oui, tu récupère bien ce que tu viens d'écrire même si ce n'est pas encore écrit physiquement.

Peux-tu expliquer comment on peut lire quelque chose qui n'est pas écrit physiquement ?????


Justement comme on l'a dit ci-dessus, pour garantir qu'on lit ce qui a été écrit, et que ce qui a été écrit correspond bien , on fait le fflush....


Exemple bête :

tu écris 20 caractères, sans faire de fflush, sans faire de fclose, dans un fichier vide..

Tu lis.... 0... (si la taille du tampon est supérieure à 20, ce qu'elle est généralement )

[valefor]

Je voulais dire écrit physiquement sur le disque/réseau/etc. Je pensais qu'un driver qui implémente un buffer en écriture, doit être capable d'aller taper dedant en lecture...

[EDIT]Après vérif de mes propres yeux, je tombe des nues..... Cela ne me semblait pourtant pas bien compliqué à faire[/EDIT]

[Médinoc]

Ça dépend à quel niveau est le buffer.

• Le "cache système" est complètement transparent et la lecture est correctement gérée.
• Par contre, les buffers des flux C sont spécifiques flux-par-flux, et le reste du processus (et à fortiori du système) n'en ont pas connaissance.

[souviron34]

Ça dépend à quel niveau est le buffer.

• Le "cache système" est complètement transparent et la lecture est correctement gérée.
• Par contre, les buffers des flux C sont spécifiques flux-par-flux, et le reste du processus (et à fortiori du système) n'en ont pas connaissance.

Oui pour le point 2, mais non pour le point 1

Si tu reprends la question :

Je voulais dire écrit physiquement sur le disque/réseau/etc. Je pensais qu'un driver qui implémente un buffer en écriture, doit être capable d'aller taper dedant en lecture...

• c'est pas le fait qu'il puisse aller "taper dedans", c'est le fait que tu écris DANS UN FICHIER. Si tu lis un fichier, tu lis ce qu'il y a écrit PHYSIQUEMENT.. Même chose quand tu écris : c'est considéré comme écrit quand c''est PHYSIQUEMENT écrit...
  
  
• D'autre part, il y a un tampon à l'écriture, un tampon à la lecture. Pourquoi, selon quelle logique, les 2 communiqueraient ? Ils peuvent être utilisés par des programmes différents, à des moments différents..... C'est juste une question de logique.... Tu peux écrire un fichier et en lire un autre....

[Médinoc]

Sous Windows en tout cas, le "cache système" n'est pas "de simples données brutes", mais une vue partielle du système de fichiers. Si tu ouvres un fichier (sur une clé USB par exemple), écris dedans avec ton programme, et le fermes, il faut un moment pour que Windows reporte les modifications sur la clé (surtout en USB1). Et pourtant, si tu rouvres le même fichier en lecture, c'est la version du cache qui sera consultée.

[souviron34]

ok, j'ai découvert à l'usage (avec de gros inconvénients d'ailleurs), que Win et tous ses outils ou presques utilisent la notion de cache. Mais comme dit plus haut, 1) c'est illogique... 2) ça fait que tu arrives à des deadlocks (et c'est pas rare sous Win) , et enfin 3) sous les autres systèmes (en tous cas unixoides), c'est faux...

[Jean-Marc.Bourguet]

[*]c'est pas le fait qu'il puisse aller "taper dedans", c'est le fait que tu écris DANS UN FICHIER. Si tu lis un fichier, tu lis ce qu'il y a écrit PHYSIQUEMENT.. Même chose quand tu écris : c'est considéré comme écrit quand c''est PHYSIQUEMENT écrit...

Pas un OS que je connais n'attends l'ecriture physique pour rendre la main.

[souviron34]

Pas un OS que je connais n'attends l'ecriture physique pour rendre la main.

J'ai pas dit rendre la main.. J'ai dit lire un fichier avec une modification non encore écrite PHYSIQUEMENT dans le fichier...

[Jean-Marc.Bourguet]

ok, j'ai découvert à l'usage (avec de gros inconvénients d'ailleurs), que Win et tous ses outils ou presques utilisent la notion de cache. Mais comme dit plus haut, 1) c'est illogique... 2) ça fait que tu arrives à des deadlocks (et c'est pas rare sous Win) , et enfin 3) sous les autres systèmes (en tous cas unixoides), c'est faux...

Et sync, fsync, *flushd, ca sert a quoi?