Discussion :

[Invité]

Bonjour,

Edit ::= Après breve analyse, le problème se précise.
Je cherche à limiter la file d'attente d'une entrée de tache dans le temps.


Message original ::=

Un ensemble de client passent leur travail au gestionnaire de l'usine qui les mets au fur et à mesure dans un tampon. Une fois que tout les clients ont soumit leur travail, le gestionnaire de l'usine soumet l'ensemble des travaux contenu dans le tampon à la machine.

Comment implémenter ce modèle en faisant attendre les clients jusqu'à ce que leur travail fait leur soit retourné ?

[PRomu@ld]

Ca ressemble fortement à une variante du producteur-consommateur :

http://www.ada-france.org/IMG/pdf/c_bellissant.pdf

[Invité]

Yep, bonjour,

Merci PRomu@ld.

Je n'ai jamais utilisé ce mécanisme, ni même étudié sérieusement, mais il est certain que j'était mal parti pour faire mon boulot.

A propos des producteur/consommateurs, il n'y a pas des problèmes persistants malgré les mécanismes mis en œuvre dans ce modèle ?

[Invité]

Yep

Petite question en extra...

Les entrées dans un select sont elle acceptées dans l'ordre ou elles apparaissent dans le select ?

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
16
17
18
19
20
21
22
23
 
select
   accept Logout do
      ....
   end Logout;
or
   accept Login do
      ....
   end Login;
or
   accept Take() do
      ....
   end Take
or
   accept Submit() do
      ....
   end Submit;
or
   delay 0.05;
   if travail_a_faire then
      faire_les_jobs;
   end if;
end select;

Vais-je accepter tous les logout avant les login ?

Extra extra ... Que pensez vous d'une tache telle que celle ci ?

Le mécanisme dont je souhaite profiter est la mise en queue des entrées. En effet, je souhaite accumuler tous les travaux en entrée de Submit pour traiter ainsi toute la file d'attente d'un coup.

Merci !

[boromir73]

L'ordre d'exécution des alternatives d'un select est essentiellement arbitraire bien que certains types d'alternatives puissent être exécutés avant les autres (cf ARM 9.7.1 (14, 15)).

Je ne suis pas sûr de bien comprendre "accumuler tous les travaux en entrée de Submit", mais tu pourrais par exemple empiler (ou enfiler) les traitements lors de chaque Submit et exécuter la pile (ou la file) lors du dernier Logout.

Alternativement, si chaque client possède 2 tâches (une appelant Logout et l'autre Submit), alors tu peux mettre une garde à Submit (du genre "when Nb_Connectes = 0").

[Invité]

Yep,

Merci boromir73

L'ordre d'exécution des alternatives d'un select est essentiellement arbitraire bien que certains types d'alternatives puissent être exécutés avant les autres (cf ARM 9.7.1 (14, 15)).

Merci pour cette précision.

Je ne suis pas sûr de bien comprendre "accumuler tous les travaux en entrée de Submit", mais tu pourrais par exemple empiler (ou enfiler) les traitements lors de chaque Submit et exécuter la pile (ou la file) lors du dernier Logout.

Par "accumuler tous les travaux en entrée de Submit" j'entend simplement traiter toute la queue de l'entrée d'un coup.

Mon problème est de limiter cette queue dans le temps.

Alternativement, si chaque client possède 2 tâches (une appelant Logout et l'autre Submit), alors tu peux mettre une garde à Submit (du genre "when Nb_Connectes = 0").

Je cherche !

mon projet est la Na'hash_Ada_Project-0.0.0e.tgz , les problèmes que j'évoque ici sont ceux relatif au paquetage nahash-nahash dans nahash-server, qui doit donner les travaux à un module Ia qui n'est pas encore développé. C'est loin d'être finalisé tout de même.

[Invité]

Donc, je cherche à présent comment limiter la file d'attente d'une entrée de tache dans le temps.

Si j'écris ::

Code :

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

1
2
3
 
when date_courante < echéance =>
accept ....

Est-ce que ça vous dérange ?


Et, pourais-je en alternative écrire

Code :

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

1
2
3
4
5
 
....
or
   delay until echéance;
...

?

Merci !