Re: RE : [Tsp-devel] reverse blackboard

[eric.noulard]

>From: address@hidden on behalf of TSP
>Sent: Wed 05/10/2005 14:46
>Subject: RE : [Tsp-devel] reverse blackboard
 
>Je te fait un petit reflet de ma con-préhension pour que tu me corriges au
>cas échéant.
============================================================================
===========
>Si je comprends bien avec ton reverse BB je peux faire un cas simple du
>genre :
>- Avoir un programme à moi (genre simulateur) qui déclare/alloue ses
>variables comme il le veut ( static int
>gros_tableau_a_la_windaube[0x10000000]:=) .
>- Ensuite pour distribuer il n'a qu'à appeler à l'init de son process
>bb_reverse_publish de toutes ses variables (il se fout de l'adresse de
>retour)
>- Enfin à chaque step, il appelle bb_reverse_update avant bb_synchro.

Exactement, on peut imaginer que le bb_reverse_update fasse
aussi le bb_synchro mais c'est du détail.


>Si maintenant j'ai beaucoup de variables et je veux optimiser la recopie du
>bb_reverse_update je dois faire pareil pour l'init mais changer mon step
>- J'appel bb_reverse_return_update au cas ou il y ait eu un bb_write

En fait dans mon idée initiale avec un reverse_bb le bb_write est
inutilisable.

>- Ensuite j'appelle bb_reverse_foward_update avant bb_synchro.
>Et c'est la touille du champ asked qui ne fait la recopie de la variable que
>si quelqu'un la demandée.

Ca oui, sauf qu'il n'y a pas de champs 'asked' mais une liste
maintenue en interne par l'API (reverse)BB qui sait quels sont les symboles
demandés (en le demandant via l'API tsp provider qui va bien)

============================================================================
===========

>Cela m'a l'air super efficace comme architecture.

Merci pour ça mais faudrait essayer :))

>Le seul truc que je ne comprends pas, c'est pourquoi tu a besoin d'une
>message queue pour mettre à jour les flags asked depuis le bb_tsp_provider ?
>Il peut pas taper directement dans la structure ? Ou alors j'ai rien compris
>avant, et tu veux la message queue pour indiquer les variables qui ont été
>modifiées, et non pas demandées.

La message queue est là pour indiquer les variables DEMANDEES.
(on pourrait augmenter sa fonctionnalité aux variables bb_writées)
J'ai besoin d'une message queue car l'application qui crée/utilise
le 'reversed BB' n'est a priori pas dans le même process
que le bb_tsp_provider 
(car on peut vouloir démarrer une appli SANS bb_tsp_provider)

Hors c'est le bb_tsp_provider qui SAIT les variables qui sont
demandées.
Donc il faut un moyen de dialogue entre les 2 processes
car c'est bien le process de l'appli " FAIT l'UPDATE"
de la mémoire partagée (zone donnée du BB).

On peut rajouter un champs 'asked' à la zone de description de 
donnée du BB mais cela va à l'encontre du principe
"je publie beaucoup et je demande peu".

En gros on va payer 1 byte par variables PUBLIEE au lieu
de payer 1 int (le pgi) par variable DEMANDEE.

En gros la message queue contiendra des messages du genre
+pgi si la variable a été rajoutée à la liste des var
demandés et -pgi si la variable a été enlevé de la liste
des var demandée.

On peut aussi prendre un bout de SHM qui contienne la liste
mais il faudra gérer l'exclusion mutuelle tandis qu'avec
la MSG queue on en a pas besoin.
On aura au pire un retard d'un cycle (bb_provider) entre les
variable demandées et effectivement recopiée.

En tout les cas c'est une idée...
Sauf si quelqu'un veut s'y mettre :))