P23: Solve Lost Wakeup Issue (Built on P22)

[illuminati2285]

Note:
This branch (p23) is built directly on top of my completed p22 branch(PR [#215]) . I am pointing this PR to p20-exec as the base branch since the official upstream branches are not available yet. (Once the p23 branch is created, the base branch of this PR can be changed to p23 for merging.)
For the P22 changes please see my previous PR here: [#215]
The changes below specifically outline the P23 bug fix for the lost wakeup problem.

Overview

This PR solves the fatal "Lost Wakeup" concurrency bug present in the naive sleep implementation from P22.

In P22, a process had to manually release its protecting lock before calling sleep(). This created a dangerous time gap: if a hardware interrupt fired in that exact fraction of a second, it would trigger wakeup(). Because the process hadn't fully transitioned to the SLEEPING state yet, the wakeup signal was lost. The process would then finish going to sleep and stay stuck forever.

This PR fixes the issue by allowing a process to hold onto its lock while calling sleep(). Inside sleep(), the kernel safely acquires the global ptable.lock (which blocks all incoming wakeups) before releasing the process's data lock. This safe switch ensures that no wakeup signals are ever missed.

Key Changes

• defs.h, proc.c
  • Updated the signature of sleep() to accept a protecting spinlock as a second argument: void sleep(void *chan, struct spinlock *lk).
  • Implemented safe lock handling in sleep(): it first acquires ptable.lock, releases the original lock safely, sets the process state to SLEEPING, and restores the locks when the process wakes up.
• ide.c, sleeplock.c, log.c
  • Removed the manual release() and acquire() wrappers around the sleep calls.
  • Updated all instances of sleep() to pass their protecting spinlocks directly into the function:
    • ide.c now calls sleep(b, &idelock);
    • sleeplock.c now calls sleep(lk, &lk->lk);
    • log.c now calls sleep(&log, &log.lock);

Testing
Ran the multi-process boot sequence successfully.
Executed the custom stress.c user program simulating extreme high contention (4 concurrent processes flooding the buffer cache and disk with massive reads/writes).

[illuminati2285]

Sir @codenet , I noticed this PR was closed without merging. Could you please let me know the reason? If any changes are needed, I would be happy to update the PR.

[codenet]

Hey I deleted the p22-sleeplock branch. I think GH automatically closed the PR on that change. Let's use discord p23 channel for coordination on this.