Rørledning (software) - Pipeline (software)

I software engineering , en rørledning består af en kæde af behandlingselementer ( processer , tråde , korutine , funktioner , etc. ), anbragt således at udgangen af hvert element er indgangen på den næste; navnet er analogt med en fysisk pipeline . Normalt tilvejebringes en vis mængde buffering mellem på hinanden følgende elementer. Oplysningerne, der strømmer i disse rørledninger, er ofte en strøm af poster , bytes eller bits , og elementerne i en rørledning kan kaldes filtre ; Dette kaldes også design og mønster for rør og filtre . Forbindelse af elementer til en rørledning er analog med funktionssammensætningen .

Smalt set er en rørledning lineær og envejs, selvom udtrykket undertiden anvendes på mere generelle strømme. For eksempel kan en primært en-retningsrørledning have en vis kommunikation i den anden retning, kendt som en returkanal eller backchannel, som i lexer-hacket , eller en rørledning kan være fuldt tovejs. Strømme med et-retningsbestemt træ og dirigerede acykliske graftopologier opfører sig på samme måde som (lineære) rørledninger - manglen på cyklusser gør dem enkle - og kan derfor løst kaldes "rørledninger".

Implementering

Rørledninger implementeres ofte i et multitasking- operativsystem ved at starte alle elementer på samme tid som processer og automatisk betjene datalæsningsanmodningerne ved hver proces med de data, der er skrevet af opstrømsprocessen - dette kan kaldes en flerbehandlet pipeline. På denne måde skiftes CPU'en naturligt blandt processerne af planlæggeren for at minimere dens inaktivitetstid. I andre almindelige modeller implementeres elementer som lette tråde eller som coroutines for at reducere OS-omkostningerne, der ofte er involveret i processer. Afhængigt af operativsystemet kan tråde planlægges direkte af operativsystemet eller af en trådadministrator. Coroutines er altid planlagt af en coroutine manager af en eller anden form.

Normalt blokerer læse- og skriveanmodninger operationer, hvilket betyder, at udførelsen af ​​kildeprocessen ved skrivning suspenderes, indtil alle data kunne skrives til destinationsprocessen, og ligeledes udførelsen af ​​destinationsprocessen ved læsning, suspenderes, indtil i det mindste nogle af de anmodede data kunne fås fra kildeprocessen. Dette kan ikke føre til en blokering , hvor begge processer vil vente på ubestemt tid for hinanden at svare, da mindst en af ​​de to processer snart derefter vil få sin anmodning serviceret af operativsystemet og fortsætte med at køre.

For ydeevne bruger de fleste operativsystemer, der implementerer rør, rørbuffere , som gør det muligt for kildeprocessen at levere flere data end destinationsprocessen i øjeblikket er i stand til eller villig til at modtage. Under de fleste enheder og Unix-lignende operativsystemer er der også en speciel kommando tilgængelig, som implementerer en rørbuffer af potentielt meget større og konfigurerbar størrelse, typisk kaldet "buffer". Denne kommando kan være nyttig, hvis destinationsprocessen er betydeligt langsommere end kildeprocessen, men det er alligevel ønsket, at kildeprocessen kan fuldføre sin opgave så hurtigt som muligt. F.eks. Hvis kildeprocessen består af en kommando, der læser et lydspor fra en CD, og destinationsprocessen består af en kommando, der komprimerer bølgeformlyddataene til et format som MP3 . I dette tilfælde vil buffering af hele sporet i en rørbuffer gøre det muligt for CD-drevet at dreje hurtigere ned og gøre det muligt for brugeren at fjerne CD'en fra drevet, før kodningsprocessen er afsluttet.

En sådan bufferkommando kan implementeres ved hjælp af systemopkald til læsning og skrivning af data. Spildende travl ventetid kan undgås ved hjælp af faciliteter såsom afstemning eller valg eller multitrådning .

Nogle bemærkelsesværdige eksempler på pipelinesoftwaresystemer inkluderer:

VM / CMS og z / OS

