Cours système distribué








télécharger 87.01 Kb.
titreCours système distribué
date de publication28.03.2017
taille87.01 Kb.
typeCours
ar.21-bal.com > droit > Cours




Cours système distribué







2010/2011

Cours de système distribué M2 RSD






Table des matières


Chapitre1 : Groupe de communication 2

Introduction 2

1- Communication one to many: 2

1.1 Gestion de groupe: 3

1.2 Adressage d’un Groupe : 4

1.3. Réception de message : 5

1.4 Multicast bufferisé et non bufferisé 5

1.5 Sémantique d’émission Multicast 5

1-6 Reliability du multicast communication 6

1-7 Atomic multicast 6

1-8 Primitive de communication de groupe 6

2-Many to One communication 7

3- Many to Many Communication 7

3-1 Ordre absolu : 8

3-2 Ordre consistent : 9

3-3 Ordre causal 10

Chapitre II : Mémoire Partagée Distribuée (Distributer Shared Memory DSM) 12

Introduction : 12

2.1 Granularité : 14

2.2 Structure de l’espace mémoire partagé : 14

2.3 Cohérence Mémoire et synchronisation des accès : 14

2.4 Localisation et accès aux données : 15

2.5 Stratégie de Remplacement : 15

3. Granularité : 15

4- Structure d’espace mémoire partagée : 16

b) structure par type de donnés : 16

5- modèles de consistance : 16

5.a) modèle de consistance strict : 16

5.b) modèle de consistance séquentielle : 16

5.c)Causal consistency model : 16

5.d) PRAM : Pipelined Randum Access Memory Consistancy 17

5.e) Modèle de Consistance du Processeur : 17

5.f) Modèle De Consistance Faible : 17

5-g) Modèle De Consistance Faible : 17


Chapitre1 : Groupe de communication



Introduction


message- based interaction; one to one ou (per to per, unicst, communication)

1 seul émetteur envoi 1 message à un seul processus récepteur

Cependant beaucoup d’application distribuée que le system De communication par message,

Offre la possibilité d'une communication de groupe pour de meilleure performances et une aisseau de programmation.

> Selon que l'on ait un ou plusieurs émetteur ou récepteur nous distingue trois type

De communication de groupes :

1. One to many (1 émetteur-plusieurs récepteurs)

2. many to one (plusieurs émetteurs-un récepteur)

3. many to many (plusieurs émetteurs-plusieurs récepteurs)

1- Communication one to many:


Cette communication il ya un émetteur et plusieurs processus récepteurs est aussi désigné par le terme de Multicast ( communication a diffusion) :

Le Broadcaste est un cas particulier de la communication Multicast où le message est envoyé à tous les processus connectés au Réseau.

Le Multicast et le Broadcaste sont intéressants pour plusieurs application pratique.

Exemple 1: l'administration Réseaux…… « Linge qui manque »…….

Le même service, le processus administrateur peut réaliser un Multicast pour transmettre 1 message de demande ...serveur libre pour réaliser une requête …..et il sélectionnera alors le premier serveur qui répondra.

L’administrateur du serveur n'aura pas à guider une trace de serveur libre.
Exemple 2:

Pour localiser un serveur réalisent un service particulier, il est possible de réaliser un "Multicast" dans ce cas, il n'est pas nécessaire de recevoir une réponse de l'ensemble des serveurs .il suffit d'avoir la réponse d'un seul serveur.

1.1 Gestion de groupe:


Dans le cas d'une communication Multicast, les processus récepteurs forment un groupe.

a) Type de groupe:


Les groupes peuvent être de deux types: closed et open

- Un closed groupe : est un groupe où seuls les membres du groupe peuvent transmettre un message au groupe. Un processus externe ne peut envoyer un message au groupe mais peut envoyer un message à un membre de groupe.

- Un open groupe: est un groupe où n'importe quel processus du réseau peut lui envoyer un message. L’utilisation d’un « Open Group » ou d’un « Closed Group » dépend de l’application.

