TAOS

Inleiding

Dit had een aantal redenen:

• er was geen algemene programmeer methode beschikbaar
• programma's die voor een systeem geschreven waren konden meestal alleen op dat systeem gebruikt worden
• er was geen duidelijkheid over het te gebruiken reken- en communicatiemodel

Het is een compacte kernel voor parallele systemen, dat geschikt is voor algemene doeleinden. Een aantal zeer belangrijke kenmerken zijn:

Hardware onafhankelijkheid

Taos applicaties draaien op verschillende processor architecturen. Het is hierbij niet nodig om de programma's opnieuw te compileren.

Load-balancing

Taos voorziet in een optimale verspreiding van processen over een netwerk.

Heterogene processen

parallelle applicaties kunnen over een netwerk van verschillende processoren draaien.

Dynamic binding

alleen die delen van een programma die altijd nodig zijn, worden in het geheugen geladen.

Multi-threading

code die aanwezig is in het geheugen is beschikaar voor alle programma's, die het nodig hebben.

Object georienteerd

Taos gebruikt een object georienteerd programma ontwerp model.

Asynchrone messages

Messages houden het zendende proces niet op.

Mini kernel

Taos heeft een zeer compacte implementatie. Dit bevordert de prestatie en beperkt de geheugenbehoefte.

Communicatie naar andere processen vindt plaats door middel van het sturen van boodschappen. Er is in principe geen shared memory concept, alhoewel het mogelijk is Taos te laten draaien op een shared memory systeem.

Portabiliteit

Taos pakt dit anders aan: alle code wordt gecompileerd naar de zogenaamde Taos Virtual Processor. Het porten beperkt zich op deze manier alleen maar tot de virtual processor (VP) en niet meer tot de applicatie, onafhankelijk van de taal waarin de applicatie geschreven is. Omdat de portabiliteit van het applicatie niveau naar het processor niveau verschoven is betekent het dat er heterogene proces ondersteuning is (zie verderop).

Zonder al te veel moeite kan Taos worden geport naar elke andere processor. Het enige onderdeel dat opnieuw moet worden geschreven om een nieuwe (fysieke) processor te ondersteunen is de Translator. Dit is het programma dat de VP code vertaalt in de native code, d.w.z. de eigen machinetaal van de processor. Alle programma's die gecompileerd zijn naar de VP zullen dan meteen bruikbaar zijn op het nieuwe processortype. Het is dus niet nodig ze opnieuw te compileren. Dit heeft een ontzettend grote tijdswinst tot gevolg.

De Virtual Processor

Alle programma's die compileerd of geassembleerd zijn voor de VP staan op deze manier opgeslagen op disk. Op het moment dat de VP code van disk wordt geladen (of over het netwerk), wordt de code vertaalt in native machinecode. Dit gebeurt alleen maar als de code werkelijk nodig is (zie dynamic binding).

Deze methode lijkt traag. Dat valt erg mee, omdat de meeste processoren sneller VP code kunnen vertalen dan dat ze van disk of van het netwerk geladen worden. Er treedt dus geen merkbare overhead op. Hierbij komt nog dat VP code vaak compacter is dan de native code, zodat er minder disk ruimte nodig is en de code sneller wordt geladen in vergelijking tot native code.

Mochten er bepaalde voordelen aan het gebruik van native code zitten, dan kan deze op disk worden opgeslagen en in voorkeur tot de VP versie worden geladen. Dit zou het geval kunnen zijn als er speciale instructies aanwezig zijn die door de hardware ondersteund worden, die de snelheid bevorderen.

Een programma draait dus altijd op alle processoren en in sommige gevallen is het mogelijk de snelheid nog te vergroten dus stukjes native code te gebruiken in plaats van de VP code.

Dynamic binding

Tijdens de uitvoering van een proces zal die om een stukje code met een bepaalde naam, een tool, vragen. Dit wordt dan van disk geladen en vertaald naar native code voordat het uitgevoerd wordt. Deze tool kan op zijn beurt weer andere tools aanroepen, volgens bovenstaande procedure. Als een tool klaar is met de uitvoering, kan het verwijderd worden uit het geheugen als er geen enkel ander proces is dat er nog naar verwijst.

Dynamic binding houdt in dat meerdere processen de zelfde code (tools) kunnen delen. Dit wordt ook wel multi-threading van code genoemd. Het is gemakkelijk te zien dat dit zeer geheugen efficient is. Als een tool klaar is met uitvoering, blijft het op de lijst van beschikbare tools staan. Zou het dan nog een keer nodig zijn, dan wordt de lokale (native) copie gebruikt. Het is dus niet nodig hem opnieuw van disk in te laden. Alleen als het geheugen vol zit wordt de tool werkelijk "weggegooid" en zal hij de volgende keer dat hij wordt aangeroepen opnieuw moeten worden geladen van disk.

Heterogene processing

Heterogene processing is het gebruik van verschillende types processor geheugen en communicatie hardware. Zodoende kan een veelzijdig parallel rekensysteem ontwikkeld worden. Taos biedt de mogelijkheid informatie op te vragen over de hardware die beschikbaar is in een netwerk. Programma's kunnen dan gebruik maken van speciale hardware om bepaalde objecten uit te voeren. Op deze manier kan een heterogene machine zo efficient mogelijk gebruikt worden.

Dit is natuurlijk het optimale open systeem, waarin alle aspecten van processing worden verspreidt over verschillende processoren, netwerken en architecturen. Dit geeft de gebruiker het voordeel dat hij processoren kan kiezen op basis van de huidige prijs/prestatie verhouding of andere criteria, zonder dat de toekomst in gevaar komt. Voor de fabrikanten geeft het de flexibiliteit om hun hardware ontwerp te verbeteren zonder dat ze vast komen te zitten in historische beslissingen onder het mom van software compatabiliteit.

De kernel

De progammeur is vrij om objecten aan het systeem toe te voegen. Dit kunnen bijvoorbeeld hardware drivers of file system objecten zijn. Objecten en messages

Alle Taos objecten zijn ook parallelle processen. Elk object dat door Taos gecreeerd wordt, wordt zijn eigen proces gegeven om te executeren. Het verschil tussen objecten en processen ligt in het volgende; objecten hebeen te maken met data en code en ze kosten geheugen; processen hebben te maken met processoren en ze kosten processortijd. Wanneer die twee gecombineerd worden heb je een proces dat uitgevoerd wordt en geheugen en processortijf in beslag neemt. Een object wordt tot leven gebracht door een proces.

De enige manier waarop objecten kunnen communiceren met andere objecten is door het sturen en ontvangen van messages (boodschappen). Omdat objecten op verschillende processoren kunnen draaien is het niet mogelijk om geheugen te delen tussen twee processen. Taos biedt een soort van lichtgewicht post systeem tussen processoren.

Een boodschap lijkt op een brief, je stuurt ze door er een adres op te plakken en hem in een brievenbus te stoppen. Je gebruikt ze om te communiceren met mensen waar je niet direct mee kan praten. Zo gaat dat ook bij Taos objecten; om te kunnen communiceren met andere objecten moet er een message gestuurd worden. Direct conctact is niet altijd mogelijk omdat de objecten op verschillende processoren kunnen draaien.

Objecten ontvangen hun post door in hun eigen brievenbus te kijken. Alle boodschappen hebben een type, zodat ze van elkaar onderscheiden kunnen worden.

Boodschappen voldoen aan het standaard node formaat plus extensies om het adres van de zender en de bestemming te bevatten. Wanneer de post aankomt wordt het op een stapel gelegd waar het ontvangende proces nog naar moet kijken.

De boodschappen worden asynchroon verstuurd. Dit houdt in dat een proces niet wordt opgehouden als er een boodschap is verstuurd, maar gewoon door kan gaan met de executie. Synchrone communicatie kan worden bereikt door te wachten op een ontvangst bericht. Deze methode zorgt ervoor de processen zoveel mogelijk onafhankelijk van elkaar kunnen draaien.

Het postsysteem maak gebruik van een gedistribueerd algoritme om meerdere wegen naar de bestemming te vinden. Elke boodschap kan via meer dan een route worden verstuurd, zodat optimaal gebruik wordt gemaakt van de aanwezige communicatie paden. Als een weg wordt versperd dan wordt de boodschap via een andere weg geleid.

Gedistribueerde processing

Distributie is gebaseerd op processen die boodschappen doorlaten. Load balancing (het verspreiden van processen over een netwerk om de prestatie van het systeem maximaal te houden) wordt bereikt met behulp van een simpel algoritme dat kijkt naar de reken- en communicatie behoeften van de objecten. Wanneer een object wordt gecreeerd, wordt de loading (belasting) van de lokale processor vergeleken met die van aangrenzende processoren. Het object wordt dan toegekend aan de meest geschikte processor (die processor die op dat moment het minste te doen had).

Iedere processor houdt routing informatie bij voor elk communicatiekanaal, zodat boodschappen naar hun bestemming kunnen worden geleid. Boodschappen worden naar hun bestemming geleid op de manier zoals water door leidingen vloeit onder invloed van zwaartekracht. Op diezelfde manier worden processen bij aanmaak over het netwerk verdeeld; ze spreiden zich uit op de manier zoals water zich spreidt over een oppervlakte: alle processoren hebben ongeveer dezelfde belasting.

Object geörienteerd ontwerp

Alle objecten gebruiken de basis data node structuur. Taos kan alle entiteiten manipuleren die zich houden aan deze simpele structuur. Door de programmeur mogen nieuwe types objecten worden aangemaakt.

Data nodes zijn de basic objecten in het systeem. Tool objecten zijn stukjes code, net als bij formele OOP methoden, maar zonder een beperking op hun gebruik. Control objecten zijn objecten met een proces eraan gekoppeld. Ze communiceren via boodschappen en kunnen over processoren gedistribueerd worden. Zo'n object zal meestal meerdere verwijzigingen naar tool objecten bevatten.

Klassen (classes) voorzien in een hoog niveau functionaliteit. Ze worden gevormd door meerdere boodschap verwerkende objecten die samengebundeld zijn in de vorm van een klasse object. Een klasse kan gebruik maken van meerdere objecten die parallel werken. Deze objecten worden naar de gebruiker beschikbaar gemaakt in de vorm van aanroepen naar de klasse, bijvoorbeeld om een nieuw window aan te maken. Zoals bij standaard OOP gebruikelijk is gaat dit met behulp van het aanroepen van methods. De gebruiker ziet alleen maar de functionaliteit van de routine (zoals open window) en hoeft zich niet bezig te houden met de onderliggende parallelliteit van de uitgevoerde objecten.

Op dit moment zijn er meer dan 3000 tools beschikbaar, die een breed terrein omvatten: van string en filebeheer tot klassen die 3D polygoon werelden ondersteunen. Een programma om door een fractal landschap te vliegen bestaat uit minder dan 100 regels, wanneer gebruik wordt gemaakt van bestaande objecten!

Object en geheugenbeheer

Bij het aanmaken van objecten kent Taos het object toe aan een processor en alloceert daarna een proces om het object uit te voeren. Een typisch Taos object bestaat uit een paar honderd bytes.

Het meest low-level object in Taos is de node. Dit is de kleinste entiteit die Taos behandeld. Het is een pakket met data van variabele grootte die in een dubbel gelinkte lijst wordt geplaatst. Alle Taos enititeiten houden zich aan dit basis formaat. Vanuit deze basis bouwsteen worden andere structuren gemaakt, zoals tools, boodschappen en andere systeem objecten.

Nodes hebben een type veld dat het type van het object omschrijft en daarmee de manier waarop het behandeld moet worden. Standaard gedefinieerde types zijn onder andere: tools, control objecten, bitmaps, grafische objecten en klasse objecten. De gebruiker kan zelf nieuw types aanmaken.

Nodes worden op een of twee manieren opgeslagen. Als een node op disk staat of wordt getransporteerd over een netwerk, staat in een zogenaamde "template" vorm. Wanneer het in het geheugen wordt geladen wordt het klaar gemaakt om uitgevoerd te worden, het is dan geconverteerd naar "process=ready" vorm. Wanneer een template wordt geconverteerd naar process-ready, wordt de VP code naar native code vertaald en wordt de node ineen lijst van andere process- ready objecten ingevoegd. Als het in deze lijst staat kan het worden uitgevoerd. Het node type bepaalt hoe een object wordt uitgevoerd. Twee speciale types zijn het control object en het tool object. Ze zullen hieronder worden beschreven.

Wanneer een control object wordt aangemaakt, wordt de template van het object gedistribueerd en er een processor aan toegekend. Daarna komt er een proces beschikbaar voor het object en het object start met de uitvoering. Een control object bestaat uit een of meerdere componenten, die allemaal nodes van een of ander type zijn. Elk component wordt in volgorde uitgevoerd, totdat de laatste klaar is een het control object gesloten wordt en zijn proces stopt. The componenten kunnen andere control objects zijn, of tools, grafische objecten, enz. Alle control objecten worden aangemaakt diir eeb ander controle object en iedereen heeft het post adres van zijn ouder. Op dit manier wordt er een boomstructuur gevormd.

Omdat tools ook nodes zijn, kunnen ze gemanipuleerd worden door de kernel. Een controle object kan bestaan uit een hoeveelheid lokaal geheugen en een aantal tools die operaties uitvoeren op de data.

Ondanks dat het control object de kleinste entiteit die parallel uitgevoerd kan worden is het niet de kleinste eenheid voor geheugenbeheer. Individuele tools kunnen van disk worden geladen, omdat zij ook Taos objecten zijn (zich houden aan het basis node formaat). Een control object template bevat alleen maar de tekstuele namen van de componenten, dus niet de feitelijke code.

Wanneer een control object wordt aangemaakt kijkt de kernel of de tools waar de componenten naar verwijzen al in het geheugen staan en, als dat het geval is, plaatst een verwijzing daar naar toe. Is een object niet aanwezig, dan wordt het geladen van disk en process-ready gemaakt. Alle Taos objecten kunne multi-threaded zijn. Er zijn nooit twee copieen van hetzelfde object in dezelfde geheugenruimte, tenzij er speciaal om verzocht wordt.

Een andere eigenschap van dit executie mechanisme is dat alleen de componenten die nodig zijn worden geladen. Als een applicatie zo ontworpen wordt dat het is opgebouwd uit hierarchisch gestructureerde control objecten wordt code alleen maar geladen als het ook werkelijk uitgevoerd wordt. De benodigde geheugenruimte wordt zo dus tot een minimum beperkt en volledig bepaald door de uitvoering van een programma.

Taos in de praktijk