M2-GamaGora. Programmation Multi-Thread - partie 1. J.C. Iehl. November 13, 2008

Transcription

1 Programmation Multi-Thread - partie 1 November 13, 2008

2 pourquoi ça ne marche pas? et alors? introduction aux threads

3 threads : pourquoi ça ne marche pas? et alors? un nouveau point d entrée (une fonction du programme) : void *run( void *param ) { printf("je suis un thread"); return NULL; } qui s éxécute indépendament des autres (main + les autres threads).

4 pourquoi ça ne marche pas? et alors? threads : à éxécuter plusieurs fonctions en même temps, à réaliser plusieurs tâches en même temps.

5 pourquoi ça ne marche pas? et alors? POSIX threads : création (par le père / thread principal) pthread t tid; pthread create(&tid, NULL, run, param); attendre la fin d un thread (dans le père) pthread join(tid, NULL); terminer un thread (dans le fils) pthread exit(null);

6 POSIX threads : exemple pourquoi ça ne marche pas? et alors? # include < pthread.h > void *run ( void * param ) { std :: printf (" run!\n"); return NULL ; } int main ( void ) { pthread_t t; pthread_create (&t, NULL, &run, NULL ); pthread_join (t, NULL ); return 0; }

7 pourquoi ça ne marche pas? et alors? threads en C++ : en cours de standardisation, pour l instant, boost::thread # include <boost / thread.hpp > void run ( ) { std :: printf (" run!\n"); } int main ( void ) { boost :: thread t(& run ); t. join (); return 0; }

8 pourquoi ça ne marche pas? et alors? pourquoi ça ne marche pas? tous les threads crées travaillent en même temps. plusieurs threads modifient la même variable... thread A : i++ thread B : i++ quelle est la valeur de i? remarque: i++ est exécuté comme i= i+1, c est à dire une lecture, puis une addition, puis une écriture.

9 pourquoi ça ne marche pas? et alors? et alors? un algorithme travaillant sur des variables manipulées par plusieurs threads ne fonctionne pas! solution directe interdire à plusieurs threads de modifier la même variable simultanément, il faut arbitrer l exécution des threads, certaines parties de code ne seront exécutées que par un seul thread, les autres attendent que la modification soit terminée. ces instructions s appelent une section critique.

10 section critique définition instructions manipulant une variable partagée par plusieurs threads. remarque lire une constante ne constitue pas une section critique. par contre, si une variable est lue par certains threads et modifiée par d autres, ces manipulations forment une section critique.

11 exclusion mutuelle définition bloquer temporairement l exécution des threads, pour n en laisser qu un seul actif dans la section critique. mutex / verrou un objet de synchronisation qui permet de réaliser une exclusion mutuelle lors de l exécution d une section critique.

12 mutex et conditions

13 mutex les mutex sont des verrous pour arbitrer l éxécution des sections critiques. utiliser un mutex garanti l exclusion mutuelle des threads qui essayent de bloquer le même verrou. grosse responsabilité : relacher le verrou pour réveiller le thread qui attend... si le mutex est relaché, un thread peut le bloquer, sinon, le thread attend (que le mutex soit relaché par le thread qui l a bloqué)

14 conditions permet d attendre dans une section critique (?). grosse responsabilité : réveiller le thread qui attend...

15 à arbitrer l éxécution d une section critique par plusieurs threads. exemple 1 thread ajoute des éléments dans un tableau (et un autre enlève des éléments, en même temps). que se passe-t-il lorsque le tableau est plein? il faut attendre qu une case se libère, et c est un autre thread qui supprime des éléments du tableau... à quel moment sait-on que le tableau est plein? (dans la section critique!)

16 comment ça marche (POSIX)? pthread mutex create() / pthread mutex destroy() pthread mutex lock() pthread mutex unlock() pthread cond create() / pthread cond destroy() pthread cond wait() pthread cond signal() init() init() le système ne sait pas pourquoi le programmeur utilise un mutex ou une condition donc c est au programmeur de faire correctement son travail.

17 conditions (POSIX) détails sur cond wait() int pthread cond wait(pthread cond t *cond, pthread mutex t *mutex); le mutex doit être bloqué, cond wait() ne s utilise que dans une section critique!

