În știința calculatoarelor, modelul Actor este un model matematic de calcul concurent care tratează "actorii" ca primitivele universale de calcul digital concurent: un actor poate lua decizii locale, crea mai mulți actori, trimite mai multe mesaje, și determina cum să răspundă la următorul mesaj primit. Modelul Actor a fost creat în 1973. A fost folosit și ca framework pentru o înțelegere teoretică a calculului, și ca bază teoretică pentru mai multe aplicații practice a sistemelor concurente.

Istoric

Spre deosebire de modelele de calcul anterioare, modelul Actor a fost inspirat din fizică incluzând relativitatea generală și mecanica cuantică. A fost de asemenea influențat de limbaje de programare ca Lisp, Simula și versiunile de început ale Smalltalk, dar și de sisteme bazate pe capabilitate și comutație de pachete. Dezvoltarea sa a fost "motivată de un prospect de mașini de calcul înalt paralelizate conținând zeci, sute și chiar mii de microprocesoare independente, fiecare cu propria memorie locală și procesoare de comunicație, comunicând printr-o rețea de înaltă performanță." De atunci, evoluția concurenței masive prin arhitecturi de calculatoare multi-core a retrezit interesul în modelul Actor.

Urmând publicația din 1973 a lui Hewitt, Bishop, și Steiger, Irene Greif a dezvoltat o semantică operațională pentru modelul Actor ca parte a cercetării sale doctorale. Doi ani mai târziu, Henry Baker și Hewitt au publicat un set de legi axiomatice pentru sistemele Actor. Alte momente majore în istorie includ dizertația lui William Clinger's, în 1981, introducând o semantică denotațională bazată pe domenii de putere și dizertația lui Gul Agha din 1985 care a dezvoltat mai departe modelul semantic complementar modelui lui Clinger. Aceasta a rezultat în dezvoltarea completă a teoriei modelului Actor.

Însă cea mai importantă implementare în software a fost facută de Russ Atkinson, Beppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman, Carl Manning, Tom Reinhardt, Richard Steiger, și Dan Theriault, în Message Passing Semantics Group la Massachusetts Institute of Technology (MIT). Grupurile de cercetare conduse de Chuck Seitz la California Institute of Technology (Caltech) și Bill Dally la MIT au construit arhitecturi ce au dezvoltat mai departe transferul mesajelor în model. Vedeți Implementarea modelului Actor.

Cercetări asupra modelului Actor au fost întreprinse la Caltech Computer Science, Kyoto University Tokoro Laboratory, MCC, MIT Artificial Intelligence Laboratory, SRI, Stanford University, University of Illinois at Urbana-Champaign Open Systems Laboratory , Pierre and Marie Curie University (University of Paris 6), University of Pisa, University of Tokyo Yonezawa Laboratory and elsewhere.

Concepte Fundamentale Modelul Actor adoptă filosofia ca totul este un actor. Acesta este similar cu filosofia totul este un obiect folosită de unele dintre limbajele de programare, dar diferă prin faptul că software-ul orientat pe obiect este de obicei executat secvențial, în timp ce modelul Actor este prin esență concurent.

Un actor este o entitate computațională care, în răspuns la un mesaj recepționat, poate în mod concurent să: trimită un număr finit de mesaje la alți actori; creeze un număr finit de actori noi; stabilească comportamentul folosit la următorul mesaj pe care îl recepționează;

Nu există o ordine precisă pentru acțiunile de mai sus și pot fi efectuate în paralel.

Decuplarea emițătorul de la comunicațiile trimise a fost o evoluție fundamentală către modelul Actor asigurând comunicația asincronă și structurile de control ca modele de mesaje transferate.Carl Hewitt. Viewing Control Structures as Patterns of Passing Messages Journal of Artificial Intelligence. June 1977.

Receptorii acestor mesaje sunt identificați după adresă, câteodată numită "mailing address". Deci un actor poate doar comunica cu actori ale căror adrese le cunoaște. Poate obține acestea dintr-un mesaj recepționat sau dacă adresa este pentru un actor care s-a creat singur.

