ugkamins@sunybcs.uucp (John Kaminski) (05/13/89)
In article <21814@srcsip.UUCP> mnkonar@gorby.UUCP (Murat N. Konar) writes:
=>What advantages does 'true multi-tasking' (by which I assume you mean
=>pre-emptive multi-tasking) have over Apple's co-operative multi-tasking? Co-
=>operative multi-tasking has significant user interface advantges over the
=>pre-emptive kind.
=>
=>I for one would rather not have my application pre-empted by a background process
=>in the middle of say a menu selection. Any one who has used TOPS while a large
=>file transfer is in progress can attest to the fact that having the interface
=>slow down is a real drag. (TOPS for those who may not know, is an AppleTalk
=>fileserver system that runs in the 'background')
=>
=>Anyone who has used Suntools on the Sun's can attest to the horrible things that
=>can happen when your're trying to get a menu up but the processor is too busy servicing
=>some other process.
=>
=>Sure, pre-emptive multi-tasking makes it easier for the programmer who would rather
=>not worry about whether he's in the background or whatever, but it's the user's
=>view that matters most. That's what the Mac's all about.
=>Murat N. Konar Honeywell Systems & Research Center, Camden, MN
=>mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
Things may tend to seem to go slowly, but at least EVERYTHING is getting DONE.
I would MUCH rather get SOME timeslice sometime REGULARLY, rather than relying
on some other process "handing me" the processor. One blemish of the Amiga is
that it provides Enable(), Disable(), Permit(), and Forbid(). Any process
utilizing these falls into the same class as Multifinder. R U listening,
CATS guys? Provide access functions to the programs that do this, to do
what those programs do, which is generally access to system structures any-
way.
Another blemish on the Amiga system, performance-wise, is general disk access
by more than one process. Thrashing is most evident. That is just the
result of poor disk controlling software design. Anyone doing "concurrent"
disk accesses on an Amiga floppy knows well that something along the lines
of disk request buffering coupled with the a periodic application of a seek
optimization algorithm (elevator for example) would be "to die for."
I say "general access" because I tried both sequential and concurrent disk
formats, and on our totally preemtive Amiga, it was faster formatting two
floppies rather than just format-swap-format. This works like a charm
on a fresh box of 10 floppies. I thought from what I heard from the drives
in terms of head step rate that the system was slowed, but in an actual
timing of two formats versus format-swap-format, the "concurrent" formats
turned out to be faster by a few seconds (15?). I know it isn't very scientific,
but it WAS faster. (BTW, I was using a shell with uparrow to recall an entire
command line, so the speed of typing uparrow enter enter should be relatively
constant. Also, the format program was in the RAMdisk.)
Also to the CATS people: how about making the standard DiskCopy do a verify
pass, just like Format? Since the formatting is virtually all in software, a
DiskCopy is roughly the same speed as Format on an unformatted disk. The
ONLY reason that I always Format FIRST is to check for bad spots on the disk.
If DiskCopy had a verify read pass, this wouldn't be necessary.
I'm an Amiga user (as in as stated in the quoted article), and that's my
view. So there.
---
a-WYSIWYG, a-WYSIWIG _ _
a-WYSIWYG, a-WYSIWIG ////
a-WYSIWYG, a-WYSIWIG ////
a-WYSIWYG, a-WYSIWIG ////
In the jungle _ _ ////
The silicon jungle \\\\ ////
The process sleeps tonight \\\////
\_X_/
---
We can only contemplate the facts as we are able to perceive them.
Do we get what we deserve, or deserve what we get?
"I've seen yellow stripes in the middle of the road before, kids, but
never quite this WIDE!" -- Tom "T-bone" Stankusdoug@xdos.UUCP (Doug Merritt) (05/13/89)
In article <5847@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >on some other process "handing me" the processor. One blemish of the Amiga is >that it provides Enable(), Disable(), Permit(), and Forbid(). Any process >utilizing these falls into the same class as Multifinder. R U listening, NO! WRONG!!! (oops, sorry about that, I just got excited :-) Actually, any system that provides these functions is a "real time operating system". These calls are indispensible in such an environment. And regardless of what other great features are provided, they'll always be necessary for some things in real time systems. For one thing, you can (temporarily, one hopes) disable the preemptive scheduling people are complaining about; thus the Amiga provides a superset of what e.g. the Mac can do. For another thing, sometimes it's important to write an interrupt handler, and again this level of control is essential. One of the wonders of the Amiga is that, if necessary, you can do this, and you don't have to have OS source code, or even have to relink OS object files, in order to add it. Granted such power can be problematic, but if you don't have it, you don't have a real time OS. And for some things you just *have* to have a real time OS. >CATS guys? Provide access functions to the programs that do this, to do >what those programs do, which is generally access to system structures any- >way. Yes, that would be nice. It would remove *some* (but not all) of the need for the calls you disparaged. Doug -- Doug Merritt {pyramid,apple}!xdos!doug doug@xdos.com Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Of course, I'm no rocket scientist" -- Randell Jesup, Capt. Boinger Corps
gilham@polya.Stanford.EDU (Fred Gilham) (05/13/89)
In article <5847@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: > > One blemish of the Amiga is >that it provides Enable(), Disable(), Permit(), and Forbid(). Any process >utilizing these falls into the same class as Multifinder. R U listening, >CATS guys? Provide access functions to the programs that do this, to do >what those programs do, which is generally access to system structures any- >way. > I used Forbid() and Permit() to allow me to start up a task where things weren't quite ready for it. The parent simply did a Forbid() until it had finished setting things up. This seemed like a good use of Forbid() to me. Admittedly it is possible to get carried away. However, it is much easier to not do something than to do it. Having to give up the processor by hand seems kludgy to me. Being able to hang on to it if you REALLY need it seems flexible. You don't HAVE to use Forbid(). -Fred Gilham
jesup@cbmvax.UUCP (Randell Jesup) (05/14/89)
In article <5847@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >In article <21814@srcsip.UUCP> mnkonar@gorby.UUCP (Murat N. Konar) writes: >>I for one would rather not have my application pre-empted by a background process >>in the middle of say a menu selection. Any one who has used TOPS while a large >>file transfer is in progress can attest to the fact that having the interface >>slow down is a real drag. (TOPS for those who may not know, is an AppleTalk >>fileserver system that runs in the 'background') That's _exactly_ what can be prevented by the sort of preemptive multitasking we have on the Amiga. Menu and user interface operation aren't slowed down because they run at a higher priority than user tasks. Since it is preemptive, whenever it needs to run to handle user input it will, instead of (as in Multifinder) waiting for the current program to give up the processor, which may take a while. >>Anyone who has used Suntools on the Sun's can attest to the horrible things that >>can happen when your're trying to get a menu up but the processor is too busy servicing >>some other process. That's because the User Interface doesn't have priority, because Suns (and unix in general) are slower at task-switches (on the same hardware), and because even if the UI process gets a slot, lower-priority tasks can be given the processor (SunOS isn't a real-time OS). (Don't think I'm bashing Suns, I'm writing this on one). >Another blemish on the Amiga system, performance-wise, is general disk access >by more than one process. Thrashing is most evident. That is just the >result of poor disk controlling software design. Anyone doing "concurrent" >disk accesses on an Amiga floppy knows well that something along the lines >of disk request buffering coupled with the a periodic application of a seek >optimization algorithm (elevator for example) would be "to die for." Elevator algorithms only help if you have three or more processes competing for disk access. Usually on the amiga, you have no more than two in the situations you site. The problem is when 2 processes alternate asking for a small number of blocks. Note to developers: your programs will load with less thrashing (when two things are loaded at the same time) if you use Blink's SMALLCODE and SMALLDATA options. Also, the less static and more dynamic structures you have, the less relocation information needed, and the faster the loads will go. These apply when the program is being loaded alone, also. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) (05/17/89)
Fred Gilham <gilham@polya.stanford.edu> in Message-ID: <9160@polya.Stanford.EDU> > I used Forbid() and Permit() to allow me to start up a task where > things weren't quite ready for it. The parent simply did a Forbid() > until it had finished setting things up. This seemed like a good use > of Forbid() to me. A simple solution to this would be for Commodore to create a few new system semaphores for V1.4 of the operating system. When you want to modify the list of task structures, you would simply grab the TaskList semaphore until you complete you operation on the list. Thus when a task switch is about to occur, the system would refuse to perform it. Effectively multi-tasking is disabled, but now the system knows why. When a page fault occurs, the page fault manager now knows wether it is safe to perform a swap or not. This is the way things should be. This is not a hack nor a cludge. This is the way you will see things done a future release of the OS. (Boy, I sure am confident about those things eh?) _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA