Discussion :

[barnoufal]

Bonjour à tous,

J'ai un processus qui écrit une chaîne de caractères dans un fichier au moyen de fprintf n fois.
A chaque itération, n fait partie de la chaîne de caractères écrite.

Lorsque j'ouvre le fichier produit, j'observe bien que n est croissant au fur et à mesure des lignes écrites.

Si le nombre d'écritures est très très grand, est-il possible que les écritures se mélangent et que n ne soit plus strictement croissant?

Merci

[valefor]

Il ne peut y avoir mélange que si :
- tu es multithreadé.
- tu mélanges des 'fprintf(stdout' avec des 'fprintf(stderr' et que que tu rediriges les deux dans ton log.

[Obsidian]

Il ne peut y avoir mélange que si :
- tu es multithreadé.
- tu mélanges des 'fprintf(stdout' avec des 'fprintf(stderr' et que que tu rediriges les deux dans ton log.

Ou encore, que deux processus distincts (donc pas des threads) écrivent dans le même fichier. C'est possible aussi, spécialement si on lance deux fois le même programme par erreur.

Si le nombre d'écritures est très très grand, est-il possible que les écritures se mélangent et que n ne soit plus strictement croissant? Merci

Non, il n'y aucune raison pour que ton ordinateur « s'emmêle les pinceaux » et ne suive plus le fil. Par contre, la variable que tu vas utiliser pour faire le compte a une importance. Avec un unsigned long int 32 bits, tu peux compter jusqu'à 4.294.967.295 (0xffffffff). Donc, passé tes quatre milliards de ligne (il faut les faire, déjà), ton compteur risque de revenir à zéro. Avec un unsigned long long int sur 64 bits, en revanche, cela sera aussi le cas, mais il faudra trois ou quatre millénaires à une machine moderne pour en faire le tour, et quelques milliards de disques durs pour stocker le résultat.

[valefor]

Ou encore, que deux processus distincts (donc pas des threads) écrivent dans le même fichier. C'est possible aussi, spécialement si on lance deux fois le même programme par erreur.

Je ne pense pas. Je ne sais plus dans quel man j'avais vu l'explication, je vais rechercher.

En attendant, un petit 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
16
17
18
19
20
21
22
#include <stdio.h>
 
#include <signal.h>
 
static int stop = 0;
 
void handler(int signum)
{
  fprintf(stderr, "sigint\n");
  stop = 1;
}
 
int main(int argc, char **argv)
{
  signal(SIGINT, handler);
 
  while(!stop)
    {
      fprintf(stdout, "%s\n", argv[1]);
    }
  return 0;
}

Lances deux fois ce programme avec un paramètre différent.

[Obsidian]

Lances deux fois ce programme avec un paramètre différent.

Résultat sur mon terminal :

Code Shell :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
$ ./ecrire Un
Un
Un
Un
…
<Ctrl-Z>
$ ./ecrire Deux
Deux
Deux
Deux
…
<Ctrl-Z>
$ bg
Deux
Deux
Deux
…
($ bg)
Un
Deux
Un
Deux
Un
Deux
Un
Deux
…

Il n'y a aucune raison que cela ne se produise pas. Un fichier peut tout-à-fait être ouvert plusieurs fois en lecture et en écriture (ou alors, le système est anté-diluvien). Il faut poser un verrou explicite pour l'ouvrir en accès exclusif, et faire attention à ce que l'on fait. Sous Linux, les verrous flock() sont consultatifs. Il faut monter le système de fichiers avec une option spéciale (-mand : mandatory) pour les rendre impératifs.

Le seul problème qu'un processus peut connaître est lorsqu'il lit l'entrée standard et qu'il est en tâche de fond. Comme l'entrée standard ne peut être dirigée que vers un seul processus, il reçoit un SIGSTOP.

[valefor]

Héhé, au temps pour moi. Deux gourdes : ma manip qui n'était pas bonne et ma mémoire qui me fait défaut.

Vivement le we, merci pour ta correction.

[barnoufal]

Merci pour vos réponses!