software concurrency

73
Software concurrency Fils d’exécution tournants concurremment

Upload: kirk-moon

Post on 04-Jan-2016

32 views

Category:

Documents


0 download

DESCRIPTION

Software concurrency. Fils d’exécution tournants concurremment. Évolution de la programmation. La programmation au départ était linéaire. Série d’instructions exécutées séquentiellement. Rien n’est fait simultanément ! Résultat déterministe. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Software concurrency

Software concurrencyFils d’exécution tournants concurremment

Page 2: Software concurrency

2

Évolution de la programmation

• La programmation au départ était linéaire.• Série d’instructions exécutées séquentiellement.• Rien n’est fait simultanément !• Résultat déterministe.

• Maintenant, la programmation implique l’exécution de tâches concurrentes partageant des variables, des ressources.• « Fil d’exécution » (en anglais thread);• Interruptions;• Résultat non-déterministe.

Page 3: Software concurrency

3

Évolution de la programmation

• Des problèmes risquent de survenir si cette exécution concurrente n’est pas prise en compte.• Certains événements montrent que cela peut même

impliquer des pertes de vies.• Exemple: Therac-25

Page 4: Software concurrency

Exemple• Supposons que nous avons deux routines

concurrentes dont le contenu est identique:

• La variable i est initialisée à 0.

• Quelle sera la valeur de i lorsque ces deux routines concurrentes se seront exécutées ?• Est-ce que se sera 1 ou 2 ?

4

LDI i,R1ADDI 1,R1STI R1,i

LDI i,R2ADDI 1,R2STI R2,i

Page 5: Software concurrency

Exemple• Supposons que nous avons deux routines

concurrentes dont le contenu est identique:

• Réponse: parfois 1, parfois 2.

• Impossible à prévoir.• Cela est inacceptable.

5

LDI i,R1ADDI 1,R1STI R1,i

LDI i,R2ADDI 1,R2STI R2,i

Page 6: Software concurrency

6

Processus léger (Thread)

• Exemple en Java:• Compteurs partageant une variable.

Page 7: Software concurrency

7

Processus léger (Thread)

• Exemple en Java:

Page 8: Software concurrency

8

Processus léger (Thread)

• Exemple en Java:

Page 9: Software concurrency

9

Processus léger (Thread)

• Exemple en Java:

• Devrait compter jusqu’à 20 !

Page 10: Software concurrency

10

Processus léger (Thread)

• Exemple en Java:• Compteur amélioré:

Page 11: Software concurrency

11

Processus léger (Thread)

• Exemple en Java:

Page 12: Software concurrency

12

Processus léger (Thread)

• Exemple en Java:

Page 13: Software concurrency

13

Processus léger (Thread)

• Exemple en Java:

Page 14: Software concurrency

14

Accès à une variable partagée.

• L’accès à une variable partagée peut être source de problème si plusieurs « threads » peuvent y écrire.

Page 15: Software concurrency

15

Sémaphores

• Mise en situation:• Supposez que vous désirez absolument diner avant

Bob. Comment faire pour s’assurer que cela se produise ?

• On assume que Bob suivra vos instructions à la lettre.

Page 16: Software concurrency

16

Sémaphores

• Considérez cette séquence:

• Assure que a3 se produise avant b3 !• Donc les diners seront séquentiels.• Pour ce qui est des déjeuners, ils sont fait

concurremment car on ne sait pas qui déjeunera le premier.

Page 17: Software concurrency

17

Non-déterminisme

• Comme l’exemple précédent en Java le montre deux « thread » concurrents sont non déterministes.

• Ainsi:

• … aura comme résultats possibles:• yes no• no yes

Page 18: Software concurrency

18

Non-déterminisme

• Cela rend le test de programmes très difficile, car un programme « multithreads » peut fonctionner parfaitement 1000 fois de suite et flancher au 1001e essai…

• Donc, à moins de tester un nombre infini de fois, on ne peut garantir qu’un tel programme n’a pas de bogues.• On ne peut que les éviter par une programmation

soignée et rigoureuse !

Page 19: Software concurrency

19

Variables partagées

• Certaines variables peuvent être partagées par plusieurs « threads ».

• Façon simple de faire en sorte que les « threads » interagissent entre eux.

• Un « thread » inscrit une valeur et les autres vont consulter.• Sans mécanisme de synchronisation, comment

savoir si on lit la dernière valeur inscrite par le « thread » ou une ancienne valeur.

Page 20: Software concurrency

20

Écriture concurrente

• Exemple:

• Quelle valeur sera imprimée ?• 5 ou 7 ?

