Race conditions

Fra IT2
Hopp til: navigasjon, søk

Vennligst refer til wikipedia: http://en.wikipedia.org/wiki/Race_condition Eksakt kopi, bare denne artikkelen er oversatt til norsk.

Race condition.svg

En race condition eller race hazard er en feil i et elektronisk system eller prosess hvor utskriften og/eller resultatet av prosessen er uventet og kritisk avhenging av rekkefølgen av andre hendelser.

Race condition kan forekomme i elektroniske systemer, spesiellt logiske kretser, og i data sowftware, hovedsakelig i flertrådprogrammer.


Elektronikk

Et typisk eksempel på en race condition kan forekomme i et system av logiske porter, hvor inndata kan variere. Hvis utdataene baserer seg på inndataene, kan det bare bli definert for steady-state signaler. Når inndataene endres vil det være en liten forsinkelse før utdataene endres grunnet den fyiskse naturen til det elektroniske systemet. For en kort periode kan utdataene endres til en uønsket verdi før den går tilbake til den korrekte. Noen systemer kan tolerere slike feil men, hvis disse utdataene f.eks.fungerer som en klokke for andre systemer som inneholder minne, kan systemet fort avvike fra sin ønskede virkemåte og den midlertidige feilen blir permament.

Ordentlige design teknikker (f.eks. Karnaugh maps) oppfordrer designere til å kjenne igjen og eleminere race conditions før de skaper problemer.

Noen logiske elementer kan bli metastabile, og dette skaper enda flere problemer for krets designere.


Kritiske og ikke-kritiske race conditions

Et kritisk ”race” oppstår når endringer i rekkefølgen i interne variabler avgjør hvordan utfallet til maskinens tilstand ender opp i.


Et ikke-kritisk ”race” oppstår når endringer i rekkefølgen i interne variabler ikke endrer tilstanden til maskinen. Med andre ord, et ikke-kritisk ”race” oppstår ved flytting til en ønsket tilstand betyr at mer enn én intern variabel må endres samtidig, men uansett hvilken rekkefølge disse interne variablene endres, vil den endelige tilstanden være den samme.


Forenklet forklaring

I mange arbeidsmiljøer, er det ofte vanskelig for programvareutviklere eller ingeniører å forklare hva race conditions er til ledere, som kanskje ikke er så kjent med tekniske detaljer. I dette tilfellet kan en hesteløp metafor brukes:

Eksempel: Et hesteløp representerer et dataprogram. Hver hest representerer et bestemt element i programmet, som alle kjører parallelt, for eksempel brukergrensesnitt grafikk og nettverkskommunikasjon kjører samtidig. Programvaren kan kreve at en bestemt hest må vinne kappløpet for at programmet skal kjøre skikkelig. Programmet kan fungere problemfritt dersom hest nummer 5 kommer i mål først, mens programmet krasjer hvis en annen hest kommer i mål før hest nummer 5. En mulig løsning på dette problemet, er å legge til synkronisering slik at hest nummer 5 alltid kommer i mål før hest nummer 2. Metaforisk, så vil jockey nummer 2 og 5 samarbeide slik at nummer 5 alltid kommer først i mål.

Programmer kan kjøre på ulike hastigheter på ulike datasystemer eller ulike situasjoner (f.eks variasjoner i Internet forbindelser eller prosessor lasting), som kan føre til at programmer krasjer tilfeldig i enkelte systemer og aldri på andre. Den uforutsigbare naturen til en intermitterende feil forårsaket av en race condition er en hyppig kilde til frustrasjon i programvareutvikling yrket.


Eksempel

Her er et enkelt eksempel på race condition:

Anta at to tråder, T1 og T2 begge ønsker å øke verdien til en global integer, i, med en. Idielt sett skjer den følgende sekvensen av operasjoner:

  1. Integer i = 0 (minnet)
  2. T1 leser verdien til i fra minnet og legger den i register1: 0
  3. T1 øker verdien av i inni register1: register1 + 1 = 1
  4. T1 lagrer verdien fra register1 i minnet: i = register1 = 1
  5. T2 leser verdien til i fra minnet og legger den i register2: 1
  6. T2 øker verdien til i inni register2: register2 + 1 = 2
  7. T2 lagrer verdien fra register2 i minnet: i = register2 = 2
  8. Integer i = 2 (minnet)

I eksempelet over er den endelige verdien av i som forventet 2. Men hvis de to trådene kjører samtidig uten synkronisering eller låsing kan i få feil verdi:

  1. T1 leser verdien til i fra minnet og legger den i register1: 0
  2. T2 leser verdien til i fra minnet og legger den i register2: 0
  3. T1 øker verdien til i inni register1: register1 + 1 = 1
  4. T2 øker verdien til i inni register2: register2 + 1 = 1
  5. T1 lagrer verdien fra register1 i minnet: i = register1 = 1
  6. T2 lagrer verdien fra register2 i minnet: i = register2 = 1
  7. Integer i = 1 (minnet)

Den endelige verdien til i er 1 istedenfor det forventede resultatet 2. Dette skjer fordi øknings operasjonene i det andre scenarioet ikke er gjensidig eksklusive. Gjensidig eksklusive operasjoner kan ikke bli avbrutt mens de aksesserer noen ressurser, f.eks. minnet. I det første scenarioet ble ikke T1 avbrutt mens den aksesserte variabelen i, så operasjonen var gjensidig ekslusiv.