y term='Alan Smith'/>
Informator-BloggenInformator är Nordens största kompetensutvecklare inom IT och projektledning.<br>Vi erbjuder kurser inom avancerad IT, för slutanvändare och Soft Skills.<br> Vi har nya gästbloggare varje vecka och så bloggar ju vi på Informator såklart!
Se vårt kursutbud på www.informator.seFrida Börjesonprofile/16795749745821137101noreply@blogger.comERicsson LANGuageOm du idag googlar runt på (programmeringsspråket) Erlang, så upptäcker du snabbt att det är ett av de mest hetaste (på svengelska coolaste) språken och att det finns en hel del andra som gärna drar nytta på att förknippas med Erlang teknologi. Så vad motiverar det stora intresset? Kort sagt; molnet! Lite längre sagt, så menas egenskapen att hantera ett mycket, mycket stort antal samtidiga konversationer/transaktioner/operationer. <br /><br />Ett av de riktigt svåra problem med fler-trådad (multi-threaded) programmering är att hantera uppdateringar av gemensamma data, eller mer precist uttryckt <i>Shared Mutual State</i>. Det klassiska sättet är att omge operationerna med mutex-lås (MUTual EXclusion), så att högst en tråd kan accessa data i taget. Detta är i regel ett nödvändigt men icke tillräckligt krav för att hantera mer komplexa interaktioner. Dessutom behövs villkorsvariabler (condition variables), som modellerar ett önskat sub-system tillstånd. T.ex. "vänta här brevlådan är tom". Det finns tre villkor för att problem med gemensamt data ska uppstå:<br /><br /><ol><li>En icke-atomär sekvens av READ, MODIFY, WRITE på ett data-element.</li><li>Mer än 1 tråd som accessar datat.</li><li>Tråd-växling inuti kod-sekvensen.</li></ol><div>Samtliga måste vara uppfyllda. Strategin är att bryta mot minst ett av villkoren. T.ex. konstant-data (immutable) bryter mot villkor 1 och mutex-lås bryter mot villkor 2.</div><br />Erlang gör rent hus med detta, genom att det inte är möjligt att skapa globala data. I stället kapslar man in data i en Erlang tråd (aka <i>Erlang process</i>) och sen får nyttjare skicka asynkrona meddelanden till tråden i fråga, som sedan behandlar meddelanden ett-i-taget. Det här är kärnan i den s.k. Actors-modellen, som på senare tid har blivit kolossalt populär i språk som Groovy-GPars och Scala-Akka. <br /><br />En Erlang process, är ett slags mellanting mellan objekt och tråd. Objekt såtillvida att dess tillstånd är inkapslat och tråd såtillvida att den exekverar samtidigt med andra. Ett Erlang program kan sägas bestå av en soppa av Erlang processer som simmar omkring och kastar asynkrona meddelanden på varandra. Mellan processerna, finns <i>ingenting</i>. <br /><br />Utmärkande för Erlang är också <i>single-assignment property</i>. Detta innebär att en variabel är antingen obunden eller bunden (för tid-och-evighet) till ett visst värde. M.a.o. bryter vi mot villkor 1ovan. En konsekvens är att man inte kan ha traditionella (for-) loopar, med en loop-variabel som stegas igenom. I stället används genomgående rekursion som upprepnings-mekanism i språket. Här förutsätter det att kompilatorn gör s.k. svans-rekursions-optimering (tail-recursion optimization).<br /><br />Nå, låt oss kika på lite programkod. Så här kan vi representera ett enkelt bank-konto, som en Erlang tråd. <br /><pre>account_new() -><br /> spawn(?MODULE, account_body, [0]).<br /><br />account_body(Balance) -><br /> receive<br /> {} -><br /> BalanceNew = Balance + Amount,<br /> Sender ! BalanceNew,<br /> account_body(BalanceNew);<br /> stop -> ok<br /> end.<br /></pre>Function account_new() -kontruktor- skapar en ny tråd mha den inbyggda funktionen spawn(). Själva tråd-kroppen loopar via rekursion och innehåller trådens inkapslade tillstånd (state) som parameter. Tråden ligger och väntar på ett inkommande meddelande och uppdaterar sedan saldot, samt skickar detta tillbaka till sändare. Här kan man se Erlangs typiska send-operator '!', hämtad från CSP. För att läsa och ändra saldo har jag lagt till följande funktion, som skickar ett meddelande och sen väntar på ett svar (extended rendezvous). <br /><pre>account_balance(Account, Amount) -><br /> Account ! {},<br /> receive<br /> BalanceNew -> BalanceNew<br /> end.<br />&l