Exemple: en group de processus qui traite le même problème n’ont pas besoin de communication avec un processus extérieur du group (Téléconférence).

Exemple : un group de copies de processus dédier aux traitement distribués des requête des clients , doivent former un « Open Group » pour qu’il puissent recevoir les requête des utilisateur .

b) Adhésion/Sortie/Maitre :


  • Un système d’échange de message, avec une possibilité de communication de group offre une facilité de création et de destruction de group dynamiquement ainsi que les opérations de :

  • D’entrée d’un processus dans le groupe.

  • De sortie d’un processus d’un groupe

Pour cela, il faut disposer de mécanisme de gestion des informations sur les groupes et leurs membres

Solution :

Un mécanisme simple : l’utilisation d’un processus serveur de groupe centralisé

c) Serveur centralisé de groupe :


Le processus ne soit toute les demandes de :

  • Création/ destruction d’un group.

  • Rajouter/ supprimer un membre.

Ainsi ???????????????????????????????

  • Critique, cette approche soufre de fiabilité et du problème n’est pas appropriée ou cas de passage à l’échelle. Ce qui est le cas généralement des solutions centralisées

d) Serveur distribuée :


  • Une solution serait de réaliser un ou des copies du serveur afin de remédier à ces problèmes.

Cependant, la coexistence de plusieurs serveurs en engendré un « OverHead » (cout en communication afin de maintenir les copier des informations aux niveaux des serveurs dans un état consistent.

1.2 Adressage d’un Groupe :


L’adressage d’un group se fait par un schéma de désignation à 2 niveaux :

  • Le nom de haut niveau est une chaine ???????.??? qui est indépendante de la localisation du processus.

  • Le nom de bas niveaux dépend des couches matérielles sous-jacentes. Par exemple, sur des réseaux , il est possible de créer une adresse réseaux spéciale que plusieurs machines peuvent écouter. Cette adresse est désigné par :

  • Adresse de multicast. Cette adresse est utilisée comme un nom de bas niveaux.

Les réseaux qui ne permettre pas le fait d’avoir un adresse multicast peuvent avoir des possibilités de ‘’broadcasting’’. Un tel réseau déclare une adresse telque zéro comme ‘’broadcast adresse’’. Un message envoyé à l’adresse zéro est automatiquement délivré à l’ensemble des processeurs du réseau.

L’adresse du broadcast est utilisée comme nom de bas niveau du groupe.Ainsi, chaque machine en site « à virifier » doit vérifier chaque paquet.Cette approche est encore moins efficace que la que la solution précédente, il est à noter que l’adresse du broadcast représente le nom de bas niveau de tous les groupes.

Une troisième possibilité, dans le cas où les deux précédentes ne peuvent êtres appliqués, est d’utiliser le mécanisme de communication One-To-One. Dans ce cas, le système de la machine émettrice envoie un message à chaque machine qui supporte un processus appartenant au groupe. Dans ce cas le nom de bas niveau du groupe comporte l’ensemble des identificateurs des machines qui disposent d’un processeur appartenant au groupe.

Cette méthode génère un trafic important car elle envoie un paquet de message à chaque processeur, alors que les deux premières transmettent un seul message.Cependant, cette solution est interenaute « à vérifier » au cas où il y a un seul réseau LAN, Dans le cas où il y a plusieurs réseau avec des passerelles, la troisième solution est plus simple à appliquer.

1.3. Réception de message :


Une application usager utilise le nom de haut niveau du groupe. Le réseau centralisé de groupe maintient une table de noms de haut niveau avec les noms de bas niveau correspondant. Il maintient aussi, pour chaque groupe, une liste des identificateurs des processus appartenant au groupe.

Groupe server

demande

nom bas niveau

+

Liste identifie

A l’émission d’un message à un groupe, le site émetteur contacte le serveur de groupe pour récupérer le nom de bas niveau du group et la liste des identificateurs des processus appartenant au groupe.

La liste des identificateurs des processus d’un groupe est insérée dans le paquet transmis au groupe.Dans le cas d’une adresse multicast ou d’une adresse broadcast, le système du site émetteur envoie le message à cette adresse multicast/broadcast. Dans le cas d’une liste de processus, un paquet du message est envoyé vers chaque processus.

Lorsqu’il machine reçoit le message, elle le retransmet vers les processus qui lui sont connectés. Si aucun processus n’est connecté, la progression (à vérifier) du message est stoppé.L’avantage est que l’émetteur ne se soucis pas de la taille du groupe ou du mécanisme de gestion de groupe, mais uniquement du nom de haut niveau du groupe.

1.4 Multicast bufferisé et non bufferisé


Le multicast est un mécanisme asynchrone car :

1. il n’est pas réaliste de faire attendre les processus émetteurs jusqu’à ce que tous les membres du groupe reçoivent le message.

2. le processus émetteur peut ne pas être concerné par le traitement du message à la réception dépend du fait que le multicast sont buffresé ou non-bufferisé.

  • Multicast non-bufferisé: dans ce cas, le message est perdu si le processus récepteur n’est pas en attente du message.

Le message ne peut être reçu que par les processus qui sont prêt à le recevoir.

  • Multicast bufferisé : dans ce cas, le message est stocké dans un buffer et tous les processus finissons par recevoir le message.

1.5 Sémantique d’émission Multicast


Il y’a deux sémantique d’émission multicast :

One-to-all : une copie du message est envoyée à chaque processus du groupe de multicast et le message est mit en buffer en attendant sa réception.

’Bulletin board’’ : le message est adressé à un canal. Le canal joue le rôle d’un bulletin de board. Un processus qui reçoit le message prend une copie du message mais ne le supprime pas du canal. Ainsi, le message reste disponible aux autres processus.Les processus ayant le droit d’accès au canal appartiennent au groupe de multicast.

Cette dernière approche est plus ???????????? car :

  • l'importance du message pour le processus la pertinence <<à vérifer>>

 ???????????? peut dépendre de l’état du processus.

  • un message non reçu au bout d'un certain temps peut devenir non valide

par exemple ,une requête qui peut être servie par un des processus d’un groupe multicast sera déposé au niveau du canal et seul un processus prêt pour le traitement de la requête pourra la prélever.

1-6 Reliability du multicast communication


Les différentes application nécessite des degrés déférents reliability

1- o_ reliability

2- 1_ reliability

3- m_out_of_n_reliability

4- all_ reliability

1-7 Atomic multicast


Dans le cas un message émie à un groupe multicast doit étre reçu par l’ensemble des nœud du groupe multicast ou par aucun d’entre eux. Généralement on suppose qu’un membre d’un groupe multicast qui tombe en panne n’est plus membre « de » qu’il est en panne

L’atomicité peut être spécifiée au niveau du message.

Dans le cas d’un mécanisme de multicast ?????????????,un message est envoyé à chaque membre et chaque membre envoie un acquittement ACK au noyau .Si tous les serveurs non pas répondu le noyau retransmis le message au bout d’une certaine période et ainsi de suite jusqu'à recevoir les ACK de tous les processus et alors le système confirme la réalisation du multicast atomique. Cette solution peut être adopté dans le cas ou on suppose qu’il n’ya pas de panne de l’émetteur et de récepteur ,sans quoi , il faut adopter un protocole de tolérance aux pannes.

1-8 Primitive de communication de groupe


La primitive d’émission d’un message devrait être la même qu’il s’agie d’une émission one-to-one ou one-to-many. Dans les deux cas, il faut spécifie l’adresse du destinataire qu’il s’agie d’un processus ou d’un groupe multicast. Et un pointeur vers le contenu du message.

Cependant la plupart des systèmes qui offre une communication de groupe dispose d’une primitive send-receve Ceci simplifie l’implémentation car le system ne pourra pas savoir s’il s’agit d’un nom de serveur ou de groupe de réseau pour le nom de bas niveau.De plus une primitive send-groupe permettre de spécifier le N° de reliability (fiabilité) et d’autre paramètre tel que l’atomicité du multicast.

2-Many to One communication


Nous avons alors de multiple émetteurs et un seul récepteur. Le récepteur unique peut être sélectif ou non sélectif. Un récepteur sélectif spécifie un émetteur unique. Un échange de message aura lieu uniquement si cet émetteur envoie un message Un récepteur non sélectif spécifie un ensemble d’émetteurs. Dans ce cas, un échange de message a lieu si l’ensemble des émetteurs envoie un message. Cependant, on ne peut pas savoir quel processus émetteur détiendra l’information et quand.Ce qui nous donne un ensemble non deterministe.Il est non comprit de contrôler dynamiquement le groupe d’émetteur. Par exemple, un buffer peut stocker les données fournies par des non comprit.

3- Many to Many Communication


- Nous avons plusieurs émetteurs et plusieurs récepteurs.

- Les communications many-to-one et one-to-many sont implicitement incluses dans le schéma de communication many-to-many.

Donc, les concepts déjà vus s'appliquent toujours mais les nouveaux concepts sont propres à ce type de communication telle que la délivrance de messages ordonnés.

La délivrance de messages ordonnés assure la réception des messages dans un ordre accepté par l'application. Cette propriété est nécessaire au bon fonctionnement d'un bon nombre d'applications.

Exemple : m1 et m2 messages de mises à jour de copies d'une BDD

figure1.jpg

La réception non ordonnée entrainera une incohérence de la BDD.

Cet ordonnancement ne peut être maintenu que par un séquencement.Le séquencement est évident dans le cas d'une communication one-to-many. L'émetteur unique devra confirmer la fin du 1er multicast avant d'initier le suivant.Dans le cas des communications many-to-one, l'ordre est maintenu par le récepteur unique. Donc, dans ces deux derniers cas, il n'est pas difficile d'assurer l'ordre de délivrance des messages.Par contre dans le cas de communications many-to-many il n'est pas évident d'assurer cela. L'ordre de réception est non déterministe.

m1

m2

S1

S2

S3

S4

Temps

m1

m2

Nous avons trois mécanismes d'ordonnancement de message :

3-1 Ordre absolu :


Les messages doivent être transmis aux récepteurs dans l'ordre exact de leur émission. Dans ce cas la solution est d'utiliser une estampille globale. Par exemple, on suppose que les

Horloges des processus sont synchronisées .L’heure d’émission est alors ????????? Dans chaque message comme identificateur.

Le système d’un récepteur utilise alors une file d’attente pour chaque émetteur où les messages reçus de cet émetteur sont stockés et régulièrement toute les périodes des messages sont délivrés au récepteur. Cette fenêtre a une taille représentée par un intervalle de temps fixe. Périodiquement, les messages reçu et qui sont à l’intérieur de cette fenêtre sont délivrés et les messages non encore inclus dans la fenêtre restent en attente dans la file car d’autre messages avec des dates inférieures peuvent arriver.

La taille de la fenêtre est définie en prenant en considération le temps maximal possible pour la transmission d’un message d’une machine à n’importe quelle d’autre machine.

3-2 Ordre consistent :


Un ordre absolu nécessite des horloges synchrones ce qui peut être très difficile à obtenir d’une part, et d’autre part, la plupart des applications n’exigent pas ce type d’ordre.

Exemple : les requêtes de mise à jour d’une BDD émises par des émetteurs (clients) différents.Il suffit qu’elles arrivent dans le même ordre au niveau des serveurs de copies de la BDD, puisque le résultat nous mènera vers des copies BDD cohérentes. Donc, un ordre consistent peut être différent de l’ordre d’émission.

Un mécanisme permet d’implémenter cet ordre et d’utiliser la communication de groupe Many-to-one et One- to-many.

c:\users\youcef\desktop\sans titre.jpg

Au niveau d’un récepteur les messages sont ordonnés séparément dans des files différentes (une pour chaque émetteur). Le message est alors ?????????directement s’il n’y a pas de ????????? dans le numéro de séquence sinon le message reste dans la file jusqu’à la réception de tous les messages ayant des numéros de séquence inférieur.


M2

M1

S2

R2

R1

S1


Cette solution soufre du fait de dépendance de serveur ( le serveur central de séquencement).Elle prévôt donc tout les inconvénients d’une solution centrale (cas de panne du serveur de sequencement,…, congestion) .

La solution serait d’avoir un mécanisme distribué par exemple le protocole ABCAST .

1- L’émetteur affect un n° temporaire de séquence à son message avant l’émission. Ce n°doit être supérieur aux n° précédents.

2- Un membre du groupe qui reçoit le message proposé proposer un nouveau sequence number comme suit (qu’il retourne à l’émetteur)

Max (Fmax , Pmax)+1+i/N

Fmax : Nombre maximum de nombre finale de séquence attribué dans le groupe .

Pmax  : Nombre de séquence maximum proposé par le membre

N : nombre de membres dans le groupe

i : n° de membre

3- Quand l’émetteur reçoit les n°de séquence proposés de tous les membres, il sélectionne le plus grand entre eux et le transmet dans un ‘Commit message’ à tout les membres .

4- En recevant le ‘commit message’, chaque membre attribue ce numéro au message.

5- Les messages avec le n° de séquence final sont ordonnés et délivrés au récepteur.

3-3 Ordre causal


Certaine applications n’exigent pas l’ordre consistant mais elle se suffisent d’un ordre causale. Un ordre causal assure que si l’événement d’émission d’un message est causalement liée à l’événement d’émission d’un autre message, les deux messages sont reçus aux récepteur dans un ordre correct. Deux événements d’émission non liés par une relation de causalité peuvent arriver dans un ordre quelconque. Deux événements liés par une relation hapened-before (relation de causalité).

Exemple :

S1

R1

R2

S2

R3

M1

M2

M3

Une implémentation de cette solution et offerte par le Protocol CBCAST :

1- Chaque membre dispose d’un vecteur à n composant ou n est le nb total des membres de groupe. Chaque membre se voit assigné un numéro de séquence entre 1 et N.

Le i ème composant d’un vecteur de membre digne le nb de message reçu de i par ce membre

Pour envoyer un message un processus incrémente la valeur de son propre composant dans un vecteur et envoie le vecteur dans le message.

A la réception du message, le système vérifie certaines conditions pour déterminer si le message doit être :

S[i]=R[i]+1 and S[j]<=R[j] qlq i=! j

S vecteur contient les messages R est un vecteur de réception

Délivré ou retardé avant sa réception par le processus récepteur. Ceci afin d’assurer l’ordre causal.La première condition assure que le répéteur a reçu tous les messages émis avant le message courant par l’émetteur, La seconde condition assure que l’émetteur n’a reçu aucun message que le récepteur n’a pas reçu.


D

C

B

A
Exemple :

3

2

5

1



3

2

5

1

2

2

5

1

3

2

4

1


Emission de nouveau message




4

2

5

1

message




Message retardé

Message délivré


A[1] != C[1]+1

Message retardé

A[3]<= D[3]




Cette condition assure que le message de l’émetteur n’est pas causalement lié à un message non reçu par le récepteur.Si la condition est vérifiée, le message est délivré sinon il est mis dans un buffer et le test est refait plus tard.

















Chapitre II : Mémoire Partagée Distribuée (Distributer Shared Memory DSM)

Introduction :


  • Deux concepts fondamentaux à la communication inter_processus :

      • Partage mémoire

      • Passage de message




  • Le passage de message permet de partager une donnée transmise par l’émetteur par la primitive SEND et reçu par un récepteur RECEIVE 

SEND ( récepteur, Data);

RECEIVE (Data);



  • La donnée est partagée entre l’émetteur et le récepteur .L’abstraction mémoire partagé Illusion d’une mémoire physique partagée

Mémoire

CPU

Gestionnaire Mémoire

Mémoire

CPU

Gestionnaire Mémoire

Mémoire

CPU

Gestionnaire Mémoire

Communication Réseau

DSVM (Distributed Scared Virtual Machine)

1-Architecture d’une DSM 


  • Le gestionnaire de mémoire locale prend en charge l’intégration de la mémoire locale dans la mémoire virtuelle

  • L’espace mémoire virtuelle distribué est partitionné en bloc

  • La notion de mémoire cache est toujours utilisée réduire le temps de latence

  • Chaque gestionnaire de mémoire considère toute sa mémoire locale cache de la DSDV

  • Un nœud qui référence un bloc mémoire de DSDV, le gestionnaire mémoire locale prend en charge la requête

-Si la donnée disponible localement donc accès locale

-Sinon la requête est transmise au nœud sur le quel se trouve la requête

          • Migration du bloc de donnée

          • Création d’une copie locale

Création d’une copie trafic de communication non visible user

La copie éliminer ce trafic pour les accès ultérieur à ce bloc

Trafic diminue considérablement en cas de première implémentation localité des accès par l’application.

2. ?????????????????????????????????????????????????

2.1 Granularité :


Unité de partage ou taille de bloc transféré.

La sélection de granularité =>exprime le d° de parallélisme.

2.2 Structure de l’espace mémoire partagé :


=> cette structure dépend de l’application que supporte le DSVM.

2.3 Cohérence Mémoire et synchronisation des accès :



Copie211

Copie11






Mémoire Mémoire

Manipulation Parallèle

Nécessite + Protocole de cohérence

+ Primitives de synchronisation

+ Sémaphore

+ Compteur d’événement . + Verrous

2.4 Localisation et accès aux données :


Localiser et retourner d’une donnée => Nécessite d’un mécanisme de localistion de blocs de données (recherche).

2.5 Stratégie de Remplacement :


Dans le cas ou la mémoire locale est pleine => stratégie de remplacement des données

qui Par nouvelle données (A VERIFIER)

2.6 Mise à jour :

Possibilité de dérouler des actions

2 nœuds exécutent des actions concurrentes

2.7 Hétérogénéité :une DSVM doit prendre en compte le problème d’hétérogénéité dans le cas de machine hétérogène (codage,…).

3. Granularité :


Le choix de la granularité est influencée par :

  • Overhead en pagination

  • Taille du répertoire

  • Mise à jour des blocs (si un grand bloc est mis à jour alors tout le bloc doit être transféré alors que seule certaine partie ont été modifie).

  • Faux partage (exemple : 2 variable = dépendantes dans un même bloc).

?????????????????????????????????????????????????????????????

  • Beaucoup de système de DSVM opte pour la taille de page physique de la mémoire virtuelle ??????

Ce choix a pour avantage :

  • Utilisation du schéma de DP traitement pour gérer la cohérence (mise à jour et copie)

  • Permet le contrôle d’accès (droit d’accès)

  • Intégrer dans le gestionnaire de la mémoire

1page tient 1 paquet  overhead

4- Structure d’espace mémoire partagée :


Approche :

a) Non structuré :{ensemble de mots} simple a programmer