18 comment ça marche (boost::)? # include <boost / thread.hpp > boost :: mutex mutex ; int compteur = 0; void compteur ( ) { boost :: mutex :: scoped_lock lock ( mutex ); int i= compteur ++; std :: printf ("%d\n", i); }

19 conditions (boost::) # include <boost / thread.hpp > boost :: mutex mutex ; boost :: condition pas_plein ; boost :: condition pas_vide ; int compteur = 0; void ajouter ( ) { boost :: mutex :: scoped_lock lock ( mutex ); while ( compteur > 10) pas_plein. wait ( lock ); } compteur ++; pas_vide. notify_all ();

20 conditions, a priori, attendre dans une section critique (mutex bloqué), empêche les autres threads de bloquer le mutex : pour travailler sur les variables partagées, et modifier la condition... (cf. compteur--) quand un thread doit attendre dans une section critique, seuls les autres threads peuvent l aider!

21 conditions, mais si, ça marche! pthread cond wait() et boost::condition::wait() font plusieurs choses : le mutex est relaché (pour permettre aux autres threads de le bloquer à leur tour), l activité du thread est suspendue (par le système), le thread sera réveillé lorsqu un thread aura signalé que la condition a changée, lorsque le thread se réveille, le mutex doit être à nouveau bloqué par le thread, puisqu il est dans une section critique!

22 conditions... les threads doivent coopérer : dans l exemple, le thread qui ajoute des éléments dans le tableau, doit attendre une place libre, c est le thread qui enlève des élements du tableau qui a la responsabilité de le prévenir. et c est réciproque!

23 Lecteurs et Rédacteurs Interblocages synchronisation : lecteurs et rédacteurs comment un thread accède-t-il à une variable? lecture, écriture / modification. comment arbitrer les accès? bloquer toutes les modifications... pas le choix, bloquer toutes les lectures, c est simple, mais... pas de bonne raison de les bloquer s il n y a pas de modification en cours. l exclusion mutuelle réduit l interêt des threads, pourquoi?

24 Lecteurs et Rédacteurs Interblocages synchronisation : lecteurs et rédacteurs contrôle d accès, arbitrage 2 types d accès (lecture, écriture), 1 seul type d accès à la fois, tous les lecteurs, ou, un seul rédacteur, exclusion entre les lecteurs et le rédacteur, (exclusion entre les rédacteurs).

25 Lecteurs et Rédacteurs Interblocages synchronisation : lecteurs et rédacteurs à quel moment autoriser / bloquer une lecture? à quel moment autoriser / bloquer une écriture? quel est l interêt de faire cette distinction?

26 Lecteurs et Rédacteurs Interblocages synchronisation : quelques problèmes malgré toutes ces précautions (mutex, conditions, etc), il reste des problèmes. exemple un carrefour à priorité à droite avec 4 embranchements, 4 voitures se présentent en même temps...

27 Lecteurs et Rédacteurs Interblocages synchronisation : quelques problèmes solution simple 1 seul verrou, exclusion mutuelle, 1 seule voiture sur le carrefour solution intuitive autoriser plusieurs voitures à traverser le carrefour 4 verrous, 1 par embranchement, A, B, C et D

28 Lecteurs et Rédacteurs Interblocages synchronisation : quelques problèmes cycle dans le bloquage des verrous la dernière voiture à bloquer un verrou bloque le carrefour / programme, A, B, C sont déja bloqués, A attend B, B attend C et C attend D, si D attend A, il y a un cycle et le programme se bloque. notion de graphe de réservation / dépendance.

29 Lecteurs et Rédacteurs Interblocages synchronisation : quelques problèmes plusieurs idées de solutions ne pas autoriser plus de 3 voitures sur le carrefour, blocage des verrous en 2 étapes : vérifier l état de tous les verrous et les bloquer s ils sont tous disponibles, sinon attendre.

30 Lecteurs et Rédacteurs Interblocages synchronisation : conclusion il y a toujours de l exclusion mutuelle citation c est mal... la différence est la durée de l accès exclusif : soit toute l action est en accès exclusif (et ça, c est mal), soit la prise de décision se fait en accès exclusif, mais pas l action (c est mieux!) la meilleure synchronisation est l absence de synchronisation! (mais ce n est pas toujours possible... )