• Quelle sera la valeur finale ?• 5 ou 7 ?

Page 21: Software concurrency

21

Écriture concurrente

• Exemple:

• A première vue, pas de bogues…

• Mais, une fois compilé en assembleur, cela peut entrainer une lecture suivit d’une écriture:

Page 22: Software concurrency

22

Définition d’un sémaphore

• Un sémaphore est une variable globale initialisée à 1 (ou tout autre valeur, selon l’application):

• La fonction signal incrémente la valeur du sémaphore.

• La fonction wait décrémente la valeur du sémaphore et bloque le « thread » si la valeur devient négative.

Page 23: Software concurrency

23

Définition d’un sémaphore

• Ainsi, un « thread » restera bloqué sur un « wait », tant qu’un autre « thread » ne fera pas un « signal » pour libérer le sémaphore.• Une notification permet de libérer un « thread

bloqué », même si le sémaphore est à une valeur négative.

• Cela permettra de faire des synchronisations.

Page 24: Software concurrency

24

Sérialisation par signalisation

• Soit un « thread A » contenant une instruction a1 devant obligatoirement être exécutée avant une instruction b1 d’un autre « thread » identifié B.

• Solution:• Que le « thread A » signale au « thread B » la fin de

l’exécution de l’instruction a1.

Page 25: Software concurrency

25

Rendez-vous

• Voici deux « Thread »:

• Comment faire pour garantir que l’instruction a1 soit exécuté avant l’instruction b2 et b1 avant a2 ?

• Cela s’appelle un rendez-vous.

Page 26: Software concurrency

26

Rendez-vous

• Solution, utiliser deux sémaphores:

• Autre solution possible:

Page 27: Software concurrency

27

Rendez-vous mortel !

• Rendez-vous vers un interblocage:

Page 28: Software concurrency

28

Accès mutuellement exclusif

• Appelé aussi « mutex ».

• Pour rendre l’accès à des variables globales mutuellement exclusif:

• L’incrément d’une variable peut donc être rendu exclusif avec un sémaphore:

Page 29: Software concurrency

29

Accès limité à n « threads »

• C’est un « multiplex » !

• Imaginez que le sémaphore soit initialisé à 3 plutôt qu’à 1. Et supposons qu’il y ait 10 « threads » utilisant ce sémaphore comme suit:

Page 30: Software concurrency

30

Accès limité à n « threads »

• Séquence des événements:• Thread A arrive multiplex = 2• Exécution permise

• Thread B arrive multiplex = 1• Exécution permise

• Thread C arrive multiplex = 0• Exécution permise

• Thread D arrive multiplex = -1• Exécution bloquée

• Thread E arrive multiplex = -2• Exécution bloquée

Page 31: Software concurrency

31

Accès limité à n « threads »

• Suite…:• Thread B terminé multiplex = -1• Signale à un autre thread qu’il peut exécuter

• Thread E débloque et exécute• Thread F arrive multiplex = -2• Exécution bloquée

• Thread C terminé multiplex = -1• Signale à un autre thread qu’il peut exécuter

• Thread D débloque et exécute• Thread E terminé multiplex = 0• Signale à un autre thread qu’il peut exécuter

• Thread F débloque et exécute

Page 32: Software concurrency

32

Accès limité à n « threads »

• Suite…:• Thread A terminé multiplex = 1• Thread F terminé multiplex = 2• Thread D terminé multiplex = 3

• Tous les threads y sont passé.• Quand le multiplex > 0, indique le nombre de places

libres pour accéder à la zone critique.• Quand le multiplex <0, la valeur négative indique le

nombre de « threads » en attente d’un accès à la zone critique.

Page 33: Software concurrency

33

Barrière

• Code:

• Indice de solution:

Page 34: Software concurrency

34

Barrière

• Solution:

Porte tournante #1

Porte tournante #2

Page 35: Software concurrency

35

File (d’attente)

• Salle de dance en couple:• Meneurs (leaders) / suiveurs (followers).• Pour pouvoir aller sur la piste de dance, un leader

doit accompagner un follower.• Il y aura donc des files d’attentes.• Sémaphores.

Page 36: Software concurrency

36

File (d’attente)• Pour le meneur:

• Pour le suiveur:

Page 37: Software concurrency

37

File (d’attente)• Pour le meneur:

• Pour le suiveur:

• L’attente sera-t-elle raisonnable ?

Page 38: Software concurrency

38

File exclusive• Initialisation:

• Accès exclusif à la piste de dance !

Page 39: Software concurrency

39

