Starvation & race

1) Forklaring
Halvvejs - starvation VED jeg hvad betyder:

Starvation (udsultning) er det som der sker hvis een kørende process får mere processortid end alle andre processer på maskinen. I den situation siger man at de andre processer er udsat for 'starvation'. Forestil dig f.eks. en kommunikationsprocess, med maksimum priotitet (= systemprioritet). Under normale omstændigheder, betyder det blot at komm. processer får sine ressourcer næsten øjeblikkeligt, kan checke for om der er sket noget, og så frigive sine ressourcer igen, hvorfor de andre processer kører normalt. MEN ... hvis nu kommunikationen svigter, ja så står komm. processen i sin maksimale wait-tid og "hænger" - og pga. sin høje prioritet forhindrer den i praksis andre processer i at få tid, og dermed lave noget fornuftigt. (De bliver udsat for 'starvation'.)

Race har jeg et GÆT på hvad betyder:
Race er når et program går i internt loop, f.eks. en uendelig løkke, hvor der ikke sker noget/ret meget i. (while (true) idx++; f.eks.) Det at processen laver race vil - ja du gættede de, føre til starvation af de andre processer.

2) Hvordan undgår man disse
Nogen mirakel formular findes ikke - så ville Windows jo aldrig hænge ! Fidusen er selvfølgelig at gå mod at forhindre ovenstående symptomer - dvs. nedsætte programmets prioritet når det går i gang med opgaver som kan ende med at "hænge" eller lave opgaven trådet og så indbygge en timerfunktion, der slår tråden ned efter et nærmere defineret tidsinterval uden svar. Tilsvarende kan man kode "defensivt", dvs. i sin kode tage højde for at noget KAN gå galt, og indrette sin kode derefter:

while (idx != 0)
{
  // et eller andet
  idx--;
}

Ændres til

while (idx <= 0)
{
  // Et eller andet
  idx--;
};

Sidstnævnte vil altid stoppe på et eller andet tidspunkt uanset idx's startværdi, fordi et tal der tælles nedad altid vil ende med at blive negativt. Version 1 vil ikke stoppe hvis værdien 0 ikke rammes, f.eks. fordi man fejlagtigt får talt idx ned to gange inde i loop'et. Version 2 ville have stoppet alligevel.

En "race condition" er når to (eller flere) processer udfører noget på delte data, og den endelig resultat afhænger af rækkefølgen hvori de udføres.

Eksempel: Min bankkonto (som jeg har fælles med min kone) indeholder 1000 kr. Jeg (A) vil hæve 500 kr. Min kone (B) vil hæve 500 kr.

Dårligt (for banken) forløb:

A: Check saldo. Resultat: 1000
                                B: Check saldo. Resultat: 1000
                                B: Hæv 500. Opdatér saldo: 1000 - 500 = 500
A: Hæv 500. Opdatér saldo: 1000 - 500 = 500.

Voila. Jeg har tjent 500 kr.

Man undgår race conditions ved brug af monitorer, synkroniseret kode, semaforer, mutex'er eller andre synkroniseringsmekanismer, der i ovenstående tilfælde ikke tillader B at læse saldoen med henblik på at ændre den *før* A's operationer er færdige. Den samlede mængde af operationer, som A (hhv B) laver kaldes en transaktion.
Der er forskellige måder at styre transaktioner på, hvoraf nogle er simple (og naive), og andre er meget komplicerede. De simple kan med fordel bruges i systemer med lav belastning, mens der skal mere avancerede metoder til for ikke at sløve systemer med høj performance...

dittmer >> OK, så ved vi det ! Race undgår man så ved at lave thread-safe kode med en af de metoder som du beskriver.

soepro> Ja, man kan sige at du flytter en race condition væk fra de "følsomme data", og derfor (jf. definitionen ovenfor) forsvinder den...