Det findes to typer spaghettikode. Den ene kan være umulig at rydde op i

Relativt få behersker Real Time Programming. Kompleksiteten øges eksponentielt med antallet af datastrømme man kobler på.

Temperaturmåleren i stuen skal kombineres med din hjerterytme for at justere styrken på aircon-blæseren - situationer som denne kræver Real Time Programmering, skriver digi.no.

Disciplinen er med andre ord nødvendig, når flere maskiner skal snakke sammen, og der skal tages hensyn til en bestemt situation - og hvornår noget skal ske.

For mange er Real Time Programming vanskeligt og relativt få behersker det. Kompleksiteten øges eksponentielt med antallet af datastrømme man kobler på, og selv erfarne udviklere kan få problemer med at tage hensyn til alle de forskellige udfald.

Konflikter er ofte noget man opdager og fikser efterhånden, som de viser sig - og derfor bliver den endelige kode ofte uoverskuelig og vanskelig at forstå for andre udviklere.

Grafik + egen kode

»Typisk spaghettikode kan du få til at se fin ud ved at rydde op i og strukturere koden. Med lige så snart der er samtidighed inde i billedet, kan det være umulig at rydde op og samtidig få kode, som er forståelig for andre,« forklarer Frank Alexander Kraemer, teknisk leder i Bitreactive, til det norske it-medie.

Trondheim-selskabet har udviklet et grafisk værktøj til Java-udviklere, som arbejder med Real Time Programming.

I applikationen kan man inddrage de kendte Java-biblioteker for machine to machine-kommunikation (M2M) og lave 'byggeklodser', som kobles sammen. En blok kan for eksempel være en komponent, funktion eller en protokol.

Blokene ligner API'er, hvor man blandt andet kan specificere, hvilke parametre man har behov for, og hvornår de forventes.

I værktøjet kan man også analysere programmet, og opdage deadlocks, synkroniseringsfejl og andre uforudsete hændelser.

På selskabets web kan du læse mere om, hvordan blokkene fungerer, og hvilke biblioteker det er tale om.

Kommentarer (24)

Martin Jünckow

Jeg stiller mig lidt uforstående overfor at det skulle være umuligt at refaktorere kode der beskæftiger sig med samtidighed. Er det noget man kunne få uddybet?

Eller er det præmissen man må sluge for at deres produkt giver mening?
Jeg er en smule i tvivl om blogindlægget er oplysende eller blot reklame.

Christian Nobel

Temperaturmåleren i stuen skal kombineres med din hjerterytme for at justere styrken på aircon-blæseren - situationer som denne kræver Real Time Programmering

Sikke noget vrøvl - eller rettere, et rigtig dårligt eksempel.

Justeringen af temperatur sker jo ikke på et splitsekund, men har en meget lang hysterese, så om det sker lidt før eller lidt senere er bedøvende ligegyldigt.

Og selv om det så var lidt mere tidskritisk, så kan de fleste opgaver altså håndteres med en state machine, det er kun i meget kritiske systemer at det er nødvendigt at tale om real tids programmering.

Men godt forsøgt, hvor meget har den reklame indbragt?

Lars Jensen

Du mener nok procestid, Ikke hysterese.
Uanset, så er det de prøver at forklare er at man nu grafisk kan se hvordan de enkelte funktioner (Funktionsblokke, Funktionskald) er indbyrdes forbundet. Se grafikken på digi.no. Det er der ikke noget nyt i. Det har man benyttet i PLC verdenen i 20 år, men det er måske en ny opfindelse til Java? Det har intet med realtidsprogrammering at gøre. Jeg kan iøvrigt ikke se hvorfor man skal programmere anderledes om en proces tager 10ms eller 10 minutter? Nogle parametre er anderledes, men koden er den samme.

Theis Blickfeldt

Når man skriver traditionel software forsøger man selvfølgelig, at optimere sin kode så godt som muligt, men man er også hjulpet godt på vej af, at man ikke har nær de samme timing-krav som man har i realtidsprogrammering og af, at man kan arbejde i et relativt pudset miljø der ligger pænt afskærmet fra hardwaren.

Man kan forstille sig, at man skal lave et realtidsdevice, som skal stå og måle værdien af en sensor en gang hvert 1 ms. Det vil kræve, at du hooker noget kode ind i et fx. ADC-interrupt - simpelt. På baggrund af sensorværdierne vil du foretage 2 handlinger. Én simpel handling for hver ny sensorværdi (Handling A) og en handling for hvert 1000. måling (Handling B), som tager 5ms, at udføre.
Havde det været et normalt stykke software uden realtidskrav havde man bare kunnet lave én task, som tager sig af begge handlinger, og lade ADC-interruptet buffe målingerne op mens Handling B forgår, og så hurtigt foretage Handling A 5 gange efterfølgende. Men når realtidskravet kommer ind i billedet kan Handling B naturligvis ikke udføres i samme scope som Handling A, da vi så staller processen forbi 5x Handling A. Så de to handlinger på den samme sensorværdi, må altså flyttes ud i to forskellige tasks eller interrupts, hvor Handling A' task/interrupt har højere prioritet end Handling B'.
Det er ikke svært, at forestille sig kode-kompleksiteten stige når man så bare tilføjer et par sensorer mere, som der hver skal reageres på, inden for et meget snævert tidskrav, og hvor tidskravet muligvis også kan afhænge af de andre værdier. Specielt hvis man har en blanding af kode, som man gerne vil køre i normal RTOS tasks, og kode der er så tidskritisk, at det tager for lang tid, at overføre informationen med beskeder mellem tasks, og derfor skal have dele af applikationskoden blandet ned i hardware-lagene. Og så begynder spaghettig-koden.

Men det er absolut ikke fordi det er en umulig opgave, det kræver bare noget ekstra, at få realtidskode til, at være struktureret. Og meget af sandheden ligger sikkert i, at de folk (undertegnede inkluderet), som har behov for at skrive realtids-kode er elektroingeniører og ikke softwareingeniører - og vi er altså bare ikke nær så disciplinerende og systematiske i designfasen.

Og ja, jeg ser også opslaget som en stor reklame.

Theis Blickfeldt

Definitionen på realtidsprogrammering har INTET med faste værdier for max latency, at gøre. Nogen gange er tidskravet en time, andre gange 100ns. Det er applikations-afhængigt.
Og hvor hårdt man skal programmere efter, at møde kravet afhænger af om der er tale om hard-realtime krav, soft-realtime krav eller firm-realtime-krav.

Mogens Hansen

Der blandes vist 2 forskellige begreber sammen:
* Real Time Programmering:
* Concurrency (eller måske Parallel Programming)

Real Time Programmering går ud på at resultatet skal foreligge til et bestemt tidspunkt. Et for sent, men iøvrigt korrekt resultat, er en fejl.
At beregne en vejrudsigt er (typisk) et real time problem, selvom det måtte tage et døgn at beregne den. Men kommer vejrudsigten senere end det vejr den skal forudsige er begningen værdiløs.
https://en.wikipedia.org/wiki/Real-time_computing

Concurrency er flere beregninger kører i overlappende tid - f.eks. med flere tråde.
https://en.wikipedia.org/wiki/Concurrent_computing
Det kan være nyttigt for at strukturere koden bedre eller for at få bedre performance - måske kan man få begge dele samtidig.

Concurrency eller parallel programmering kan bruges til at lave programmer med real time krav, men det ene medfører eller forudsætter ikke det andet.

Troels Henriksen

Det slår mig at Java måske ikke er det bedste valg til et samtidighedssystem med realtidsbehov? Per Brinch Hansen beskrev allerede i 1976 i The Architecture of Concurrent Programs hvordan et sådan system kan strikkes sammen i Concurrent Pascal. Nutildags er Concurrent Pascal måske ikke så udbredt (hvis det nogensinde var det), men bogen er god evidens for at det er nyttigt at bruge et sprog bygget til samtidighed, hvis man gerne vil have samtidighed. Måske Erlang? Det brugte Ericsson til telefon-switche.

Concurrency eller parallel programmering kan bruges til at lave programmer med real time krav, men det ene medfører eller forudsætter ikke det andet.

Concurrency/samtidighed er slet ikke det samme som parallel programmering, og det skaber stor forvirring at blande de to ting sammen. Parallelisme er en operationel implementeringsdetalje der handler om at få kode til at køre hurtigere, og det tror jeg ikke er hvad artiklen handler om.

Jan Rasmussen

Definitionen på realtidsprogrammering har INTET med faste værdier

Det er muligt, men derfor er det stadig 5-10ms for en bruger af real time audio software, og ~1ms for en programmør af samme.

Kom gerne med et eksempel på software, gener i højniveau sprog der køre oven på et OS, hvor 100ns er max og konsekvenserne er ligeså store som den der er i den video jeg linkede til, så som at sprænge trommehinderne på 200 mennesker lyttende til 5KW PA anlæg.

Min lomme definition på Realtime er når noget for et menneske sker øjeblikkeligt, og med en garanti på eksekveringstiden.

Jan Rasmussen

Definitionen på realtidsprogrammering har INTET med faste værdier for max latency, at gøre

Nu fik jeg opdateret siden og kan da godt se at du har ret.

Den med vejrudsigten var et godt eksempel på en meget lang latency uden betydning.

Mit udgangspunkt var bl.a.:
"Sikke noget vrøvl - eller rettere, et rigtig dårligt eksempel."
og "Jeg kan iøvrigt ikke se hvorfor man skal programmere anderledes om en proces tager 10ms eller 10 minutter? Nogle parametre er anderledes, men koden er den samme."

Jeg mener at den video jeg linkede til var et bederer eksempel og et svar på hvor koden ikke er ens, blot med andre parameter.

Poul-Henning Kamp Blogger

Det her er i den grad et "Løsning søger Problem" press-release.

Men lad os starte med et helt simpelt sanity-check:

"Real-time programming" i et sprog hvor man får en rund million hits hvis man søger på "garbage collection problem" ?

Et ur med sekundviser er vist rigeligt til den slags "real-time"

Viden/marketing forholder er et godt stykke under 1.000.

Dernæst: "Spaghettikode" i Java sproget - som ikke har "GOTO" ?

Mon vi ikke bare taler om "klytkode" skrevet af folk der slet ingen ting ved om realtidsprogrammering, finite-state-machines og event-driven programmering ?

Er det bare mig eller er vi igang med dot-com og 1999, hvor ethvert press-release, uanset hvor latterligt og fakta-stridigt, bliver kolporteret uantastet i pressen fordi man "nødig skulle tale den næste RedHat ned" ?

Esben Nielsen

Mon vi ikke bare taler om "klytkode" skrevet af folk der slet ingen ting ved om realtidsprogrammering, finite-state-machines og event-driven programmering ?

Nu skal du passe på med at sige event-driven og realtidsprogrammering i samme sætning:
Hvis du lader dit system være event-drevet, får du svært ved at verificere at alle events bliver håndteret til tiden, når de indtræffer oven i hinanden.

Som jeg fik det beskrevet det engang: Det er fint med udrykningsfartøjer, som kan komme foran de andre trafikanter, men er der nok af dem, laver de bare selv en trafikprop.

En mere forudsigelig strategi er at lade systemet være tids-drevet: Lad en periodisk timer drive systemet. På baggrund af denne kan forskellige dele så rekvirerer data fra sensorer og laver beregning ud fra et (næsten) fast mønster bestemt af timeren.
Ikke at dele af systemet lokalt set kan være drevet af event, men eventen skal stamme fra timeren og spredes ud i systemet på en rimelig forudseelig måde.

I Time Triggered CAN bruger man f.eks. en central timer, som trigger en besked over CAN bussen, som beder enhederne på et netværk om at sende deres data, som dermed kommer tilbage periodisk.

Jesper Louis Andersen

Måske Erlang? Det brugte Ericsson til telefon-switche.

Erlang er et soft-realtime system med en granularitet på få millisekunder. Det er nemlig mere end nok til at skrive telekomswitche, men det er ikke nok til at drive en atomreaktor hvor din latency skal yderligere ned. AXE-switchen har en del low-level systemdesign i C for at håndtere de dele der kræver mere realtid. Og den har også en del specialhardware, der hvor C på general purpose CPUer er for sløvt.

Hvis opgaven for eksempel hed at du har en webserver med 10000 connections og en arrival rate på 30000 req/s (3 for hver connection), så kan et Erlang system give service til 99.9945% af dem på mindre end 40ms. Og latency-kurven plottet som sandsynlighedsfunktion er stort set lineær. Jeg kan afsløre at mange andre webservere ikke har en lineær kurve når man laver samme test for dem og de ikke kan opfylde samme SLA på nogen måde.

Garbage Collection behøver iøvrigt ikke være det store problem for et realtidssystem. Heap size betyder ret meget for din GC pause latency og bare den er lille nok, så kan du sagtens nå at lave et GC nu og da. Go 1.6 har en ny collector skrevet af (blandt andet) Richard Hudson og den opnår en 10ms pause for en 250 gigabyte heap. For mindre heaps på en 4-16 gigabyte er dens pause time godt under et millisekund. Det betyder for eksempel at computerspil (hvor 16.7ms per frame giver 60 frames i sekundet) nu er indenfor rækkevidde.