File exclusive• Le meneur:

Page 40: Software concurrency

40

File exclusive• Le suiveur:

Page 41: Software concurrency

41

Producteur/Consommateur• Problème du producteur/consommateur.• Division du travail entre plusieurs « threads ».• Exemple (programmation événementielle):• Un événement se produit lorsque l’usager appui sur une

touche ou bouge la souris.• Un « thread » producteur créée un événement et le met dans

une file.

• Concurremment les « threads » consommateurs retirent les événements de la file et les traitent.

Page 42: Software concurrency

42

Producteur/Consommateur• Problème du producteur/consommateur.

Page 43: Software concurrency

43

Producteur/Consommateur• Initialisation:

Page 44: Software concurrency

44

Producteur/Consommateur• Producteur:

• Consommateur:

Page 45: Software concurrency

45

Producteur/Consommateur• Cas avec file d’attente de longueur finie:

Page 46: Software concurrency

46

Producteur/Consommateur• Exemple en Java:

Page 47: Software concurrency

47

Producteur/Consommateur• Exemple en Java:

Page 48: Software concurrency

48

Producteur/Consommateur• Exemple en Java:

Page 49: Software concurrency

49

Producteur/Consommateur• Exemple en Java:

Page 50: Software concurrency

50

Producteur/Consommateur• Exécution, mais il y a un bogue.

Page 51: Software concurrency

51

Producteur/Consommateur• Exemple corrigé en Java:

Page 52: Software concurrency

52

Producteur/Consommateur

Page 53: Software concurrency

53

Producteur/Consommateur• Exemple corrigé en Java:

Page 54: Software concurrency

54

• Exemple corrigé en Java:

Producteur/Consommateur

Page 55: Software concurrency

55

Producteur/Consommateur• Exécution sans bogue.

Page 56: Software concurrency

56

Producteur/Consommateur• Exemple avec pile circulaire (FIFO):

Page 57: Software concurrency

57

Producteur/Consommateur

Page 58: Software concurrency

58

Producteur/Consommateur

Page 59: Software concurrency

59

Producteur/Consommateur

Page 60: Software concurrency

60

Producteur/Consommateur

Page 61: Software concurrency

61

Producteur/Consommateur• Exécution sans bogue.

Page 62: Software concurrency

62

Producteur/Consommateur• 2e exécution.

Page 63: Software concurrency

63

Cycle de vie : « thread » Java

Page 64: Software concurrency

L’interblocage (deadlock)• Si plusieurs threads partagent une même

ressource un problème peut survenir si cette ressource n’est pas libérée.

• On parle alors d’interblocage. • Les threads attendent que la ressource se libère et

rien de se passe…

Page 65: Software concurrency

Un diner de philosophes• Schéma:

Page 66: Software concurrency

Un diner de philosophes• Contraintes:• Une fourchette ne peut être prise que par un

philosophe à la fois.• Il faut éviter qu’un philosophe crève de faim en

attendant une fourchette.• Il est possible que plus d’un philosophe mange au

même moment.

Page 67: Software concurrency

Que font les philosophes• Les philosophes réfléchissent…

• Puis prennent deux fourchettes (l’une à droite, l’autre à gauche)…

• Puis mangent à satiété…

• Et déposent leurs fourchettes, pour replonger à nouveau dans leur réflections.

Page 68: Software concurrency

Que font les philosophes• En code machine:

• Assumons que les philosophes savent comment réfléchir et comment manger.• Reste à gérer les fourchettes.

Page 69: Software concurrency

Gestion de fourchettes• Identifions chaque philosophe par un

nombre i, allant de 0 à 4.

• Ainsi définissons pour chacun, la fourchette gauche et la fourchette droite:

• Et un sémaphore par fourchette:

Page 70: Software concurrency

Gestion de fourchettes• Essayons donc de gérer les fourchettes

comme suit:

• Qu’en pensez-vous ?

Page 71: Software concurrency

Gestion de fourchettes• Si tous les philosophes prennent leur

fourchette de droite gros problème !

• Tout le monde attends que la fourchette à sa gauche devienne disponible.

• Interblocage !

Page 72: Software concurrency

Ça nous prend un gaucher• Si l’un des philosophe est gaucher et prend sa

fourchette gauche en premier, alors sa fourchette de droite reste disponible pour son collègue et il y en a au moins un qui peut manger.

• Et, ça débloque le système !

Page 73: Software concurrency

Limiter le nombre de mangeurs

• Voici un bout de code ou on limite le nombre de mangeurs simultanés:

• footman est un multiplex initialisé à 4.