> [oxymoron wrote:]
> >Excuse me? When a process calls a system call, the process is running _in
> >the kernel_ (see below). Multiple processes can call the same system
> >calls. If the machine is SMP, two processes can call the same system call
> >simultaneously. What, pray tell, is your definition of reentrant?
>
> i think author didnot mean processes in wait state.
And I'm not talking about processes in the wait state either (even though
blocking I/O was my original example). Syscalls that take more than a very
small amount of time are supposed to have code like 'if(need_reschedule)
schedule()'. That very same syscall can then be called by another process.
Again, on a multiprocessor system, two processes can call it concurrently.
Reentrant is the property of being able to call a function while a
previous call to that function is in progress. The only difference is that
Linux uses coprocesses and NT (presumably) uses preemption.
> what about the kernel threads? what all core processes/threads are needed
> for process and device management apart from Scheduler? could someone
> please throw light on it.
Short, almost-right answer: none. The kernel is not a process. The
scheduler is not a process. Nor are either threads. Similarly for devices.
This is why the Linux kernel is classified as a monolithic kernel.
More correct answer: a couple. Recent kernels use kernel threads that look
almost like normal processes for a few tasks. In fact, a kernel thread is
practically identical in implementation to a user thread, except it starts
inside the kernel. One of these is kswapd which takes care of low-priority
memory management tasks. The kernel NFS server (knfsd) is also a kernel
thread.
> does linux have kernel multithreads, instead of just user multithreads,
> some thing like light weight processes on Solaris (each process can have
> multiple kernel threads to schedule on and multiple user threads to perform
> tasks).
The Linux kernel has a unique approach to threads. The fork() syscall is
very* fast on Linux, so they're already light-weight. The kernel approach
to threads has been to make fork() take options that indicate what parts
of a task should be copied and what parts should be shared. Thus, a
full process and a thread under Linux are facets of the same thing, with
many other possibilities existing.
There's also a threading library that's implemented without the help of
the kernel, but I've never heard of anyone masochistic enough to mix the
two.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/