Discussion :

[contremaitre]

Bonjour

Soit n objets de type X qui peuvent etre dans l'état 0 ou 1
Si on passe Xn de l'état 0 à 1 on sait qu'il faudra faire une action sur Xn au bout d'un temps t, qui peut être modifié (alongé) par un evenement extérieur.

L'idéal serait d'avoir un timer pour chaque objet, qui viendrait réveiller ma tache dès qu'un des objets atteint son temps limite.
Ce timer pourrait etre modifié en cas d'évenement exterieur.

Pour l'instant je bloque sur un select pour pouvoir recevoir des messages qui sont mes evenement exterieur.

Comment implémenter ce timer, pour qu'il vienne me réveiller et me dire que tel objet a besoin de faire une action ?

merci

[Obsidian]

Comment implémenter ce timer, pour qu'il vienne me réveiller et me dire que tel objet a besoin de faire une action ?

Ça dépend énormément de l'environnement que tu utilises. Si tu es sous Windows et que tu utilises des contrôles de haut niveau, il existe des objets Timers qui servent à çà (il y en avait en VB, en tous cas) mais il ne faudrait pas que n soit trop élevé.

Sinon tu fais un truc du style ticks, avec une interruption à intervalle fixe (ça peut être à chaque tour d'un boucle principale, par exemple) et tu décrémentes une valeur dans chacun des objets enregistrés, ou enfin (le plus propre, à mon avis) : tous tes objets s'enregistrent auprès d'uen seule entité qui tient à jour une pile des objets enregistrés chacun associé une à une date d'échéance, triée, et tu places une seule alarme sur le premier objet à échoir. À chaque signal reçu, timer ou intervention externe, tu mets à jour ta pile et tu réinitialises le réveil.

[yan]

regarde peut être les signal/slot de Boost et Qt.
Ça pourrais correspondre

[nicroman]

L'idée est probablement d'avoir un vecteur de tes objets, trié par ordre d'execution (celui qui doit s'executer le plus tôt d'abord).

La fonction "set" va aller dire au manager (qui maintient le vecteur) de retrier l'objet... si il est dans le vecteur... on le déplace à la bonne position, si il n'est pas dans le vecteur on l'y rajoute.
Si l'objet était ou devient le premier de la liste, on raise un event "MODIFIED".

La fonction "reset" va aller dire au manager de retirer l'objet du vecteur. Si il y était, on raise un event "MODIFIED".

Le manager a un thread qui fait un truc genre (pseudocode):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
while (!manager_ended) {
    long waitTime = -1;
    if (vector_of_objects is not empty)
       waitTime = vector_of_objects[0].nextExecutionTime() - now();
    if (waitTime <= 0) {
       // retirer object 0 from vector_of_objects
       // executer ....
    } else {
       WaitEvent(MODIFIED,waitTime);
    }
}

[Obsidian]

L'idée est probablement d'avoir un vecteur de tes objets, trié par ordre d'execution (celui qui doit s'executer le plus tôt d'abord).

J'ai envie de dire que, d'une part, c'est en substance ce qui est écrit au post #2 et que, d'autre part, une liste chaînée toute bête serait plus indiquée qu'un gros vecteur pour faire une queue de tâches, à mon avis.

[contremaitre]

Merci pour vos idées.

Déjà je suis sous linux.

J'avais pensé à ce système de vecteur, mais j'avais peur que ça bouffe beacoup de ressources CPU de devoir trier sans arret cette liste.

Il faut que je fasse une estimation de la complexité de cette solution pour voir si c'est réalisable.
Je vais également regarder du coté de boost, QT étant un peu trop "gros" pour ce dont j'ai besoin.

[contremaitre]

Je n'ai pas trouvé de quoi faire ce que je veux avec les signal de boost. Je ne vois pas comment réveiller une tache d'après la doc que j'ai lu.

Je pense donc partir sur les std::list pour garder en mémoire les prochaines actions à effectuer.

Donc pour garder la liste triée, l'idée serait, lors de l'ajout d'un élément, de parcourir la liste jusqu'a trouver sa place et de faire un insert.
Et lors de la mise à jour d'un élément, de parcourir la liste pour le trouver, puis faire un erase, puis un insert à son nouvel emplacement.

Ce qui me parait le plus gourmand est la mise à jour d'un élément, car pour le trouver, comme il peut être n'importe ou dans la liste c'est assez couteux ( O(n) ) de le chercher.

[Kujara]

Récente addition a cette merveille qu'est Boost, Asio est ton nouvel ami:

http://www.boost.org/doc/libs/1_36_0...tuttimer2.html

[Obsidian]

J'avais pensé à ce système de vecteur, mais j'avais peur que ça bouffe beacoup de ressources CPU de devoir trier sans arret cette liste.

N'utilise pas un vecteur, fais une liste chaînée, c'est à ça que ça sert. C'est nettement plus rapide d'y déplacer un objet et ton timer ne lira que la première entrée à chaque fois. Au pire, si vraiment tous tes objets changent de place en permanence, tu fais une deque et chaque objet garde une référence vers son propre emplacement dans la liste. C'est le moins coûteux.

Si tu es sous Linux et que tu ne veux pas utilisers les timers d'une bibliothèque toute faite, tu regardes du côté de SIGALRM.

C'est pour faire quoi, tout çà, au final ?

[contremaitre]

Récente addition a cette merveille qu'est Boost, Asio est ton nouvel ami:

http://www.boost.org/doc/libs/1_36_0...tuttimer2.html

merci je regarde ça.

Si tu es sous Linux et que tu ne veux pas utilisers les timers d'une bibliothèque toute faite, tu regardes du côté de SIGALRM.

D'après ce que j'ai lu, on ne peut lancer qu'un SIGALRM à la fois, donc ça ne marche pas sur plusieurs objet.

Sinon c'est pour lancer des enregistrements pour une certaine durée, et pouvoir les areter au bout de cette durée.

[Obsidian]

D'après ce que j'ai lu, on ne peut lancer qu'un SIGALRM à la fois, donc ça ne marche pas sur plusieurs objet.

C'est ce que je t'explique dans mes précédents posts. Si tu tries tes objets dans une deque, tu colles un SIGALRM sur la tête de ta liste et chaque fois qu'il arrive à échéance, tu éjectes l'objet et tu réinitialises un nouveau SIGALRM sur le suivant. C'est ce qui coûte le moins cher.

Si tu devais toi-même programmer la bibliothèque de timers, tu t'y prendrais comment ?

[contremaitre]

Ha oui, je croyais que tu disais de faire un SIGALRM par objet.
Mais sinon j'avais une autre idée, c'est de calculer le temps avant le prochain réveil nécessaire pour le premier objet de la liste.
Et faire un select avec un timeout de ce temps, car j'ai deja un select mis en place pour recevoir des messages.

[Obsidian]

Mais sinon j'avais une autre idée, c'est de calculer le temps avant le prochain réveil nécessaire pour le premier objet de la liste.

C'est une solution qui a le mérite de ne pas faire explicitement appel au signal et qui sera donc peut-être plus portable, par contre, je ne sais pas dans quelle mesure la valeur du timeout est garantie ...

Sache de toutes façons qu'un signal casse le select() de toutes façon, tout comme les sleep(). De toutes façons, il me semble bien que le timeout d'un select() est réalisé en se servant de SIGALRM également, mais je n'arrive plus à retrouver la référence.