On Thu, 2005-03-24 at 13:06 +0100, Jan Engelhardt wrote:
> >i want to distinguish between thread and process and
> >after distinguishing between user thread and kernel
> >thread
>
> I think there are only kernel threads.
>
Um... what? I don't know about you but I run lots of multithreaded user
>So you want to say that only one task could be running
>at a single time
per processor, yes.
>but how to know which one
The kernel is not a separate task. If you call read() for example, you change
from user to kernel space, so there can be multiple threads being in kernel
space at the same
> Tasks do not change their state without holding a
> lock. (There is an exception,
> but it is justified.)
list after that..
>
> So you want to record task state changes? That is
> better done at the right
> places in the kernel rather than traversing the task
> list repeatedly (the
> latter is
>I had a wild idea to process one function that repeatedly checks the task list
>and find out which process is in which state
Why do not you do so, then? Note that on uniprocessors, all other tasks are
suspended, so their state does not change in between.
Tasks do not change their state without
> What exactly do you want to know about the
> scheduler?
>
I had a wild idea to process one function that
repeatedly checks the task list and find out which
process is in which state
At first i retrieve the information from fork.c in
do_fork() and exit.x in do_exit()
but the problem it showe
>Dear sir,
>
> I am new to kernel. I want to know which function in
>the file sched.c or procedure is called to bring a
>process for processing in the CPU after context
>switching.
In schedule(), context_switch() is called -- there is not any processing
needed, the task state is just copied from
6 matches
Mail list logo