Når flere tråder deler data, kan operasjonene deres flettes midt i en oppdatering med flere steg, og skape en race condition — en feil der resultatet avhenger av uforutsigbar timing. Synkronisering er settet med verktøy som tvinger fram trygg rekkefølge.
count++ ser atomisk ut, men er egentlig read-modify-write:
// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐ interleaving loses an update:
// thread B: read count (0) ─┤ both read 0, both write 1 → count == 1, not 2
// thread A: write 1 │
// thread B: write 1 ┘
Vinduet mellom lesing og skriving er en critical section — kode som berører delt tilstand og ikke må kjøre samtidig.
pthread_mutex_lock(&m);
count++; // critical section — eksklusiv
pthread_mutex_unlock(&m);
Locks løser races, men innfører nye risikoer: deadlock (tråder som venter på hverandres locks), priority inversion og contention (tråder serialiseres, og dreper parallellitet). Tommelfingerregelen: hold kritiske seksjoner korte, og skaff alltid flere locks i en konsistent global rekkefølge.
Samtidighetsfeil er blant de vanskeligste å finne — de er ikke-deterministiske og forsvinner ofte under en debugger. Intervjuere vil se at du kan oppdage en kritisk seksjon, velge riktig primitiv (mutex vs semafor vs atomic), og resonnere om feilmodusene (deadlock, contention). Dette gjelder direkte for enhver flertrådet server, delt cache eller teller.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner