[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-current-users
Subject:    Re: R: Why NetBSD (pthread-related items)
From:       Thor Lancelot Simon <tls () rek ! tjls ! com>
Date:       2001-11-28 22:19:19
[Download RAW message or body]

On Wed, Nov 28, 2001 at 11:06:44PM +0100, Jaromir Dolecek wrote:
> James Sharp wrote:
> > My understanding of NetBSD locking right now is that if one process
> > executes a syscall then all others are blocked, even if they're running
> > different syscalls.  Solaris locking lets different processes use
> > different parts of the kernel separately.
> 
> Yes, but this is separate thing.
> 
> Only one process can be executing in kernel on NetBSD at the time
> currently, even on SMP system. However, potentially many processes
> (or LWPs) can be _blocked_ in kernel, awaiting execution (or,
> awaiting their CPU time share to resume execution in high kernel).
> 
> > So will process A be able to read(), process B write(), and process C
> > ioctl() simultaneously?  Or is it just process A thread 1 can read() and
> > process A thread 2 write()?  That would be a big win on multiprocessor
> > units.
> 
> Currently, they won't execute simultaneously, but we will eventually

James' question is somewhat vague, so the answer Jaromir gave, while
correct, may be a bit misleading.

The answer is that you have to remember that I/O operations take *time to
complete*, and that during that time other processes can certainly issue 
system calls; the I/O operation will probably eventually cause the kernel
to be asynchronously awoken by an interrupt, and then control will be
transferred back to the appropriate process at a time of the kernel's
choosing.

When we have scheduler-activation threads, the same will be true of the
individual schedulable entities within a process.  It will *not* be the
case that multiple processes or threads will be able to *execute* code
within the kernel at the same time, but that's not quite the same thing
as single-threading all I/O through the kernel, because the kernel can
block your process and handle another process's request while your I/O
is happening.

[prev in list] [next in list] [prev in thread] [next in thread]