Calvin Lin Abstract Programming for scalable multicores with more focus on loc ality has increased the interest in message passing models of programming One of the well known theoret ical and practical models of message passing is the actor model Th ID: 20677
Download Pdf The PPT/PDF document "Actor Oriented Programming in Chapel Ami..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
ActorOrientedProgramminginChapelAminShaliDepartmentofComputerScience,UniversityofTexasatAustinSpring2010CS380P,Prof.CalvinLinAbstractProgrammingforscalablemulti-coreswithmorefocusonlocalityhasincreasedtheinterestinmessagepassingmodelsofprogramming.Oneofthewellknowntheoreticalandpracticalmodelsofmessagepassingistheactormodel.Thereareamultitudeofactororientedlibrariesandlanguages,eachofwhichimplementsomevariantofactorsemantics.AmongthelanguagesandthelibrariesbasedontheactorsemanticswecannameErlang,SALSA,ElanguageandAxum.Chapelisaglobalviewlanguageandhavenonotionofactorandmessagepassing.However,ittendstobeagenerallanguageforparallelandconcurrentprogrammingandwantstoprovidesimplemeansfortheprogrammertoimplementaparallelprogram.InthisworkwewanttostudyandanalyzesomequestionsregardingactorsintheChapellanguage.Inparticularwewanttoanswerthefollowingquestions:WhydoweneedactorsemanticsinChapel?InparticularwewanttoseeifwereallyneedsomethinglikeactorsinChapel.WhataretheadvantagesanddisadvantagesofhavingactorsemanticsimplementedinChapel?Byansweringthisquestionwewillseewhatisthepro tofhavingactorsforprogrammer.Alsowetrytoseewhatisthecostofhavingtheactorsemanticsimplementedinchapel.CanwedoactororientedprogrammingwithcurrentChapellanguageconstructs?ThisquestiontriestorevealhowwellorpoorlythecurrentconstructsinChapelsupportactorstyleprogramming.WhatchangesareneededtosupporttrueactorsemanticsinChapel?Theanswertothisquestionhelpsustorealizethechangesrequiredtothecompilerandrun-timeinordertohaveatrueactorsemanticsinChapel.ThisstudywouldbevaluabletotheChapelcommunitybecauseitprovidesafairamountofknowledgeonthecostandbene tsofhavingactorsinChapelandcanhelpthemwithstartingpointsforimplementingactorsemanticsinthelanguage.1IntroductionTheadventofmulti-coreCPUsdemandedabiggerneedforparallelandconcurrentprogramming.Theprogramthatwasrunningfastonmydesktopmachineyesterdayisnotrunningasfastwithmynewquadcoremachinetoday[1].Thesequentialprogrammingmodelsofyesterdayarenotsuitabletotakeadvantageofthepowerofmulti-cores.Thereforefromaprogramminglanguageperspectiveweneedashiftinthewayweprogramthesenewmachines.Parallelprogrammingishardandisnotlikethatofsequentialprogramming.Programmershavemoreconcernswhenitcomestotamingparallelism.Parallelprogramsareusuallybiggerthanequivalentsequentialones.Modelsofparallelprogramminglanguagesaredi erentfromfamiliarandpopularsequentiallanguages.Evenlibrariessupportingparallelprogramminghavedi erentandstrangeconcepts.Thismakestheparallellanguagesabitunattractive[2].Alsoparallelmachinesaredi erentarchitecturallyandprogrammersareconcernedwithnewissuessuchascommunicationandsynchronization.Parallelandconcurrentprogramminghasbeenaroundsincealmostthebirthofdigitalcomputers.There-foremanyoftheissuesregardingparallelprogramming,mainlysuchasCorrectness,Performance,ScalabilityandPortability[3],hasbeendiscussedanddealtwithindi erentscales.However,recentlytheseissueshasgainedmoreattentionandthatisbecauseoftheabundanceofmulti-coreCPUs.Inthisbetween,programmingmodelsareofgreatimportanceintheperformanceandproductivityofparallelandconcurrentprograms.Therehasbeentwomodelsofparallelprogrammingfromamemorypoint1 ofview;SharedmemoryandDistributedmemory.Inthesharedmemorymodelallthethreadsorprocessesseethememoryasonebigcontinuouschunkwhichcanbeaccessedbyallofthem.Thismemorymodeliswhatwehaveinsequentialprogrammingandthereforeitiseasierfortheprogrammertodealwith.Ontheotherhand,inthedistributedmemorymodel,di erentprocessesseedi erentpartsoftheaddressspace.Inthismodelprocessesusuallycommunicateusingmessagepassingoranabstractionofmessagepassing.Forinstance,Pthreadisalibraryforparallelprogrammingwhichisbasedonsharedmemorymodel.OpenMPisanotherexamplefromthismodel.MPIisanexampleofaparallelprogramminglibrarybasedondistributedmemorymodel.Moreover,theActorprogrammingmodelwhichisbasedonmessagepassingassumesadistributedmemorymodel.Wecannotreallysaywhichofthesetwomodelsissuperiorovertheotherone.Eachonehasitsownadvantagesanddisadvantageswithrespecttotheapplication.Thesharedmemorymodelisfamiliar.Butithasthedisadvantagethatmanipulatingshareddatarequiressynchronization.Thissynchronizationcanbeverycostlyifonedoesnotdoitright.Besides,programswritteninthismodelareveryhardtodebugandreasonabout.Thedistributedmemorymodelhasthisadvantagethatitexploitslocalityverywell.Inaddition,sincethereisnosharedmemorytheassumptionisthatwedonothavetheproblemofsynchronizationandthatisabigrelief.However,thismodelhassigni cantcommunicationoverheadandthatisthesourceofperformanceineciency.Inordertosolvetheissuesofthesetwoparallelprogrammingmodelsandtakeadvantageoftheirstrengths,anewprogrammingmodelhasbeenintroduced[2].ThisnewmodelwhichisthecombinationofdistributedandsharedmemorymodeliscalledPartitionedGlobalAddressSpace(PGAS).ThePGASmodelissimilartosharedmemorymodelinthisrespectthatitprovidesasinglecontiguousmemoryviewforalltheprocesses.However,memoryispartitionedintopartsanddi erentthreadshavedi erentanitieswithvariouspartsofmemory.Thethreadsinaparallelprogramseeaglobaladdressspace.However,thephysicalmemorymightbedistributedacrossdi erentnodes.Inordertoexploitlocalityeachthreadorprocesshasanitywithapartofmemoryandaccessingthememoryofotherpartscomesatacost.TheChapelprogramminglanguageisdesignedandimplementedbasedonPGASmemorymodel.WewilltalkaboutChapellanguagelater.ThePGASmemorymodelallowsustobuilddi erentprogrammingmodelsontopofthat.Forexample,wecanbuildamessagepassingprogrammingmodelbasedonPGASinfrastructure.ButthequestioniswhyweneedsuchamodelontopofPGAS?Theanswertothisquestionistwofold.Firstcomesperformance.Somealgorithmsaredesignedwiththeassumptionthatthememoryisdistributed(whichisarealisticassumption)andthereforethealgorithmdesignertakeintoconsiderationthecostofcommunication.Ontheotherhand,therearealgorithmswhicharedesignedwiththeideaofsharedmemorymodelandtheyperformreallywellontruesharedmemorymachines.However,theydon'tperformverywellonsimulatedsharedmemorymodels(e.g.PGAS)becausetheyhavenotconsideredthecostofcommunicationinalgorithmdesign.Therefore,itmakessensetohavemessagepassingprogrammingmodelonPGASbecausethenwecanoptimizetheprogramforperformancebytakingadvantageofthelocalityintroducedbymessagepassingmodel.Sincetherearealreadyecientalgorithmsdesignedforthemessagepassingmodel,itiseasiertohavetheabilitytoexpresstheminanymemorymodelwehave.Andthisbringsustothesecondreasonwhichisexpressiveness.Weneedaneasywaytoexpressprogramswhicharebasedonmessagepassing.Providingprogrammerswithfacilitiesandlanguageconstructstowritethoseprogramsincreasethepoweroftheparallellanguage.Inaddition,therearestrongtoolsforcorrectnessvalidationandveri cationofmessagepassingprograms.OneofthefamousandimportantprogrammingmodelsbasedonmessagepassingistheActormodel[4].Itisaninherentlyconcurrentmodelmerelybasedonasynchronousmessagepassing.Theactorsemanticscomprisesofanumberofimportantconceptsincludingencapsulation,fairscheduling,locationtransparency,localityofreferences,andtransparentmigration[5].Allthesemaketheactormodelasuitableprogrammingmodelfordistributedsettings.Thereareamultitudeoflanguages,librariesandplatformsdevelopedbasedontheactormodel[5].LanguagesincludeErlang[6],Elanguage[7],SALSA[8]andAxum[9].TherearealsomanylibrariesfromwhichwecannameActorFoundry[10],ActorsGuild[11],Retlang[12],Jetlang[13],Jasab[14]andJavAct[15].TherearealsoplatformssuchasActorNet[16]basedonactormodelforprogrammingwirelesssensornetworks.Noonereallyknowswhatwouldbetheappropriatearchitectureandprogrammingmodelofthefuturegenerationofmutil-coreswithorderofthousandsofcores.However,actormodelisde nitelyagoodcandidate.Theargumentinfavoristhatmemorybandwidthandconsistencyaremajordrawbacksfor2 performance.Thereforearchitecturestendtobemoredistributedandprogramstrytoexploitlocality.Sinceactormodelisbasicallydesignedasaprogrammingmodelfordistributedsystemswithnosharing,itsoundslikeagoodchoice.Aswediscussedearlier,eveninglobalviewlanguagesbasedonPGASmodel,itisgoodandconvenienttosupportmessagepassingmodel.Thatsaid,weneedtochooseanappropriateandsimpleenoughmessagepassingmodeltosupport.Actormodelwithastrongsemanticsandtheorysuggestsasimpleandyetpowerfulmodel.WedonotwanttoadoptsomethinglikeMPImessagepassingmodelfortworeasons.First,itisarathercomplicatedmodelwithsomanydi erentkindsofsendsandreceives.Second,itdoesnothaveastrongsemanticsandtheorybehindit.Therestofthispaperisorganizedasfollows:InthenextsectionwediscusstheconceptsoftheActormodelandwhyitisimportant.Insection3wereviewthebasicsoftheChapellanguageandstudythelanguageconstructsthatweneedforourmessagepassingmodelinChapel.Section4discussesthedesignoftheactormodelinChapelandhowweactuallyadopttheactormodelinit.Furthermore,insection5,weexplainthecompilersupportforactorprogramminginChapeland nallysection6willconcludethepaper.2ActorsActormodelisamodelofconcurrentcomputationfordistributedsystems[4].Anactorsystemconsistsofanumberofconcurrentandautonomousentitiescalledactors[5].Anactorhasitsownthreadofcontrolandstateandistheunitofconcurrencyintheactormodel.Thestateofactorisencapsulatedandisnotshared.Eachactorupdatesitsownlocalstatebyprocessingmessagesthatitreceivesinitsmailbox.2.1MessagesActorscommunicateusingasynchronousmessagepassing.Thesenderactorsendsamessagetotheotheractor(receiver)andcontinuewithoutbeingblocked.Thereceivingactorhasamailboxtoreceiveallthemessagesfromwhichitprocessesmessagesoneatatimeinasingleatomicstep[5].Thesingleatomicstepexecutionofamessageinanactorenablesthemacro-stepsemantics[17]whichiscrucialinreasoningaboutactorsystems. [msg_a][create] MailboxMethodsThreadState MailboxMethodsThreadState MailboxMethodsThreadState Figure1:Actorscommunicatemerelyusingasynchronousmessagepassing.(Figurefrom[5])AsillustratedinFigure1,actorsdonotsharestate.Eachactorpicksamessagefrommailboxandprocessthemessageandupdatesitsstate.Eachmessageresemblesatask.Weusethetermstaskandmessageinterchangeably.Atask,asde nedin[4],isatupleof:Atagwhichdistinguishesthetaskfromallothertasks,Atargetwhichisthenameoftheactortoreceivethetask,Acommunicationwhichisbasicallyinformationrequiredtodothetask.Itisatupleofvalues.Thetargetofthetaskistheaddressofthereceiveractor.Thisaddresscanbeamailboxaddress.Insomesystemsbasedonactormodelitisauniquenamefortheactorwhichwouldhavethesamefunctionalityofthemailboxaddress.Thenameshouldnotbesomethingthatcanbeguessed.Anactorcansendmessagestootheractorsthatitknows.Itcanreceivetheaddressofotheractorsthroughthereceivedmessagesoruponitscreationthroughtheconstructor.3 2.2ActorStructureAnactorhasamailboxoraqueueofmessages.Insomelanguagesandlibrariesthisqueueisexposedtoprogrammerandsomesystemshidethequeue.ForexampleinKilim[18]librarythemailboxisexposed.However,inActorFoundryframeworkitishiddenfromprogrammer.TheprocessofdeliveringamessageMconsistsof ndingtheappropriatemessagehandlerforitandgivethemessagehandlerthecommunicationinformationforthatmessagetoprocessthemessage.Whiledeliveringamessageinanactornootheractivityisbeingdoneinsideit.Inotherwordsmessagedeliveryisserializedinsideanactor.Theprocessof ndingtheappropriatemessagehandlerisapatternmatchingprocess.Eachmessageismatchedagainstanumberofpatterns.Ifitmatchesthentheexpressionsorstatementsassociatedwiththatmatchwillbeexecuted.Thereafter,theactorstartsovertoreceiveanddeliveranothermessageifthereisany.Ifthereisnomessagetoprocess,actorwillwaituntilitreceivesamessage.Figure2showstheabstractstructureofreceivinganddeliveringmessagesinanactor. Figure2:TheabstractstructureofreceivinganddeliveringmessagesinanactorAsarealexample,wecanseeinFigure3anactorwhichiswritteninScalalanguage[19].Asidefrom Figure3:AnactorinScala.Noticethatthepartsforreceivingandmatchingthemessagesarehighlighted.[19]thedetailsofde ngingtheactor,wecanseethatthereisaneverendingloop(while(true))inwhichthereisareceivestatementforreceivingmessages.Insidethereceivestatementtherearetwomatchstatementstartingwithcase.Everytimeamessagesmatchesanyofthemitwillexecutethestatementsafterthecase.Notalltheactorlanguagesorlibrarieshasthiswayofmessagehandlingmechanism.Forexample,intheActorFoundry[10]messagehandlersarede nedasusualJavamethods.Theframeworkthenwouldhandlethemessagedeliverybydispatchingthemessageinthequeuetooneofthemethodsthatmatchesthat.TheprocessofdispatchingisbasicallyinvokingthemethodswiththeactualparametersprovidedinthemessageusingJavaRe\rection.Figure4showsthePongactorde nedintheActorFoundry.Scalahasthelanguagelevelsupportforpatternmatchingandthusitmakesitsuitableforthatstyleofmessagedelivery.ErlangisprettymuchthesameasScalainthisregard.Java,ontheotherhand,doesnothavesuchthingandthenactorlibrariesusuallyincorporatetheJavare\rectiontoaccomplishthepurpose.4 Figure4:AnactorinActorFoundryWecannotreallysaywhichwayissuperiortotheother.Itdependsonthelanguageandtheexpressivenessoftheapproachinthatlanguage.Inadditiontomessagedeliverypart,anactormaintainsastate.Thestaterepresentationdependsonthelanguage.InimperativelanguageslikeJavaorScala, eldsoftheobjectsrepresentthestate.InfunctionalactorlanguagessuchasErlangthestatecanbepassedasavaluetupleintheloop.Sofarwehaveseenwhatanactorisallaboutandwhatitsstructureis.Ithasmainlytwoparts:staterepresentationandbehaviorrepresentation.Nowwewanttoseewhataretherequirementsforaminimalactorlanguage.InotherwordswewanttoinvestigatethestructureofanActorprogram.2.3ActorProgramStructureAprograminanactorlanguageoralibrarywhichsupportactorprogrammingconsistsof:actorde nition,whichisusuallyde nedbyaclassthathasthestatevariablesandthepartforhandlingmessagesaswesawinthepreviouspart.newexpressions,inordertocreatenewactors.sendcommands,inordertosendmessages(creatingtasks).InScalaandActorFoundryanactorcanbecreatedbyusingthekeywordnew.InErlanganactorcanbecreatedusingthekeywordspawn.BothErlangandScalausethebangoperator,!,todeclareamessagesend.Thesyntaxforsendingamessageintheselanguageslookslikethis:receiver!MessageInErlang,the\Message"isdeclaredbyatupleusingbraces.InScala,though,itisatupleorasinglevalue.InActorFoundrythemessagesendingisdoneusingthesendfunctionwhichisprovidedinthelibrary.Theparameterstothesendfunctionare:1.Theactornamewewishtosendthemessageto.2.Thenameofthemessagewhichisastringliteral.3.Theactualparameters,asmanyasneeded.send(receiver,"messagename",parameters...)Sofarwesawtheoverviewoftheactormodelfromsyntaxandsemanticspointofview.Inthenextpartwewanttodiscusssomeimportantsemanticspropertiesofactorsystems.ThisdiscussionisimportantforourpurposeinthisworksincewewanttoseetowhatextentwecansupportthesepropertiesinChapel.2.4ActorPropertiesTherearefourimportantpropertiesforactorsystems[5]:encapsulation,fairness,locationtransparencyandmobility.WearegoingtointroducethesepropertiesinthispartandlateronwewillseehowwecanimplementthesepropertiesinChapel.5 2.4.1EncapsulationEncapsulationisbynomeansoneofthemostimportantpartsoftheobjectorientedprogramming.Itisalsoimportantinactorsystems.Encapsulationprovideslocalityandsafetyforactors.Asaresultwewillhavedataracefreeandmemorysafeactorprograms.Encapsulationistwo-fold[5]:statesafetyandmessagingsafety.Statesafetymeansthatnoactorcanaccessthestatevariablesofanotheractor[5].Theonlywaytoaccessandmanipulatethestateofanactoristhroughitsmessages.Thereforethelanguageorlibraryshouldprovidesomesortofmechanismforhidingdataandmakingsurethatdatacanonlybeaccessedandalteredusingmessagepassing.Messagingsafetyisconcernedwithwhatisbeingpassedinsidemessages.Inordertoguaranteethatthereisnosharedstatebetweenactorsweneedtoenforcethecall-by-valuesemanticsformessagepassing[5].Call-by-valuesemanticsrequiresmakingacopyoftheactualdataandputitinthemessageeveninshared-memorysystems.Inotherwordsweneedtomakesurethatthereisnopointerorreferencetodatathatisbeingpassedinthemessages.Somelanguagesencourageprogrammerstouseimmutableobjectsinsidemessagesorexplicitlymakeacopyofdatauponsendingthedata.Otherlanguageslettheprogrammersdecideswhichdatashouldbecopiedandwhichdatacanbesentbyreference.Theselanguagesprovidesometagstoannotateparameters.Thereafter,ifthecopyingisnecessaryitwillbedonebythelanguagerun-time.2.4.2FairnessInactorsemanticsitisstatedthatasafairnessconditioneverysinglemessageshouldbedelivered nally.Bydeliveringamessagewemeansuccessfullyprocessingthemessageandremoveitfromthemailbox.Thereisnostrictwayofguaranteeingfairnessde nedinactorsemantics.OnecanimplementthefairnessusingaFIFOqueueofmessagesoranyothermechanism.Whateverthemechanismis,wewanttomakesurethatnomessagewillremaininthemailboxinde nitely.2.4.3LocationTransparencyInactorsemanticsthelocationoftheactordoesnotinterferewithitscomputationandalsodoesnota ectothers'computation.ThismeansthatitdoesnotmatterifanactorisrunningonaGPUoranothernodeinthenetworkorinthelocalCPU.Thelocationoftheactoronlya ectsthelatencyandnotthesemanticsofthesystem.Thereforewecannotmakeanyassumptionbasedonthelocationofactors.Locationtransparencyenablesseamlessmigrationofactorswhichwearegoingtodescribenext.2.4.4MobilityItisimportantthatwecanmovedataandcomputationfromoneprocessingnodetotheotherone.Thisisspeciallyimportantwithtoday'sheterogeneousarchitectureinwhichwewanttocreateabalancedworkloadandwewanttoexploitdi erentkindsofcomputationpowerssuchasGPUs,DSPsetc.Inordertohavemobilityweneedtobeabletomovethedata,programandthestateofthecomputationtoanotherplace.Therearetwokindsofmobility[20];weakandstrong.Weakmobilityistheabilitytomovethecodeanddataandstrongmobilityistheabilitytomovecode,dataandtheexecutionstate.Strongmobilityismorediculttosupportandrequirespreemptionofthecomputationatanypointsoratsomedesignatedpointsinthecode.Weakmobility,ontheotherhand,iseasiertosupportanditonlyrequiresanidleactor(onethatisnotprocessinganymessage).2.5ProgrammingAbstractionsTherearetwousefulprogrammingabstractionsthatwearegoingtodiscusshere.[5].2.5.1Request-ReplyMessagingTheRequest-ReplyMessagingorthesynchronousmessagepassingschemeisoneofthemostcommonpatternsofmessaging.Inthisschemethesender,aftersendingthemessage,willwaituntilthereceiverprocessesthemessagecompletely.Meanwhile,thesendercanreceivemessagesfromotheractorsinitmailbox.Ifthe6 fairnessisguaranteedthemessagewilleventuallybeprocessedandthesenderwillproceed.Thispatterncanbeusedforsynchronizationpurposes.2.5.2LocalSynchronizationConstraintsTheorderofprocessingmessagesinanactor,thoughfair,isnon-deterministic.Butsometimesanactorneedstoprocessthemessagesinaspeci corderorhastodefertheprocessingofamessagebecauseithastomeetacertainconditiontoprocessthemessage.Forexample,consideraboundedbu er.Thestatemachinefortheboundedbu erisshowninFigure5. Figure5:BoundedBu erStateDiagramAscanbeseeninthe gure,whenthebu erisintheputstateitcannotacceptanygetmessage.Neverthelessitmightreceivegetmessages.Inthiscase,ithastodefertheprocessingofthegetmessageuntilithassomethinginthebu ertoo er.Localsynchronizationconstraintsenableustoencodethesestatesandde nethecircumstancesunderwhichamessagecanbeprocessed.Theseconstraintsareusuallyabooleanexpressiononthestateoftheactorandtheparameterspassedwiththemessage.Deferredmessagesareputinaqueueforfurtherprocessing.Wheneveramessageisprocessedsuccessfullyweshouldprocessallthedeferredmessages.Notalltheactorlanguagesandlibrariessupportalltheseproperties.Thereasonthatnotallofthemsupportallthesefeaturesisbasicallythecostofimplementationandtheperformancepenaltytheyhavetopaytosupportallofthem.Incasetheactorimplementationdoesnotsupportafeature,itistheresponsibilityofprogrammertoimplementthem.Forinstance,inScala,inordertoassurethesafemessagingoneshouldmakeafullcopyofthedatabeingpassedorhandintheownershipofdatatotherecipient.However,somefeatureslikefairschedulingrequiressomesupportintherun-timesystemandcannotbeimplementedbytheprogrammer.Althoughinthesecasesprogrammercanwriteabettercode.Forinstance,programmercanwriteacooperativecodethatdoesnottakedownthethreadforalongtime.Inanycase,theburdenisonprogrammer,whichisnotalwaysgoodandispronetoerror.2.6WhyActorprogrammingisimportant?Actormodelisaninherentlyconcurrentmodelofprogramming.Soconcurrencyisintheheartofthemodel.Itisveryeasytocreateconcurrent/parallelprogramsinanactorbasedlanguageorlibrary.Programmerdoesnothavetodealwithcomplexitiesofthreadcreationandsynchronization.ForexampleinGUIapplicationwhereweneedalotofresponsivenessandconcurrency,actormodelisde nitelyagoodsolution.Thenon-sharedmemoryarchitectureoftheactormodelisahugegainincorrectnessandsimplicityofthereasoningabouttheprograms.Sincethereisnosharedstate,therewouldbenorace.Inaddition,becausethereisnoexplicitlockingrequired,programmerwillnotrunintoproblemsresultedfromlocking.Sincethelockingformessageprocessingisbeingdonebytheactorframeworkorlibraryitcanbeimplementedinanecientwaytoincreasetheperformance.Themeansofcommunicationbetweenactors,themessagepassing,andthelackoflockingsuggestlesscontentionintheprogram.Thishelpsimprovingtheperformance.Inadditiontothis,programswrittenwiththeideaofnon-sharedmemoryarchitecturewillperformbetteronnon-sharedmemorymachines.Incontrast,programswrittenwiththeideaofasharedmemorywillnotperformverywellwhenwerunthemonasimulatedsharedmemorymachinewhichisinfactanon-sharedone.Inadditiontoallthesethesimplicityofactormodelmakesiteasyforanecientimplementationandportability.Itisamodelandhasnorestrictiononthekindofunderlyinghardware.So,wecantheoreticallyrunactorsonCPU,GPU,embeddeddevicesandallothersortsofhardwaresprovidedthatwecancommunicatewiththem.TherearecurrentlyimplementationoflanguagesandlibrariessuchasActorNet[16]tooperateinwirelesssensornetworks.7 3ChapelInthissectionwearegoingtohaveabriefoverviewoftheChapellanguage.Wemainlyfocusonthepartsofthelanguagethatisimportantinourimplementationofactors.Chapel[2]isaglobalviewlanguagebasedonthePGASmemorymodel.However,incontrasttootherSPMDlanguagesbasedonthePGASmodel,ChapelisanMPMDone.Chapelhasbeendesignedtoful llfourgoals:1.Programmability2.Performance3.Portability4.RobustnessInfactChapeltendstobeageneralprogramminglanguageforparallelcomputing.Ittargetsthedesktopmulti-coresandclusters.Chapelisamultiresolutionlanguage.Itprovideslanguageconstructsfordataparallelism,taskparallelismanddistributionofdata.Inaddition,thereisthisnotionoflocalesinChapel.Alocaleisaunitofcomputationinthesystem.ItcouldbeaCPU,GPU,DSPorwhatevercomputingdevicethatexistsinthesystem.Chapelallowsprogrammertochoosewhichlocaletorunacomputation.Italsoenablesprogrammertosaywheretoresidethedata.ChapelissimilartoC++fromasyntacticpointofview.Itsvariableandfunctionde nitionsaresimilartothatofPerlandPython.WeassumethatreaderhassomebasicknowledgeabouttheChapellanguage.Thereforewearenotgoingtospendmuchtimeonexplainingthesyntacticdetails.Thethreeimportantaspectofthelanguagewhichareofinteresttousaretaskcreation,taskcoordinationandencapsulationmechanisms.Fortaskcreationprogrammercanusethebeginkeywordbeforeasinglestatementorablockofstatements.Thiswillcausethatsinglestatementorthatblockofstatementstoberunconcurrentlywiththerestoftheprogram.Figure6showsanexampleoftaskcreationinChapel.Asillustratedinthis gure,task1willrunconcurrentlywiththerestoftheprogram.Inotherwords,theprogramwillnotblockforthetask1tocomplete. Figure6:TaskcreationinChapelTaskcoordinationisdonethroughsynctypevariables.Synctypevariablesinadditiontoavaluemaintainafull/emptystate.Wheneversomeonewritestothevariable,itwillbecomefullandwheneversomeonereadsthecontentofthevariableitwillbecomeempty.Thedefaultbehaviorofwriteandreadoperationsisthattheywillblockforthevariabletobecomeemptyandfullrespectively.Thisbehaviorthencanbeusedtocreatealock.Awriteoperation(acquiringthelock)tothesyncvariablewillnotproceeduntilvariablebecomesempty(someonereleasethelock)andareadoperationwillnotproceedunlessthevariablehasbeenalreadywritteninto.Figure7showshowwecande neasyncvariable.Chapelsupportsobject-orientedfeaturesinordertoleveragetheproductivityboostinaparallelsetting[2].Thisisimportantforusbecausewewanttohaveencapsulationandtheobjectorientedfeatureswillprovidethatforus.CurrentlyChapeldoesnotsupportanyaccesscontrolontheclass elds.Chapelteamisplanningtosupportthatinthefuture.8 Figure7:SyncvariablesinChapel3.1WhyweneedactorprogramminginChapel?Chapelisaglobalviewlanguage.Ithasnonotionandmeansofmessagepassing.MessagepassingissomethingthatweusuallyseeinlocalviewlanguagesandlibrarieslikeErlangorMPI.SothequestioniswhywemightwanttodoactorprogramminginChapel?Themotivationbehindthisworkistwo-fold.Firstmotivationisprogrammability.Chapelis(orwantstobe)ageneralprogramminglanguage.Itwantstoprovideordinaryprogrammerstoeasilyprogramformulti-coresandclusters.Inordertodoso,itshouldhaveenoughandstronglanguageconstructstosupportdi erentknownconcurrent/parallelprogrammingmodels.Actormodelisawell-knownconcurrentprogrammingmodel.Ithasaniceabstractionwhichmakesconcurrentprogrammingeasierandlesspronetoerror.Therefore,evenifChapelisaglobalviewlanguage,itstillmakessensetosupportlocalviewconstructsandabstractions.Thissupportwillincreasetheusabilityandprogrammabilityofthelanguageanditwillboosttheproductivity.ThesecondmotivationbehindactorprogramminginChapelisperformance.Actorboundarieshighlightthecostofcommunications.Thisisveryimportantbecauseasidefromthesequentialcomputationthatisgoingoninsideanactor,theonlycostlyoperationsarethemessagepassingbetweenactors.Therefore,thisfactcanbeusedtocreateanelegantperformancemodelbasedonthepatternandthenumberofmessages.Inadditionaswementionedbefore,programswrittenwiththeideaofnon-sharedmemoryperformandscalebettercomparedtoprogramswrittenwiththeideaofasinglesharedmemory.Besides,actormodelhasastrongtheorybehinditwhichmakesthereasoningaboutactor-basedprogramseasier.Therearemanytoolstomodelcheckandverifythesystemsdevelopedbasedonactormodel.4Chapel+ActorInthissectionwewanttoseehowwecanmarryChapelandActormodel.Beforeweproceed,letushavealookattheanatomyofanactor.AnactorasillustratedinFigure8hasamailbox.Thismailboxisbasicallyaqueueofmessages.Asingleactivethreadinsidetheactorwillcontinuallygetamessagefromthismailboxandprocessitatomically.Thestateoftheactormightchangeasaresultofprocessingthemessage.Nowthatweknowenoughaboutanactor'sanatomyletusseehowwecanimplementthisanatomyinChapel. Figure8:AnActor'sAnatomy[5]Thereareanumberofchallengeswearefacinghere:1.Howtomodelthemailbox?2.Howtoguaranteeatomicityinmessageprocessing?3.Howwedotheasynchronousmessagepassing?4.Howwesupportlocality?5.Howwesupportprogrammingabstractionssuchasrequest-replyandlocalsynchronizationconstraint?6.Howaboutlocationtransparencyandmigration?9 4.1ModelingMailboxAswesawpreviously,Chapeldoesnotsupportanysortofmessagepassing.Weneedtosomehowsimulatemessagepassing.Unfortunately,Chapellacksagoodmechanismforpatternmatchingofvaluesandpa-rameters.Besides,itlacks\rexibledatastructureslikequeueandlinkedlist.We rsttriedtosimulatethemailboxusingourownde nedqueue.However,itfailedbecauseChapelarraysarenot\rexibletosupportheterogeneoustuples(likethatofScala).Nonethelesswedesignedaneasysolutiontosolvebothmailboxandatomicitytogether.Thesolutionistouseasyncvariable.Thereisanimplicitqueueassociatedwitheverysyncvariable.Wheneverathreadistryingtowriteintothat,itwillbeputintothatqueue.Inotherwords,thewriteoperationsonthesyncvariablesareserialized.Figure9showsanillustrationofthisqueueforthesyncvariablelock$. Figure9:Thequeueassociatedwithsyncvariablelock$.Therefore,usingasyncvariablewecaneasilysimulatethemailboxandmessages.Whatweneedtodoistotrytowriteintothesyncvariablebeforeprocessingthemessage.Writingintothesyncvariablewillmakeitfull.Asaresult,anyconsequentcallsforwritingintothatwillbeblocked.Afterwards,weneedtoreadfromthesyncvariabletomakeitempty.Whenthesyncvariablebecomesemptyanotherwriter(thread)cancomeinandwriteintoitandprocessthemessage.4.2AtomicityInordertoensuretheatomicityacrosstheactorweneedtoacquirethelock(writeintothat)andreleasethelock(readfromit)beforeandaftertheprocessingofeachmessagerespectively.ConsideringthatwerepresentanactorwithaclassinChapelandeverymessageisafunctionde nedinthatclass,weneedtohaveaclass-widesyncvariable.Letuscallthisvariablelock$.Whatweneedtodonextistoaltereachfunctionde nitiontoaddawritestatementandareadstatementatthebeginningandendofthefunctionblock. Figure10:Messagebodiesarealteredwithtwostatementstoacquireandreleasethelockvariablelock$Fromnowon,inordertohaveaconcreteexample,wearegoingtohavearunningexample.Thisisthefamousexampleprogramusedbyalmosteveryprogramminglanguage;the\HelloWorld!"example.InouractorizedversionofHelloWorldwehavetwoactors;theHelloactorandtheWorldactor.Thehelloactorhasamessagehello.AHelloactoruponreceivingthehellomessagewillprintthe"Hello"stringonthe10 consoleandthenitcreatesaWorldactorandsendaworldmessagetothat.TheWorldactoruponreceivingtheworldmessagewillprintthe"World!"stringontheconsole.4.3AsynchronousandSynchronousMessagingInordertosolvetheissueofasynchronyweneedtoresorttothebeginkeywordtocreateanewtask.Aswesawbeforethetaskscreatedthiswayruninparallelwiththerestoftheprogram.Therefore,everytimewewanttosendanasynchronousmessagetoanactorwesimplycalltheappropriatefunctionfromtheactorclassprecededbyathebeginkeyword. Figure11:HelloWorldactorsinChapel4.3.1SynchronousMessagingandReturnValuesForsynchronousortherequest-replystyleofmessagepassingwesimplydonotusethebeginkeywordbeforethecalltotheappropriatefunction.Thereforethesenderofthemessagewillbeblockeduntilthereceiverprocessesthemessage.Messagesdonothaveareturnvalue.Thisisanimportantthingtoconsiderwhenwritingprogramsinthemessagepassingstyle.However,wecansimulatearegularfunctioncallusingthesynchronousmessagepassingandamemoryreference.Wealreadyknowhowwecandosynchronousmessagepassing.Buthowdowegetthereturnvalue?Inordinaryprogramswehavethestackofcalls.Thecalleewillputthevalueontothestackandthecallerwillgrabitfromthere.Inmessagepassingwedonothavethisstackbutwehavememoryreferences.Basedontheunderlyingsystemandframework,thereareanumberofwaystoimplementthis.Infactthisisjustanimplementationissue.InChapelwecantakeadvantageofthisfactthatthelanguageisglobalview.Thereforewecanusememoryreferencestosolvethisproblem.Bypassingamemoryreferencetothefunctionandletthefunctionsetthevalueofthatmemorybeforereturnwecangetthereturnvaluefromamessage.InChapelthereareacoupleofintentkeywordswhichcomesbeforetheformalparameters.Oneofthesekeywordsisout.Thee ectofoutkeywordisthatthevalueassignedtotheparameterwillbesetuponthereturningfromthefunction.So,wedonotpassanythingtothefunction,butthefunctionpasssomethingbacktousinthatparameter. Figure12:UsingoutintenttogetthereturnvaluefromamessageFigure12showsamultiplicationfunction(whichcouldbeamessagede nedinanactorformathematicaloperations).Asyoucanseethexparameterhasintentout.Uponreturningfromthefunctionthevaluea*bwillbeassignedtox.Ifwecombinethiswithsynchronousmessaging,thenwecangettherequest-replye ect.ThankstoChapelmemorymodel,theimplementationofthisisveryeasy.4.4LocalityLocalityisanotherissuethatwehavetodealwith.Thecomputationofthemessagesshouldbedoneonthelocaleoftheactor.Actorscanbecreatedandplacedondi erentlocalesusingtheon-clause.Inaddition11 wecanusetheonclausetorunacomputationonaspeci clocale.Thereisalocaleassociatedwitheveryinstanceofaclass.Theclauseonthisselectthelocaleofthecurrentinstancerepresentedbythis.Figure13showsacodesnippetwithanon-clausearoundit.ThecodesnippetisinfactthebodyofthehellomessagefromHelloactor.Thereforeaswesaw,usingtheon-clausewecanachievethelocality. Figure13:On-clausearoundthebodyofthemessageNotethatthecostofmessagespassedbetweenactorsthatareonthesamelocaleisfarlessthanthemessagespassedbetweenactorsonseparatelocales.Therefore,carefulplacingofactorsonlocalescouldhaveadramatice ectonperformanceimprovement.4.5LocalSynchronizationConstraintsIn2.5.2wediscussedwhatthelocalsynchronizationconstraintsare.Theimplementationoflocalsynchro-nizationconstraintsisnoteasyinChapelsincethereisnoexplicitqueueormailboxtomanipulate.Asaresultwehavetodothisusingonlysyncvariablesandlocks.TheimplementationdetailsareinappendixA.Herewearejustgoingtogiveageneralideabehindtheimplementation.Wesawpreviouslythatforlocalsynchronizationconstraintsweneedasecondqueueinadditiontothemainqueueinwhichwekeepthearrivedmessages.Inthissecondqueuewekeepthedeferredmessages.Wesimulatethisqueuebyusinganothersyncvariable.Letuscallthissecondvariablelsc$.Eachtimeamessageisdeferreditwillbeblockedonthisvariable.Uponsuccessfullyprocessingofamessagewithoutdeferring,weneedtoseeifwecanprocessanyofthedeferredmessages.Therefore,thetaskwhichhassuccessfullyprocessedthelastmessageisresponsibleforwakingupthedeferredmessagesonebyone.Adeferredmessagethenwilltesttheconditiontoseeifitcanproceed.Ifitcan,itwillgoandprocessthedeferredmessage.Otherwiseitwillgobacktothesecondqueueagain.Wealsoneedacallbackmechanismtoinformtheinitiatortaskwhenadeferredmessageisdoneorisbacktothewaitingqueue.4.6LocationTransparencyandMobilityLocationofactorsinChapeldoesnota ectthecomputationatall.Itonlya ectsthelatency.SinceChapelisbasedonaglobaladdressspace,alltheobjectsincludingtheactorsarepartofthesameaddressspace.Itdoesnotmatteronwhichlocaletheyreside,wecanalwayscalltheirmethodsandsendthemmessageaslongaswehaveareferencetothem.Thisreferenceisindeedvalidonallthelocalesbecauseoftheglobalviewtomemory.MobilityinthecontextofChapelmeansthatweshouldbeabletomoveactorsacrosslocales.Rightnowthereisnoconstructinthelanguagetodothis.Itisnotcleariftheprogrammercanmoveobjectacrosslocalesbycopyingtheircontentandcreateacopyoftheobjectonthedestinationlocale.Thequestioniswhatisgoingtohappentoallthereferencestotheoldobject?Whoisgoingtoupdatethem?Currentlywesupportnoautomaticwayofmovingactors.Weneedtoanswersomebasicquestioninordertobeabletodothat.Thisisleftasfuturework.5CompilerSupportforActorsinChapelInthissectionwearegoingtoexplainverybrie\ryourcompilersupportforactororientedprogramminginChapel.Whatistheroleofcompilerinactorprogramming?AswesawintheprevioussectionChapelhasnecessarylanguageconstructsforactorprogramming.However,writingallthosecodeforlocking,atomicity,asynchrony,localityandlocalsynchronizationconstraintsisatediousjobandispronetoerror.Forexample,justconsiderwritingthelocalsynchronizationconstraintsforallthemessagesinanactor.Itisalotofworkwhichcanbeautomated.Therefore,inorderoralleviatetheprogrammer'sjobweneedsomecompiler12 supportsothatprogrammercaneasilywriteanactorprogram.WehaveextendedChapelcompilerwithasyntaxforactorde nition,messagepassingandlocalsynchronizationconstraints.Henceforth, rstwearegoingtoshowourproposedsyntaxandthenweexplainalittlebithowweextendedtheChapelcompiler. Figure14:Anactorde nitioninChapelFigure14showsthesyntaxforactorde nition.Itisbasicallytheclassde nitioninChapelwhereinsteadofusingthekeywordclassweshouldusekeywordactor.Therestisallthesameasclassde nition.Therearesomerestrictionsappliedtofunction(message)de nitions.Nomessagecanhaveareturnvalue.Becausetheyareregardedasmessagesandaswesaidbefore,messagescannothavereturnvalues.Localsynchronizationconstraintisaconditionde nedonamessage.Thisconditionisabooleanexpres-sionde nedonthestateoftheactorandthemessageparameters.Inourproposedsyntaxweoverloadedthewhenkeyword(alreadypresentinChapel)tode netheconstraint.Programmercanwriteabooleanexpressionfromtheparametersandtheactor'svariablesprecededbythewhenkeywordandrightafterthemethodsignature.Themeaningofthisbooleanexpressionisthat,whenevertheexpressionevaluatestotrue,themessageisenabledandcanbeprocessed.Otherwisewehavetodeferitsprocessing.InFigure14wecanseethesyntaxforthispurpose.Also,inordertomakethemessagepassingeasierandmoreverbose,wehavethesyntaxshowninFigure15forasynchronousandsynchronousmessagepassing.Forasynchronousmessagepassingweusethe'@'rightbeforethemessagenameandsynchronousmessagepassingisjustlikeusualfunctioncallwith'.'beforethemessagename. Figure15:ThesyntaxforsendingasynchronousandsynchronousmessagesTheextendedcompilerdoesthejobofgeneratingtheappropriatecodeforeveryaspectoftheactorprogram.Wechecktheactorprogramrightaftertheconstructionofabstractsyntaxtreeoftheprogram.Then,foreachactorde nedintheprogramwegeneratethenecessaryChapelcodes.Itisbasicallyasourcetosourcetransformation.ThecompilercanbedownloadedfromthefollowingURL:http://www.cs.utexas.edu/~amshali/chaptor-1.0.zipThereareanumberofexamplesintheexamples/actorfolder.6ConclusionandFutureWorkInthisworkwestudiedactormodelofprogramming,ahighlyconcurrentmodelbasedonmessagepassing.Actormodelisimportantbecause, rst,itisaninherentlyconcurrentmodelwhichabstractstheuseofthreads.Inaddition,messagesinsideanactorareprocessedatomicallyandnoonecanaccessthedataencapsulatedintheactor.Therefore,programmerdoesnothavetodealwiththreadcreation,schedulingandlocking.Thisisagreatdealandmakesprogrammingandreasoningabouttheactorprogramseasier.Ontheotherhand,Chapeltriestobeageneralparallel/concurrentprogramminglanguage.However,itlacksagoodmessagepassingmodel.OurmaincontributioninthisworkwastomarrytheactormodelwiththeChapelprogramminglanguage.Wedesignedacompletesystemforde ningactorsandsending13 messagesbetweenactors.Wealsocameupwithadesignfordoingusefulprogrammingabstractionssuchasrequest-replymessagingandlocalsynchronizationconstraintsinthissystem.WethenextendedtheChapelcompilertosupportaproposedsyntaxforactorde nition.WebelievethatdoingmessagepassingstyleprogrammingeveninaglobalviewlanguagelikeChapelisstillbene cialforthreereasons:Increasedprogrammability:Thereareprogramsandalgorithmswhichareinherentlydesignedbasedonmessagepassingmodel.Beingabletoexpresstheminasuccinctwayisanimportantmatter.ThereforebringingthenotionofmessagepassingtotheChapelwouldincreasethecapabilitiesofthelanguage.Betterperformance:Mostarchitecturesaregoingtowardsanon-sharedmemorystylebecauseoftheissueofcacheandmemoryconsistency.Programswritteninthemessagepassingstylewiththeabilitytoexploitlocality(asinactormodel)areabletoperformbetterinnon-sharedmemoryarchitectures.Easierperformancemodeling:Thevolumeofmessagespassedbetweenactorscouldbeusedformod-elingtheperformanceofthesystembasedonactors.Everythingelseishappeninglocallyineachactorandwecanuseregularsequentialprogramperformancemodelingforthem.Asopposedtoanarbitraryparallelprogramwhichcouldexposeacomplicatedbehavior,actorprogramsaremucheasierforperformancemodeling.ForthefutureworkwearegoingtostudytheissueofmobilityinChapel.Inparticularweneedtoseewhatarethedicultiesofmovinganactorfromalocaletoanotherlocale.Doessimplecopyingof eldsandstateoftheactorsuceformovingtheactor?Whatisgoingtohappenifactorreceiveamessageinthemiddleofmovement?Thesequestionsbuildsthefoundationofourresearchforfuturestudiesinthisarea.References[1]HerbSutter.Thefreelunchisover:Afundamentalturntowardconcurrencyinsoftware.February2005.[2]B.L.Chamberlain,D.Callahan,andH.P.Zima.Parallelprogrammabilityandthechapellanguage.Int.J.HighPerform.Comput.Appl.,21(3):291{312,2007.[3]LarrySnyderCalvinLin.PrinciplesofParallelProgramming.Addison-Wesley,2009.[4]GulAgha.Actors:amodelofconcurrentcomputationindistributedsystems.MITPress,Cambridge,MA,USA,1986.[5]RajeshK.Karmani,AminShali,andGulAgha.Actorframeworksforthejvmplatform:acomparativeanalysis.InPPPJ'09:Proceedingsofthe7thInternationalConferenceonPrinciplesandPracticeofProgramminginJava,pages11{20,NewYork,NY,USA,2009.ACM.[6]JoeArmstrong.ProgrammingErlang:SoftwareforaConcurrentWorld.PragmaticBookshelf,2007.[7]Theelanguage.http://www.erights.org/elang,2000.[8]CarlosA.Varela,GulAgha,Wei-JenWang,TravisDesell,KaoutarElMaghraoui,JasonLaPorte,andAbeStephens.THESALSAPROGRAMMINGLANGUAGE1.1.2RELEASETUTORIAL.RensselaerPolytechnicInstitute,Troy,NewYork,February2007.[9]MicrosoftCorporation.Axumprogramminglanguage.http://msdn.microsoft.com/en-us/devlabs/dd795202.aspx,2008-09.[10]MarkAstley.TheActorFoundry:AJava-basedActorProgrammingEnvironment.OpenSystemsLaboratory,UniversityofIllinoisatUrbana-Champaign,1998-99.[11]TimJansen.Actorsguild.http://actorsguildframework.org/,2009.[12]MikeRettig.Retlang.http://code.google.com/p/retlang/,2007-09.14 [13]MikeRettig.Jetlang.http://code.google.com/p/jetlang/,2008-09.[14]RexYoung.Jsasb.https://jsasb.dev.java.net/,2008-09.[15]S.RougemailleJ.-P.Arcangeli,F.Migeon.Javact:ajavamiddlewareformobileadaptiveagents,February2008.[16]YoungMinKwon,SameerSundresh,KirillMechitov,andGulAgha.Actornet:Anactorplatformforwirelesssensornetworks.InFifthInternationalJointConferenceonAutonomousAgentsandMultiagentSystems(AAMAS),pages1297-1300,2006.[17]GulAgha,IanA.Mason,ScottSmith,andCarolynTalcott.AFoundationforActorComputation.JournalofFunctionalProgramming,7(01):1{72,1997.[18]S.SrinivasanandA.Mycroft.Kilim:IsolationtypedactorsforJava.InProcedingsiftheEuropeanConferenceonObjectOrientedProgramming(ECOOP),2008.[19]Scalaactors:Ashorttutorial.http://www.scala-lang.org/node/242,2010.[20]AlfonsoFuggetta,GianPietroPicco,andGiovanniVigna.Understandingcodemobility.IEEETrans-actionsonSoftwareEngineering,24(5):342{361,1998.ALocalSynchronizationConstraintsImplementationdefmessage(){onthis{deflsc():bool{returnevaluate_condition;}varwere_blocked=false:bool;lock$=true;while(true){//iflocalsynchconstraintistruethengoonif(lsc()){break;}else{//ifthisisthefirsttimethismessageisbeing//blockedthenaddittotheblockedqueueandrelease//thelockif(!were_blocked){blocked=blocked+1;were_blocked=true;lock$;}//ifprocessalreadyhasbeenblockedbefore//andisgoingtobeblockedagainthenremove//itfromthetoprocessqueueandwakeupthe//initiator.else{toprocess=toprocess-1;callback$=true;}//waitforthenextchangeinactorlsc$;}}////messagebody15 ...//////ifmessageneverblockedthensomeblockedmessage//mightbeabletobeprocessed.if(!were_blocked){begin{//gooverallblockedmessagesanddeliverthemonebyonetoprocess=blocked;while(toprocess�0){//releaseoneblockedmessagelsc$=true;//waituntiltheblockmessagecallbackcallback$;}lock$;}}//ifmessagewasintheblockedqueuethen//justremoveitselffromblockedqueueandinform//theinitiatorelse{blocked=blocked-1;toprocess=blocked;callback$=true;}}}16