The states are:
- Loading: A program being read from the batch disk. This is caused either by a process issuing a fork request for the program or by on system boot.
- Ready: A process ready to execute. A process P becomes ready to execute either when P's program has been completely loaded or when P joins with an exited process.
- Running: A process in the cpu. A process enters the running state when the current running process exits the cpu via an exit or join system call.
- Exited: A process waiting to be joined with. A process is exited after it has made an exit system call and before it is joined with by another process.
- Gone: A process that has exited and been joined with. Gone processes no longer exist in the system.
- Blocked: A process that's waiting for a join.
Each level represents a single priority or a set of related priorities. Multi-level queues have the advantage making it easier to switch among various priority groups (such as interactive, batch, and real-time). In a pure priority scheduler all processes would be on the same queue and only the head of the line would be available for scheduling. On the other hand, a pure priority scheduler is easier to implement than is a multi-level queue.
The interactive responsiveness would be bad because the all the processes in the ready queue at the time the interactive process joins the ready queue would gain the cpu before the interactive process does (they all have longer wait times than does the interactive process). If there's a lot of processes in the ready queue or the ready-queue processes spend a lot of time in the cpu (or both), the interactive process will be long delayed before it can execute.
Fork-join synchronization requires that one process (the joining process) block until another process executes (the joined process). Once the joined process exits, the joining process unblocks.
A single, shared binary semaphore can provide this behavior. A fork call would allocate a semaphore initialized to 0 (no stone) and make it available to the joining and joined process (and any other processes that may be interested). The joining process would perform a join by waiting on the shared semaphore (grab the stone). When the joined process exits, it would first signal the shared semaphore. (put the stone back).
This approach works when there's a single joining process, but may not work when there are multiple joining process; it depends on how the semaphore implementation releases waiting processes.