Le Scheduler
Transcription
Le Scheduler
http://www.sigl.epita.net Le Scheduler 24 juin 2002 David Bernat Salim Harouat Djibril Ndoye ACOO Pattern de conception : le singleton 25/02/02 slide 1 Sommaire • Rappel sur les Threads – – – – Qu’est ce qu’un Thread Les états d’un Thread Les priorités Synchronisation • Le Scheduler – – – – – – – – ACOO Synopsis Contexte Problème du séquencement Solution Structure Conséquences Exemples de code Java Modèle apparenté Pattern de conception : le singleton 25/02/02 slide 2 Rappel sur les Threads ACOO Pattern de conception : le singleton 25/02/02 slide 3 Qu’est ce qu’un Thread ? (1/3) • Processus = unité fonctionnelle • Un processus est l’entité d’exécution dans un système – Un processus = un programme en cours d’exécution Code Operating System Données Ressources ACOO Pattern de conception : le singleton 25/02/02 slide 4 Qu’est ce qu’un Thread ? (2/3) • À l’exécution Processus 1 Operating System Processus 2 Processus 3 Temps CPU Echanges de Données • Inconvénients – Coûteux en mémoire (code + données non partagées) – Lancement lent – Partage des ressources système difficile ACOO Pattern de conception : le singleton 25/02/02 slide 5 Qu’est ce qu’un Thread ? (3/3) • Un thread est un processus « interne » à un processus • Un thread partage les données , le code et les ressources de son processus • Il peut disposer de ses données propres Un Thread t1 t2 Code t3 t7 t4 t5 t6 ACOO Données Un processus Ressources Pattern de conception : le singleton 25/02/02 slide 6 Les états d’un Thread (1/2) Construction créé wait() sleep() suspend() start() actif resume() stop() endormi stop() Destruction ACOO Pattern de conception : le singleton 25/02/02 slide 7 Les états d’un Thread (2/2) • Créé – Créé comme n’importe quel objet java • Actif – Après la création , il est activé par start() qui lance run() – Ou encore lorsqu’il est réactivé par un resume () – Il est alors ajouté à la liste des Threads actifs qui sont exécutés en temps partagés • Endormi – Sleep(long milliseconds) endort le thread pendant l’intervalle de temps spécifié – Suspend() endort un thread et resume() pourra le réactiver • Mort – Quand run() a terminé son exécution ou pour un appel explicite à stop() ACOO Pattern de conception : le singleton 25/02/02 slide 8 Les priorités • Partage de la ressource CPU : Deux types de gestion existent dans les OS du marché • Time-Slicing – La ressource CPU est partagée équitablement entre Threads de même priorité – Exécution en paralléle • Préemption – Le partage du CPU doit être géré par l’utilisateur – Le premier Thread du groupe des Threads à priorité égale monopolise le CPU. Il faut qu’il le cède soit volontairement, soit involontairement pour que les autres threads puissent s’exécuter ACOO Pattern de conception : le singleton 25/02/02 slide 9 Synchronisation (en java) • Certains accès simultanés à une ressource peuvent être gênants • Gérer les concurrences d’accès à une méthode – Cela se fait en déclarant la méthode synchronized – Lorsqu’un thread exécute cette méthode sur un objet, un autre thread ne peut pas l’exécuter pour le même objet. – En revanche, il peut exécuter cette méthode pour un autre objet. • Contrôler l’accès à un objet – Déclarer l’objet synchronized – Ainsi l’accès à l’objet passé en paramètre de synchronized Object obj) est réservé à un thread et un seul. ACOO Pattern de conception : le singleton 25/02/02 slide 10 Le Scheduler ACOO Pattern de conception : le singleton 25/02/02 slide 11 Synopsis • Modèle de conception permettant de contrôler l’ordre de threads programmés pour exécuter une même portion de code, et ceci en utilisant un objet qui séquence explicitement les threads en attente • Le pattern Scheduler fournit un mécanisme permettant d’implémenter une règle de scheduling • Il est indépendant de toute règle spécifique de scheduling ACOO Pattern de conception : le singleton 25/02/02 slide 12 Contexte (1/2) • Vous êtes sur le point de concevoir un système de sécurité. Ce système sera composé de plusieurs points de verification(checkpoint) où chaque personne devra présenter son badge à travers un scanner pour pouvoir passer • Après avoir scanner le badge, le checkpoint autorise ou non la personne à passer • Lorsqu’un checkpoint scanne un badge, une entrée est imprimée sur un support de log ACOO Pattern de conception : le singleton 25/02/02 slide 13 Contexte (2/2) ACOO Pattern de conception : le singleton 25/02/02 slide 14 Probléme du séquencement • Que se passe t-il lorsque des personnes se présentent à plusieurs checkpoint au même moment ? • Pendant que l’imprimante imprime la première entrée les autres entrées sont en attente • Après la première entrée il n’ y a aucun moyen de savoir quelle entrée sera la prochaine à être imprimée • Les entrées de log peuvent ne pas être imprimées dans le même ordre qu’elles ont été envoyées à l’imprimante ACOO Pattern de conception : le singleton 25/02/02 slide 15 Solution • Pour s’assurer que les entrées du journal sont imprimées dans le même ordre que les actions se produisent, vous pouvez mettre chacune d’entre elles dans une queue et les imprimer dans le même ordre qu’elles arrivent ACOO Pattern de conception : le singleton 25/02/02 slide 16 Résolution à l’aide du Scheduler Sans le Scheduler ACOO Pattern de conception : le singleton Avec le Scheduler 25/02/02 slide 17 Structure (1/3) Structure pour le checkpoint ACOO Généralisation de la structure Pattern de conception : le singleton 25/02/02 slide 18 Structure (2/3) • La classe Request – Elle doit implémenter l’interface ScheduleOrdering. L’objet request encapsule une requête qui sera exécutée par un objet Processor • La classe Processor – Les instances de cette classe ont pour rôle d’exécuter les requêtes. Plusieurs requêtes peuvent leur être présentées mais elles ne peuvent en traiter qu’une seule à la fois. Elles délèguent donc au Scheduler la responsabilité d’ordonnancer les requêtes à traiter • La classe Scheduler – Cette classe ordonnance les requêtes que le processeur doit traiter. Dans un souci de réutilisabilité , le Scheduler n’a aucune connaissance du contenu de la classe Request. Cependant il accède à la classe request par l’intermédiaire de l’interface ScheduleOrdering qu’elle implémente. ACOO Pattern de conception : le singleton 25/02/02 slide 19 Structure (3/3) • La classe ScheduleOrdering – La classe Request implémente cette interface. – Elle permet d’ éviter une dépendance entre la requête et le processeur – Grâce à l’appel de la méthode ScheduleBefore , le Scheduler délègue la décision de savoir quelle requête sera la prochaine à être traitées , ce qui clairement favorise la réutilisabilité. ACOO Pattern de conception : le singleton 25/02/02 slide 20 Conséquences • Le pattern Scheduler offre un mécanisme pour explicitement contrôler des threads devant exécuter la même portion de code • Les régles de scheduling sont encapsulées dans la classe ce qui favorise la réutilisabilité • Le pattern Scheduler ajoute de considérables extensions au-delà des pré-requis pour l’appel à des méthodes synchronized ACOO Pattern de conception : le singleton 25/02/02 slide 21 Exemple de code class Printer { private Scheduler sched = new Scheduler(); public void print(JournalEntry j) { try { sched.enter(j); ... } catch (InterruptedException e) { } //try sched.done(); } //print(JournalEntry) } public class Scheduler { // Contains a reference to a Thread //when the scheduled resource // is busy; null when not private Thread runningThread; __________________________________ public void enter(ScheduleOrdering s) throws InterruptedException { Thread thisThread = Thread.currentThread(); // class Printer ACOO Pattern de conception : le singleton 25/02/02 slide 22 Modèle apparenté • L’implémentation du pattern Read/Write Lock utilise le Scheduler pour s’assurer d’un bon scheduling – Ce pattern est utilisé pour l’implémentation des opérations de lecture/écriture pour les livres accompagnés de CD notamment pour la gestion du mapping des positions (exercices ….) ACOO Pattern de conception : le singleton 25/02/02 slide 23 Questions ACOO Pattern de conception : le singleton 25/02/02 slide 24