Som PHK skriver har Java dog nogen default GCs der hurtigt ender i lange pausetimes. Men hvis du investerer i for eksempel Azul systems GC, så kan du undgå dette og benytte Java til ting der normalt er mere realtidsnært.

Ivan Skytte Jørgensen

Og meget af sandheden ligger sikkert i, at de folk (undertegnede inkluderet), som har behov for at skrive realtids-kode er elektroingeniører og ikke softwareingeniører


Jeg tror at der er en hel del sandhed i at elektroingeniøreer skriver lige så fin kode, som softwareingeniører laver elektriske kredsløb. Jeg formoder at de fleste elektroingeniører ville krumme tæer hvis de så mine lodninger. Ligesom jeg får mild hjertekvababbelse når jeg ser deres kode.

Hvilket er meget naturligt - vi er jo specialiseret i forskellig områder, og det er der nok en grund til.

Jens Henrik Sandell

Artiklen på digi.no kan bedst betegnes som fordærvet rakefisk. Den danske oversættelse kan jeg allerhøjst give betegnelsen dovent øl.
5 minutter på bitreactives hjemmeside er rigeligt til at indkategorisere produktet.
De har udviklet et programmeringsmiljø, som efterligner Labview og Lego Mindstorms flow-programmering.
Det har absolut intet med real-time programmering at gøre. Som andre har sagt tidligere i denne tråd, så er det "concurrent".
Bevares, det er jo snart tid til, at Mindstorms-generationen kommer ud og søger arbejde. Men jeg troede faktisk, at de videregående uddannelser stadig underviser i programmering inden for rammerne af de berømte 80 (evt 127) karakterer i bredden ... ... ... med ASCII karaktersæt.

Niels Danielsen

”flow-programmering”
Ja, det er nu mest event-driven.


Hmm, Det kan jeg ikke forstå, men du er ikke den første der nævner dette for mig.
De flow programering værktøjer jeg kender er alle primært scan baseret, f.eks. Simulink, CodeSys, Pilz configurator, SCADE, Xcos etc.
https://www.pilz.com/da-DK/eshop/00101002067093/PNOZmulti-Tools
Jeg ser flow programmering som erstatning for kredsløb lavet med operationsforstærkere, timere, gates flipflops etc.

Det er sjovt som de forskellige eksempler der er givet i denne tråd på 'Realtids programmering' kræver noget forskellige egenskaber.

Jeg er enig i det der er skrevet om at realtime krav ikke har noget med faste latency værdier, og at systemerne kan grupperes i hard, soft, og firm real time systemer.

De realtids systemer jeg har arbejdet med har haft en fast sample rate, hvor data bliver behandlet én sample af gangen, og hvor der er krav til både latency og jitter.

I sikkerheds systemer er der krav om at kende Worst Case Exceuction time (Variant af Turing's halting problem). WCET er en del af Safe process Time, som er den tid som sikkerheds systemet har til at standse ulykken. Det er f.eks. på en hydraulisk presse er givet ved den tid som det tager en hånd at bevæge sig fra lysgitteret, til kanten af værktøjet.
Man skal kunne dokumentere at der ikke er nogle gennemløb af koden der tager længere end WCET.

Hvis vi som et eksempel kigger på kontrol af en frekvensomformer, så foretager hardwaren sampling af strømme og PWM modulation med en timing i 10ns. området. Softwaren har så en procentdel af PWM cyklusen (~100us) til at beregne næste PWM setpunkt.

Man kan faktisk køre distribueret IO over f.eks. EtherCat med en sample frekvens på op til 16Khz, og stadig nå at læse input, beregne, og sætte output inden for en sample, over 100Mbps 'Ethernet'.
Men man må så ikke indsætte alm. Ethernet switche da de generere for lange latency (pga. Store and forward).

Eksemplet med audio er anderledes da da også er et samplet system, men det er 'lydkortet' der sørger for den konstante sample rate (og overholdelse af jitter kravet.)
De noder der behandler lyden behandler flere samples af gangen, og er ikke bundet af noget jitter krav, så længe at de når det inden for deadline.

Eksemplet med Erlang er endnu mere relaxed, man skal kunne (POTS) give klartone til et antal abonnenter inden for en given tid efter at de har løftet røret, men rækkefølgen er ligegyldig.

Der er også anlæg der køre event og tids baseret, f.eks. sorterings anlæg.
Her bliver en pakke scannet ind på et bånd, og der bliver genereret en event med et tidsstempel, og den centrale styring har noget tid til at beregne hvilket afkast der skal fange pakken på et givet tidspunkt. Den stramme tidsstyring ligger i det der flytter pakken, den centrale styring skal blot nå at regne 'afkast tidspunktet' inden det første afkast.

De sidste eksempler er event basseret, men jeg vil ikke kalde det flow programmering.

Jens Krabbe

Løsning søger Problem


Ikke for at afspore den interessante diskussion om samtidprogrammering og lignende herover, men følger man digi.no-linket i artiklen, kommer man til en stort set enslydende artikel, hvor de norske IT-professionelle fremhæver samme bekymringer.
Den artikel er tilsyneladende også bare en slet skjult salgsannonce for http://www.bitreactive.com/ skrevet af Erlend Tangeraas Lygre.

På den baggrund synes jeg, at artiklen her af Henning Mølsteder et tyndt stykke journalistik.

Esben Nielsen

Problemet er, at standeard java er helt uegnet til realtidsprogrammering. For at få det til virke fjerner man så meget fra Java, at sproget bliver rigtigt grimt - på linie med fortran77 og matlab.

Realtidsjava er en managementting, hvor et ellers ok værktøj skal bruges også, hvor det ikke giver nogen mening mere, da man har alt for stor tiltro til ensretning.

Realtidssystemer kodes i C, C++ og Ada - eller VHDL.

Jens Henrik Sandell

”flow-programmering”
Ja, det er nu mest event-driven.

Hmm, Det kan jeg ikke forstå, men du er ikke den første der nævner dette for mig.
De flow programering værktøjer jeg kender er alle primært scan baseret, f.eks. Simulink, CodeSys, Pilz configurator, SCADE, Xcos etc.
https://www.pilz.com/da-DK/eshop/00101002067093/PNOZmulti-Tools
Jeg ser flow programmering som erstatning for kredsløb lavet med operationsforstærkere, timere, gates flipflops etc.

Det er sjovt som de forskellige eksempler der er givet i denne tråd på 'Realtids programmering' kræver noget forskellige egenskaber.

Kære Niels,
Den sidste kommentar var nødvendig for at distancere mig fra "realtidsdebatten". Jeg erkender, at jeg ikke har været helt tydelig i mit indlæg, m.h.t. at afvise BitReactives produkt og digi.no's sludder. Men vær forvisset om at jeg ikke ser noget behov for at give artiklen mere medietid.

PS. du henviser til en hjemmeside, hvor "produktet" umiddelbart minder meget om National Instruments Labview. Hvis du vil være så venlig og kigge en ekstra gang på Labview, så vil du se at de faktisk har både operationsforstærkere, gates, registre og complekse byggeblokke såsom FFT m.v. Og Labview er eventdriven. Period.

Henrik Baastrup

Tilbage i slutningen af 80'erne arbejde jeg på en satellit (ERS-1) med 5 radar instrumenter ombord, og alle 5 instrumenter havde en realtime programmering for data opsamling. Da det var 5 forskellige firmaer der havde lavet instrumenterne, var koden meget forskelige, men løsningerne megen ens: Man linker alle ens opgaver op i en kø, første opgave er at sæter en watchdog timer (hardware timer) i gang, sidst opgave er at klappe hunden. Hvis jeg ikke kommer til enden af køen inden hunden vågner, er jeg bagud og har et problem. For en radar betyder det, at jeg måske har mistet et ekko. For et musik instrument betyder det mærklige lyde, da frekvens spekteret flyttes. For en vejrudsigt betyder det er den er uinteressant. Køen bliver sat i gang med et regelmæssige tidsinterval, min sample tid, kontrolleret enten af watchdogen eller af en anden timer.
Det var faktisk meget strutureret kode jeg arbejde med, selv om meget var skrevet i assembler, det var klart for mig at der var gjort meget for at holde koden læsbar, men jeg mener faktisk at det var den simple løsning, med at dele opgaven op i meget afgrænsede domæner der hjalp, der var kun et eller to mulige interrupts eller events (det er ikke helt sandt), tingene blev afviklet på linje, ingen parralle programmering (instrumenterne havde kun 1 CPU, ingen multi core), så det gav mening.
Jeg har set mange mærklige forsøg på at lave realtime programmering siden, nogle vellykket andre noget rod, selv I Java har jeg set vellykket programmering, løsningen på garbage collection problemet er at havde styr på din garbage, men det er det egentligt også i C/C++ hvis du vil undgår memory leaks.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen