Alla vet att vanliga operativsystem inte fungerar som realtidsoperativsystem precis som alla vet att månen är en ost. Vanliga missförstånd som en gång i världen i varje fall delvis var sanna.
Realtidstillämpningar finns i många olika former och storlekar. En server som hanterar anrop från tusentals bankautomater kräver att responsen är tillräckligt kort för att inte kunden skall förlora tålamodet och börja slå på maskinen. Emellertid spelar någon halvsekund mer eller mindre inte någon roll.

Att hantera tv-utsändningar i realtid kräver att längsta responstiden är kortare än vertikala skanningstiden (16,67 eller 20 millisekunder). Att tappa en enda respons medför att utsändningen stoppas och man ådrar sig BBC:s eller SVT:s vrede. I detta fall är medeltiden för responsen inte viktig till skillnad från maximala tiden. Att spara någon millisekund ger inte något extra värde till produkten.

När Linux föddes i en lägenhet i Helsingfors som en kärna för ett generellt operativsystem hade den redan den vitala egenskapen som, när den utvecklats, skulle göra den idealisk som realtidsoperativsystem. Egenskapen var “preemption” vilket är möjligheten för kärnan att stoppa en process (task) och starta en annan med högre prioritet i stället. Kärnan kan stoppa en långvarig process när en realtidsrespons krävs. Jämför med operativsystem som ursprungligen är byggda för bordsdatorer - där kan en aldrig så akut process avbryta en pågående process.

Tidiga versioner av Linuxkärnan var verkligen inte lämpliga för realtidsanvändning om man inte med stort arbete separerade realtidskod från kärnan. Det gick åt många millisekunder för att rensa upp minnesallokeringar eller flytta runt interna datastrukturer bara för att gå tillbaka för att köra någon kod när man gjort vad man trodde var viktigt.
Kärnan har ändrats radikalt över åren. Den är nu mycket mindre och snålare samt, tack vare företag som MontaVistas arbete, kapabel till mycket goda realtidsprestanda.
Det är i huvudsak tre saker som har ändrats i kärnan. För det första kan, förutom att kunna avbryta en process (preempt), nu kärnan till viss del även preempta sig själv.
Om ett avbrott inträffar kan detta trigga en schemalagd verksamhet när kärnan gör något långvarigt, under förutsättning att kärnan inte är inne i en låst sektion.
För det andra har de låsta sektionerna trimmats till det yttersta för att få dem så korta som möjligt.
Tillsammans har dessa två förändringar ändrat kärnans beteende. Innan realtidsmodifieringarna kunde den svara på en servicebegäran med ett ”Ja ja, jag återkommer till dig när jag har tid. Nu svara den med ”Javisst, genast”.

Den tredje förändringen är att flytta ”bottom half”-koden som hanterar de långsamma delarna av avbrottshanterarna bort från en privat, speciell mod till trådar i kärnan.
Det ger inte längre kärnan något att skylla på när något viktigt måste utföras. I stället måste kärnan agera på en högprioriterad händelse.

Detta måste för övrigt hanteras försiktigt av dem som skriver drivrutiner.
Missbruk av trådarna i kärnan ger en felmod som liknar invertering av prioriteter. Det vanligaste försöket till missbruk är försöka köra alla trådar med högre prioritet än alla andra trådar, vilket förstås är omöjligt. Om det inte finns någon skillnad i prioritet måste något få lägre och något annat högre prioritet.

Tillsammans garanterar dessa förändringar att det finns en absolut maximal sämsta tid efter ett avbrott som taskschemaläggaren hanterar avbrottet, se figur 1 ovan.
Dessutom gör dessa förändringar att den normala responstiden blir kortare.
Jämför det med en telefonerande bekant. Om vederbörande är välorganiserad och affärsmässig svarar han vanligtvis inom tio sekunder och maximalt inom trettio. Om han eller hon å andra sidan är av typen som inte kan bestämma sig om att laga mat eller städa badrummet är viktigare så kan telefonen fortsätta att ringa efter fem minuter.
Detta är skillnaden mellan realtidskärnor och den äldre typen av kärnor.

