Messages in this thread | | | Date | Sun, 24 Jan 1999 10:22:25 -0600 (CST) | From | Oliver Xymoron <> | Subject | RE:RE: [OFFTOPIC] Re: Linux Kernel constraints! |
| |
On Tue, 24 Mar 1998, Rajib Chakma wrote:
> [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/
| |