Modelul Actor este caracterizat de concurența calculelor prin esența între și printre actori, crearea dinamică de actori, includerea adreselor de actori în mesaje și interacțiunea numai prin direct asynchronous message passing (comunicare asincronă) fără restricție asupra ordinii sosirii mesajelor.

Systeme Formale De-a lungul anilor, mai multe sisteme formale diferite s-au dezvoltat și au început să permită gândiri despre sistemele în modelul Actor. Acestea includ:

Semantica Operațională Legi pentru sisteme Actor Semantica Denotationala Semantica de tranziție

Există de asemenea și formalisme care nu sunt compatibile total cu modelul Actor prin faptul că nu formalizează expedierea garantată a mesajelor incluzând următoarele ( Vedeți Attempts to relate Actor semantics to algebra and linear logic) (Încercări de a relaționa semantica modelului Actor cu algebra și logica liniară): Mai multe algebre Actor diferite Logica lineară

Aplicații

Modelul actor poate fi folosit ca un framework pentru modelare, înțelegerea și gândire despre o mare arie de sisteme concurente. De exemplu: Poșta Electronică (e-mail) poate fi modelat ca un sistem Actor. Conturile sunt modelate ca Actori și email addresses ca adrese Actor. Servicii Web pot fi modelate cu noduri SOAP ca adrese Actor. Obiecte cu locks (de exemplu Java și C#) pot fi modelate ca Serializatoare, cu condiția ca implementarea lor să fie ca mesajele să sosească continuu ( de exemplu prin stocarea într-o coadă internă). Un serializator (serializer) este un tip important de Actor definit de proprietatea că e disponibil în mod continuu pentru sosirea noilor mesaje. Orice mesaj trimis către un serializator este garantat să ajungă. Notarea Test și Controlul Testului (Testing and Test Control Notation (TTCN) ), ambele TTCN-2 și TTCN-3, urmează un model Actor de aproape. În TTCN, un Actor este o componența de test: ori un component de test în paralel (PTC - parallel test component) ori un component de test în principal ( MTC - main test component). Componentele de test pot trimite și recepționa mesaje către și dinspre parteneri de la distanță (componente test la peer sau interfețe de sisteme de test), ultimul fiind indentificat de adresa sa. Fiecare component de test are o diagramă de comportament legată de el. Componentele de test rulează în paralel și pot fi create dinamic de componentele de test părinte. Constructorii de limbă conținuți de ei asigură definirea acțiunilor ce trebuie întreprinse când un mesaj este recepționat de la o coadă de mesaje internă,

Modele precedente modelului Actor Modelul actor se bazează pe modele anterioare de calcul.

Calculul Lambda

Calculul Lambda al lui Alonzo Church poate fi văzut ca cel dintâi limbaj de programare bazat pe transmiterea mesajelor ( message passing ). (vezi Hewitt, Bishop, and Steiger 1973; Abelson and Sussman 1985). De exemplu, expresia lambda de mai jos implementează o structură de arbore de date când îi sunt furnizați parametrii pentru un leftSubTree și un rightSubTree. Când acestui arbore îi este dat un mesaj parametru "getLeft", el returnează leftSubTree și invers, dacă primește "getRight", returnează rightSubTree.

λ(leftSubTree,rightSubTree) λ(message) if (message == "getLeft") then leftSubTree else if (message == "getRight") then rightSubTree

Oricum, semantică calcului lambda este exprimată folosind substitutia de variabile în care valorile parametrilor sunt substituite în cod prin invocarea expresiilor lambda. Modelul de substituție este nepotrivit pentru concurență deoarece nu îngăduie capacitatea partajarii resurselor de schimbat. Inspirat de calculul lambda, interpreter pentru limbajul de programare Lisp face uz de o structură de date numită mediu în felul că valoarea parametrilor nu trebuie să fie substituită în corpul expresiilor lambda invocate. Această a dat voie la partajarea efectelor secundare cum ar fi updatarea structurilor de date partajate dar nu a îngăduit și concurența.

Simula

Simula 67 a fost un pioner în transmiterea mesajelor pentru calcule, motivat de aplicațiile de simulare a evenimentelor discrete. Aceste aplicații erau mari și nemodulare în limbile de simulare de dinainte. La fiecare pas, un larg și central program trebuia să fie rulat și să actualizeze fiecare obiect de simulare care se schimbau în funcție de stare obiectele care interacționau la fiecare pas. Kristen Nygaard și Ole-Johan Dahl au dezvoltat idea (prima dată descrisă în IFIP workshop în 1967) ca având metode pe fiecare obiect care își updateaza propria stare locală bazându-se pe mesaje de la alte obiecte. În adiție, au introdus o structură de clare pentru obiecte cu mostenire. Inovația lor a îmbunătățit în mod considerabil modularitatea programelor.

Totuși, Simula folosea o structură de control coroutine (corutină) în loc de concurență adevărată.

Smalltalk

Alan Kay a fost influențat de transmiterea mesajelor în invocarea direcției modelelor prin Planificator în dezvoltarea Smalltalk-71. Hewitt a fost interesat de Smalltalk-71 dar a renunțat datorită complexității comunicării care includerea invocări cu mai multe câmpuri incluzând global, sender, receiver, reply-style, status, reply, operator selector, etc.

În 1972 Kay a visitat MIT și discutat ideile sale despre Smalltalk-72 construind limbajul de programare Logo ajutat de Seymour Papert și modelul "little person" (persoană mică), model de calcul utilizat în predarea programării copiilor mici. Totuși, transmiterea mesajelor în Smalltalk-72 era destul de complex. Codul în acest limbaj era vizionat de interpretor ca simple stream-uri de tokene. După cum Dan Ingalls a descris mai târziu:

Primul (token) întâlnit (într-un program) era folosit într-un context dinamic, pentru a determina receptorul mesajelor următoare. Căutarea numelui începe cu dicționarul claselor a activării prezente. De acolo se mișcă către expeditorul acelei activări și continuă pe lanțul expeditorului. Când o legătură este găsită potrivită pentru token, valoarea lui devine receptorul noului mesaj, și interpretorul activează codul pentru clasă al acelui obiect.

De aici și modelul de transmitere a mesajelor din Smalltalk-72 este legat la un model mașina particulară și o sintaxă de limbaj de programare care nu se dedică concurenței.

Versiuni anterioare de Smalltalk au urmat calea folosirii metodelor virtuale din Simula în structura message-passing programelor. Totusi, Smalltalk-72 a folosit primitivele ca integrii, numere în format virgulă mobilă, iar etc ca obiecte. Autorii Simula au considerat transformarea astfel a primitelor dar s-au abținut să le folosească pe scară largă din motive de eficiență. Java la început a folosit un expedient având ambele primitive și versiuni de obiect ca integrii, numere format virgula mobilă, etc. Iar limbajul de programare C# (și verisiuni mai recente de java, începând cu Java 1.5) au adoptat soluția mai puțin elegantă de a folosi boxing și unboxing, o variantă folosită mai devreme în implementările Lisp.

Sistemul Smalltalk a devenit foarte influent, inovând în afișările bitmap, calcul personal (PC), interfețe de browser de clase și multe alte căi. Pentru detalii vizitați Kay's The Early History of Smalltalk. Între timp, eforturile pentru modelul Actor la MIT au rămas concentrate pe dezvoltarea științei și ingineriei la nivel înalt de concurență. (Vedeți cartea lui Jean-Pierre Briot pentru idei care au fost dezvoltate mai tărziu despre încorporarea anumitor tipuri de concurență Actor în ultimele versiuni de Smalltalk)

Rețele Petri Înainte de apariția modelului Actor, Rețelele Petri erau larg folosite în modelul de calcul nondeterministic. Oricum, ele erau larg cunoscute ca având limitări importante: ele modelau flowul de control dar nu și cel de date în consecință, ele nu erau composabile, deci erau limitate în modularitate.

Hewit a accentuat o altă dificultate a rețelelor Petri: Acțiunea simultană.