Termen “deterministiskt sämsta fallet” refererar till den absolut längsta responstid som överhuvud taget kan inträffa. Under inga omständigheter får kärnan ta längre tid på sig än så för att hantera en händelse (event). Utvecklare av drivrutiner och tillämpningar måste först vad detta innebär.
Det betyder att om något måste hanteras inom ett visst antal mikrosekunder så kommer också så att ske. Det betyder inte att en drös högprioriterade händelser kan triggas samtidigt och förvändas få samma garantera responstid (jag har sett exempel på någon som försökt detta).
Deterministisk respons betyder att ett fåtal kritiska responser kan garanteras. Det är inte så att det på något magiskt vis gör att processorn kan hantera fler instruktioner under responstiden. Allt det kan göra är att se till att endast de nödvändiga instruktionerna utförs.

Prestandan i ett system i termer av händelser eller transaktioner per tidsenhet beror på två saker. För det första med vilken hastighet en processor kan hantera instruktioner. Detta låter som om det vore en absolut vägg som markerar den absoluta gränsen för systemprestanda men med moderna processorer är det mer att likna med att köra in i en marshmallow. Det finns en viss flexibilitet.
Orsaken till detta är den andra faktorn som påverkar prestanda, nämligen moderna processorers cacheminne och pipeline. De gör inte att processorn går fortare men de kan eliminera många långsamma externa cykler.
Tillsammans kan en kompilator som är medveten om ett chips speciella egenskaper och en kärna som kan hantera en cache på rätt sätt se till att påverkan av cachefel och tömning av pipeline hålls på ett minimum.

Det är på denna punkt som Linux såsom varande öppen programvara har stora fördelar. Många har haft ögonen på kompilatorn och koden den genererar, inklusive kärnan, så om det funnes en teknik för att förbättra prestanda skulle den redan ha föreslagits och förmodligen redan används.
Att få maximal prestanda innebär att man drar nytta av de nya funktioner som gör det möjligt att finjustera trådprioritering och schemaläggning. Försök att skriva ”man chrt” som en snabb introduktion till tillgängliga tillval (options).
Det finns två knep för att finjustera trådning. För det första måste man vara säker på att realtidsschemaläggningen endast används för trådar som verkligen behöver det, och för det andra att man ger högre prioritet till trådar som hanterar hårdvara som måste ha snabb respons. Detta måste man tänka på när man skriver nya drivrutiner för speciell hårdvara.

Att ha korrekt schemaläggning och prioritering är så viktigt att det kan vara avgörande för att lyckas med ett projekt. Jag såg en gång ett instrument under utveckling som betedde sig så illa att projektet var nära att läggas ner. Bara genom att köra ”chrt” med rätt parametrar fick man utrustningen att fungera perfekt.
Fortfarande gäller det att vara noggrann! Riktig fintrimning av trådar distribuerar begränsade processorresurser mellan processer (tasks) så att man uppnår rätt resultat. Det trollar inte fram extra processorcykler ur luften.
Detta är naturligtvis hanterbart för den erfarna programmeraren som arbetat med kärnan i åratal. Men de flesta som arbetar med realtidstillämpningar vill inte gräva ner sig i kärnans innersta. De vill få en mobiltelefon, bankomat eller ett vetenskapligt instrument ut på marknaden så fort och billigt som möjligt. De vill inte trava igenom tusentals rader kod på kernel.org för att få de funktioner de behöver.

Det är i detta sammanhang den märkliga naturen med öppen programvara kommer in. Öppen programvara är gratis men det är ofta billigare att betala för den. Detta innebär att man för en tillämpning kan köpa ett paket med kärna, filsystem, ingenjörsstöd, telefonsupport, kurser och professionell service från ett företag som MontaVista.
Med detta paket får man igång målhårdvaran med alla periferienheter och ett grundläggande ramverk snabbare. Det är en färdig basenhet. Bara tillämpningsprogram behöver tillföras.

Under de senaste åren har MontaVista hjälpt till att bygga paket som detta för många kunder. MontaVista har levererat program som gjort det möjligt att få fram handdatorer (PDA), trafikstyrningar och kemiska instrument som arbetar i realtid med Linux. Vi har kunnat använda vår specifika expertis på realtidskärnan för att bygga de delar av en produkt som kunden inte har erfarenhet av.
Det är nu möjligt för alla att använda realtids-Linux precis som vilken komponent som helst som man kan köpa från en specialiserad leverantör och som fungerar enligt en specifikation.
Efter flera år av utveckling är nu definitivt Linux lämpligt för realtidstillämpningar. Föreställningen att det inte är lämpligt är en rest från Linux tidigaste dagar då dess tilltänkta användning var som alternativt operativsystem för persondatorer. Nu klarar det så mycket mer och kan användas i de flesta realtidssammanhang.