Race conditions

Ett race condition handlar om felsituationer som beror på att flera processer eller trådar tävlar om samma resurs.

Exempel

Ett typfall är från databasvärlden där två processer försöker öka en räknare utan att använda någon sorts låsning, semafor eller liknande kommunikation.

I exempel går det kanske normalt bra

• Process A läser värdet fem som en räknare har
• Process A skriver det värdet plus ett, dvs sex, till räknaren
• Process B läser värdet sex som en räknare har
• Process B skriver det värdet plus ett, dvs sju, till räknaren

Nu har räknaren helt korrekt ökats med två.

Ibland vinner fel process

• Process A läser värdet tio som en räknare har
• Process B läser värdet tio som en räknare har
• Process A skriver det värdet plus ett, dvs elva, till räknaren
• Process B skriver det värdet plus ett, dvs elva, till räknaren

Nu har räknaren felaktigt ökats med endast ett, trots att två olika processer var och en ville öka den med ett.

Åtgärd

Det finns flera olika lösningar på problemet. De går alla ut på att endast en process i taget har rätt att utföra operationerna läsning och skrivning i taget. På något av flera olika vis reserverar man en process räknaren åt sig, utför läsning och skrivning samt släpper reservationen. Om en process vill reservera räknaren men den redan är reserverad, måste processen vänta på att räknaren blir ledig.

Några olika begrepp som används i de olika lösningarna, är semafor, monitor, atomär, låsning.

Att hitta race condition-fel

Man kan endera analysera eller testa för att hitta race condition-fel.

• Analys är den säkrare metoden. Tyvärr druknar metoden lätt i större projekt. Det finns helt enkelt för mycket kod att gå igenom. Om många olika personer har varit inblandade, om det är ont om tid, om pengar för utveckling börjar bli knappa och om inte analys har används genomgående redan från början av projektet, ja då är det i det närmaste omöjligt att i efterhand tillämpa analys. Tyvärr är det ont om verktyg för att automatisera denna sorts analys, alltså kvarstår det att utföra analysen manuellt.

Om några symptom inte har märkts av än, av några sådana fel, så är det svårt att ävertyga projektledningen att spendera tid och pengar på denna sorts analys.

Att ens råka ut för symptom kan vara nog svårt. För den enstake utvecklaren som sitter ensam på sin uvecklarstation och som kör en process eller en tråd i taget, är det i det närmaste omöjligt.I verkliga livet är analys tyvärr inte kostnadseffektiv med ett tillräckligt lågt pris.

• Testning kan användas för att provocera fram symptom och för att isolera felkällan. Eftersom många race condition-fel har låg sannolikhet att uppträda, kan man med ren funktionell testning knappast provocera fram felet. Däremot klarar man det med hjälp av stresstestning och dess läggande av hög last mot systemet.

Med många anrop fås många försök att provocera fram felet. Även om varje försök har en tusendels chans att få konkurrerande processer att utföras i fel ordning (se exemplet ovan), så är sannolikheten till minst en sådan instans väldigt hög efter flera tusen eller miljoner anrop.

Se även

• Dödlig låsning (deadlock)
• Låsning (även Locking).

Redigera?

Artikeln skriven 2009-01-18 av Learning4sharing

Inga kategorier för denna artikel än...

Intresserad av fler artiklar?

VSOP
W C Fields
Tonsill
Snodd
Kökkenmödding
Hydrologi
Institut
Anders Nunstedt
Daniel Swedin