CMS-rørledninger er en port af pipeline-ideen til VM / CMS- og z / OS- systemer. Det understøtter meget mere komplekse rørledningsstrukturer end Unix-skaller, med trin, der tager flere inputstrømme og producerer flere outputstrømme. (Sådan funktionalitet understøttes af Unix-kernen, men få programmer bruger den, da den giver komplicerede syntaks- og blokeringsfunktioner, selvom nogle skaller understøtter den via vilkårlig filbeskrivelsestildeling ).

Traditionelle applikationsprogrammer på IBM mainframe-operativsystemer har ingen standardinput- og outputstrømme, der muliggør omdirigering eller piping. I stedet for gydeprocesser med eksterne programmer har CMS Pipelines en letvægtsdispenser til samtidig at udføre forekomster af indbyggede programmer til at køre rørledningen. Mere end 200 indbyggede programmer, der implementerer typiske UNIX-værktøjer og interface til enheder og operativsystemtjenester. Ud over de indbyggede programmer definerer CMS Pipelines en ramme, der tillader brugerskrevne REXX- programmer med input- og output-streams, der kan bruges i rørledningen.

Data på IBM-mainframes ligger typisk i et Record-orienteret filsystem, og tilsluttede I / O-enheder fungerer i record-tilstand i stedet for stream-mode. Som en konsekvens håndteres data i CMS-rørledninger i record-tilstand. For tekstfiler indeholder en post en tekstlinje. Generelt buffer CMS Pipelines ikke dataene, men videregiver dataoptegnelser på en lås-trin måde fra det ene program til det næste. Dette sikrer en deterministisk strøm af data gennem et netværk af sammenkoblede rørledninger.

Objektrørledninger

Foruden byte-strømbaserede rørledninger er der også objektrørledninger. I en objektrørledning behandler elementer outputobjekter i stedet for tekst. Windows PowerShell inkluderer en intern objektpipeline, der overfører .NET- objekter mellem funktioner inden for PowerShell-kørselstiden. Kanaler , der findes i Limbo-programmeringssproget, er andre eksempler på denne metafor.

Rørledninger i GUI'er

Grafiske miljøer som RISC OS og ROX Desktop gør også brug af rørledninger. I stedet for at angive en gemdialogboks, der indeholder en filhåndtering, så brugeren kan specificere, hvor et program skal skrive data, giver RISC OS og ROX en gemdialogboks, der indeholder et ikon (og et felt, der angiver navnet). Destinationen angives ved at trække og slippe ikonet. Brugeren kan slippe ikonet overalt, hvor en allerede gemt fil kunne blive droppet, inklusive på ikoner i andre programmer. Hvis ikonet falder ned på et programs ikon, indlæses det, og det indhold, der ellers ville være blevet gemt, sendes videre til det nye programs standardindgangsstrøm.

For eksempel kan en bruger, der surfer på nettet, komme over et komprimeret .gz-billede, som de vil redigere og uploade igen. Ved hjælp af GUI-rørledninger kunne de trække linket til deres de-arkiveringsprogram, trække ikonet, der repræsenterer det udpakkede indhold, til deres billededitor , redigere det, åbne dialogboksen Gem som og trække ikonet til deres uploadsoftware.

Konceptuelt kunne denne metode bruges med en konventionel gemdialogboks, men dette ville kræve, at brugerens programmer havde en åbenbar og let tilgængelig placering i filsystemet, der kan navigeres til. I praksis er dette ofte ikke tilfældet, så GUI-rørledninger er sjældne.

Andre overvejelser

Navnet "rørledning" kommer fra en grov analogi med fysisk VVS, idet en rørledning normalt lader information flyde i kun én retning, ligesom vand ofte strømmer i et rør.

Rør og filtre kan ses som en form for funktionel programmering , der bruger byte-streams som dataobjekter; mere specifikt kan de ses som en særlig form for monade til I / O .

Begrebet rørledningen er også central for Cocoon webudvikling ramme eller til enhver XProc (W3C Standards) implementeringer, hvor den tillader en kildestrøm, der skal modificeres før eventuel skærm.

Dette mønster tilskynder brugen af ​​tekststrømme som input og output af programmer. Denne afhængighed af tekst skal redegøres, når der oprettes grafiske skaller til tekstprogrammer.

Se også

Bemærkninger

  1. ^ Der er undtagelser, såsom "brudt rør" -signaler.
  2. ^ "Monadic I / O og UNIX shell programmering" .

eksterne links