b) structure par type de donnés :


=>la taille des objets et variables accédés changent

=>taille de bloc partagé variable (difficulté+complexité du DSVM)

c) structure BDD : ensemble d’enregistrement

5- modèles de consistance :


Ensemble de règles que l’application doit respecter pour garantir la consistance des données .un certain nombre de protocol ont été proposé => la recherche continue de nouveau protocoles

Plus de concurrence => mois de consistance =>meilleur performance de l’application.

5.a) modèle de consistance strict :


Forme de cohérence forte

=> La valeur que retourne une opération de lecture est toujours la dernière valeur écrite (en un temps strict)

=> Nécessité d’une horloge global ou synchronisation quelque soit le site lecteur on écrive

=> Impossible

Exemple: (READ (r1) ,write(w1), READ (r2))

(r1, w1, r2) est le seul ordre possible

5.b) modèle de consistance séquentielle :


Modèle proposé par Lamport 1979

Tous les processus perçoivent le même ordre des opérations d’accès sur la DSVM.

Exemple : si on a les operations READ (r1), write (w1), read (r2)

toutes les combinaison {(r1,w1,r2),(r1,r2,w1),(w1,r1,r2),(w1,r2,r1),(r2,w1,r1),(r2,r1,w1)}

Consistance  pas garantie de lecture de la dernière

5.c)Causal consistency model :


Seuls les opérations d’accès mémoire causalement liées doivent êtres observées dans un même ordre au niveau de tous les nœuds.

Deux références sont causalement liées si par exemple la valeur obtenue par une référence mémoire dépend de la valeur obtenue par la deuxième.

Modèle Consistance causale  toutes les opérations d’écriture causalement liées sont observés dans un même ordre correcte. Les opérations d’écritures non causalement liées peuvent êtres observés dans un ordre quelle conque.

Exemple : si W2 est causalement liée a W1 le seul ordre ????????? est (W2 ,W1)

Implémentation  graphe de dépendance des accès mémoire.

5.d) PRAM : Pipelined Randum Access Memory Consistancy


Propose par Lipton & Sandberg 1988

P1 réalise : (W11, W12) P2 : (W21, W22)

P3 peut observer : [(W11, W12), (W21, W22)]

P4 peut observer : [(W21, W22), (W11, W12)]

Dans le modèle e consistance séquentielle, le même ordre doit être observé par tous les processus  P3 et P4 doivent observer le même ordre.

5.e) Modèle de Consistance du Processeur :


Proposé par Goodman 1989

C’est le modèle PRAM + restriction de cohérence. Pour une mémoire donnée située sur une position x, les processus doivent tous observer le même ordre pour les Operations intervenants sur cette position x

tous les processus doivent observer un seul ordre (W11, W12), (W21, W22) ou (W21, W22), (W11, W12

5.f) Modèle De Consistance Faible :


Bubois & All 1988

Les résultats de plusieurs Opérations peuvent être combinées et envoyées a un autre processus uniquement lors qu’il a besoin. Accès rares aux variables partagées ou des applications, qui accèdent a des variables partagées et puis pas d’accès pour une longue durée.

5-g) Modèle De Consistance Faible :


  • Tout changement réalisée par un processus propagé à tous les autres nœuds.

  • Tout changement réalisé par les autres nœuds sont propagé vers le nœud du processus.

similaire:

Cours système distribué iconCours système distribué

Cours système distribué iconInktank s’associe avec suse pour prendre en charge le système de...
«Ensemble, suse et Inktank aident les entreprises à tirer pleinement parti de la puissance d’un cloud open-source en apportant leur...

Cours système distribué iconCours I. Système décimal et définitions 7

Cours système distribué iconLe Groupe Serge Ferrari conçoit, fabrique et distribue des matériaux...

Cours système distribué icon* Cours de langue
«Etude sur le système suffixal du grec», sous la direction de M. Jean-Victor vernhes, Maître de Conférences à l'Université de Provence...

Cours système distribué icon* Cours de langue
«Etude sur le système suffixal du grec», sous la direction de M. Jean-Victor vernhes, Maître de Conférences à l'Université de Provence...

Cours système distribué iconRéunion de Bureau du 31/08/2012
«mécénat» disponible au bagad qui pourrait être distribué aux personnes volontaires

Cours système distribué iconAutomne 2013 plan de cours
«Unified», combinée à l'apprentissage du langage uml, est présentée et mise en pratique dans un projet de conception et d'implantation...

Cours système distribué iconUn système temps réel est un système (application ou ensemble d’applications)...
«qui va vite / rapide» mais un système qui satisfait des contraintes temporelles (les contraintes de temps dépendent de l’application...

Cours système distribué iconLe systeme d’exploitation windows : évolution historique et comparaison des différentes versions
«New Technology». Ce système d’exploitation de la firme Microsoft évolue de la manière suivante








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com