• Aucun résultat trouvé

Le langage CRP  présenté en détail dans ce rapport , et la sémantique qui lui est associée,  concernant la structure de canal,les processus ou le mode de lecture et écriture des processus  dans les canaux , ont pour but de rendre les applications de traitement de signal , en particulier  de flux vidéo, plus fiables et efficaces ,et ceci de différentes manières :

   1.la degré de parallélisme  :

     Le langage CRP permet d' augmenter la degré de parallélisme de ce type d'applications         soit au niveau de compilation ou au niveau d'exécution:

au niveau de compilation :  Considérer chaque processus  comme un module  indépendant , par conséquent ,éviter de recompiler toute  l'application en cas  d'erreur localle (gain de temps de compilation)[1][5].

au niveau d'exécution: En CRP tous les processus démarrent ensemble au début  de l'application,et sont exécutés en parallèle , avec une garantie de 

synchronisation d'accéder dans les canaux (la partie essentielle de notre travail).

      Cette propriété conduit aussi a un gain de temps ,par conséquent supporter plus        en plus des applications pour systèmes embarqués et en temps réel.

Le mode de lecture et écriture  supporté en CRP (une écriture et plusieurs lectures),permet  aussi d'augmenter la degré de parallélisme,( contrairement au KPN par exemple qui supporte  seulement une seule écriture et une seule lecture) , parce que la propriété de plusieurs lectures  permet  a plusieurs processus de lire la même donnée (qui écrit une fois).

Ce mode de lecture/écriture permet aussi d'écrire de nouvelles applications de flux vidéo   qui  ne peuvent  être  supportes par d'autres langages qui  exigent d'autres sémantiques . l'une de ces applications ,par exemple , celle qui consiste à faire plusieurs copies de même  image ,dans ce cas on peut lancer le même processus de copiage plusieurs fois, avec des  paramètres différents .

 Une autre application qui consiste à faire une copie d'une image et de changer l'échelle  comme c'est présenté dans la figure suivante :

          

   

      figure9:schéma de copiage et changement de  l'échelle d'une image

  2.La syntaxe de langage : Le langage CRP a la même syntaxe du langage C (comme             présenté précédemment), cela permet d'utiliser différentes primitives fournies par le           langage C et surtout des primitives de manipulation sur les signaux (tel  que sigalarm..) .           par conséquent il permet d'écrire  d'autres applications de traitement de signal.

 3.Consommation de mémoire : En CRP on utilise des canaux de taille bornée, et à l'aide         de réinitialisation des cases de canal , on peut  diminuer la consommation de mémoire,         mais cette solution pose un autre  problème qui sera présenté par la suite.

 Le langage CRP  rend un certain nombre d'applications de traitement de signal plus  fiables,mais il reste  d'autres problèmes qui n'ont pas été encore résolus ,ou  des nouveaux  problèmes sont  rencontrés avec  d'autres applications , nous citrons,dans ce qui va suivre,  quelques problèmes ,dont certains sont en cours d'études:

La taille de canal et la réinitialisation des cases: 

Le problème majeur présenté dans CRP est le choix de la taille de canal.

dans notre simulation nous avons fixé la taille de canal par une constante  , la valeur de  cette constante est choisie aléatoirement  sans  aucune méthode ou algorithme ou tout  autre critère .

       Le problème  principal  dans le choix de  cette valeur  est que , d'un coté,  

       l'environnement de travail (système embarqué) exige une utilisation très limite de la           mémoire, et d'un autre coté , certains type d'applications supportent  l'utilisation de la         mémoire pour augmenter la degré de parallélisme .

       Pour résoudre le problème de taille de canal, on doit chercher à trouver une solution,qui         permet de réutiliser le même espace mémoire de canal,parce que il faut limiter la taille         de canal (a cause de limite  matérielle).

       paul en [1], présent  une méthode ,qui  consiste à  réinitialiser une case de           canal après chaque utilisation afin de réutiliser cet espace . Cette réinitialisation         dépend d'un critère de durée de vie de donnée .

source | | | | | | 

copier

changer l'échelle

       durée  de vie de  donnée: C' est le temps entre l'écriture de donnée dans la case et sa           dernière utilisation par des processus[1][5].

       par conséquent la réinitialisation des cases de canal permet  de réutiliser ces cases         plusieurs fois.

       Cette solution pose un autre problème , c'est comment calculer la durée de vie de         donnée?

      En  StreamIt par exemple ,la méthode INIT, dans la classe filtre , permet de positionner       le  nombre des données produites et consommées  dans le canal au démarrage .

      Dans notre simulation l'opération de réinitialisation  des cases d'un canal est basée sur le         nombre  des processus qui lisent dans ce canal, ce nombre est calculé au  début de          lancement des processus.

Un autre problème  peut être  posé dans le même sujet , c'est quand la durée de vie d'une  donnée dans une case est  longue (le temps de garder une donnée dans une case est prolongé). 

Ce cas peut être présenté avec des applications qui supportent beaucoup de parallélisme, en  particulier, quand on a plusieurs  processus de lecture  dans un canal,alors il faut garder le  contenu de chaque case, jusqu'à  la dernière lecture,qui conduit à un cas où le processus  qui  écrit dans le canal se bloque parce que il n'y a aucune case vide pour écrire des données,   et  l'opération de réinitialisation  attend le délai pour vider une case (voir la figure10).

             

        lecture       écriture       lecture       lecture         lecture               après n cycle 

       d'exécution

lecture       écriture bloquer

      lecture       (attente l'opération de lecture)        

       figure10: le problème de ré initialisation de cases

Une solution peut être présenté pour ce problème qui consiste à  limiter le nombre de 

processus de lecture dans un canal donné, mais cette solution permet de diminuer la degré de  parallélisme.

problème techniques:  L'un des problèmes techniques que nous n'avons pas résolus  est le choix de l'ordre de l'instruction de réinitialisation dans le code d'un  processus . dans notre simulation on lance l'opération de réinitialisation à la fin de processus.

D'autres limites qui peuvent être présentés aussi en CRP :

certaines applications ne supportent pas la sémantique de CRP[1] .

le projet de  SYNTOL  est en cours de développement.

plusieurs recherches et études concernent le calcul d'ordonnancement en  CRP[5].

|  |  |   |   |   |   |   |   |   |   | |  |  |   |   |   |   |   |   |   |   |

IIX.CONCLUSION

Ce stage montre que plusieurs applications de traitement de signal , en particulier de flux  vidéo sont possibles à écrire avec le langage CRP qui est le coeur de nos études, parce que ce  langage fournit une sémantique et un modèle de communication , qui ne peuvent pas être  trouvés  avec d'autre langages qui utilisent par exemple le modèle de communication KPN.

L'écriture des applications en CRP permet de vérifier de plus en plus les contraintes de  l'environnement de travail (systèmes embarqués).

 La sémantique de CRP permet d'augmenter la degré de parallélisme,par conséquent un gain  de temps (un temps réel)  exigé pour les  systèmes embarqués .il permet aussi de diminuer la  consommation de mémoire .pour satisfaire  cette condition   une sémantique et des approches  destinées à cet égard et  qui consistent  par exemple  à  réutiliser le même espace mémoire  plusieurs fois. plusieurs recherche  et travaux,concernant ce point, sont en cours .le but  c'est  d'améliorer  ou  de trouver d'autres méthodes plus efficaces . 

D'une autre part, le travail que nous avons réalisé durant ce stage : 

le compilateur qui permet de compiler une application écrite en CRP, et produire un  code correspondant  dans un langage  de plus haut niveau (langage C++). 

la bibliothèque qui elle fournit des primitives  garantissant  une synchronisation entre  les processus de l' application pour accéder  à un espace mémoire partagé entre eux  (un canal).

Ce travail permet de supporter de plus en plus d'autres applications de traitement de signal. 

par conséquent enrichir la base d'exemples de projet de syntol qui est en cours de  développement par l'équipe compsys .

En ce qui concerne l'expérience réalisée pendant le stage, il faut noter l'importance du travail  dans un environnement de systèmes embarqués ,et avec des applications qui supportent des  modèles de communication comme celui   présenté en CRP.

D'autres expériences notées  concernant des principes et des outils de compilation tel que le  langage ocaml et le c++.

Annexe:

le code en CRP et en C++ réalisé par notre compilateur de l'application de MPEG qui est  présenté dans ce rapport, est ecrit comme suit:

Documents relatifs