Kun useat threadit jakavat dataa, niiden operaatiot voivat limittyä (interleave) kesken monivaiheisen päivityksen, tuottaen race conditionin — bugin, jossa lopputulos riippuu ennustamattomasta ajoituksesta. Synkronointi on työkalujen joukko, joka pakottaa turvallisen järjestyksen.
näyttää atomiselta mutta on todellisuudessa read-modify-write:
count++// 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 ┘
Lukemisen ja kirjoittamisen välinen ikkuna on critical section — koodi, joka koskee jaettuun tilaan eikä saa ajaa rinnakkain.
pthread_mutex_lock(&m);
count++; // critical section — exclusive
pthread_mutex_unlock(&m);
Lukot ratkaisevat racet mutta tuovat uusia riskejä: deadlock (threadit odottavat toistensa lukkoja), priority inversion ja contention (threadit sarjallistuvat, tappaen rinnakkaisuuden). Nyrkkisääntö: pidä critical sectionit lyhyinä ja hanki useat lukot aina johdonmukaisessa globaalissa järjestyksessä.
Rinnakkaisuusbugit ovat vaikeimpia löytää — ne ovat epädeterministisiä ja katoavat usein debuggerin alla. Haastattelijat haluavat nähdä, että osaat tunnistaa critical sectionin, valita oikean primitiivin (mutex vs. semaphore vs. atomic) ja päätellä vikatilat (deadlock, contention). Tämä pätee suoraan mihin tahansa monisäikeiseen palvelimeen, jaettuun cacheen tai laskuriin.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita