Objets concurrents, répartis et mobiles · Objets concurrents, répartis et mobiles --- Denis...

Objets concurrents, répartis et mobiles --- Denis Caromel --- 1

Objets concurrents, répartis etmobiles

Denis Caromel

Université de Nice Sophia Antipolis

INRIA Sophia Antipolis

Projet OASIS

EJCP’2003

ECOLE

JEUNES CHERCHEURS EN

PROGRAMMATION

AUSSOIS, CENTRE PAUL LANGEVIN

Lundi 2 juin 2003

www.inria.fr/oasis/Denis.Caromel/

[email protected]

Version Mai 2003


PréambulePlan sommaire du cours:

- Introduction - Cadre - Objectifs:• Présentation du modèle asynchrone (par rapport a

l’hypothèse synchrone).• Langages de haut niveau d'abstraction permettant à

l'utilisateur de s'abstraire du placement, des communi-cations, etc.

• Objectifs: facilité et puissance d'expression, réutilisa-tion, ...

• Quelques concepts de bases.

- Langages à objets parallèles:• Principes, utilisation de l’héritage et du polymor-

phisme.

• Réutilisation et transformation de code séquentiel.

• Abstractions pour la programmation du contrôle desprocessus (expressions de chemins, compteurs de syn-chronisation, conditions d'activation, ensembles d'acti-vation, ...)

• Exemples de langages (langages d'Acteurs, Eiffel//,extensions de C++, Java, etc.).

• Mobilité

• Jini


Table des Matières

CHAPITRE 1 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

1.1 Cadre et généralités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71.1.2 Modèle Asynchrone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.1.3 Types d'applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.1.4 Contrôle et Données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.1.5 Architectures de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

1.2 Propriétés souhaitables des langages/modèles . . . . . . . . . . . . . . . . . . . . . . . .211.2.1 Indépendant de l'architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211.2.2 Abstrait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221.2.3 Granularité variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

1.3 Différents types de langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241.3.1 Shared-memory paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241.3.2 Mémoire distribuée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251.3.3 Impératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251.3.4 Parallel OO Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261.3.5 Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261.3.6 Logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271.3.7 Autres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

CHAPITRE 2 Techniques de base (Systèmes d’Exploitations) . . . . . . . . .28

2.1 Moniteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292.1.1 Définitions: procédures, conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . .292.1.2 Exemple: tampon à N places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312.1.3 Moniteurs Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

CHAPITRE 3 Langages de plus ‘‘haut niveau’’: Concepts de base . . . . . .41

3.1 Dimensions fondamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.1.1 Exécutions parallèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.1.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433.1.3 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

3.2 Autres dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463.2.1 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463.2.2 Partage ou non . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473.2.3 Passage des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473.2.4 Services et Points d'Entrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

a ) Modélisation des routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48


b ) Modélisation des requêtes et de leur service . . . . . . . . . . . . . . . . . . 48c ) File d'attente des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.5 Programmation de l'activité des processus . . . . . . . . . . . . . . . . . . . . . . 49a ) Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49b ) Services des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2.6 Continuations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.7 Terminaison des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

CHAPITRE 4 Programmation à Objets: Modèles et Principes de base. . . 54

4.1 Programmation à objet séquentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.1 Héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.2 Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.3 Liaison dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.4 Système séquentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2 Objets actifs et Parallélisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.1 Parallélisme orthogonal aux objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 Parallélisme par objet actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Dimensions fondamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.1 Exécutions parallèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.2 Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.3 Objets partagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.4 Synchronisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.5 Continuations Automatiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.4.1 Polymorphisme objet - processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.4.2 Arbre Binaire de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

a ) Version séquentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70b ) Version parallèle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.5 Précisions sur la sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5.1 Attente-par-nécessité et affectation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5.2 Stratégies de Continuation Automatiques. . . . . . . . . . . . . . . . . . . . . . . 774.5.3 Caractéristiques du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

CHAPITRE 5 Programmation des Processus. . . . . . . . . . . . . . . . . . . . . . . 81

5.1 Programmation du contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.1.1 Analyse d'exemples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

a ) Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82b ) Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83c ) Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.1.2 Choix: Contrôle explicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.1.3 Exemple: Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.1.4 Service des routines: exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

a ) Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87b ) Concurrent C (N. Gehani) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.1.5 Choix: bibliothèque de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


5.1.6 Exemple: Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.1.7 Exemple: Reader-Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

a ) Lecteurs-Rédacteurs en Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93b ) Lecteurs-Rédacteurs en ProActive . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.1.8 Contrôle implicite: Abtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.1.9 Example: Buffer déclaratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.1.10 Réutilisation de synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.1.11 Programmation d'une abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2 Une méthode de parallélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.1 Conception et programmation séquentielle . . . . . . . . . . . . . . . . . . . . 101

a ) Sequential design and programming: . . . . . . . . . . . . . . . . . . . . . . 1015.2.2 Parallélisation -- Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

a ) Process identification:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101b ) Process programming: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101c ) Adaptation to constraints: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.3 Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.3.1 Modèle de placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.4 Résumé du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

CHAPITRE 6 Réflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.2 Reification points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.3 Adaptation: utilisation de la réification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

CHAPITRE 7 Java, Migration, MOP, Méta-Objets et Outils. . . . . . . . . . 110

7.1 Modèle de base en Java: ProActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.2 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.3 MOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.4 Méta-Objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.5 Application et Outil: IC2D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Objets concurrents, répartis et mobiles -- 2003 -- Denis Caromel --- 6

CHAPITRE 1 INTRODUCTION

Cadre et généralités

Objets concurrents, répartis et mobiles -- 2003 -- Denis Caromel -- 7

1.1 Cadre et généralités

1.1.1 Définitions

Concurrence:Accès, ou tentative d’accès, simultané à uneressource physique ou logique

Exemples:

zone ou mot mémoire, cache, secteur disque, écran,imprimante, etc.

Parallélisme:Exécution, ou réalisation simultanée de plu-sieurs activités, ou processus

Exemples:

2 multiplications en même temps sur 2 processeursdifférents, ou par 2 parties distinctes d’un proces-seur. Impression d’un fichier sur 2 imprimantes enmême temps, stockage sur plusieurs disques(RAID: Redundant Arrays of Inexpensive Disks)

Distribution (en fait Répartition):Plusieurs espaces d’adressage,

Exemples:

2 PCs LAN, cluster de PC, machines en WAN,



1.1.2 Modèle Asynchrone

Cadre distribué:

Langages Asynchrone:

Pas d'horloge globale

''Loosely coupled'':processus faiblements couplés,chacun progresse à son propre rythme

Communication: aucune hypothèsetemps (durée) de communication nondéfini, non borné, ‘ priori non nul

--> • Pas d'ordre total sur les événements d'unsystème (ordre partiel uniquement)

Exemples:CSP, Occam, Ada, Modula 3,

Electre, etc.

Acteurs: Actors, ABCL/x, ProActive, C++//,etc.

Types d'applications:Applications distribuées, parallèles, etc.

Par opposition:



Hypothèse synchrone (langages synchrones):Un programme réagit ''instantanément'' àses input, en un temps considéré nul.

Communication: ''Instantanée''temps (durée) de communication nul(borné par un temps que l'on peut consi-déré nul).''Instantaneous broadcasting'': un proces-sus reçoit un message (un événement) à ladate où il est envoyé.

Réaction “dans le même instant’’, y com-pris à l’absence d’événement.

''Tightly coupled'':processus fortement couplés.

Calculs dirigés par les événements (inputdrivens).

Horloge globale

--> • Ordre total sur les événements d'un sys-tème, simultanéité

Exemples:Esterel, Lustre, Signal, StateCharts,

Types d'applications:Applications Réactives, Déterministes



Ne pas confondre:Modèle Synchrone / Asynchrone

etCommunication Synchrone / Asynchrone

Dans le modèle asynchrone, on trouve des langagesà communication:

synchrone

ouasynchrone

Un des challenges:

- Faire des modèles asynchrones déterministes

- Distribuer des modèles synchrones



1.1.3 Types d'applications

La programmation parallèle pourquoi faire?

Parallélisme de situation:Le domaine à modéliser est intrinsèque-ment parallèle (Concurrence)

(Problem Domain parallelism)

Parallélisme de résolution:Le parallélisme est un choix de concep-tion (Parallélisme).

(Solution Domain parallelism)

Visant souvent à augmenter les performances

Eventuellement, la taille des problèmes (don-nées) que l'on peut traiter

Parfois la fiabilité

Situation:Systèmes d'Exploitation (OS): la 1ère appli!!

synchronisation de processus concurrents,mémoire partagée, communication, inter-blocage, correction, etc.

Applications distribuées



Systèmes Coopératifs, CollectielsCSCW (Computer-Supported CooperativeWork),Tableau blanc (whiteboard or blackboard)

Systèmes réactifs

Système de commandes de procédés indus-triels

Client/Serveur

Transactionnels (BD: Banques, Réservations,etc.)

RésolutionApplications numériques (surtout)

CFD (Computational Fluid Dynamics):Simulation of Any complex gas or liquidflow within engine, wings, etc.

N-body Methods (particle, molecules ...)

Image synthésis (Ray tracing, etc.)

Simulation (à événements discrets vs.numériques)

Data mining, etc.

Toutes les applications qui peuvent poser unproblème de temps d'exécution, taille, ou fiabi-lité.



1.1.4 Contrôle et Données

Modèles de base:Basés sur la structure des programmes

Contrôle:Mécanisme d'exécution des instructions

Données:Mécanisme d'acheminement des données

Parallélisme de Contrôle: control-drivenLe programme décrit explicitement le parallé-lisme (création, terminaison, communication,synchronisation)

Parallélisme de données: data-drivenLe parallélisme est structuré sur / par les don-nées. (Implicite)

Parallélisme de réduction: demand-drivenLangages fonctionnels, à affectation unique.

Une instruction est sélectionnée et exécutéelorsque ses opérandes sont prêtes (calculées).

Data Flow.



1.1.5 Architectures de base

Basée sur la structure des machines, et les notionsde flots de données, et de flots d'instruction (Flynn,72)

Flot:Séquence d'éléments traités par un processeur

SISD: Single Instruction, Single DataMachine séquentielle classique,

Von Neumann, (schéma classique)

FIGURE 1 Machine séquentielle classique

UC

MC

P1CodeTasPile

M1



SIMD: Single Instruction, Multiple DataType MMX (graphisme)

Vector-Array Processing:Plusieurs éléments de calcul (processeur +mémoire) exécutant la même instruction surdes données différentes,

Supercalculateurs Vectoriels

MISD: Multiple Instructions, Single DataPipeline: chaque processeur exécute une ins-truction spécifique sur des données circulant(chaîne de montage).

MIMD: Multiple Instructions, Multiple DataPlusieurs éléments de calcul, des données dif-férentes.

Systèmes / Architectures distribués (répartis)

+ Multiprocesseur



Raffinement: Couplage

Couplage entre éléments de calcul / mémoire(s):

Couplage fort:Vectoriel (SIMD)

Couplage moindre:MIMD à mémoire partagée

Couplage faible:MIMD sans mémoire partagée(mémoire distribuée)

En général:--> • Multiprocesseurs: mémoire partagée

SMP:Symetric Multi-processing, ouShared Memory Parallelism

--> • Architecture répartie: mémoire distribuéeMPP:

Massively Paralel Processing, ouMessage Passing Parallelism

faiblement couplée, multimachines,‘‘clus-ters’’

Mais change un peu, maintenant:souvent cluster de SMP



Architectures dites ‘‘à mémoire partagée’’:

En réalité, plusieurs types existent:

UMA: Uniform Memory Access

Accès à la mémoire(s) via un bus avec tempsd’accès uniforme

FIGURE 2 UMA: Uniform Memory Access

UC

MC

CodeTasPile

UC

MC

CodeTasPile

UC

MC

CodeTasPile

UC

M

CodeTasPile



NUMA: Non Uniform Memory Access, ou

DSMA: Distributed Shared MemoryMémoire souvent répartie par UC, avectemps d’accès différent selon la zonemémoire accédée et le processeur qui faitl’accès

Le mapping devient alors très important.

FIGURE 3 UMA: Uniform Memory Access

UC

CodeTasPile

UC

CodeTasPile

UC

CodeTasPile

UC

CodeTasPile



COMA: Cache Only Memory ArchitectureArchitecture classique, mais chaque pro-cesseur n’utilise sa propre mémoire quecomme un cache, + mémoire globale

Répartition dynamique des données sur le système(Hard + Soft, automatic data migration and replica-tion capabilities of cache, page)

Proche de:

Distributed Virtual Shared Memory (DVSM)systems

Dans ce cas, on est encore “plus NUMA’’ que leNUMA d’origine rachitecture.



Extensions de la classification:

à la limite:Modèle de programmation / Architecture:

qui se présente comme la classification architecture

SPMD: Single Program Multiple DataMême programme qui s’exécute sur chaqueprocesseur.

De type SIMD, data parallelism, mais syn-chronisation faible.

BSP: Bulk Synchronous Parallel ComputerDe type SPMD

Barrier Synchronizations

Supersteps

two-level memory model

(+ ou - idem SPMD, mais ‘‘marketing’’),

Propriétés souhaitables des langages/modèles


1.2 Propriétés souhaitables deslangages/modèles

Une bonne abstraction des primitives de bases desarchitectures

• trop concret, bas niveau: obsolète rapidement

• trop haut niveau: performances difficiles à obte-nir

Nécessité de compromis, en particulier par rapportà un certain nombre de propriétés.

1.2.1 Indépendant de l'architecture

Exécuter le programme sur des architectures diffé-rentes (SMP, MPP, ou cluster de SMP):

sans modifier le source

Le modèle, théoriquement, doit s'abstraire de toutesles caractéristiques spécifiques à certainesarchitectures.



1.2.2 Abstrait

Cacher certains aspects du parallélisme:• Décomposition en activités parallèles (threads),

surtout pour le Parallélisme (op. concurrence)

e.g. 1000 processeurs, l'état du programmedépend de l'état des 1000 processeurs

Impossible de l'appréhender

• Communication

Actions d'envoi et de réception doivent êtrecachées

Il existe différents niveaux:

--> •ports, socket--> •RPC en C--> •CORBA, RMI, DCOM--> •ProActive (asynchrone)--> •

• Synchronisation

Soit complètement cachée, soit gérée automa-tiquement d'une façon implicite

Par exemple: data-driven



1.2.3 Granularité variable

Ne pas avoir de granularité prédéfinie de l'unitéélémentaire de travail confié à une activité(processeur)

Une application:- 2 à 20 : coarse-grain (gros grain)

- 20 à 200 : medium

- > 200 : fine-grain (grain fin)

La difficulté:Faire du grain fin efficace !

Différents types de langages


1.3 Différents types de langages

Langages ou paradigmes, ou API

Classification au niveau langage, et non pasarchitecture.

1.3.1 Shared-memory paradigm

Mémoire globale, à accès uniforme et transparent

Correspond au SMP. (e.g. OpenMP)

Le programme est responsable de la cohérence desaccès multiples et simultanés à la même adressemémoire.

Quelquefois, on utilise des techniques de type OS(sections critiques, etc.). Voir plus loin.

Modèle PRAM (Parallel Random Access Machine)pour les calculs de complexité des algos parallèles.

Approche particulière: Tuple Space

Coordination Languages (e.g. Linda)

Tuple space = shared associative memory

Les ‘‘threads’’ mettent et prennent dans cet espace(communication + synchronisation).



1.3.2 Mémoire distribuée

Distributed-memory

Processus qui coopèrent par échange de messages

Reflète l’architecture MPP, MIMD à mémoiredistribuée. Processus communicants et coopérants(e.g. PVM, MPI, etc.)

1.3.3 Impératif

En général à mémoire distribuée, plutôt un casparticulier de ci-dessus.

Notion de processus, composé d’une listed’instructions, en général séquentielles.

Points clés:--> • Création des processus:

--> •Statique (CSP)--> •Dynamique (ADA, objets, etc.)

--> • Coopération / Synchronisation:--> •Envoi de messages--> •Rendez-vous--> •Remote Procedure Call--> •Synchros pures, Terminaisons--> •Déterminisme/Non-Déterminisme

etc.



1.3.4 Parallel OO Programming

Notions de classes et d’objets pour la programma-tion parallèle.

Points clés:--> • Utilisation de l’Héritage,--> • Liaison dynamique,--> • Envoi de messages

Voir plus loin.

1.3.5 Fonctionnel

Parallélisme en majorité implicite :E.g. évaluation en parallèle des argumentsd’une fonction

Points clés:--> • Normal-order of fct. evaluation + control

(Multilisp)or Eager

--> • Possibilité d’analyses statiques (e.g. stric-tness analysis)

--> • Fonctions de premier ou de second ordre(ou ordre N: e.g. Haskell)

--> • Dataflow



--> • Compromis entre parallélismeimplicite et explicite

1.3.6 Logique

Evaluation en parallèle de clauses de Horn:H <--- B1, B2, . . . Bn

Points clés:--> • OR parallelism:

plusieurs clauses qui toutes s’unifient avecun but donné

--> • AND parallelism:plusieurs sous-buts

--> • Compromis entre parallélismeimplicite et explicite (annotations)

Voir plus loin.

1.3.7 Autres

Tout ce que l’on n’arrive pas à classer dans cescatégories, paradigmes mixtes, plus formel, etc.



CHAPITRE 2 Techniques de base

(Systèmes d’Exploitations)

Mémoire partagée

Origines:Développement des Systèmes d'Exploitationmulti-utilisateurs et temps-partagé

Techniques de base à connaître, mais égalementune perspective et un exemple d’ évolution de larecherche.

Moniteurs


2.1 Moniteurs

Evolution des Régions Critiques:

les moniteurs [Hoare 74]

Plus de variables partagées (même protégée).

Partage: objet plus abstraitType Abstrait de Données, (ADT)

Procédures pour manipuler l’objet partagé.

2.1.1 Définitions: procédures, conditions

Composantes d’un moniteur:

Ensemble de procédures publiques,

Procédures privées, données privées,Code pour Initialisations,Evt. . paramètres de création

Conditions:variables de type particulier: permettent lasynchronisation:deux opérations prédéfinies:Wait et Signal

Sémantique:• Toutes les procédures s’exécutent en

exclusion mutuelle

Moniteurs


• En fin d’opération (sortie du moniteur)on recherche et active un processus enattente (entrée, ou Signal)

cond.Signal;• reprise du processus (thread) en attente

(évt. le plus ancien) sur la conditioncond.

• le processus en cours est suspendu

cond.Wait ;• Suspend le processus en cours.

Exemple de moniteur:moniteur m debut

foo1 () ... c2.Signal; ...foo2 ( ... ) ... c1.Wait; ...

private:bar1 () ...bar2 (...) ...

conditions:c1, c2, ...

Init... initialisation des variables etc.

finUtilisation:

m.foo1(); m.foo2(); ....

Moniteurs


2.1.2 Exemple: tampon à N places

moniteur tampon_borné debut

Anytype t [0, N-1]; // Tamponconditions: vide, plein;

ajouter ( x )if [plein] then plein.Wait end;... mettre dans tampon ...vide.Signal;

enlever ( x )if [vide] then vide.Wait end;... prendre dans tampon ...plein.Signal;

Init[Mettre à vide ]

fin

Moniteurs


Conclusions sur les moniteurs:

Bas niveau :• Sémantique de Signal assez difficile à

saisir, de plus des variations existent.

• Signal est quelquefois utilisé à des finsd’optimisation.

• Les programmes réalisés avec des moni-teurs deviennent très rapidement trèscomplexes.

mais utiles:• pas vraiment mieux quand on doit gérer

explicitement de la mémoire partagée:Système d’Exploitation (multi-tâches,multi-utilisateurs, multi-processeurs,multi-threading)

Extensions quelquefois utilisées:

cond.Queue ;• Retourne vrai s’il existe des processus

en attente sur la condition

Nécessaire pour un lecteur-rédacteurs si l’on veutcontrôler (un peu) les priorités

Moniteurs


2.1.3 Moniteurs Java

Threads + Moniteur (objets)

Principes:1 lock / objet

1 lock / classe

ou 1 lock par block

D’après:Concurrent Programming in Java,© 1996 Doug Lea, Addison-Wesley,October 1996.

http://gee.cs.oswego.edu/dl/

Thread Control Methods:

suspend();(itself or other, but deprecated)

temporarily halts a thread in a way that will conti-nue normally after a (non-suspended) thread callsresume on that thread.

T.resume();(other, but deprecated)

Resume a suspended thread.

Moniteurs


sleep (ms);(itself)

causes the thread to suspend for a given time(specified in milliseconds) and then automaticallyresume.

The thread might not continue immediately afterthe given time if there are other active threads.

thread.join()

suspends the caller until the target thread completes(that is, it returns when isAlive is false).

A version with a (millisecond) time argumentreturns control even if the thread has not completedwithin the specified time limit.

thread.interrupt()

causes a sleep, wait, or join to abort with an Inter-ruptedException, which can be caught and dealtwith in an application-specific way.

(deprecated)

Moniteurs


Synchronization

Synchronization is implemented by exclusivelyaccessing the underlying and otherwise inaccessi-ble internal lock:

sometimes called a mutex, monitor

that is associated with each Java Object (includingClass objects for statics).

Each lock acts as a counter.

If the count value is not zero on entry to a synchro-nized method or block because another threadholds the lock, the current thread is delayed (bloc-ked) until the count is zero.

On entry, the count value is incremented. The countis decremented on exit from each :

synchronized method or

block,

even if it is terminated via an exception.

Moniteurs


Waiting and Notification

The methods:wait, notify, and notifyAll

may be invoked only when the synchronizationlock is held on their targets.

This is normally ensured by using them only withinmethods or code blocks synchronized on theirtargets. Compliance cannot usually be verified atcompile time.

Failure to comply results in an IllegalMonitorSta-teException at run time.

A wait invocation results in the following actions:• The current thread is suspended.

• The Java run-time system places the thread in aninternal and otherwise inaccessible wait queueassociated with the target object:

Dormant

• The synchronization lock for the target object isreleased, but all other locks held by the thread

Moniteurs


are retained. (In contrast, suspended threadsretain all their locks.)

A notify invocation results in the following actions:• If one exists, an arbitrarily chosen thread, say T,

is removed by the Java run-time system fromthe internal wait queue associated with the tar-get object (Dormant).

• T must re-obtain the synchronization lock forthe target object, which will always cause it toblock at least until the thread calling notifyreleases the lock.

Dormant ---> blockedIt will continue to block if some other threadobtains the lock first.

• T is then resumed at the point of its wait.

A notifyAll invocation:

works in the same way as notify except that thesteps occur for all threads waiting in the wait queuefor the target object.

Two alternative versions of the wait method takearguments specifying the maximum time to wait inthe wait queue. If a timed wait has not resumedbefore its time bound, notify is invokedautomatically.

Moniteurs


If an interrupt occurs during a wait, the same notifymechanics apply except that control returns to thecatch clause associated with the wait invocation.

Récapitulatif:Wait --> Dormant, perte du lock

notify --> choisi un Dormant -> blockedle lock n’est pas perdu

Exemple:

Produser / Consumer in Java

FIGURE 4 Produser / Consumer in Java

Moniteurs


Cubby Hole

FIGURE 5 Cubby Hole program

Moniteurs


Cubby Hole execution: deadlock

Cubby Hole normal execution

FIGURE 6 Cubby Hole execution: deadlock

FIGURE 7 Cubby Hole normal execution

Moniteurs


CHAPITRE 3 Langages de plus

‘‘haut niveau’’: Concepts de base

Langages de plus haut niveau,

Cadre ''asynchrone'' et ''impératif''.

Quelque soient les options prises par un langageparallèle:

au moins trois dimensions fondamentales

Dimensions fondamentales


3.1 Dimensions fondamentales

3.1.1 Exécutions parallèles

Parallèle ==>

plusieurs exécutions simultanéesplusieurs processus dans le cadre''asynchrone'' et ''impératif''

Au niveau langage:constructions syntaxiques permettant

de définir, de déclarer des processus

Ada Taks, CSP [ ], objet pour POO//, etc.

Solutions possibles:Création:

- statique (nb. et type connus à la compila-tion, e.g CSP)

- dynamique (nb. inconnu, Ada, POO//)

Déclaration:

- à plat

- imbriquée ( CSP [ [ ] ] )



Exécution:

- séquentielle

...

- quasi-séquentielle

...

- parallèle

...

3.1.2 Communication

Transfert d'information d'un processus à l'autreDeux grands types:

- Variables partagées

- Envoi de messages

Envoi de message: différentes sémantiques:

Cas d'une instruction v := p.f ( ... );Synchrone:

- Rendez-vous

- RPC (Remote Procedure Call)

Asynchrone



- Uni-directionnelle

- Bi-directionnelle (résultat, futur)

- Sure (préserve l'ordre FIFO)

- Asynchrone avec Rendez-vous==> Interruption

3.1.3 Synchronisation

(Synchronisation interne à un processus)

Satisfaction de contraintes relatives à l'enchaî-nement des actions des différents processus

Mécanismes possibles:

- Attente active

Exemple: while (not cond) do end;

- Sections critiques, Sémaphores, Moniteurs

- Expressions de chemins:

Exemple: {put, get}*

- Rendez-vous ou Com. synchrone

- Services bloquants

Exemple: Accept unlock;



- Remplacement (become)

lg. d'acteurs: changement d'état dans unlg. fonctionnel

Cadre initialement fonctionnel, rem-place la notion d’état.

- Verrouillage: lock

read lock: bloque tous les processus quitentent de modifier la donnée verrouillée

write lock: ... lire ou modifier ...

En fait:

Synchronisation et Communication ne sont pasdeux phénomènes indépendants

--> • Communication synchrone est une syn-chronisation (implicite)

--> • Même une com. asynchrone est une syn-chronisation:un processus ne peut pas utiliser un mes-sage, une valeur qu'il n'a pas encore reçue

Autres dimensions


3.2 Autres dimensions

3.2.1 Topologie

Topologie d'une application (dynamique,exécution):

Un graphe orienté:- Noeud: un processus du système

- Arc: référence d'un processus vers un autre

Une communication potentielle

Choix:--> • La topologie d'une application est-elle sta-

tique ou dynamique?Statique:

Concurrent Pascal, DP, CSP, OCCAM,

Dynamique:

Ada, Plasma, Act1, ABCL, Orient84/K,ConcurrentSmalltalk, POOL, Hybrid

De plus en plus:--> • Topologie Dynamique

Création dynamique ==> Topologie Dyn.

Propriétés: Arbre, DAG, cycle

Autres dimensions


3.2.2 Partage ou non

Dans le cadre d'un langage basé sur lacommunication:

Est-ce qu'il y a partage d'information?

- variables partagées

- moniteurs (zone passive partagée)

3.2.3 Passage des paramètres

Lors des communications entre processus:Inter Process Communication (IPC)

Passage des paramètres:- Par copie (par valeur)

- Par référence (par nom)

Implication sur le partage:Par référence généralisée ==> Partage

Par copie ==> n'implique pas le partage

Autres dimensions


3.2.4 Services et Points d'Entrées

Processus communicants:- Points d'Entrées:

e.g.: Entry point d'Ada, RPC

Caractéristique importante:Unification Point d'Entrée et Routine?

a ) Modélisation des routines

Possibilité fondamentale:Passer des routines en paramètre?

Flexibilité et modularité de l'expression desservices

Routine de première classe (1st class citizens,simple si vesion réduite, sinon réflexivité)

Exemple:opérateur & de C

F ( 3, v, & g ) où g est une fonction

b ) Modélisation des requêtes et de leurservice

Possibilité fondamentale:Une modélisation des requêtes?

Autres dimensions


Pouvoir les passer en paramètre, les affecter dansune variable, les stocker dans une liste

Réaliser le service comme une opérationquelconque

Requêtes de première classe

c ) File d'attente des requêtesUne liste des requêtes en attente accessi-ble par le programmeur?

Enjeux: Flexibilité et modularité

Choisir, sélectionner une requête ==> parcourir laliste

Ada: pas directement accessible

3.2.5 Programmation de l'activité desprocessus

a ) ContrôleDéfinition de l'activité d'un processus

- Activité propre

- Service des requêtes

Autres dimensions


Caractéristiques du contrôle:

Répartition géographique:Centralisé:

Son expression est regroupée en un pointdu processus, et (totalement) séparée decelle des routines et des points d'entrées

Exemple: Ada

Décentralisé:

Réparti en plusieurs points du processus,en général mélangé avec le code des routi-nes

Exemple: type moniteur (Lg. Hybrid)

Méthode d'expression:Contrôle explicite:

Programmer directement l'activité du pro-cessus, un fil de contrôle, (select).

Contrôle implicite:

Les autres cas, en général déclaratif

Décentralisé ===> implicite

Centralisé ===> implicite ou explicite

Autres dimensions


b ) Services des requêtes

Exécuter la routine (point d'entrée) sur laquelleporte la requête

Aussi appelé: Acceptation de messageService explicite:

Une instruction permet de servir explicite-ment les requêtes reçues.

e.g. En Ada: Accept get;

Service implicite:

Il n'existe pas d'instructions de service,service transparent, en général décidé àpartir de propriété (contrôle implicite).

e.g. moniteur: Guide, Hybrid

En général:

Contrôle explicite ===> service explicite

Contrôle implicite ===> service implicite

Sélection sur paramètres:Si le contrôle d'exécution d'un processus peutêtre exprimé en fonction de la valeur des para-mètres effectifs des requêtes.

e.g. Concurrent C: serve lock (i) such that free (i)

Autres dimensions


3.2.6 Continuations

Apparaît avec l'appel asynchrone de fonctionsUn processus p appelle une fonction f1d'un processus p1.

Il y a continuation lorsque le résultat de lafonction f1 est le résultat (sans modifica-tion) d'un appel à une fonction f2 d'unautre processus p2

==> Dessin

Continuation expliciteLe programmeur doit spécifier lui-mêmeque le résultat de la fonction f2 doit êtreretourné à p

Continuation impliciteRéalisé sans programmation spécifique.

Autres dimensions


3.2.7 Terminaison des processus

Terminaison programmée:Définie par le programmeur: envoi de messa-ges qui indiquent à une tâche qu'elle doit seterminer

Terminaison automatique:Dépendances statiques:

toutes les tâches mères et les tâches soeurssont soit terminées, soit en attente (selectde Ada)

Impossible dans un modèle où les dépendancessont complètement dynamiques (objets).

Ramasse-miette de processus:

Si un processus n'est plus référencé par unautre processus (actif), il ne recevra plusde requêtes: il peut éventuellement êtreterminé.

==> Terminaison distribuée

Pb des cycles.

Autres dimensions


CHAPITRE 4 Programmation à

Objets: Modèles et Principes de base

Programmation à objet séquentielle


4.1 Programmation à objet séquentielle

Langage de classes, typé

4.1.1 Héritage

Simple, multiple, répété

Interface (Java), Délégation

Redéfinition (overriding ou overwriting), surcharge(overloading), Renommage

Co-variance, No-variance, contra-variance

4.1.2 Polymorphisme

Type statique, Type Dynamique (entité, variable)

Type des objets (ni statique ni dynamique)

Affectation polymorphe

B A

AB

foo()

foo()



Affectation polymorphe inverse (?=) ou castdynamique

4.1.3 Liaison dynamique

Le corps de la routine appelée est décidé dynami-quement, en fonction du type dynamique de lavariable.

Après affectation polymorphe:

4.1.4 Système séquentiel

Une seule activité (‘‘processus’’, ‘‘thread’’):l’objet racine du système

a -> foo ( ... );ab -> foo ( ... );

pab

a

"A"

"AB"



Appel de routine: l’activité ‘‘passe’’ d’un objet àl’autre (pile d’exécution)

pab

a

"A"

"AB"

a = ab ;a -> foo ( ... );ab -> foo ( ... );

Legend

Void pointerPointer

Object Member



On parle quelquefois ‘‘d’envoi de messages’’ pourles langages à objets séquentiels (e.g. Smalltalk),mais c’est un abus de langage car la sémantiquedemeure celle d’un appel de routine.

Question: comment passer à plusieurs activités ??

Pointer

(iii)

(v)

(iv)

(i)

(1)

(2)

(3)

(5)

(6)(ii)

(4)

Sub-system

Legend

MemberObjectProcess/Active Object

Void pointer

Objets actifs et Parallélisme


4.2 Objets actifs et Parallélisme

Une solution qui nous semble très peu ‘‘à objets’’:

4.2.1 Parallélisme orthogonal aux objets

Les activités parallèles sont dissociées des objets(elles sont orthogonales aux objets).

Ces solutions sont en général fortement inspi-rées de la notion de moniteur + Threads

C’est par exemple le cas de Java, ou encoreHybrid, ConcurrentSmalltalk

4.2.2 Parallélisme par objet actif

Chaque activité est associée à un objet actifUne activité est un objet (actif)

Solutions plus novatrices, vrai paradigme de‘‘parallélisme à objet’’. Ce que nous allonsétudier

Deux grandes catégories:

Objets actifs et Parallélisme


Modèles Uniformes, ou Homogènes:Tous les objets sont actifs

e.g. Acteurs

Modèle non-uniformeSeuls certains sont actifs

Attention:la première solution est intéressantedans certains cas (parallélisme de plusbas niveau, Système d’Exploitation).Cf. Java.

A partir de maintenant:étude d’un modèle particulier:

Eiffel//, C++//, ProActive

Réutilisation (Seq. --> Parallèle, Répartie)



4.3 Dimensions fondamentales

Exécutions //, Communication, Synchronisation,partage, etc.

4.3.1 Exécutions parallèlesProcesses are objectsEvery object is not a process

Use of inheritance for parallel activitiesDirectly or indirectly (class or Interface)

Active and passive objects:

PROCESSA* a;P_A* p_a;

a -> g ( ... );p_a -> g (... );

A

P_A

Pointer

(iii)

(v)

(iv)

(i)

(1)

(2)

(3)

(5)

(6)(ii)

(4)

Sub-system

Legend

MemberObjectProcess/Active Object

Void pointer



Active objects:Class-based:

Heir of a PROCESS class:

new P_A ( ... );Allocation-based:

Instantiation of a seq. class:

new (typeid(A)) Process_alloc(...)Classes, objects, active objects:

Sequential processes---> one thread per object

Reuse:---> A a; ... P_A pa;---> Polymorphism between objects and

processes:a = pa;

‘‘A’’

C++ Class Process

C++ allocation

Objects

Active

Objects

Passive

‘‘P_A’’

Object

‘‘A’’ (FIFO)

Allocation style

Class based

new P_A ( ... )

new Process_alloc ( typeid(A), ...)

Legend

Inherit from

new A (...)

Classes Objects

Classes

Sequential

Process

A

P_AClasses

Process



4.3.2 CommunicationCommunication semantics:

---> Method as IPC (entry point)---> Systematically asynchronous towards

active objects---> FIFO order is respected

Decision at the class level, not the routineone

Structuring of the parallelism is based on theobject structuring:

Asynchronous sub-systems

Reuse:---> A a; ... P_A pa;---> a.foo ();---> ....---> pa.foo(); // a remote call, a parallel call

// an asynchronous callDefault behavior:

A FIFO service of requests

PROCESSA* a;P_A* p_a;

a -> g ( ... );p_a -> g (... );

A

P_A



4.3.3 Objets partagésNo shared passive objects

---> Call-by-value between processes,

Deep copy for both Calls and Returns

Passive objects only,Active Objects keep a reference semantics

Initially : no shared object, then if none shared atstep N, none at step N+1.

Sub-system structuring:all asynchronous references are towards theroot objects

--> Picture

Asynchronous reference from whithin a sub-system is OK.



4.3.4 SynchronisationWait-by-necessity:

---> Systematic, implicit andtransparent futures

A wait occurs (automatically):- upon a strict operation on a future (unknownvalue)

- upon passing a future as a parameter in anasynchronous call

p_a -> g ( ... );v = p_a -> f ( p );...v -> foo ( ... ) ;

return ( value );

f

pp_a

a

"A"

"P_A"



2 Predefined operations:Wait, Awaited

Ease the programming of synchronizations

Reuse of routines

To understand futures, find an implementationtechnique for them.

2 main solutions:--> • 1 bit per object + check in every method,

upon each call--> • Wrapper object + check in wrapper, upon

each call as well... Pictures ...

4.3.5 Continuations AutomatiquesAutomatic Continuation:

Goal: Avoid needless wait --- Reuse

Principal: transparent carry of result

If a result is not available when it has to besend back to the caller (upon completion ofa request), then the current object is notblocked, and the result will be send backlatter on and transparently, when available.

See Binary Tree example (second examples).

Exemples


4.4 Exemples

4.4.1 Polymorphisme objet - processusC++//

From a normal (sequential) classes:

// Any user classclass C { public: Res* foo ( param ); virtual Res* vfoo ( param ); C(P1 p1); C(P2 p2);};

Exemples


Parallelization with C++//:

// An asynchronous class based on Processclass AC: public C, public Process { public: AC(P1 p1): C(p1); AC(P2 p2): C(p2); };

PROCESSfoo ()vfoo ()

C (P2)

C

AC

C ( P1)

AC ( P1) AC ( P2)

Exemples


Usage :

// Explicit useAC* ac = new AC(p1);Res* r1 = ac->vfoo ( param ); // Asynchronous callsRes* r2 = ac->foo ( param ); // Async. call

r1->vbar(); // Automatic Wait if awaited // r1->bar(); // Cannot be used: not virtual// ... Picture ... __________________________________

// Implicit use (reuse of sequential code)C* c = ac; // Polymorphic assigment...// Reusability of sequential code:Res* v = c->vfoo ( param ); // Asynchronous call,

// virtuals onlyv->vbar(); // Automatic synchronization// Reuse limit due to Dynamic Binding limitation// +/- idem in other dist. C++: e.g. CORBA, orbix __________________________________// Explicit use of future through the proxy:Future_P* f1=ac->get_future (EC_Any(r1));

// Use of primitives, get a Future proxyf1->Wait(); // Wait the valueif (!f1->Awaited()) ...; // Test availableRes* r =(Res *)f1->Value(); // Get the value,

Exemples


4.4.2 Arbre Binaire de recherche

Binary tree, Eiffel//

a ) Version séquentielle

Code Séquentielle:

class BT [ T -> COMPARABLE, U]-- T is the key, U the information

exportinsert, -- Insert k in the BTsearch, -- Value with key k ?left, right

featurekey: T; info: U;left, right: like current;

...

Exemples


Routines insert et search:insert (k: T; i: U) is

doif key.Void then

key := k; info := i;left.Create; right.Create;

elsif k.equal (key) theninfo := i;

elsif k.lt (key) thenleft.insert (k, i);

elseright.insert (k, i);

end;end; -- insert

search (k: T) : U isdo

if key.Void thenResult := <Not found>

elsif k.equal (key) thenResult := info;

elsif k.lt (key) thenResult :=left.search (k);

elseResult :=right.search (k);

end;end; -- search

Exemples


Topologie à l’exécution:

Exemple d’utilisation:

bt

"BT"

infokey

rightleft

bt: BT; bt.Create;...bt.insert (k1, v1);bt.insert (k2, v2);bt.insert (k3, v3);...s2 := bt.search (k2);s1 := bt.search (k1);bt.insert (k1, vx);s3 := bt.search (k1);...

Exemples


b ) Version parallèle

Trouver les objets actifs:chaque noeud de l’arbre binaire

Topologie à l’exécution:

Note:

La construction ‘‘Like Current’’ est importante.

Elle correspond à une technique de la programma-tion à objets classique (séquentielle) qui permet dedéfinir le type d’une entité comme étant dépen-dante de l’objet courant ( MyType dans d’autreslangages) -- important pour la réutilisation.Ici cela permet de passer de séquentiel à parallèle.

bt ou pbt

"P_BT"

infokey

rightleft

Exemples


Code Parallèle:

Exemple d’utilisation:

class PBT [ T -> COMPARABLE, U]-- T is the key, U the information

exportrepeat BT

inheritBT;PROCESS;

feature

end -- Class PBT

bt: BT;... pbt: PBT; pbt.Create; bt := pbt;bt.insert (k1, v1);bt.insert (k2, v2);bt.insert (k3, v3);...s2 := bt.search (k2);s1 := bt.search (k1);bt.insert (k1, vx);bt.insert (k1, vy);s3 := bt.search (k1);s3.print (); // must print vy

Exemples


Affectation polymorphe ou appel de routine--> •Réutilisation du code

Propriétés :

- Au plus, le niveau de parallélisme est égal aunombre de noeud de l’arbre.

- Le service FIFO est fondamental.

- Le fait que les communications point à point res-pectent l’ordre FIFO est également fondamental.

- Si l’on cherche à prouver que la version séquen-tielle est équivalent à la version parallèle (exercicenon trivial), il faudra démontrer que:

• pour chaque noeud dans le cas parallèle,la liste des requêtes reçues respectel’ordre du cas séquentiel.

Précisions sur la sémantique


4.5 Précisions sur la sémantique

4.5.1 Attente-par-nécessité et affectation

Soit le code suivant:

Quelle sont les sémantiques possibles ?

Quelle est la meilleure?

Comment programmer l’une avec l’autre?

v1 = p_a -> f ( ... );v1 = p_a -> f ( ... );

return ( value );

f

pp_a

p_b

"P_A"

"P_A"

v1 = p_b -> f ( ...);...v1->print



4.5.2 Stratégies de ContinuationAutomatiques

Dealing with partial results.

General case is more complex than Binary Tree.

Goal: maximize parallelism, avoid dead-locks and livelocks

For instance:



At least two solutions:

1.: Synchronous: a result is returned only when itcontains no more futures.

Requires to build a copy of values to be retur-ned when they are known (at the end of theroutine) or upon reception. Deep clone.

This avoids potential modifications from thecurrent active object, in order to maintain thesequential semantics.

2.: Asynchronous: partial results are returned assoon as they are available.

Requires to build more futures to be sentbetween active objects (sub-systems) in placeof unknown values.

There is a risk of endless looping when cyclicdependencies occur between asynchronouscalls. But:

- Correspond to deadlock with Sol. 1

- Are dynamically detectable

Solution 2 leads to more parallelism, and avoidsome deadlock that sould not occur (a ‘‘lazy solu-tion’’ in a functionnal sense, where non-strictvalues that are not correct do not preclude fromreaching a correct solution).At the end: unknown futures remain



Note: these strategies could also be applied uponasynchronous calls, when passing a future asparameter.



4.5.3 Caractéristiques du modèle

Parallel model:

MIMD model: Active objects,

Wait-by-necessity:Data-flow object-oriented parallelism

Object-flow

Computations are structured insub-systems



CHAPITRE 5 Programmation des

Processus

Définir le corps, le contrôle, la synchronisation,l’activité des processus

Programmation du contrôle


5.1 Programmation du contrôle

5.1.1 Analyse d'exemples

a ) Adatask body buffer isbegin

loopselect

when notFull =>accept put (x) do

...end;

orwhen notEmpty=>

accept get (x) do...

end;or

terminate;end select;

end loop;end buffer ;

Caractéristiques :---> Mainly Centralized (but code of entry point)---> Mainly Explicit (but non-determinism)



b ) Guide

Inspiré des Compteurs de SynchronisationCLASS buffer is

METHOD put (x)BEGIN

...END;

METHOD get (x) doBEGIN

...END;

CONTROLput:(completed(put) - completed(get)<size)and current(put) = 0;get:(completed(put) < completed(get))and current(get) = 0;

end buffer ;

Caractéristiques :---> Centralized (fully declarative)---> Implicit (no thread at all)



c ) Hybrid

Univ. of Genevatype buffer of ( ... )

...private{

... put: ( x ) -> ;

uses notFull;{

...» signal notEmpty »

}

get: -> x ;uses notEmpty;

{...» signal notFull »

}}

Caractéristiques :---> Not centralized---> Implicit (not an explicit thread)---> Very much a monitor like solution



5.1.2 Choix: Contrôle expliciteDefault:

---> Centralized---> Explicit control

The Process class:

Why ? :

Centralized:

--> • Readability: separation betweenActions / Synchronization

--> • Reusability: add the synchronizationExplicit:

--> • Lower level: imperative programming--> • An implicit control can be programmed

// An asynchronous class based on Processclass Process { public: Process (...) { // Process creation ... } virtual void Live () { // Process body ... // Default FIFO behavior } ... };



5.1.3 Exemple: Buffer

An example: Bounded Buffer in C++//

On retrouve:

Centralized:

--> • Readability:no Action / Synchronization mixed up

--> • Reusability: of ListExplicit:

--> • Lower level: imperative programmingclassical control structure

New question: how to achieve:

‘‘serve the oldest on put” ?

plus: termination?, non-active wait ?

// An asynchronous class based on Processclass Buffer: public Process, public List { virtual void Live () { // Process body while (not ‘‘termination'') { if (!full) ‘‘serve the oldest on put '' if (!empty)

‘‘serve the oldest on get'' } } };



5.1.4 Service des routines: exemples

a ) Ada

task body buffer isbegin

loopselect

when notFull =>accept put (x) do

...end;

...when startwrite›COUNT = 0 =>

accept startread do...

Caractéristiques :---> Serve the oldest request on put

(No other choice)---> Selection upon the state of the request line



b ) Concurrent C (N. Gehani)

accept buffer(id) suchthat libre (id)...

Caractéristiques :---> Selection upon the parameters value of a

request

Conclusions :---> Expressivenes is limited

---> Always new extensions that have to beadded to the language (cf. Add 95)

---> Very low modularity:how to program new services, and makethem available to other users?



5.1.5 Choix: bibliothèque de services

What is needed to achieve it ?

Service:

Some Reflection and Reification---> Routines as first class objects

(ROUTINE class, operator &)

ROUTINE rout;rout = & put;

---> Requests as first class objects(REQUEST class)

REQUEST req;req.serve();

---> Access to the list of pending requests

from pendReq.start til pendReq.enddo

req = pendReq.current;if .... then req.serve ();



Library of service routines:

Non-blocking services• serve_oldest(); // Serve the oldest request of all• serve_oldest(f); // The oldest request on f

Blocking services• bl_serve_oldest(); // Serve the oldest request of all

bl_serve_oldest(f); // The oldest request on f

Timed services• bl_serve_oldest(Time limit); // Blocking, with time out• etc.

Waiting primitives• wait_a_request(); // Wait until a request arrives• wait_a_request(f); // A request to serve on f• wait_a_request_to_serve(); // Wait until a request to serve

==> non active WaitExtensible by the end user:

• serve_oldest_of2 (f1, f2); // The oldest request on f1 and f2• etc.

(Typical program.: critical section, select, service,...)

Member functions representations:• mid(put)• mid(A::put)• mid(A::put, A::get);• mid(A::put(int, P *));



5.1.6 Exemple: Buffer

An example: Bounded Buffer in C++//

Caractéristiques :

---> si ni vide ni plein, ne respecte pas l'ordred'arrivé, mais alterne put et get.

// An asynchronous class based on Processclass Buffer: public Process, public List { virtual void Live () { // Process body while (!stop) { if (!full) serve_oldest ( mid (put) ); if (!empty) serve_oldest ( mid(get) );

wait_a_request_to_serve(); } } };



Other policy:

---> si ni vide ni plein, respecte l'ordre d'arrivé

// Respecting arrival ordering of the requests if (full) serve_oldest ( mid (get) ); else if (empty) serve_oldest ( mid(put) ); else serve_oldest ( mid(put), mid(get));



5.1.7 Exemple: Reader-Writer

a ) Lecteurs-Rédacteurs en Adaselect

when STARTWRITE’COUNT= 0 =>accept STARTREAD do

nb_readers := nb_readers +1;end;

oraccept STOPREAD do

nb_readers := nb_readers - 1;end;

orwhen nb_readers = 0 =>

accept STARTWRITE;accept STOPWRITE;for i in1..STARTREAD’COUNT loop

accept STARTREAD donb_readers := nb_readers +1;

end;end loop;

end select;COUNT : Nombre d’appels en attente sur un pointd’entrée

Mais pas accès à l’ordre des demandes de RDV!

Priorité: Mixte,



Ni Lecteur, Ni Rédacteur,Ni équitable

b ) Lecteurs-Rédacteurs en ProActive

Politique complètement équitable

// An asynchronous class based on Processpublic class ReaderWriter implements Active {

// Even Policypublic void live(Body myBody){ // Loops over lifetime... while(!done){

// if there is no writer and no write requests// are before the first Read rq.if(writeCount==0 &&

isOlder(myBody,"startRead","startWrite"))myBody.serveOldest("startRead");

// If ther is no activity and the first request// is startWriteif(readCount==0 && writeCount==0 &&

isOlder(myBody,"startWrite","startRead"))myBody.serveOldest("startWrite");

// Allow endXX requestsmyBody.serveOldestWithoutBlocking("endRead");myBody.serveOldestWithoutBlocking("endWrite");

myBody.waitForRequest(); // Passive wait.}}



/** * isOlder* @return True if methodA is before B, False otherwise */private boolean isOlder(Body myBody,

String methodA,String methodB){// Buferize new incoming requestsmyBody.bufferizeNewRequests();// Iterate through the pending requestsMethodCall mc=null;String method=null;RequestLineIterator rq=myBody.getRequestLineIterator();while(rq.hasMoreMethodCalls()){

mc=rq.nextMethodCall();method=mc.getName();// if methodA is present before MethodBif(method.equals(methodA)){// Accept new requests and put the bufferred into the queue

myBody.acceptNewRequests();return true;

}else{if(method.equals(methodB)){// methodb is present Before methodA

myBody.acceptNewRequests();return false;

} } }// There is no request matching methodA myBody.acceptNewRequests(); return false; }



Conclusion:

Explicit control and Services:

powerful,

sometimes needed,

sometimes, we want a more abstractexpression:

for instance with non-determinism

--> • Abstraction for concurrency control



5.1.8 Contrôle implicite: AbtractionAbstractions for concurrency control:

• Enabled set: Rosette, C. Tomlinson, V. Singh

• Behavior Abstraction: ACT++, D. G. Kafura, K.H. Lee

• Activation Conditions: Guide, D. Decouchant,S. Krakowiak

• Path Expression: R. Campbell, A. Haberman

• Synchronization Counters: P. Robert, J.-P. Ver-jus



5.1.9 Example: Buffer déclaratif

Note:

Select vs. abstraction:non determinism,

terminaison

// An asynchronous class based on Processclass Buffer: public Abst_Process, public List { virtual void Synchronization () { associate (mid (put), mid (full) ); associate (mid (get), mid (empty) ); }};



5.1.10 Réutilisation de synchronisationProgrammation incrémentalede synchronisations (impossible en explicite)

Nouveau buffer:Deux nouvelles routines:

nb_element:

retourne le nb. d'éléments dans le buffer

get_last

retourne le dernier élément ajouté

// An reuse of synchonizationclass Buffer2: public Buffer{ virtual void Synchronization () {

Buffer::Synchronization(); associate (mid (get_last), mid (empty) ); }};



5.1.11 Programmation d'une abstraction

// The Abst_Processclass Abst_Process: public Process{ virtual void Live () { // Process body synchronization();

while (!stop) {from <beg. of request line> until <end>loop<Get request, Test blocking routine>if <false> then // Request can be served

req.serve();<remove req from the list>

end;<next request>end loop;wait_a_request_to_serve();

}}

associate (rout:ROUTINE,sync:ROUTINE) {....< Associate a blocking condition>

}

synchronization () {// Default synchronization: empty= FIFO

} // A redefinir par l'utilisateur

};

Une méthode de parallélisation


5.2 Une méthode de parallélisation

A programming method

5.2.1 Conception et programmationséquentielle

a ) Sequential design and programming:

5.2.2 Parallélisation -- Distribution

a ) Process identification:(1) Initial activities:

Parallelism, Distribution, Concurrence(2) Shared objects:

- Default copy semantics (check semantics)- Reference semn. needed: Active object

---> back to --> a.2

b ) Process programming:(1) Define the type of the control(2) Define the process class(3) Define the interface(4) Define the process activity -- synchronization(5) Use the process: polymorphism

Une méthode de parallélisation


c ) Adaptation to constraints:(1) Synchronization refinement(2) Routine redefinition(3) Topology refinement(4) New process definition (--> a.2)

Placement


5.3 Placement

Mapping:

Assigns each active object to

an operating system process onan actual machine or processor.

5.3.1 Modèle de placementMapping model:

Virtual node names: File .c++ll-mapping

// Virtual name Actual name Mach_A Nice Mach_B bolas.isi.edu GLOBUS Proc1 Inria.Sophia.fr Server pitcairn.mcs.anl.gov GLOBUS

p2

I3S-1 (Actual Machine ("P1"))

...p1

p3

OS processMachine (processor)

Legend

Language process (sub-system)

Inria.Sophia.fr (Actual Machine ("Server"))Current machine

Résumé du modèle


5.4 Résumé du modèle

Based on the Eiffel// model:---> Heterogeneous model

Passive and active objects (processes, actors---> Sequential processes---> Polymorphism between objects and pro-

cesses---> No shared passive objects

Call-by-value between processes

---> Unified syntax betweenmessage passing andinter-process communication

---> Systematic asynchronous communicationstowards active objects

---> Wait-by-necessityAutomatic and transparent futures

---> Automatic Continuation (CA)No un-needed waitsA transparent delegation mechanism

---> Centralized and explicit controlLibraries of Abstractions

Extensions / generalizations:---> Allocation-based active object---> Migration

With forwarding (or centralized) + optimizations---> Light-weight active objects

Threads---> Control of mapping

Résumé du modèle


CHAPITRE 6 Réflexion

Introduction


6.1 Introduction

Inter-Process Communication:

2 Reifications: objects:

Request:* ID* Sender* Receiver* Target routine* Effective Parameters* ...

Reply:* ID* Sender* Receiver* Result* ...

v := p.f ( ... );

f

<Service>

request

reply

Reification points


6.2 Reification points

Inter-Process Communication:

4 Reification points:

1 . Send Request2 . Receive Request3 . Send Reply4 . Receive Reply

Each reification point:

---> Specific routine---> Default behavior---> Possible redefinition

v := p.f ( ... );

f

<Service>

12

3

4

Reification points


Reification points

Default behaviors:

Send RequestEstablish communicationSend the request object

Receive RequestPut it in the request line

Send ReplyEstablish communicationSend the reply object

Receive ReplyAssign the reply object into the awaited entity

v := p.f ( ... );

f

<Service>

12

3

4

Adaptation: utilisation de la réification


6.3 Adaptation: utilisation de laréification

Modification of the default behavior:

---> Specific Abstractions

Reactivity:

Interruption of the current service,Management of priority (express messages),Co-routines, or monitor-like programming

Unreliable communications:

Delay the sending of a reply

Fault-tolerance:

Management of the request line in persistent storage(with RDV communication semantics)

Replication

For availability, and maybe resilience ...

Adaptation: utilisation de la réification


CHAPITRE 7 Java, Migration,

MOP, Méta-Objets et Outils

Modèle de base en Java: ProActive


7.1 Modèle de base en Java: ProActive

7.2 Migration

7.3 MOP

7.4 Méta-Objets

7.5 Application et Outil: IC2D

Objets concurrents, répartis et mobiles · Objets concurrents, répartis et mobiles --- Denis...

Documents

Transcript of Objets concurrents, répartis et mobiles · Objets concurrents, répartis et mobiles --- Denis...