Queues...let's get this straight

[Daniel Ramsbrock]

OK, let's attempt to finally clear up what we need to do with all of the
queues...

s_runQueue - if a process is here, its state is R. Needs to be checked
for both kills and ps.

any of the I/O queues (I won't list them here since that might be
"giving away too much", but here's a hint: we have one keyboard and two
disk drives right now...) - if a process is here, its state is S. Needs
to be checked during kills, but not necessarily during ps (depending on
how you code it--one approach is to let the default state be S, and then
specifically check for R and Z--if it's neither of those, it must be S)

s_graveyardQueue - from the description and use in kthread.c, it seems
like it's used to briefly hold processes that are being handed over to
the Reaper thread. Is that correct? If so, we will never need to check
it for kills (since they're already dead), but what about the ps
listing? It don't think we need to check it because in the project
description, zombies are defined as " Any process that is dead, but
still has a reference count greater than 0 is called a zombie. That is,
it is dead, but cannot yet be reaped by the reaper. " Therefore, no
zombie processes would ever be in s_graveyardQueue since Reap_Thread
(which is the only place processes are being added to it) only gets
called when refCount == 0 (see Detach_Thread).

s_reaperWaitQueue - it seems like its only purpose is to hold the single
kernel Reaper thread and then have Wake_Up called on it from time to
time to let the Reaper know that there is work to do. Therefore we'll
never have to check it for kills (since the Reaper thread is a kernel
thread that can't be killed). We don't explicitly have to check it for
ps listings (since, as above, if the thread is not in R or Z state, it
must be in S state), but if you are checking queues to determine the S
state, then this one must be included (otherwise pid 3, the Reaper
thread, won't have the proper state). Is all of this correct?

Zombies - as was pointed out before, zombies are not on any queue.
They're dead, so obviously not on the runQueue or any of the I/O queues.
They're also not on the graveyardQueue or the reaperWaitQueue (see
above). However, they are still on the s_allThreadList. A good way to
check for them is to take the description's definition of zombies (see
above) quite literally (is it dead? is its refCount > 0?).

Dr. Hicks and the TA's, please correct any inaccuracies in the above
information.

Daniel

[c***@CSIC.UMD.EDU]

TAs reply to the question whether we can use alive as an indicator
whether a thread is dead or not is below. This makes me believe
you cannot detect zombies. Anything that is not there in the
waitQueues and runQueue and does not exist in graveyard must be
Zombie if it is there in the allThreadList.


-----

let me not answer this directly, but say this: a thread is dead
when it is not in any of the wait queues or the runnable queue of
the system. If it happens to be lying around in the graveyard
queue then it is dead but only waiting for its resources to be
freed up. if it does not exist anywhere then it is obviously dead
as well.

the setting of the variable 'alive' will depend on whether that is
done atomically with the transition of the thread from any of the
active queues in the system to the graveyard or not. depending on
the atomicity of the operation it might be the case that the alive
flag may be off. but the condition that truely indicates the state
of the thread is the queue it is in. you need to figure out
whether the flag also truely reflects this or not.

saurabh