Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sauron.UUCP
Path: utzoo!linus!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!ncrcae!sauron!campbell
From: campbell@sauron.UUCP (Mark Campbell)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops and context switching
Message-ID: <616@sauron.UUCP>
Date: Fri, 21-Feb-86 14:46:13 EST
Article-I.D.: sauron.616
Posted: Fri Feb 21 14:46:13 1986
Date-Received: Mon, 24-Feb-86 21:04:21 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <2795@amdahl.UUCP> <221@myrias.UUCP> <2817@amdahl.UUCP>
Reply-To: campbell@sauron.UUCP (Mark Campbell)
Organization: NCR Corp., Advanced System Development, Columbia, SC
Lines: 14
Xref: linus net.arch:2398 net.micro.mac:4798 net.micro.68k:1445

One last (I hope) word about this stuff...concerning context switches and
timers with respect to timing delays inherent in some devices.  It really
doesn't make a lot of sense to talk about setting up a timer to implement
these delays, even if the delay were much longer than ~2us.  The problem
is not only the context switching times others have mentioned, but the
overhead associated with setting up some type of critical region around
the device in question.  With two or more processes attempting to
access the device, the "sleep"/"wakeup" scheme just won't cut it.  This
isn't speculation; I recently had to build some tightly-coupled
interprocessor communication code that required that a new state be added
to Unix for just this reason.  It wasn't a pretty sight...
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell