Le design pattern Rendezvous

Le Rendezvous pattern (Figure 3.8) est un modèle simple qui permet la synchronisation d'un ensemble de tâches. Il permet aussi de partager des

Chapitre 3. Conception du framework

Synch Policy

Callback

Rendezvous

reset()

register()

release()

1

1

1

1

*

1

*

1

Task

notify()

1

2..*

1

2..*

Fig. 3.8  Rendezvous design pattern

données après synchronisation. L'avantage de ce design pattern est qu'il per-met de xer des politiques de synchronization ou des préconditions avant d'acceder à une ressource.

3.6.2.1 Structure

Le principe de ce pattern est que chaque tâche prête pour la synchro-nisation vient s'inscrire dans l'objet Rendezvous (gure 3.8). L'inscription entraîne un blocage de la tâche jusqu'a une notication éventuelle lui permet-tant de reprendre l'exécution. Cette approche présente une grande exibilité dans la modélisation des préconditions complexes. La structure du Rendez-vous design pattern est illustré dans la gure 3.8.

Chapitre 3. Conception du framework 3.6.2.2 Collaboration

Callback

L'objet Callback possède les adresses des tâches clientes. Il permet à l'objet Rendezvous de notier (i.e libérer) tous les tâches inscrites, une fois que la précondition est réalisée.

Task

Ce design pattern est utile pour la synchronisation d'au moins deux tâches. Lorsqu'une tâche atteint son point de synchronisation elle s'inscrit dans l'ob-jet Rendezvous en laissant son adresse.

Rendezvous

L'objet Rendezvous gère la synchronisation entre les tâches. Normalement il possède une opération (méthode) d'inscription dans son interface. Les tâches invoquent cette méthode pour signaler qu'elles sont prêtes pour la synchro-nisation.

Synch Policy

L'objet Sync Policy concrétise un ensemble de préconditions dans un concept unique. Une version simple de Sync Policy consiste à inclure un compteur des tâches inscrites. Lorsque le compteur atteint une valeur bien déterminé, il le signale à l'objet Rendezvous qui libère toutes les tâches.

3.6.2.3 Intégration au framework

Ce design pattern peut être utilisé sous deux approches selon la notica-tions des tâches :

 Notication collective.  Notication sélectionnée.

Notication collective : Dans ce cas les tâches inscrites attendent la réa-lisation de la précondition pour être notiées et libérées toutes. La politique de synchronisation dans ce cas est simple, car elle s'occupe d'une précondition concernant toutes les tâches.

Chapitre 3. Conception du framework

Notication selective : Dans ce cas les tâches inscrites sont notiées in-dividuellement. L'objet Rendezvous sélectionne les tâches à notier sui-vant la politique de synchronisation. Cette dernière s'avère plus com-pliquée dans ce cas, car elle doit tenir compte de plusieurs contraintes et préconditions.

De point de vue implémentation il y a une diérence entre les deux va-riétés de ce design pattern. Dans le cas de la notication collective, l'objet Rendezvous peut ne pas avoir une liste (Callback) des adresses de toutes les tâches inscrites. L'inscription dans ce cas peut être eectuée à travers un sémaphore initialement vide que l'objet Rendezvous possède et que les tâches voulant s'inscrire prennent. Ceci entraîne le blocage de toutes les tâches qui viennent de s'inscrire. Lorsque l'objet Rendezvous exécute la méthode relea-seAll() il libère toutes les tâches bloquées sur ce sémaphore.

L'intégration de ce design pattern dans le framework nécessite la prise en compte de ses deux variétés. La gure 3.9 présente la structure de ce design pattern dans le framework en tenant compte de ses variétés.

AbRVclass est la classe abstraite de laquelle dérivent les classes concréti-sant les deux variétés de ce design pattern.

AbRVsyncPolicy est la classe abstraite de laquelle dérive toute classe concré-tisant une politique de synchronisation.

RVsyncPolicy est la classe concrète qui dénit une politique de synchroni-sation bien déterminée.

RVclassCollect est la classe concrétisant la notication collective. Elle hé-rite les méthodes de AbRVclass ainsi que l'agrégation d'une politique de synchronisation et possède un sémaphore. Les tâches s'inscrivant dans ce type de Rendezvous dérivent de la classe Atask.

RVclassInd est comme RVclassCollect sauf qu'elle possède une liste (RVcall-back) au lieu du sémaphore. Par contre, les tâches s'inscrivant dans ce type de Rendezvous ont leurs propres sémaphores. Elles sont des instances de RVtask.

Chapitre 3. Conception du framew ork Aqueue AbRVsyncPolicy AbRVclass register() reset() RVsyncPolicy sync() Atask <<Active>> Abstract Classes RV pattern Classes Concret Classes RVcallback RVclassInd release() RVtask notify() Task Asemaphore RVclassCollect releaseAll() Fig. 3.9  Rendezv ous Pattern in tégré dans le framew ork 75

Chapitre 3. Conception du framework

RVcallback est une sorte de liste (elle dérive de Aqueue) qui sert à enregistrer des références sur les tâches inscrites dans un Rendezvous.

RVtask est une tâche qui possède son propre sémaphore utilisé par l'objet RVclassInd pour la bloquer.

Il faut noter que l'instance de RVclassInd est un objet passif et que son code s'exécute dans le thread de contrôle de la tâche appelante.

La gure 3.10 présente un diagramme de séquence illustrant un cas d'uti-lisation du Rendezvous Design Pattern. Les trois tâche : Tâche1, Tâche2 et Tâche3 s'inscrivent respectivement au Rendez-vous en appelant la méthode register() de l'objet Rendezvous. L'inscription entraîne un blocage de la tâche jusqu'à la réalisation de la condition. À chaque opération d'inscription l'ob-jet Rendezvous vérie la condition de synchronisation en exécutant la mé-thode sync() de l'objet PolSync. Une fois la condition est réalisée (dans ce cas nombre de tâches inscrites égale à trois), l'objet PolSync appelle la méthode releaseAll() de l'objet Rendezvous qui libère toutes les tâches.