Xref: utzoo unix-pc.general:2417 comp.sys.att:5779
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!rutgers!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Question about windows and processor time (3b1)
Summary: Is a Rose a Rose a Rose?
Message-ID: <1428@mtunb.ATT.COM>
Date: 8 Mar 89 14:33:41 GMT
References: <356@flatline.UUCP> <450@amanue.UUCP> <1211@lemuria.usi.com>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 46

In article <1211@lemuria.usi.com> dpw@lemuria.UUCP (Darryl P. Wagoner) writes:
>
>There is two forms of context switchs, voluntary and involuntary.  It
>is true that a involuntary is based upon a hardward interrupt but it
>still causes a context switch even in kernel mode.  This in most cases
>doesn't happen in kernel mode because system calls will either finish
>before the time slice is up or will sleep on an address which causes a
>voluntary context switch.

We seem to be nailing ourselves on a semantic cross.  Ouch!

A switch of PROCESSES is clearly a context switch as the MAP is changed,
	the process pointer is altered, and the USER structure is
	changed.  This is a fairly time consuming step.  (LIAR: this
	ignores the NULL context-switch wherein the process goes to
	sleep and there's no other process to run.  While at a certain
	conceptual level, context should change to an IDLE process, the 
	reality is that the 3B1's SLEEPING process is left IN-CONTEXT,
	saving the two switches [out/in] if said process is first to be
	runnable.)

A switch from user to kernel -- by trap (including system call) or
	interrupt -- is in another sense a context switch because the
	SYSTEM mode bit becomes set: certain accesses and commands are
	now permitted without inducing protection traps.  BUT, the
	process-context is preserved and fully accessible by the kernel.
	(This is "irrelevant" for interrupts, save that there exists
	a kernel stack to run upon... which really isn't such an irrelevance.)
	In other words: the KERNEL doesn't view it as a context switch
	-- but would YOU believe a kernel given the awful things it
	occasionally does to you?

A switch from kernel state (trap or interrupt) to interrupt state (or
	trap, such as page-fault) is a pretty thin excuse for using the
	term "context switch".  All that happens is some stuff is pushed
	upon the stack.  (Is a subroutine call a "context switch"?-)

Well, who cares?  I've never worried too much about the TERMS because
the actions are what must be coped with.  A "getcontext()" call only
occurs with the actual switch between two runnable processes.  (OK,
I think I could blither on with an exception HERE too -- but... yawn...
it's winter hibernation season out here.)

Hoping you're just as confused as before... ;^)

john	-- att!mtunb!jcm	-- juzz muttering, wake me up when its over