Discussion :

[Celelibi]

La mémoire partagée est une assez bonne idée, mais si la machine crash, on a tout perdu.
Il faudrait donc encore une fois l'écrire sur le disque (besoin de mutex etc...).

[milouz123]

Je suis d'accord sur ce point.

En ce qui concerne l'écriture sur disque, l'application elle même écrit dans des tampons en mémoire et à moins que ce ne soit précisé, les écritures ne sont pas synchrones.
Donc écrire dans un fichier, sur un UNIX, revient à écrire dans un tampon en mémoire.

Certe, pour des volumes important (comme pour une base de données), le flush des tampons sur disque peut rallentir le système. Mais c'est là une autre problématique.

[Sylar44]

je ne vois pas trop à quoi peut servir les fflush

Par contre je ne vois pas l'interet de me servir de threads, j'utilise déjà un compteur, une sorte de rdtsc si vous connaissez et qui est assez précis, donc autant faire l'appel à la fonction d'écriture dans un fichier plutot que de me servir de threads.

[Celelibi]

On a pas parlé de fflush, mais du flush des buffers disque (via l'appel système sync cf man 2 sync).

L'intérêt des threads c'est de ne pas bloquer ton application durant l'écriture sur disque, ce qui semblait être ta préoccupation principale.

[milouz123]

Une remarque sur l'utilisation des threads : je ne sais pas sur quelle version d'OS tu vas coder, mais si tu ne veux pas être bloqué par les accès disques, fait bien attention à ne pas utiliser des threads implémentés en user space.

[Sylar44]

ben je serais sous ubuntu et je programmerai en C
je me demandais juste si les valeurs que j'allais écrire dans le fichier texte n'allait pas être erronné à cause du thread, vu que l'ecriture sera mis entre parentheses par moment et donc les valeurs ne seront plus bonnes du fait du temps passé(par exemple si je prend la position d'un objet comme valeur à enregistrer)
vous croyez pas?

[milouz123]

Quel est le but de ce programme si ça n'est pas indiscret ?

[Celelibi]

Sylar44, le but est d'écrire sur le disque, un état complet et cohérent.
Pour limiter les cas où la machine crash pendant l'écriture, il faut que l'écriture ne soit pas trop fréquente.
Si le but c'est bien de faire de la reprise sur crash, écrire l'état une fois toutes les heures est amplement suffisant à mon avis (au vu de la stabilité des machines actuelles). Si t'es vraiment parano tu écrit une fois toutes les 10 secondes, voire, toutes les secondes...
L'intervalle d'écriture donne le temps maximal de calcul que tu aura perdu dans le crash.
C'est beaucoup de perdre une heure de calcul tous les 42 jours ?

Je suppose aussi que si tu veux faire de la reprise sur crash c'est que le calcul risque de durer plusieurs jours. N'est-ce pas ?

[Sylar44]

oui c'est ca

[Celelibi]

Sinon, au lieu que ce soit un thread qui fasse l'enregistrement (ce qui impliquerait des mutex qui donc ralentiraient le programme), tu peux faire l'enregistrement directement dans le programme principal.

Tu peux te servir de la fonction alarm() qui permet de programmer l'envoie d'un signal SIGALRM au bout d'un certain nombre de secondes.
Et quand tu reçoit ce SIGALRM tu enregistre l'état sur le disque.

Le seul problème c'est que le SIGALRM peut interrompre ton programme n'importe quand. Donc pour ne pas risquer d'enregistrer un état incohérent, tu peux :
- Définir une variable globale qui indiquera que l'état doit être sauvegarder
- Dans le handler du SIGALRM définir cette variable à 1
- Dans la boucle de calcul vérifier à chaque itération la valeur de cette variable
- Si elle vaut 1, on enregistre l'état et on la remet à 0

Bien entendu, tu t'arranges pour que dans ta boucle principale, l'enregistrement se fasse uniquement quand l'état est cohérent.

[lu6fer]

je n'zi pas forcement tout compris, ni tout suivit.

mais pour quoi ne pas utiliser des fork ?

le prog principal de calcul, et un fils d'écriture.

et une communication par pipe.

quand le prog principal est arriver a un état cohérent, il l'envoie au fils qui va l'écrire.

Effectivement c'est moins paralléliser que du theard, mais a la vitesse des processeurs, et les performance du scheduller, ca ne devrai pas te poser probleme.

de plus comme tu controle l'envoie (envoie sur etat coherent uniquement) tu es sur que tu ecrit uniquement des données fiables.

[Celelibi]

Il faudrai simplement vérifier que l'état n'est pas trop gros, sinon le write sur le pipe risque d'être bloquant le temps de l'écriture.
Pour éviter cet éventuel blocage il serait possible de remplacer le pipe par une file de messages.
Mais bon, personnellement, je ne pense pas qu'il soit réellement nécessaire de déporter l'écriture dans un autre processus. En effet, il va pas écrire l'état à chaque tour de boucle (ça serait débile, inutile et risquerai de corrompre la sauvegarde en cas de crash), donc je ne pense pas que ça soit si terrible de perdre 0.1 seconde à écrire l'état sur disque toutes les heures.

Il ne faut pas oublier que pour écrire régulièrement l'état, il faut un timer. Qui, si possible, nécessite très peu de calculs dans la boucle principale du programme. Je pense que la fonction alarm est parfaite pour ça.