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

Documents pareils