Når flere tråde deler data, kan deres operationer flettes ind i hinanden (interleave) midt i en opdatering med flere trin og skabe en race condition — en fejl, hvor udfaldet afhænger af uforudsigelig timing. Synkronisering er det sæt værktøjer, der gennemtvinger sikker rækkefølge.
ser atomisk ud, men er i virkeligheden 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 ┘
Vinduet mellem læsning og skrivning er en critical section — kode, der rører delt tilstand og ikke må køre samtidigt.
pthread_mutex_lock(&m);
count++; // critical section — eksklusiv
pthread_mutex_unlock(&m);
Locks løser races, men indfører nye risici: deadlock (tråde, der venter på hinandens locks), priority inversion og contention (tråde serialiseres, hvilket dræber parallelismen). Tommelfingerreglen: hold critical sections korte, og tag altid flere locks i en konsistent global rækkefølge.
Samtidighedsfejl er blandt de sværeste at finde — de er ikke-deterministiske og forsvinder ofte under en debugger. Interviewere vil se, at du kan spotte en critical section, vælge den rigtige primitiv (mutex vs. semafor vs. atomic) og ræsonnere om fejltilstandene (deadlock, contention). Dette gælder direkte for enhver flertrådet server, delt cache eller tæller.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér