Exercises — Synchronization primitives (locks, barriers)

Fix hai ek lock (mutex) jo ek hardware atomic jaise Test-and-Set ya Compare-and-Swap par bana hota hai. Ek plain bool flag fail hota hai kyunki "check then set" do instructions hain — check aur set ke beech mein, doosra thread ghus jaata hai. Sirf ek atomic read-modify-write purani value padhta hai AUR nayi value ek indivisible step mein likhta hai, isliye exactly ek hi thread jeet sakta hai. Dekho Atomic operations.

• (a) Lock — ek shared variable ko simultaneous writes se bachata hai (mutual exclusion).
• (b) Barrier — ek meeting point jahan sabhi $N$ threads wait karte hain jab tak sab aa na jaayein, phir sab milke aage badhte hain. Trick: "ek resource, kaafi writers" → lock. "ek wall jahan sab wait karte hain" → barrier.

acquire spin karta hai jab tak TAS 1 return karta hai.

• T2 pehle chalta hai: old value 0 padhta hai, flag ko 1 set karta hai, 0 return karta hai → 0 != 1, toh T2 enter karta hai.
• T1: old value 1 padhta hai, 1 return karta hai → spin karta hai.
• T3: old value 1 padhta hai, 1 return karta hai → spin karta hai. Exactly ek winner (T2). Return ki gayi values (T2, T1, T3) order mein [0, 1, 1] hain.

$W_{avg}=\frac{T_c}{2}=\frac{40}{2}=20\mu s.$

Dekho Figure s01 neeche: chaar queued threads $1T_c,2T_c,3T_c,4T_c$ (bars) wait karte hain, aur dashed line unka mean mark karti hai. Sum $=(1+2+3+4)T_c=10T_c$. 4 threads mein average: $\bar{W}=\frac{10T_c}{4}=2.5T_c=\frac{N}{2}{T}_c=\frac{5}{2}\times 40=100\mu s.$ Toh exact answer hai $\frac{N}{2}{T}_c=100\mu s$. Parent ka shorthand $\frac{(N-1)}{2}{T}_c=\frac{4}{2}\times 40=80\mu s$ thoda kam approximation hai — difference pehchaanna achha hai, lekin is discrete FIFO queue ke liye $100\mu s$ sahi hai.

Spins per thread $=\frac{T_c}{t_{spin}}=\frac{40000ns}{50ns}=800$ iterations. $E_{waste}=800\cdot 4\cdot 2\text{nJ}=6400\text{nJ}=6.4\mu J.$ Contention ke saath yeh growth ($N-1$) exactly wahi reason hai kyun blocking locks exist karte hain: ek sota hua thread ~0 energy burn karta hai. Dekho Thread scheduling.

Generation ke bina:

1. Phase 1: A, B, C sab pahunchte hain, count 3 hit karta hai, C count=0 reset karta hai aur CV par broadcast karta hai.
2. A jaagta hai, niklta hai, phase 2 mein race karta hai, count++ karta hai → count = 1.
3. B (phase 1 se) jaagne mein slow tha; woh condition re-check karta hai. Lekin condition ("kya barrier khul gayi?") ek fresh phase-2 arrival jaisi lagti hai — B aur A ki states tangled hain. B ya toh bina sab phase-2 ke pahunche slip through kar sakta hai, ya phir permanently count == 3 ke wait mein stuck ho sakta hai jo already reset ho chuka hai. Generation ke saath:

• Har thread CV par wait karne se pehle my_gen = b->generation record karta hai.
• Last thread generation++ karta hai, isliye purane aur naye episodes ke different numbers hote hain.
• Ek jaaga hua thread tabhi aage badhta hai jab b->generation != my_gen — yaani jab uska episode sach mein khatam hua ho, na sirf tab jab CV signal hua ho. Yeh har barrier crossing ko logically alag banata hai, reuse race khatam kar deta hai. Related idea: Memory consistency models mein spurious wakeups ke liye bhi wahi "loop aur real condition re-check" discipline chahiye.

Haan, ek weak model par dono 0 read kar sakte hain: har core apna store apne load ke baad reorder kar sakta hai, isliye dono loads purana 0 dekhte hain isse pehle ki koi store visible ho. Yeh classic "store buffering" outcome hai. Fix hai ek memory fence (ek full barrier instruction) jo har thread mein store aur load ke beech rakha jaata hai. Yeh store ko globally visible hone ke liye force karta hai load execute hone se pehle, r1 == 0 && r2 == 0 ko impossible banata hai. Yeh exactly Memory consistency models ka territory hai aur hood ke andar Cache coherence protocols dwara enforce hota hai.

typedef struct { int S; lock_t lock; cond_t cv; } sem_t;
 
void sem_init(sem_t *s, int val) {
    s->S = val; lock_init(&s->lock); cond_init(&s->cv);
}
 
void sem_wait(sem_t *s) {
    lock(&s->lock);
    while (s->S <= 0)          // LOOP, not if: guards spurious wakeups
        cond_wait(&s->cv, &s->lock);
    s->S--;                    // ab slot lena safe hai
    unlock(&s->lock);
}
 
void sem_signal(sem_t *s) {
    lock(&s->lock);
    s->S++;
    cond_signal(&s->cv);       // ek waiter ko jagao
    unlock(&s->lock);
}

Correctness:

• lock S par mutual exclusion deta hai, isliye counter par koi lost updates nahi.
• while (na ki if) jaagne ke baad S > 0 re-check karta hai — spurious wakeups ke against aur doosre thread ke freed slot pehle le lene ke against essential hai.
• val = 1 set karna ek plain mutex deta hai; bada val multiple threads ko allow karta hai (size $S$ ka resource pool).

Deadlock interleaving:

1. T1 A acquire karta hai. 2. T2 B acquire karta hai. 3. T1 B ke liye wait karta hai (T2 ke paas hai). 4. T2 A ke liye wait karta hai (T1 ke paas hai). Circular wait → koi aage nahi badhta. Universal fix: ek global lock ordering laago — har thread ko locks same fixed order mein acquire karne chahiye (maan lo, hamesha A pehle, phir B). Phir ek cycle impossible hai: koi bhi thread "higher" lock hold karte hue "lower" lock ka wait nahi karta, isliye Coffman ki chaar conditions mein se ek (circular wait) tod di jaati hai. Dekho Deadlock and livelock.

Ek plain bool par bana lock fail karta hai kyunki check-and-set ::: atomic nahi hai (do alag steps doosre thread ko interleave karne dete hain) Hold $T_c$ ke liye expected per-arrival spin wait hai ::: $T_c/2$ Ek barrier ko back-to-back phases mein survive karne ke liye generation counter chahiye ::: reuse ke across (the reuse race) Chaar-condition deadlock ek global ::: lock ordering se tod diya jaata hai (circular wait rokta hai)