RE : [Tsp-devel] hypothèses sur TSP_w rite

[TSP]

>-----Original Message-----
>From: CHOQUET, Mathias [mailto:address@hidden 
>Sent: Tuesday, May 24, 2005 5:15 PM
>To: 'address@hidden'
>Subject: [Tsp-devel] hypothèses sur TSP_write
>
>
>Bonjours,
>Voici les hypothèses et choses à faire pour tsp-write.
>J'aimerais avoir vos avis.
>
>Merci.
>----------------------
>Hypothèses principales
>----------------------
>
>1)Le Consumer peut écrire sur n'importe quelle donnée du provider même
>celles qui n'ont pas été 
>séléctionnées. 
>
>2)Le provider peut refuser cette écriture et dans ce cas renvoyer -1 au
>consumer.
>
>3)C'est à l'utilisateur de gérer ce refus aisni que les problèmes de
>concurrences d'écritures.
>(ce changement d'hypothèses a été décidé avec Yves Dufrenne 
>Mardi 24 Mai)
>C'est à l'utilisateur 
>qui va écrire la partie GLU (GLU_init, CLU_thread...) de gérer 
>ce problème
>et non à tsp. 
>L'hypothèse est que l'écriture se fait pour une donnée du 
>simulateur, c'est
>donc au simulateur 
>de gérer lui même ce problème de concurrence.

Attention quand Mathias parle d'utilisateur, il faut comprendre le coté GLU
du provider, qui donc s'occuperait lui meme de poster l'écriture au moment
adéquat.

>4)On suppose que le provider et le consumer connaissent grâce 
>au p_g_i le
>type de la donnée envoyée.
>
>5)Pour les problèmes d'endianité, j'utiliserais la glib.
>
>5)Schéma : 
>
>                                   ___________
>    ____________        _________|             |_______
>______________
>   |           |       |            |          |       |       |
>|
>   | consumer  | rpc_req|           | Core     | GLU   |       
>|  provider
>|
>   |           |---------->| tsp_rpc    |              |       
>| req  |
>coté               |
>   |           |       |            |          |       |--------->|
>utilisateur    |
>   |           |   retour|          |          |       |       
>| (gestion
>des    |
>   |   -d-     |<----------|   -a-          |  -b-     | -c-   
>| retour  |
>mutex) revoi   |
>   |____________|      |_________|             
>|_______|<---------|  -1 si
>refus  |
>                                 |_____________|
>|___envoi______|
>
>----------------------------------------------------
>coté client (coté C et Java (à faire pour les 2!)) : 
>----------------------------------------------------
>
>1) ds tsp_rpc.x  : rajouter le prototype de la fonction int
>TSP_ASYNC_SAMPLE_WRITE(
>                       int provider_global_index, void* value, size_t
>valuesize) (-a-) 

Tu pourrais aussi creer une structure qui regroupe ces 3 parametres, sachant
en plus que le void * doit etre remplacé par opaque value<> qui contiendra
déja la valuesize. (voir code généré)


>2) ds tspConsumer.c & .h : rajouter l'appel de la fonction
>TSP_ASYNC_SAMPLE_WRITE sous 
>                          forme d'une fonction de tspConsumer (-d-).
>
>3) ds tsp_client.c & .h  : rajouter
>TSP_async_sample_write(async_write_t,TSP_server_t) et gérer
>                          les problèmes d'endianités (big et little).
>
>-----------------------
>coté serveur (coté C) : 
>-----------------------
>
>4) ds tspprovider.c et .h : rajouter la fonction 
>tsp_async_sample_write qui
>sera appelé par 
>                           TSP_ASYNC_SAMPLE_WRITE. deplus, il 
>faut proposer
>une API de 
>                           deux fonctions tsp_write_lock et
>tsp_write_unlock pour la gestion
>                           de l'exclusion_mutex.(-b-)
>
>
>5) ds glue_sserver.h : rajouter le proto de la fonction et les 
>explication
>sur les problèmes de
>                      concurrences. Ces protos sont les fonctions GLU
>implémenter dans les 
>                      providers (-c-)
>
>6) ds tsp_server.c & .h : rajouter
>TSP_async_sample_write_1_svc(async_write_t) et gérer
>                         les problèmes d'endianités (big et little).
>
>
>Mathias choquet
>

important_notice.txt
Description: Text document