Software concurrencyFils d’exécution tournants concurremment

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.

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

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

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

6

Processus léger (Thread)

• Exemple en Java:• Compteurs partageant une variable.

7

Processus léger (Thread)

• Exemple en Java:

8

Processus léger (Thread)

• Exemple en Java:

9

Processus léger (Thread)

• Exemple en Java:

• Devrait compter jusqu’à 20 !

10

Processus léger (Thread)

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

11

Processus léger (Thread)

• Exemple en Java:

12

Processus léger (Thread)

• Exemple en Java:

13

Processus léger (Thread)

• Exemple en Java:

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.

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.

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.

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

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 !

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.

20

Écriture concurrente

• Exemple:

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

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

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:

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.

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.

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.

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.

26

Rendez-vous

• Solution, utiliser deux sémaphores:

• Autre solution possible:

27

Rendez-vous mortel !

• Rendez-vous vers un interblocage:

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:

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:

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

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

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.

33

Barrière

• Code:

• Indice de solution:

34

Barrière

• Solution:

Porte tournante #1

Porte tournante #2

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.

36

File (d’attente)• Pour le meneur:

• Pour le suiveur:

37

File (d’attente)• Pour le meneur:

• Pour le suiveur:

• L’attente sera-t-elle raisonnable ?

38

File exclusive• Initialisation:

• Accès exclusif à la piste de dance !

39

File exclusive• Le meneur:

40

File exclusive• Le suiveur:

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.

42

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

43

Producteur/Consommateur• Initialisation:

44

Producteur/Consommateur• Producteur:

• Consommateur:

45

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

46

Producteur/Consommateur• Exemple en Java:

47

Producteur/Consommateur• Exemple en Java:

48

Producteur/Consommateur• Exemple en Java:

49

Producteur/Consommateur• Exemple en Java:

50

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

51

Producteur/Consommateur• Exemple corrigé en Java:

52

Producteur/Consommateur

53

Producteur/Consommateur• Exemple corrigé en Java:

54

• Exemple corrigé en Java:

Producteur/Consommateur

55

Producteur/Consommateur• Exécution sans bogue.

56

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

57

Producteur/Consommateur

58

Producteur/Consommateur

59

Producteur/Consommateur

60

Producteur/Consommateur

61

Producteur/Consommateur• Exécution sans bogue.

62

Producteur/Consommateur• 2e exécution.

63

Cycle de vie : « thread » Java

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…

Un diner de philosophes• Schéma:

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.

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.

Que font les philosophes• En code machine:

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

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:

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

comme suit:

• Qu’en pensez-vous ?

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 !

Ç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 !

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.