Chapitre II : La gestion des ressources Notions fondamentales
Eric.Leclercq@u-bourgogne.fr
D´epartement IEM
http://ufrsciencestech.u-bourgogne.fr http://ludique.u-bourgogne.fr/~leclercq
February 2, 2011
Plan
1 La notion de processus La gestion des ressources D´efinitions
La commutation de contexte
2 Implantation du m´ecanisme multitˆaches Multitˆache / multi-utilisateurs Classification des processus
3 Filiation des processus
Modes de lancement des processus Les processus l´egers
Le cycle de vie des processus
4 API thread de Java
5 La communication inter-processus Le diff´erents modes de communication
6 Le partage de ressources entre processus
Notion de processus concurrents, exclusion mutuelle
7 Autres mod`eles de Thread
La gestion des ressources
Comme nous l’avons vu dans les chapitres pr´ec´edents, une des premi`eres fonctions d’un SE est la gestion des ressources de l’ordinateur.
Nous allons ´etudier dans ce chapitre et les suivants les principes de la gestion :
du processeur
de la m´emoire centrale
des supports de stockage (disques, bandes etc.)
L’´ evolution de la notion de processus
La notion de processus est bas´ee sur celle de programme Le terme processus apparu dans les ann´ees 60 avec les embryons de syst`eme d’exploitation (moniteurs)
Pr´ehistoire : open shop,closed shop Traitement par lots : batch processing
Apparition des moniteurs permettant de lancer les programmes et de les g´erer : Disk Operating Systems
D´eveloppement de la multi-programmation puis de son
´
evolution naturelle vers le temps partag´e (time-sharing)
D´ efinitions
D´efinition : (Processus)
Un processus est un programme en ex´ecution
D´efinition : (SE multitˆaches)
Un syst`eme d’exploitation est dit multitˆaches s’il permet
d’ex´ecuter, apparemment simultan´ement, plusieurs programmes.
Ce fonctionnement est r´ealis´e en alternant rapidement l’ex´ecution de diff´erents processus c’est-`a-dire en effectuant un multiplexage temporel du processeur (chaque processus s’ex´ecute pendant une fraction de seconde)
L’ex´ecution des processus est entremˆel´ee
Par cons´equent, il ne s’agit pas r´eellement d’un traitement simultan´e sauf si la machine `a plusieurs processeurs
La commutation de contexte
D´efinition : (Commutation de contexte)
Le passage de l’ex´ecution d’un processus `a un autre est appel´e la commutation de contexte.
Lors d’une commutation de contexte, le syst`eme doit sauver l’´etat du processus en cours (le compteur ordinal (Instruction Pointer), les valeurs des registres, etc.) pour les restaurer plus tard.
Deux strat´egies peuvent ˆetre envisag´ees pour la commutation de contexte :
le mode coop´eratif le mode pr´eemptif
La commutation de contexte
Le multitˆache coop´eratif : chaque processus doit explicitement permettre `a un autre d’acc´eder au processeur
ce m´ecanisme a ´et´e utilis´e dans les SE Microsoft Windows jusqu’`a Windows 3.11 et dans Mac OS jusqu’`a Mac OS 9 cette approche simplifie l’architecture du SE mais pr´esente plusieurs inconv´enients :
si un des processus ne passe pas la main `a un autre processus, le syst`eme entier peut ˆetre bloqu´e ;
le partage des ressources (CPU, m´emoire, disque, etc.) peut ˆ
etre inefficace (IO bound)
La commutation de contexte
Le multitˆache pr´eemptif : le processeur signale au syst`eme d’exploitation que le processus en cours d’ex´ecution doit ˆetre mis en sommeil pour permettre l’ex´ecution d’un autre processus.
A la diff´` erence du multitˆache coop´eratif, la commutation de contexte est transparente.
D’une fa¸con g´en´erale la strat´egie de commutation choisie `a un impact ´enorme sur l’utilisation des ressources.
Une question subsiste : comment peut-on r´ealiser la commutation de contexte dans le mode pr´eemptif ?
Understanding the Linux Kernel, Third Edition, Daniel P. Bovet, Marco Cesati, Oreilly, November 2005, pp. 942
Linux System Programming, Robert Love, Oreilly September 2007, pp. 388
De nombreux chapitres disponibles enpreview sur le site http://www.oreilly.com
Gestion des ressources en environnement multitˆ ache
Probl´ematique d’une fa¸con g´en´erale il s’agit d’´etudier comment allouer des ressources aux processus, plus pr´ecisement :
comment identifier les processus ?
comment partager le CPU entre plusieurs processus ? comment restaurer l’´etat de chaque processus ?
comment allouer et g´erer la m´emoire attribu´ee aux processus ? comment g´erer les E/S dans un environnement multitˆaches ? Tr`es bon site de David Decotigny et Thomas Petazzoni :
http://sos.enix.org/fr/PagePrincipale
Multitˆ ache / multi-utilisateurs
Avec la multi-programmation, plusieurs programmes peuvent ˆ
etre trait´es en mˆeme temps : c-`a-d en cours d’ex´ecution et non termin´es
Ce proc´ed´e permet l’emploi simultan´e de la machine par plusieurs utilisateurs
Grˆace `a ce m´ecanisme chaque utilisateur a l’impression d’avoir la machine pour lui seul
La machine traite alors des processus qui sont chacun la propri´et´e d’utilisateur (humain ou virtuel)
Classification des processus
Un certain nombre de processus existent aussi longtemps que l’ordinateur est en fonctionnement
Exemple :
la gestion des connexions utilisateur, gestion des disques, le processusinit
A contrario, d’autres processus ont une dur´ee de vie limit´ee Exemple :
le processus de la commandedate n’existe que le temps de la commande
Certain processus ont un acc`es privil´egi´e au SE : propri´et´e de l’administrateur ou d’utilisateurs privil´egi´es
Certain processus sont sous le contrˆole des utilisateurs (user-mode) , d’autre sous le contrˆole du SE (ex´ecution en mode kernel)
Filiation des processus
De fa¸con g´en´erale le SE alloue un processus pour l’interface utilisateur (un shell par exemple) puis d’autres processus (fils du premier pour chaque commande utilisateur ou pour chaque programme lanc´e `a partir du shell
Ainsi, il se cr´ee une hi´erarchie de processus (p`ere fils) prenant la forme d’un arbre
jaromil ~ # pstree
init-+-adsl-connect---pppd---pppoe
|-6*[agetty]
|-bdflush
|-cron
|-cupsd
|-devfsd
|-gconfd-2
|-gdict-applet
|-gdm---gdm-+-X
| ‘-gnome-session---ssh-agent
|-gnome-netstatus
|-gnome-terminal-+-bash---evolution---evolution---8*[evolution]
| |-bash
| |-bash---ssh
| |-gnome-pty-helpe
| ‘-gnome-terminal---gnome-terminal
|-gweather-applet---gweather-applet---3*[gweather-applet]
Filiation des processus
Le syst`eme d’exploitation d’une machine personnelle g`ere une centaine de processus, celui d’un serveur plusieurs centaines Il existe une limite maximum fix´ee dans le noyau
Exemple :
pour un SE Linux le fichier concern´e est
include/linux/tasks.h, la variable NR TASKSfixe la limite `a 4096. Dans les noyaux 2.4 la limite est une fonction de la taille m´emoire disponible.
Les modes de lancement des processus
Un processus donn´e `a trois fa¸cons pour cr´eer un processus fils : clonage : processus parall`ele identique au p`ere mais ind´ependant ;
recouvrement par le fils ;
mise en route d’un processus fils ne comportant que certaines portions du processus parent.
Ces diff´erentes strat´egies permettent de fournir une mani`ere efficace pour organiser l’ex´ecution des applications dans le SE.
La majorit´e des SE multi-tˆaches propose les trois modes de cr´eation Comment sont g´er´ees les interactions p`ere fils et attente de
terminaison ?
Clonage
Clonage et communication : strat´ egies
Exemple de cr´ eation par clonage
L’appel syst`emefork()cr´ee un nouveau processus :
apr`es l’ex´ecution le pointeur d’instruction du fils et du p`ere sont positionn´es sur l’instruction suivante
fork()retourne la valeur 0 au fils
fork()retourne un entier non nul (identifiant du processus fils) au p`ere
Exemple :
id-fils=fork() if (id-fils==0)
traitements relatif au fils else
traitements relatif au p`ere
Exemple de cr´ eation par clonage
Exemple :
...
pid = fork();
switch(pid) {
case -1: /* erreur dans fork() */
fprintf(stderr,"error %d in fork: %s\n",errno,sys_errlist[errno]);
exit(errno);
case 0: /* on est dans le fils */
fprintf(stdout,"Dans le fils, pid = %d\n",getpid());
sleep(20);
break;
default: /* on est dans le pere */
fprintf(stdout,"Dans le pere, pid = %d\n",getpid());
sleep(20);
Exemple de cr´ eation par recouvrement
La cr´eation par recouvrement se fait au moyen d’une op´eration de la familleexec
Exemple : ...
printf("Exemple de recouvrement\n");
execve("/bin/ls", argv, envp);
printf("Ne s’affiche pas");
...
Lancement des processus
Ils existe diff´erent types de processus :
les d´emons(daemon) sont des processus cr´ees par le syst`eme hors contrˆole des utilisateur. Plus g´en´eralement dans les SE Unix, les d´emons
peuvent ˆetre relanc´es automatiquement si ils sont tu´es avoir comme parent direct le processusinit
les zombies : processus sans filiation directe, ne pouvant pas ˆ
etre tu´es
les processus utilisateurs, par exemple : applications, commandes, processus de communication cr´ee `a partir d’un d´emon
Note :
A l’origine le terme daemon signifiait Disk And Execution MONitor` c-`a-d un mini syst`eme d’exploitation pour contrˆoler les disques et l’ex´ecution des programmes.
Les processus l´ egers (Thread)
Certains SE proposent en plus de la notion de processus, un m´ecanisme de processus l´egers appel´esthread ou fil d’ex´ecution.
Ce m´ecanisme permet :
une cr´eation rapide des processus fils
une communication simplifi´ee entre un processus p`ere et ses enfants
Le processus p`ere et le ou les threads fils partagent la zone de donn´ees du programme.
Note :
La commandeps -efLpermet de visualiser les thread sous Linux.
qpshttp: // qps. kldp. net/, top sont des commandes plus synth´etiques.
Les processus l´ egers (Thread)
Les threads existent dans de nombreux SE : la famille UNIX Windows NT et 2000 WIN 9x et Me
Dans cette derni`ere famille (9x, Me), la notion de processus n’existe pas : les programmes lanc´es depuis l’interface graphique sont des threads.
Ainsi le syst`eme peut ˆetre rendu instable si un programme endommage la zone de m´emoire commune.
Impl´ ementation des Thread dans Java
La plateforme Java propose une machine virtuelle (MV) Java qui est un environnement d’´ex´ecution permettant d’´ex´ecuter des programmes Java ind´ependament du processeur hˆote et du syst`eme d’exploitation.
Une machine virtuelle r´ealise une abstraction des machines r´eelles : elle propose uninterpr´eteur de byte-code: langage
machine/instructions d’un processeur virtuel traduites dans en instructions pour le processeur r´eel
elle fournit un m´ecanisme d’interaction avec le syst`eme d’exploitation hˆote (Linux, Windows, MACOS X etc.) elle se comporte comme un syst`eme d’exploitation : gestion de la m´emoire dans la MV, gestion des processus l´egers, gestion des E/S
Impl´ ementation des Thread dans Java
La machine virtuelle est lanc´ee au moyen de la commandejava et elle devient un processus du syst`eme d’exploitation
Programme Java fichiers .class
code objet Chargeur de classes
Interpréteur Java
fichiers .class API Java
Système hôte Processus num X du système Machine virtuelle
(byte code)
traduction du byte code
Les fichiers.classsont les mˆemes quelquesoit le syst`eme d’exploitation : inutile de recompiler un application si on change de SE ou de mat´eriel.
Les Thread dans Java
Le langage Java propose deux modes de cr´eation des threads via l’h´eritage ou l’impl´ementation d’interface (h´eritage de
fonctionnalit´e) :
1 c l a s s W o r k e r 1 e x t e n d s T h r e a d { 2 p u b l i c v o i d run () {
3 S y s t e m . out . p r i n t l n ( " I Am a W o r k e r T h r e a d " ) ;
4 }
5 }
6
7 c l a s s W o r k e r 2 i m p l e m e n t s R u n n a b l e { 8 p u b l i c v o i d run () {
9 S y s t e m . out . p r i n t l n ( " I Am a W o r k e r T h r e a d " ) ;
10 }
11 } 12
13 p u b l i c c l a s s F i r s t {
14 p u b l i c s t a t i c v o i d m a i n ( S t r i n g a r g s []) { 15 // une p r e m i e r e f o r m e d ’ u t i l i s a t i o n 16 W o r k e r 1 t h r 1 = new W o r k e r 1 () ; 17 t h r 1 . s t a r t () ;
18 S y s t e m . out . p r i n t l n ( " I Am The M a i n T h r e a d " ) ; 19 // une s e c o n d e f o r m e d ’ u t i l i s a t i o n
20 R u n n a b l e r u n n e r = new W o r k e r 2 () ; 21 T h r e a d t h r d = new T h r e a d ( r u n n e r ) ; 22 t h r d . s t a r t () ;
23 }
24 }
Interaction de la MV avec le SE
1 i m p o r t j a v a . io .*;
2 p u b l i c c l a s s O S P r o c e s s {
3 p u b l i c s t a t i c v o i d m a i n ( S t r i n g [] a r g s ) t h r o w s I O E x c e p t i o n { 4 if ( a r g s . l e n g t h != 1) {
5 S y s t e m . err . p r i n t l n ( " U s a g e : j a v a O S P r o c e s s < command > " ) ; 6 S y s t e m . e x i t (0) ;
7 }
8
9 // a r g s [0] c o r r e s p o n d au p r o c e s s u s `a c r ´e e r ( c o m m a n d e ou p r o g r a m m e ) 10 P r o c e s s B u i l d e r pb = new P r o c e s s B u i l d e r ( a r g s [ 0 ] ) ;
11 P r o c e s s p r o c = pb . s t a r t () ; 12
13 // c r ´e e des f l u x p o u r les E / S
14 I n p u t S t r e a m is = p r o c . g e t I n p u t S t r e a m () ;
15 I n p u t S t r e a m R e a d e r isr = new I n p u t S t r e a m R e a d e r ( is ) ; 16 B u f f e r e d R e a d e r br = new B u f f e r e d R e a d e r ( isr ) ; 17 S t r i n g l i n e ;
18 w h i l e ( ( l i n e = br . r e a d L i n e () ) != n u l l) 19 S y s t e m . out . p r i n t l n ( l i n e ) ;
20 br . c l o s e () ;
21 }
22 }
Le cycle de vie des processus
Un processus peut avoir trois ´etats principaux : en train d’ˆetre ex´ecut´e : on dit qu’il est actif
en attente d’ˆetre ex´ecut´e : il est prˆet (toutes les ressources dont il a besoin sont disponibles)
bloqu´e : il est en attente de ressources ou d’un signal provenant d’un p´eriph´erique
mort : il n’existe plus et la place qu’il occupe dans le syst`eme va ˆetre lib´er´ee
Le cycle de vie des processus
Contrˆ ole des threads
Pour g´erer l’ex´ecution des threads les m´ethodes propos´ees sont : public void start() : permet de d´emarrer un thread, la m´ethode start, lance un nouveau thread dans le syst`eme dont le code `a ex´ecuter d´emarre par le run. Si vous invoquez la m´ethode runle code s’ex´ecute bien, mais aucun nouveau thread n’est lanc´e dans le syst`eme.
public void suspend() : permet d’arrˆeter temporairement un thread en cours d’ex´ecution.
public void resume() : permet de relancer l’ex´ecution d’un thread, au pr´ealable mis en pause viasuspend.
public void stop(): permet de stopper, de mani`ere d´efinitive, l’ex´ecution du thread. Une autre solution pour stopper un thread consiste `a simplement sortir de la m´ethode run.
Les diff´ erents modes de communication
Le terme IPC (Inter Process Communication) recouvre les modes de communication entre processus `a l’int´erieur du SE ou entre plusieurs SE sur des machines diff´erentes :
communication par message (Message Passing) m´emoire partag´e et buffering (Shared Memory)
appel de proc´edures / m´ethodes (Remote Procedure Call) socket pour les syst`emes distribu´es (chapitre 7)
communiquant via un r´eseau
Les deux mod` eles principaux de communication
segment partagé a
a a
Noyau Noyau
Processus A Processus A
Processus B
Processus B
Passage / ´ echange de messages
Deux fonctions de bases sont propos´ees pour la communication entre processus :
send(message) receive(message)
Si les processus P et Q souhaitent s’envoyer des messages un lien de communication est n´ecessaire :
Lien direct : send(P, message) etreceive(Q,message) Lien indirect avec boˆıte aux lettres : send(A, message) et receive(A,message)
Lien synchrone : envoi bloquant ou non, r´eception bloquante ou non
Lien bufferis´e avec file d’attente
M´ emoire partag´ ee et buffer
Une zone de m´emoire est d´eclar´ee comme partag´ee par un processus et peut ˆetre utilis´ee ensuite comme un moyen de communication entre plusieurs processus.
Les paradigme de coop´eration est le suivant : un processus producteur ´ecrit des informations dans le buffer qui sont consomm´ee par un processeus consommateur.
Le buffer peut ˆetre limit´e (bounded-buffer) ou s’´etendre en fonction des capacit´e m´emoire du syst`eme (unbounded-buffer)
Note :
Lors de l’utilisation de threads, la zone de m´emoire utilis´ee par le parent et partag´ee automatique avec les thread cr´ees.
M´ emoire partag´ ee et buffer en Java
Producteur Consommateur
Objet Java BoundedBuffer
référence référence
1 p u b l i c i n t e r f a c e B u f f e r { 2
3 // les p r o d u c t e u r s u t i l i s e r o n t c e t t e m ´e t h o d e 4 p u b l i c a b s t r a c t v o i d i n s e r t ( O b j e c t i t e m ) ; 5
6 // les c o n s o m m a t e u r s u t i l i s e r o n t c e t t e m ´e t h o d e 7 p u b l i c a b s t r a c t O b j e c t R e m o v e () ;
8 }
Appel de proc´ edure (RPC)
Ce m´ecanisme est essentiellement utilis´e pour des communications au travers d’un r´eseau.
On parle alors de RPC (Remote Procedure Call).
Un syst`eme similaire est propos´e pour les langages orient´es objet (Java RMI pour la langage Java).
Hors du domaine couvert par le cours de L2.
La notion de processus concurrents
D´efinition : (Ressource)
La notion de ressource dans les SE d´esigne tout ´el´ement qui est utile au d´eroulement d’un processus
Une ressource peut ˆetre :
Physique (si on se place du point de vue du syst`eme d’exploitation) : processeur, m´emoire, p´eriph´erique
Logique (si on se place du point de vue du programmeur) : fichier, variable, objet
La notion de processus concurrents
Plusieurs processus peuvent avoir besoin des mˆemes ressources.
D´efinition :
une ressource est dite partageable si elle peut ˆetre utilis´ee en mˆeme temps `a plusieurs processus. Une ressource est dite non partageable si elle doit ˆetre `a utilis´ee exclusivement par un seul processus.
Dans ce cas on dit que lesprocessus doivent ˆetre exclusion mutuellepour l’acc`es `a la ressource.
La notion verrouillage
Lorsqu’une ressource est partag´ee, si plusieurs processus acc`edent
`a la ressource, des incoh´erences peuvent en r´esulter : il faut un arbitre
Exemple :
des guichets automatiques de retrait d’argent : simulation du comportement
Comment ´eviter les situation de comp´etition sur des ressources non partageable ?
interdire l’acc`es partag´e `a la ressource : exclusion mutuelle interdire l’ex´ecution simultan´ee du cod´e acc´edant `a la ressource : section critique
La notion verrouillage
Pour r´esoudre ce probl`eme on utilise la notion de verrou (lock) deux op´erations sont propos´ees :
Verouiller(v)permet `a un processus d’acqu´erir un verrou, s’il n’est pas disponible, le processus est bloqu´e en attente du verrou
D´everouiller(v) permet de lib´erer un verrou
Les s´ emaphores
Les s´emaphores (Dijkstra 1965) proposent un m´ecanisme de contrˆole de la concurrence sous la forme d’un distributeur de jeton (n jetons).
Deux op´erations sont d´efinies :
P(s) pour obtenir un jeton : l’op´eration P est mise en attente jusqu’`a ce qu’une ressource soit disponible
V(s) pour restituer un jeton :
P et V signifient en n´eerlandaisProberen(tester) etVerhogen (incr´ementer).
Note :
Les op´erations P et V doivent ˆetre indivisibles : le SE leur garanti une ex´ecution atomique (pas de commutation de contexte).
Si il y a un seul jeton alors le s´emaphore est un verrou.
Les moniteurs
Hoare (1974) `a propos´e une solution de plus haut niveau bas´ee sur le concept de moniteur.
il s’agit d’une construction sp´ecifique au langage de programmation ;
un seul processus `a la fois peut ex´ecuter une fonction du moniteur ;
les moniteurs sont implant´es dans le langage Java via la notion de m´ethodes d´efinies avec le modificateursynchronized
Probl` eme des verrous mortels
Le probl`eme des verrous mortels traduit une situation
d’interblocage caus´e par l’acc`es `a une ressource non partageable.
On parle ´egalement d’´etreinte fatale.
...
Verouiller(R1) Verouiller(R2) utiliser R1 et R2 Déverouiller(R2) Déverouiller(R1) 1
...
Verouiller(R2) Verouiller(R1) utiliser R1 et R2 Déverouiller(R1) Déverouiller(R2) 2
Commutation de contexte
R2 P2
2
R1 1
P1
Solutions au probl` eme des verrous mortels
Il n’existe pas de solution r´eellement satisfaisante : Politique de l’autruche
Pr´evention
D´etection puis gu´erison
Synchronisation
La synchronisation des processus est un probl`eme plus large que celui de la concurrence.
La synchronisation des processus concerne les m´ethodes mises en oeuvre afin que les processus coordonent leurs activit´es.
Cette partie est abord´ee en TD et en TP au travers de l’ exemple de barri`ere de synchronisation.
Threads et langages fonctionnels
Les mod`ele de processus et d’´etat partag´e induit des probl`emes : de concurrence
de synchronisation de verrou mortels de famine
Sans partage d’´etat ces probl`emes n’existent plus.
Depuis 3 ans les langages fonctionnels pour les applications distribu´ees et multi-thread se d´eveloppent :
Erlang origine Ericson
Scala origine EPFL (objet et fuonctionnel) : fonctionne sur une machine virtuelle Java
Paradigme d’acteur
Definition
Un acteur (actor) est une abstraction logicielle qui impl´emente un protocole de passage de message permattant de g´erer la
concurrence.
Les acteurs n’ont pas d’´etat partag´e, ils communiquent par envoi et reception de messages.
This is a paradigm that provides a very different and much simpler concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and is avoiding all of the latter one’s problems with deadlocks, live locks, thread starvation etc.
The most well known and successful implementation of actors can be found in the Erlang language where it has been used to
implement extremely fault tolerant and massively concurrent systems (with hundreds of thousand simultaneous actors).
Paradigme d’acteur
Each actor has a mailbox in which it receives incoming messages and can use pattern matching on the messages to decide if a message is interesting and which action to take.
Les acteurs proposent leur services sous la forme de trait ( A trait is Scala’s mixin construct. Traits allows you to build up your components using so-called mixin composition which is something that can give you a very high grade of reuse and flexibility.
Exemple
Trait only defines a single method named status which prints out info about the enclosing instance. Then we subclass this mixin and define the ServerOne concrete server class (with the status method mixed in).
1 // s e r v e r s
2 t r a i t S e r v e r {
3 def s t a t u s = p r i n t l n ( " c u r r e n t s e r v e r : " + t h i s)
4 }
5 c l a s s S e r v e r O n e e x t e n d s S e r v e r
Instantiate the ServerOne class and see what the status method it will print out. Here we are doing it interactively through Scala’s REPL (read-eval-print-loop).
1 $ s c a l a - cp . 2
3 scala > val s e r v e r = new S e r v e r O n e 4 s e r v e r : S e r v e r O n e = S e r v e r O n e @ 7 b e 7 5 d 5
6 scala > s e r v e r s t a t u s
7 c u r r e n t s e r v e r : S e r v e r O n e @ 7 b e 7 5 d
Exemple : mise en place des ´ ev´ enements
Defining the messages to respond to.
Scala is using case classes which are similar to normal classes but with some enhancements:
Match on them, e.g. use pattern matching (similar to the one found in Erlang)
Create them without using new, the compiler generates getters and setters for the constructor arguments, equality is not based on object id but on meaning/content
We define two different messages : StatusandHotSwap.
1 // t r i g g e r s the s t a t u s m e t h o d 2 c a s e o b j e c t S t a t u s
3 // t r i g g e r s h o t s w a p - c a r r i e s the new s e r v e r to be h o t s w a p p e d to 4 c a s e c l a s s H o t S w a p ( s : S e r v e r )
Exemple : d´ efinition de l’acteur
Actor is a base class in the Scala library
Choose to either extend it explicitly or to create an anonymous actor through the actor {...} construct.
When subclassing the actor: implement the method called actwhich is the callback method that is invoked when the actor is started up.
Scala comes with two different implementations; one that is based on Java threads in that each actor is getting its own thread, while the other one is based on events and very lightweight allowing hundreds of thousands of actors to run simultaneously.
We will use the event-based version (which is done by using thereact method instead of thereceive method for receiving messages).
Exemple : d´ efinition de l’acteur
1 c l a s s S e r v e r A c t o r e x t e n d s A c t o r {
2 def act = {
3 p r i n t l n ( " s t a r t i n g s e r v e r a c t o r ... " ) 4 l o o p (new S e r v e r O n e )
5 }
6
7 def l o o p ( s e r v e r : S e r v e r ) {
8 r e a c t {
9 c a s e S t a t u s = >
10 s e r v e r . s t a t u s 11 l o o p ( s e r v e r ) 12
13 c a s e H o t S w a p ( n e w S e r v e r ) = >
14 p r i n t l n ( " hot s w a p p i n g c o d e ... " ) 15 l o o p ( n e w S e r v e r )
16
17 c a s e _ = > l o o p ( s e r v e r )
18 }
19 }
20 }
Exemple : d´ efinition de l’acteur
Create a companion object for our ServerActor class. In this object, which is a singleton but should be seen upon as a module for functions and immutable state, we define an immutable handle to an instantiated and started actor.
1 // a c t o r c o m p a n i o n o b j e c t 2 o b j e c t S e r v e r A c t o r {
3 val a c t o r = {
4 val a = new S e r v e r A c t o r 5 a . s t a r t ; a
6 }
7 }
Exemple : d´ efinition de l’acteur
1 $ s c a l a - cp . 2
3 scala > i m p o r t h o t s w a p . _ 4 i m p o r t h o t s w a p . _ 5
6 scala > val a c t o r = S e r v e r A c t o r . a c t o r 7 s t a r t i n g a c t o r ...
8 a c t o r : h o t s w a p . S e r v e r A c t o r = h o t s w a p . S e r v e r A c t o r @ 5 2 8 e d 7 9
10 scala > a c t o r ! S t a t u s
11 c u r r e n t s e r v e r : h o t s w a p . S e r v e r O n e @ 2 2 6 4 4 5 12
13 scala > c l a s s S e r v e r T w o e x t e n d s S e r v e r {
14 | o v e r r i d e def s t a t u s = p r i n t l n ( " h o t s w a p p e d s e r v e r : " + t h i s)
15 | }
16 d e f i n e d c l a s s S e r v e r T w o 17
18 scala > a c t o r ! H o t S w a p (new S e r v e r T w o ) 19 hot s w a p p i n g c o d e ...
20
21 scala > a c t o r ! S t a t u s
22 h o t s w a p p e d s e r v e r : l i n e 5 $ o b j e c t $ $ i w $ $ i w $ $ i w $ S e r v e r T w o @ b 5 5 6
Remote Actor : d´ efinition
RemoteActorobject in package scala.actors.remote.
This object provides methods to create and connect to remote actor instances.
A remote actor is uniquely identified by a Symbol. This symbol is unique to the JVM instance on which the remote actor is executed.
1 i m p o r t s c a l a . a c t o r s . _ 2 i m p o r t s c a l a . a c t o r s . A c t o r . _ 3 i m p o r t s c a l a . a c t o r s . r e m o t e . _
4 i m p o r t s c a l a . a c t o r s . r e m o t e . R e m o t e A c t o r . _ 5 c l a s s M y A c t o r e x t e n d s A c t o r {
6 def act () {
7 a l i v e ( 9 0 0 0 )
8 r e g i s t e r ( ’ myActor , s e l f ) 9 // la s u i t e
10 } 11 }
Remote Actor : utilisation
Connecting to a remote actor: obtain a remote reference to a remote actor running on machine myMachine, on port 8000, with name ’anActor,
Use select in the following manner.
The actor returned from select has type AbstractActor which provides essentially the same interface as a regular actor, and thus supports the usual message send operations
1 val m y R e m o t e A c t o r = s e l e c t ( N o d e ( " m y M a c h i n e " , 8 0 0 0 ) , ’ a n A c t o r )
