Flere processorer kræver ny programmering
»Det er vigtigt at få problemerne løst, men jeg tror nu ikke så meget, det er i den almindelige udviklers bevidsthed,« siger Kim Harding Christensen, tidligere partner og medstifter af Java-firmaet Trifork.
Problemerne består i, hvorledes software kan komme til at køre optimalt i hardwarearkitekturer med mange kerner eller processorer.
»Det er stadigvæk semaforer, man bruger til at sikre adgang til delte ressourcer. Det er et begreb, som er 30 år gammelt, det er det, vi finder i vores biblioteker, i vores sprog, og det gør, at det er meget svært at skrive programmer, som håndterer concurrency (samtidighed) rigtigt. Det er noget, som er vigtigt at få løst, og som begynder at røre på sig nu.«
Hukommelse med transaktionsstyring
Der er forskellige måder at løse problemerne med at opdele et programs opgaver, så de kan udføres samtidigt på flere processorer. Det kræver, at den ene opgave ikke roder rundt i samme hukommelse, som den anden opgave benytter. Humlen er altså at begrænse adgangen til den fælles hukommelse på en eller anden måde.
Et forslag hedder software transactional memory (STM) og går ud på, at programmøren benytter hukommelsen på samme måde, som man bruger transaktionsstyring i databaser for at sikre sig, at to brugere ikke opdaterer de samme data på samme tid. Kim Harding Christensen forklarer:
»Vi starter en transaktion, så roder vi rundt i databasen, og så comitter vi ændringerne til sidst. Hvis der opstod en fejl, så ruller vi tilbage, så vi er i samme tilstand som før, vi startede. Det er i hvert fald en model, som folk kan finde ud af at bruge,« siger Kim Harding Christensen.
Programmøren skal stadig tænke sig om, men det er meget nemmere at realisere, fordi det er den model, som udviklerne er vant til, når de koder op imod en database. Det er simpelthen nemmere at forstå.
Programmer med 100.000 tråde
En anden mulighed er Erlang, som er et programmeringssprog, der er begyndt at røre på sig. I Erlangs afviklingsmiljø kan massevis af tråde udføres samtidigt, op til hundrede tusindvis. Erlang benyttes i teleindustrien, men kan også bruges til helt almindelige formål som f.eks. at skrive en server for chat-protokollen Jabber.
»Problemet ved at lave nye modeller og nye sprog er, at det tager lang tid at modne. Specielt i servere og programmer, som er kritiske. Der er det ikke bare at lave et sprog, det er mere selve implementeringen, som afgør, om det er modent nok til kritiske systemer. Der har Erlang vist sit værd. Det er et gammelt system, hvor fejlene er luset ud for længst.«
Erlang er dagens hype
Men Kim Harding Christensen tror ikke, at Erlang bliver det næste Java, selv om "Dem, der ikke synes, at Ruby er hot længere, kigger på Erlang." Problemet er, at for mange udviklere er sproget ikke tilgængeligt. Dets syntaks er for underligt. De eneste sprog, der bliver populære, er "curly brace"-sprog, mener Kim Harding Christensen, og sådan et er Erlang bestemt ikke. Syntaksmæssigt ligner det lidt Prolog.
Men der er mange gode ideer i Erlang, som man også vil komme til at se i andre sprog, tror Kim Harding Christensen.
Der er også interesse i at implementere det paradigme for samtidighed, der benyttes i Erling som klassebiblioteker, man så kan bruge i eksisterende sprog.
Denne artikel stammer fra det trykte Version2. som udkommer d. 21. september.
Kommentarer (1)
Hvis man insisterer på at programmere alting i "curly-brace" sprog (dvs. sprog, der ligner C), så kommer man ikke langt med massivt parallelle systemer. Der er en tendens i retning af "real programmers don't use Pascal" (http://www.pbm.com/~lindahl/real.programmers.html), men hvor de omtalte "real programmers" fra de tidlige firsere brugte Fortran til alt, så bruger dagens "rigtige" programmører curly-brace sprog til alt, og de kan ikke i deres vildeste fantasi forestille sig, at der kan findes bedre alternativer til nogle formål.
Erlang har mange gode ideer, og jeg synes ikke, at syntaksen er slem (selvom jeg havde foretrukket noget mindre Prolog-agtigt og mere lig Haskell (www.haskell.org) eller ML (http://en.wikipedia.org/wiki/Standard_ML)). Jeg er dog stærk tilhænger af statiske typer for alle programmer over 100 linier, så Erlangs dynamiske typesystem er jeg lidt skeptisk overfor.
