Discussion :

[Sylar44]

Bonjour,
je souhaite récuperer quelques valeurs de mon programme en C qui tourne sous Ubuntu.
Ce que je veux, c'est m'en resservir plus tard, lors d'une autre application(enfin dès que je coupe le programme et que je le rallume).
Je voudrais faire une sorte d'enregistrement dans un fichier texte, mais l'ouverture et l'ecriture dans un fichier est trop long pour ce que je veux faire.
Quelqu'un a une idée pour savoir commet je dois proceder?

[publicStaticVoidMain]

Bonjour,
je souhaite récuperer quelques valeurs de mon programme en C qui tourne sous Ubuntu.
Ce que je veux, c'est m'en resservir plus tard, lors d'une autre application(enfin dès que je coupe le programme et que je le rallume).
Je voudrais faire une sorte d'enregistrement dans un fichier texte, mais l'ouverture et l'ecriture dans un fichier est trop long pour ce que je veux faire.
Quelqu'un a une idée pour savoir commet je dois proceder?

[Sylar44]

oui ca vous parait bizarre aussi
autant enregistrer ces valeurs en cas d'erreurs ou en cas de fermeture, c'est ce qu'il y a de mieux dans la limite du possible non?

[valefor]

Que sont ces valeurs ?

Des variables représentant l'état du programme ?
Un dump mémoire ?
Autres choses ?

[Sylar44]

oui c'est ca des valeurs qui représente l'état du programme mais aussi de l'automate associé.

[valefor]

Tu as donc une structure que tu peux sauver en l'écrivant dans un fichier de conf (binaire, texte, xml, etc...). Ce fichier sera rechargé au démarrage de ton appli.

C'est le même principe d'une sauvegarde de jeux que tu veux ?

[Sylar44]

oui c'est ca en quelques sortes

le problème c'est que le temps d'ecriture et de lecture doivent être rapide
en millisecondes au maximum

sinon je charge les données qu'en quand il y a une panne sur l'automate et que je change un bout de programme mais en cas de coupure de courant ca fait mal

[valefor]

Effectivement, en cas de coupure...

Une solution serait de régulièrement écrire ton état sur le disque. Tu perds juste ce qui s'est passé dans ton intervalle d'écriture.

Ou si tes données constituent un état qui ne change pas trop souvent, tu écris à chaque changement d'état.

A réfléchir.

[Sylar44]

oui mais là si j'écris pendant que l'atomate tourne, je ne peux pas faire tout ce que je veux faire car je dois pouvoir le suivre( si je peux accéder à la dizaine de micro-secondes ca serait bien) et si j'écris dans un fichier pour tout sauver c'est trop long pour moi

[FloMo]

Théoriquement, si tu enregistres tes données via des flux ( fopen, fclose ) , tes accès seront très rapides ( je parcours un fichier indexé de 2200 x 2Mo en moins de 2s ) .
Il te suffit alors de vider le tampon de temps en temps pour t'assurer que les données sont écrites.

[valefor]

Tu ne peux pas faire un thread basse priorité qui a accès au disque pour la sauvegarde ?

[Sylar44]

et on fait ca comment valefor?

[Elv13]

Fait une recherche pour pthread

http://www.google.ca/search?as_q=pth...s=&safe=images

[Sylar44]

Ben je trouve pas ca terrible, surtout si je dois appeler des programmes tout les n microsecondes(voir tout les n millisecondes)

[sliderman]

Ben je trouve pas ca terrible, surtout si je dois appeler des programmes tout les n microsecondes(voir tout les n millisecondes)

ben tu fait un programme multithread

venant du java, je ne sais pas trop si tu peux le faire en C (sans le ++)
à mon avi faire trois thread
1 => programme
2 => sauvegarde (tu peux l'ordmire et le réveiller)
3 => contact avec les autres appli

[Sylar44]

oui mais le problème c'est que mon programme tourne sur un automate
si je fais un enregistrement en me servant de threads, le programme risque d'être completement déphasé avec ce qui arrive sur l'automate(un enregistrement dans un fichier c'est trop long, plursieurs millisecondes), il doit bien avoir une autre solution, comment les constructeurs de logiciels automatiques font? je pense pas que c'est comme ca, en tout cas.

[valefor]

Pour avoir travaillé sur un projet dans lequel on a eu ce genre de problème, je peux te dire que la solution des threads n'est pas délirante.

Dans notre cas, on écrivait régulièrement dans une EEPROM. Ce n'est pas un fichier, mais, c'est pareil, cela demandait des "accès lents". Un thread avait donc été fait pour désynchroniser les accès à l'EEPROM. Périodiquement (disons T secondes), on écrivait l'état de l'appareil en eeprom. En cas de coupure, on perdait au maximum T secondes.
Bien sûr, suivant le média sur lequel tu écris, il faut mettre en place un mécanisme de détection de corruption.

[Sylar44]

voilà, c'est ca que je veux utiliser
une EEPROM ca à vraiment l'air bien

Il me reste plus qu'à savoir comment l'utiliser

Merci valefor

[Celelibi]

Je ne comprend pas bien pourquoi c'est si dérangeant de perdre une centaine de millième de seconde pour écrire sur disque. Si tu ne fais ça que toutes les secondes, voire, toutes les 10 secondes, le temps d'écriture sera vraiment insignifiant par rapport au temps de calcul.
Si tu veux vraiment ne pas devoir bloquer le temps de l'écriture, tu place l'écriture dans un thread. Malheureusement ça nécessite d'utiliser des mutex si tu ne veux pas écrire des choses corrompues sur le disque, et les mutex sont assez lents...

Sylar44, je ne suis pas sûr que tu gagnerai du temps à écrire sur une EEPROM au lieu du disque dur.

[milouz123]

shmget() devrait faire l'affaire ;-)