Terminazione

Consideriamo il seguente scenario: un attore parent genera un figlio child e gli assegna qualche compito. child inizia ad eseguire ci`o che gli `e stato comandato di fare e nel frattempo un attore a manda un messaggio al genitore che ne causa la terminazione. Chiamiamo gli attori parent e child rispettivamente p e c per semplicit`a di lettura e consideriamo la seguente configurazione:

[p 7→ ∅](β ↑ ∅ ↓ c)p{0} | [c 7→ ∅](β0↑ p ↓ ∅)c{e}) | [a 7→ ∅]C a{p!m; } β = {m ⇒ stop(p); c ! m⁰; ep}

β0 = {m0⇒ ec}

Facciamo alcune considerazioni sulla configurazione da cui partiamo per l’a-nalisi. Abbiamo un attore p con un figlio attivo c che sta eseguendo un corpo e. Abbiamo poi in parallelo un attore a che invia a p un messaggio m. Il compor-tamento β di p prevede che, alla ricezione di un messaggio m, l’attore esegua un comando stop su se stesso e successivamente invii un messaggio al figlio e prosegua con altre istruzioni ep. Questo non ha molto senso, ma ci `e utile per illustrare la nostra semantica. Notiamo inoltre che, quando c riceve m⁰, inizia l’esecuzione di una serie di istruzioni e_c.

Vediamo ora come evolve runtime la configurazione illustrata:

−→SEN D (νp)((νc)([p 7→ m](β ↑ ∅ ↓ c)p{0} | (β⁰ ↑ p ↓ ∅)c{ec}) | (νa)([a 7→ ∅]C a{0}))

−→RECEIV E(νp)((νc)([](β ↑ ∅ ↓ c)p{stop(p); c!m⁰; e_p} | [](β0↑ p ↓ ∅)c{e}) | (νa)([]C a{0})) −→ST OP −SELF (νp)((νc)([](0 ↑ ∅ ↓ c)p{c!m⁰; ep; stop(c)} | [](β⁰ ↑ p ↓ ∅)c{e}) | (νa)([]C a{0}) −→SEN D(νp)((νc)([](0 ↑ ∅ ↓ c)p{ep; stop(c)} | [c 7→ m⁰](β⁰ ↑ p ↓ ∅)c{ec}) | (νa)([]C a{0}))

Partendo da questa configurazione, che chiameremo F , mostriamo due pos-sibili andamenti dell’esecuzione:

Caso 1

Supponiamo di trovarci nella configurazione F e ipotizziamo che l’esecuzione passi a c. c `e ancora ignaro che il padre stia terminando, poich´e verr`a avvertito da p solo al termine dell’esecuzione di ep. Pu`o quindi ricevere il messaggio in mailbox e processarlo:

−→...(νp)((νc)([](0↑ ∅ ↓ c)p{ep; stop(c)} | [c 7→ m⁰](β⁰↑ p ↓ ∅)c{0}) | (νa)([]C a{0})) −→RECEIV E(νp)((νc)([](0 ↑ ∅ ↓ c)p{e_p; stop(c)} | [](β⁰ ↑ p ↓ ∅)c{ec}) | (νa)([]C a{0})) −→...(νp)((νc)([](0 ↑ ∅ ↓ c)p{ep; stop(c)} | [](β⁰↑ p ↓ ∅)c{0}) | (νa)([]C a{0}))

A questo punto l’unico attore della configurazione che pu`o evolvere `e p, che finir`a di eseguire il corpo e<sub>p</sub> e infine invier`a un comando stop al figlio.

−→...(νp)((νc)([](0 ↑ ∅ ↓ c)p{stop(c)} | [](β⁰ ↑ p ↓ ∅)c{0}) | (νa)([]C a{0})) −→ST OP (νp)((νc)([](0 ↑ ∅ ↓ c)p{0} | [](β⁰↑ p ↓ ∅)c{stop(c)}) | (νa)([]C a{0}))

c nell’ultima configurazione non stava eseguendo nulla quindi riceve imme-diatamente il comando di stop dal padre ed esegue una stop su se stesso. c non ha figli e non ha messaggi in mailbox, quindi setta semplicemente il proprio comportamento a 0 e termina avvisando il padre.

−→ST OP −SELF (νp)((νc)([](0 ↑ ∅ ↓ c)p{0} | [](0 ↑ p ↓ ∅)c{0}) | (νa)([]C a{0})) −→EN D(νp)((νc)([](0 ↑ ∅ ↓ ∅)p{0} | [c 7→ ∅]) | (νa)([]C a{0}))

A questo punto p non ha pi`u figli attivi, n´e corpo, n´e messaggi in mailbox da scartare, e ha comportamento vuoto, pu`o quindi terminare:

−→T OP −EN D(νp)((νc)[p 7→ ∅] | [c 7→ ∅]) | (νa)([]C a{0}))

Dal momento che i nomi p e c non appartengono ai nomi liberi di []C a{0}, Questa configurazione `e

Scriviamo ora questo programma in Scala Akka e verifichiamo che i passaggi mostrati con le riduzioni nel linguaggio A+ si verificano effettivamente anche in Akka. In particolare, per ottenere l’interleaving descritto e quindi poterlo verificare, inseriamo alcuni Thread.sleep in modo da far prendere la strada desiderata all’esecuzione. 1 i m p o r t akka . a c t o r . Actor 2 i m p o r t akka . a c t o r . A c t o r R e f 3 i m p o r t akka . a c t o r . Props 4 i m p o r t akka . a c t o r . ActorSystem 5 6 o b j e c t Stop e x t e n d s App{ 7 8 v a l s = ActorSystem ( ) 9

10 v a l p a r e n t = s . a c t o r O f ( Props ( new Actor {

11 v a l c h i l d = c o n t e x t . a c t o r O f ( Props ( new Actor {

12 d e f r e c e i v e = { 13 c a s e ” do ” => p r i n t l n ( ” c h i l d : . . . d o i n g s o m e t h i n g . . . ” ) 14 Thread . s l e e p ( 6 0 0 0 ) 15 p r i n t l n ( ” c h i l d : done ” ) } 16 o v e r r i d e d e f p o s t S t o p ( ) = { p r i n t l n ( ” c h i l d : t e r m i n a t i n g m y s e l f ” ) } 17 } ) ) ; 18 19 c h i l d ! ” do ” 20 21 d e f r e c e i v e = { 22 c a s e ”m” => p r i n t l n ( ” p a r e n t : s t o p p i n g m y s e l f ” ) 23 c o n t e x t . s t o p ( s e l f ) 24 p r i n t l n ( ” p a r e n t : s e n d i n g message t o c h i l d ” ) 25 c h i l d ! ” do ” 26 p r i n t l n ( ” p a r e n t : w a i t i n g a l i t t l e ” ) 27 Thread . s l e e p ( 1 2 0 0 0 ) 28 p r i n t l n ( ” p a r e n t : f i n i s h ” ) 29 } 30 o v e r r i d e d e f p o s t S t o p ( ) = { p r i n t l n ( ” p a r e n t : t e r m i n a t i n g m y s e l f ” ) } 31 32 } ) ) 33

34 v a l a = s . a c t o r O f ( Props ( new Actor {

35 Thread . s l e e p ( 3 0 0 0 )

36 p a r e n t ! ”m”

37

39 } ) )

40 }

Notiamo che nel codice Scala Akka, per tenere traccia della terminazione degli attori, utilizziamo il metodo postStop, che viene invocato quando un’i-stanza di attore termina.

Output 1 c h i l d : . . . d o i n g s o m e t h i n g . . . 2 p a r e n t : s t o p p i n g m y s e l f 3 p a r e n t : s e n d i n g message t o c h i l d 4 p a r e n t : w a i t i n g a l i t t l e 5 c h i l d : done 6 c h i l d : . . . d o i n g s o m e t h i n g . . . 7 c h i l d : done 8 p a r e n t : f i n i s h 9 c h i l d : t e r m i n a t i n g m y s e l f 10 p a r e n t : t e r m i n a t i n g m y s e l f

Analizziamo l’output. La situazione `e quella descritta precedentemente: child sta eseguendo il proprio corpo (e nel corrispondente programma A+), nel frattempo parent esegue il comando context.stop(self). In accordo con la regola (STOP-SELF) parent finisce di processare il messaggio corrente, quin-di invia un messaggio a child e poi continua ad eseguire mettendosi in sleep per un po’ (corrispondente all’espressione ep del programma A+). A questo punto l’esecuzione passa a child che, dal momento che parent non ha ancora finito di eseguire il suo corpo, non sa ancora che parent sta terminando, prende dalla mailbox un altro messaggio e lo processa.

Quando parent termina la sleep, invia il comando di stop a child che pu`o procedere alla sua terminazione. Solo quando child `e terminato anche parent termina.

L’output del programma Scala Akka conferma quanto mostrato dalla ridu-zione del programma A+: l’attore parent, dopo aver eseguito un comando stop su se stesso, finisce di processare il messaggio corrente prima di avviare effet-tivamente la propria terminazione, ovvero inviare ai figli un comando di stop. Questo `e dimostrato dal fatto che child riesce a processare anche il secondo messaggio (inviatogli da parent dopo che questo si `e stoppato) e spiega perch´e `e corretto usare e; (stop(ci))i∈I nella regola (STOP-SELF). Inoltre l’output con-ferma che parent non termina prima che tutti i suoi figli (in questo caso il solo figlio child) siano terminati.

Caso 2

Supponiamo di trovarci nella configurazione F sopra descritta e supponiamo questa volta che p finisca di processare tutto il suo corpo prima che c termini l’esecuzione di ec. L’evoluzione del programma `e la seguente:

(νp)((νc)([](0 ↑ ∅ ↓ c)p{e_p; stop(c)} | [c 7→ m⁰](β⁰↑ p ↓ ∅)c{ec}) | (νa)([]C a{0})) −→...(νp)((νc)([](0 ↑ ∅ ↓ c)p{stop(c)} | [c 7→ m⁰](β⁰↑ p ↓ ∅)c{ec}) | (νa)([]C a{0})) −→ST OP (νp)((νc)([](0 ↑ ∅ ↓ c)p{0} | [c 7→ m⁰](β⁰ ↑ p ↓ ∅)c{e_c; stop(c)}) | (νa)([]C a{0})) A questo punto c `e l’unico attore che pu`o proseguire perch´e sia a che p hanno

corpo nullo e mailbox vuota.

−→...(νp)((νc)([](0 ↑ ∅ ↓ c)p{0} | [c 7→ m⁰](β⁰↑ p ↓ ∅)c{stop(c)}) | (νa)([]C a{0})) −→ST OP −SELF (νp)((νc)([](0↑ ∅ ↓ c)p{0} | [c 7→ m⁰](0 ↑ p ↓ ∅)c{0}) | (νa)([]C a{0})) Ora c non pu`o ancora terminare perch´e ha dei messaggi in mailbox. Pu`o per`o applicare la regola (JUNK) per svuotare la mailbox e quindi terminare. −→J U N K (νp)((νc)([](0 ↑ ∅ ↓ c)p{0} | [c 7→ ∅](0 ↑ p ↓ ∅)c{0}) | (νa)([]C a{0})) −→EN D(νp)((νc)([](0 ↑ ∅ ↓ ∅)p{0} | [c 7→ ∅]) | (νa)([]C a{0}))

A questo punto p non ha pi`u figli attivi e pu`o terminare: −→T OP −EN D (νp)((νc)([p 7→ ∅] | [c 7→ ∅]) | (νa)([]C a{0})) ≡ (νa)([]C a{0})

Codice Scala Akka

Per provare che il comportamento descritto `e quello del programma in Scala Akka apportiamo le seguenti modifiche al codice, in modo da far prendere la strada desiderata all’esecuzione. La funzione receive di child diventa:

1 d e f r e c e i v e = {

2 c a s e ” do ” => p r i n t l n ( ” c h i l d : . . . d o i n g s o m e t h i n g . . . ” )

3 Thread . s l e e p ( 1 2 0 0 0 )

4 p r i n t l n ( ” c h i l d : done ” )

mentre quella di parent: 1 d e f r e c e i v e = { 2 c a s e ”m” => p r i n t l n ( ” p a r e n t : s t o p p i n g m y s e l f ” ) 3 c o n t e x t . s t o p ( s e l f ) 4 p r i n t l n ( ” p a r e n t : s e n d i n g message t o c h i l d ” ) 5 c h i l d ! ” do ” 6 } Output 1 c h i l d : . . . d o i n g s o m e t h i n g . . . 2 p a r e n t : s t o p p i n g m y s e l f 3 p a r e n t : s e n d i n g message t o c h i l d 4 c h i l d : done 5 c h i l d : t e r m i n a t i n g m y s e l f 6 p a r e n t : t e r m i n a t i n g m y s e l f

Dall’output possiamo vedere che parent inizia il processo di terminazione mentre child sta processando un messaggio. Come abbiamo detto questo com-porta l’invio di un segnale di stop al figlio. Successivamente parent invia al figlio un messaggio. Quando child finisce di processare il messaggio corrente ha in mailbox il messaggio inviato dal padre, ma lo scarta e termina, in analogia con la riduzione descritta per il programma in linguaggio A+.