From owner-freebsd-hackers Tue Oct 3 7:27: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id B7F9D37B502; Tue, 3 Oct 2000 07:27:00 -0700 (PDT) Received: from jade (jade.cs.binghamton.edu [128.226.140.161]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id KAA24355; Tue, 3 Oct 2000 10:26:59 -0400 (EDT) Date: Tue, 3 Oct 2000 10:26:26 -0400 (EDT) From: Zhiui Zhang X-Sender: zzhang@jade To: John Baldwin Cc: freebsd-hackers@FreeBSD.org Subject: RE: process scheduling quantum In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 3 Oct 2000, John Baldwin wrote: > > On 02-Oct-00 Zhiui Zhang wrote: > > > > Suppose a process is scheduled to run, will it run until its quantum ends > > unless it calls tsleep() on his own? In other words, is it possible for a > > process to give up its quantum earlier without having it to do so > > voluntarily? Thanks. > > If an interrupt occurs and puts a thread on the run queue (which will have > higher priority than the currently running proceess) then the current > process will be stopped so that the interrupt thread can run. Thanks. But I guess that you are talking about the new SMP threads. For FreeBSD 4.1-Release, I am not sure this can happen. I am wondering any time taken by interrupts (hardware or software) will be accounted to the current process. If so, the process's quantum is stolen away and nothing useful for that process is done. I wrote program the other day. It read the number of context switches done so far in a loop. If the number changes, then the process exits. In between, it calls getpid(). I just want to see how many system calls can be done between context switch. It turns out sometimes the number of calls to getpid() is zero. That is why I am asking the above question. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message