lrg7030@uxa.cso.uiuc.edu (Loren Rittle) (01/10/91)
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <17289@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > > In article <MWM.91Jan8110848@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > >Then again, I'll could decide that "true" multitasking means "no task > >can ever be completely blocked out, unless the user specifically > >allows it to happen by tagging the blocked task". That makes a lot > >more sense to me than just not allowing low priority tasks to starve > >higher priority ones. But then the Amiga doesn't have "true" > >multitasking. > > While not every multitasking OS tries to get close to realtime response, > your restriction is nothing you'd expect to find in the average > multitasking system, realtime or not. > > I disagree - every multitasking OS I've worked with (sans AmigaDOS) > either met that restriction, or met it if you never used the real-time > facilities. They all "aged" tasks so that a low-priority CPU-bound > task would get some cycles, even in the presence of many high-priority > cpu-bound tasks. Couldn't we decide to not use the real-time facilities of AmigaOS, and replace the dispatcher with one that "ages" tasks, ala UNIX, like ``every multitasking OS [mike has] worked with [now including AmigaOS].'' According to Tim Holloway in his lastest article in the Jan. Byte, ``Exec gives good performance with a simple time-slice dispatching algorithm. More complex custom algorithms can be attached in a straightforward manner, if required.'' I assume he means via the SetFunction() function. Does anyone know exactly what must be done to change the algorithm to support "aging" and some of the other neat functions talked about (I mean, which function, not how to change the algorithm)? Is the current system precisely described anywhere? Could an Amiga developer get source to the pertinent routines? (thought not :-(, I'll just use my commented EXEC disassembly :-) Any pointer are most welcome, I can summarize if you just want to mail me. Or, post if the info is of general importance to this topic... > While what you consider to be multitasking > depends on definition, a wacky restriction designed to exclude mainly the > Amiga OS is silly, and you know it. > > Yup, I know it. To me, it looks like "true multitasking" is defined to > exclude multifinder and similar hacks. I think that's silly. I agree with both of you :-) Loren J. Rittle -- ``In short, this is the absolute coolest computer device ever invented!'' -Tom Denbo speaking about The VideoToaster by NewTek ``Think about NewTek's VideoToaster! Now think about the Amiga!'' Loren J. Rittle lrg7030@uxa.cso.uiuc.edu
burley@geech.ai.mit.edu (Craig Burley) (01/11/91)
In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <17289@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > > In article <MWM.91Jan8110848@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > >Then again, I'll could decide that "true" multitasking means "no task > >can ever be completely blocked out, unless the user specifically > >allows it to happen by tagging the blocked task". That makes a lot > >more sense to me than just not allowing low priority tasks to starve > >higher priority ones. But then the Amiga doesn't have "true" > >multitasking. > > While not every multitasking OS tries to get close to realtime response, > your restriction is nothing you'd expect to find in the average > multitasking system, realtime or not. > > I disagree - every multitasking OS I've worked with (sans AmigaDOS) > either met that restriction, or met it if you never used the real-time > facilities. They all "aged" tasks so that a low-priority CPU-bound > task would get some cycles, even in the presence of many high-priority > cpu-bound tasks. > While what you consider to be multitasking > depends on definition, a wacky restriction designed to exclude mainly the > Amiga OS is silly, and you know it. > > Yup, I know it. To me, it looks like "true multitasking" is defined to > exclude multifinder and similar hacks. I think that's silly. I agree with both of you :-) I'm confused -- is the issue that AmigaDOS' scheduling algorithm allows low-priority tasks to be starved when higher-priority tasks stay eligible? That, to me, has nothing to do with the definition of "true multitasking" -- it is purely a scheduling issue, albeit perhaps an important one in that it might be wrong for a given system or way a system is used. True multitasking, as I believe it is defined, means preemptive scheduling. That is a hard thing to introduce to an operating system with a large installed base including 3rd-party applications. Multifinder is not true multitasking, period. It is cooperative multitasking. Multifinder was doable without a lot of work because the original Mac OS had the concept of cooperative multitasking designed pretty much from the beginning, unlike, say, MS-DOS. However, going from cooperative multitasking to true (preemptive) multitasking is really hard, because suddenly things need to be "locked" against effectively simultaneous access by other tasks, when access to those things used to be effectively locked simply by the owning task not "cooperatively" giving up control until it finished using those resources. Further, applications written under a cooperative or non multitasking OS are likely to not take into consideration possibilities that, for example, files can appear and disappear, directories change names, and so on, while the apps are running. This sort of thing isn't usually too bad for ordinary apps like word processors, perhaps, but for system utilities, it can result in flaky software, at best. Given a system that already has true multitasking, like AmigaDOS, but has a less-than-ideal (or perhaps simply insufficiently flexible) scheduler, it is much easier for the OS developers to enhance the scheduler without affecting existing software. There are still pitfalls, to be sure -- PRIMOS, for example, had an annoying tendency to give a single lower-priority user more CPU time than a higher-priority user because there were many hi-pri users and it tried to divvy up time among the levels somewhat equitably; and things get pretty complicated when processes are interacting via the file system or shared memory and depend on each other, yet eat up resources while waiting for each other (a deadly embrace of sorts) -- but it is a fairly trivial issue compared to true (preemptive) vs. cooperative multitasking. In summary, I don't think it is at ALL silly to define true multitasking to exclude Multifinder, and I doubt that even Apple Marketing would disagree -- and I do agree it IS silly to claim that true multitasking includes meeting any particular set of requirements for task scheduling, especially since "priority levels" are used to mean so many different things in different situations. Some might well argue that if they give one process, "HI", high priority and another, "LO", low priority, any scheduler that wasted time running LO when HI still wanted to run is wrong. It depends on what you mean -- "Run HI, but any time it can't run for some reason, LO is a useful background task to run, but not critical", or "HI is most important, but LO is important also, so run HI a lot but run LO occasionally" -- the latter interpretation is certainly more vague, hence harder to get "right" for any particular situation. Admittedly it is probably more typical. Please note I don't define single-tasking, cooperative multitasking, or true multitasking as GOOD or BAD. They all have their advantages and disadvantages, and I have done lots of useful work in all three environments (the bulk under true multitasking) and had problems with all three. The goodness and badness is no more etched in stone than that of deciding whether to stay single, get married and have no children, get married and have two children, or become a day care worker (talk about true multitasking! :-). -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/11/91)
In article <BURLEY.91Jan10111657@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: I'm confused -- is the issue that AmigaDOS' scheduling algorithm allows low-priority tasks to be starved when higher-priority tasks stay eligible? Of course you're confused - you've walked into the middle of a discussion, and have no idea what we're talking about. Loren Rittle was asking if it was possible to change the Amiga's multitasking so that user processes can't be starved, based on commentary in an ongoing discussion of the phrase "true multitasking". He quite correctly moved the discussion to .programmer from .misc. I'll try and fill you in, and point followups to comp.sys.amiga.misc, where this belongs. True multitasking, as I believe it is defined, means preemptive scheduling. Actually, "true multitasking", as it is commonly _used_, means preemptive multitasking. If you've got a reference to a textbook that defines the term (in any way), I'd appreciate hearing about it. As I've just pointed out, there's a perfectly adequate term preemptive multitasking, without the derogatory implication that someone else's multitasking is "fake" or "false" in some way. The first uses I saw were from insecure Amiga owners trying to demonstrate the inferiority of someone else's machine. As such, the terminology is bad, and should be avoided. That is a hard thing to introduce to an operating system with a large installed base including 3rd-party applications. Multifinder is not true multitasking, period. Bullshit. Explain to a user who doesn't have the foggiest idea what a scheduler is why his machine - which, as far as he can tell, behaves exactly like an Amiga under normal operation - has "fake" multitasking. Especially when (from what I hear of the Mac world) the percentage of commercial programs that are multitasking friendly on the Mac is larger than on the Amiga. In summary, I don't think it is at ALL silly to define true multitasking to exclude Multifinder, and I doubt that even Apple Marketing would disagree -- and I do agree it IS silly to claim that true multitasking includes meeting any particular set of requirements for task scheduling, especially since "priority levels" are used to mean so many different things in different situations. Actually, I think it's silly to define "true multitasking" at all. Either something is multitasking, or it isn't. I've already explained how to tell which is which. If you insist on defining "true multitasking", do it in non-technical terms. How about "no non-privileged task can starve any other task"? Please note I don't define single-tasking, cooperative multitasking, or true multitasking as GOOD or BAD. They all have their advantages and disadvantages, and I have done lots of useful work in all three environments (the bulk under true multitasking) and had problems with all three. I take it that the bulk wasn't done on the Amiga - it doesn't have "true multitasking" by the definition I'm going to use until an authoritative source appears. <mike --
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/11/91)
burley@geech.ai.mit.edu (Craig Burley) and others write:
[tons and tons of good stuff deleted, aren't y'all glad? The gist is --]
> True multitasking, as I believe it is defined, means preemptive scheduling.
I think the main argument is about using "true" versus "preemptive".
Cutting to the core, I suspect that people latch onto "true" because
a) they have no idea what preemptive means, and/or b) it's a lot easier
to say and not explain... plus it just sounds "superior" as a bonus prize.
And if magazine authors use it, you _know_ the word has been corrupted :-).
"True" might be relative to the OS you like. "Preemptive" is much more
concrete a term, I'd think (altho I've seen wars over that, too!)... and
therefore is preferable to use when sorting out differences in this case.
Once you start using words like "true", then you could open up other cheap
war topics; such as (thinking quickly...ummm) Are the Amiga custom DMA
chips really "true coprocessors"? If so, can an IBM user claim to have
coprocessors in his keyboard and SCSI port? And where do you fit in
the Mac-II 6502 coprocessors? Are they truer? Falser? Ad nauseum.
Think of the claim "I'm a true American patriot and you're not." Such
wording only causes trouble. cheers - kev <kdarling@catt.ncsu.edu>mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) (01/13/91)
In article <BURLEY.91Jan10111657@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: >In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: > > mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > In article <17289@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > > > > In article <MWM.91Jan8110848@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > > > >Then again, I'll could decide that "true" multitasking means "no task > > >can ever be completely blocked out, unless the user specifically > > >allows it to happen by tagging the blocked task". That makes a lot > > >more sense to me than just not allowing low priority tasks to starve > > >higher priority ones. But then the Amiga doesn't have "true" > > >multitasking. This is indeed a problem that I have frequently had on the Amiga. Often when trying to debug a task that is supposed to run at higher priority than the debugger, or worse, the console.device that the debugger uses... (The problem is really in the debugger, but the issue still arises when low-priority tasks do I/O --- the disk handler should run at the requestors priority) > > While not every multitasking OS tries to get close to realtime response, > > your restriction is nothing you'd expect to find in the average > > multitasking system, realtime or not. > > > > I disagree - every multitasking OS I've worked with (sans AmigaDOS) > > either met that restriction, or met it if you never used the real-time > > facilities. They all "aged" tasks so that a low-priority CPU-bound > > task would get some cycles, even in the presence of many high-priority > > cpu-bound tasks. > > While what you consider to be multitasking > > depends on definition, a wacky restriction designed to exclude mainly the > > Amiga OS is silly, and you know it. Not at all. When I put a compile session at a low priority, I DO expect it to finish. Just a little bit slower. Only tasks such as the input.device and things that interact with ME should pre-empt. (People are real time events too!) > > Yup, I know it. To me, it looks like "true multitasking" is defined to > > exclude multifinder and similar hacks. I think that's silly. > > I agree with both of you :-) > >I'm confused -- is the issue that AmigaDOS' scheduling algorithm allows >low-priority tasks to be starved when higher-priority tasks stay >eligible? It is now. >That, to me, has nothing to do with the definition of "true >multitasking" -- it is purely a scheduling issue, albeit perhaps an >important one in that it might be wrong for a given system or way a system >is used. The issue of whether MS-DOS/Finder/etc can multitask or not is an issue for comp.sys.amiga.advocacy. (Is this appropriate for .programming?) Is there any chance of having a bit somewhere that will let me desginate a process as 'pre-emptive'? Otherwise, I'd prefer to have a rung on the round-robin system (for equal priority tasks) be assigned to the 'next' lower priority. (Still, if I make something -10, it probably should be run less often than if it were -1, even if there are no other tasks at -10..-1) Does 2.0 make sending DOS packets, and doing asynch dos I/O any easier? Can one abort a DOS request? Thought not... -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me Bell: (613) 237-5629 + about joining ocunix.on.ca!
dillon@overload.Berkeley.CA.US (Matthew Dillon) (01/14/91)
In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: > ... >algorithm. More complex custom algorithms can be attached in a >straightforward manner, if required.'' I assume he means via >the SetFunction() function. Does anyone know exactly what must >be done to change the algorithm to support "aging" and some of >the other neat functions talked about (I mean, which function, not how >to change the algorithm)? Is the current system precisely described >anywhere? Could an Amiga developer get source to the pertinent >routines? (thought not :-(, I'll just use my commented EXEC >disassembly :-) Any pointer are most welcome, I can summarize if Look at the .FD files for exec.library ... you will note that there a about a half a dozen low vectors used to switch tasks, schedule, and deschedule them. This is what you would SetFunction() into. I've never done this myself so can't give you any info beyond that. >> Yup, I know it. To me, it looks like "true multitasking" is defined to >> exclude multifinder and similar hacks. I think that's silly. > >I agree with both of you :-) >Loren J. Rittle If it isn't preemptive, it isn't 'true' multitasking. If it *is* preemptive, it IS true multitasking. It is that simple. There is such a thing as non-preemptive multitasking, but to apply it to a computer with a large user community (i.e. beyond the workbench from whence it was created) is ludicrous. In the realm of public computing and public computers, multitasking must be preemptive. -- -Matt Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (01/14/91)
In article <1991Jan12.175908.6479@Latour.Sandelman.OCUnix.On.Ca> mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) writes: > > Does 2.0 make sending DOS packets, and doing asynch dos I/O any >easier? Can one abort a DOS request? Thought not... I do not think it made it, though it is simple to do. The basic problem is that the multi-packets-pending problem was never fixed. DOS still expects the packet is sends synchronously to be the FIRST one returned to the message port. Thus, you cannot have multiple packets pending because only one of them will be 'first' replying back. A shame, really. >-- > :!mcr!: | The postmaster never | - Pay attention only > Michael Richardson | resolves twice. | to _MY_ opinions. - > HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me > Bell: (613) 237-5629 + about joining ocunix.on.ca! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/15/91)
In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes:
Couldn't we decide to not use the real-time facilities of AmigaOS, and
replace the dispatcher with one that "ages" tasks, ala UNIX, like
``every multitasking OS [mike has] worked with [now including AmigaOS].''
According to Tim Holloway in his lastest article in the Jan. Byte,
``Exec gives good performance with a simple time-slice dispatching
algorithm. More complex custom algorithms can be attached in a
straightforward manner, if required.''
I can't see an easy way to do aging. Others on the net have claimed it
can be done; I'd be interested in knowing how (no code, just a
description).
The problem is that aging should be done based on how much CPU a
process has gotten (recently, at that), not how old it is. The Amiga
exec doesn't (to my knowledge) collect stats on this. So you have to
add hooks to do that. Normally, this is done by having a scheduler
that keeps track of such information. The best I can see doing on the
Amiga is choosing a regular, always present interrupt, and putting
code in that to keep track of how many times it interrupts each task.
This requires a bit of magic, but is doable.
Given the information on how "old" a process is, aging processes can
indeed be done as a script. Getting that information is the tricky
part.
<mike
--jesup@cbmvax.commodore.com (Randell Jesup) (01/15/91)
In article <dillon.9252@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991Jan12.175908.6479@Latour.Sandelman.OCUnix.On.Ca> mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) writes: >> >> Does 2.0 make sending DOS packets, and doing asynch dos I/O any >>easier? Can one abort a DOS request? Thought not... > > I do not think it made it, though it is simple to do. The basic > problem is that the multi-packets-pending problem was never fixed. > DOS still expects the packet is sends synchronously to be the FIRST > one returned to the message port. Thus, you cannot have multiple > packets pending because only one of them will be 'first' replying > back. You ought to read the autodocs/notes more closely, Matt. ;-) There are calls in 2.0 Dos for sending packets asynchronously, with a user-specified replyport. You must service the replyport yourself, and if it's your process message port, you must not do any synchronous I/O until you WaitPkt(). There's an entry for AbortPkt, but we couldn't figure out any good method to do it in the timeframe available (it'll require rewrites of most of the handlers, some may be major). 2.0 also has synchronous packet calls (DoPkt), and calls for allocating and inititalizing packets (AllocDosObject). As I said, it's in there... :-) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
vidynath@function.mps.ohio-state.edu (Vidhyanath K. Rao) (01/16/91)
In article <MWM.91Jan14151149@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: <>I can't see an easy way to do aging. Others on the net have claimed it <>can be done; I'd be interested in knowing how (no code, just a <>description). <> <>The problem is that aging should be done based on how much CPU a <>process has gotten (recently, at that), not how old it is. The Amiga <>exec doesn't (to my knowledge) collect stats on this. So you have to <>add hooks to do that. Normally, this is done by having a scheduler <>that keeps track of such information. The best I can see doing on the <>Amiga is choosing a regular, always present interrupt, and putting <>code in that to keep track of how many times it interrupts each task. <>This requires a bit of magic, but is doable. I am going by the write up in Mortimore's "Handbook", as these functions are not described in the 1.3 autodoc [t least the disk version]. (That says something, I am sure :-) There are four functions that deal with scheduling: Dispatch(), Schedule(), Reschedule() and Switch(). To age all processes, you will need to change all of these, at the least. If Exec is guarantted to always go through these four functions [no such guarantee exists, to my knowledge], you just have change these functions. Of course, to do aging, you just need a monotonic function of time used by each task. The former is not too hard. But getting the precise time accounting is probably close to impossible without major surgery. -- Vidhyanth Rao It is the man, not the method, that solves function.mps.ohio-state.edu the problem. - Henri Poincare (614)-366-9341 [as paraphrased by E. T. Bell]
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
Aging isn't that terribly tricky; you want to bump a little the process' chance to have its priority raised, every time it surrenders control with a "wait", and bump a little the process' chance to have its priority lowered, every time it is still executing at the end of its time slice, and surrenders control to the timer interrupt instead. You bump a little the chance of processes in the ready queue but not at the highest priority in that queue having their priority raised once in a while. The former processes are intuitively "i/o hungry" and should get better cpu service, the middle processes are intuitively "cpu hungry" and so should be restrained to allow others a better chance at the cpu when they need it, the latter processes are intuitively cpu starved and need their odds of getting a slice improved. The details have flown, but a combination of adding/subtracting amounts that depend on the process' existing priority to a single counter for each process, and occasionally shifting all the counters right to prevent overflow and suppress/age older information, and then once a tenth-second or so revising all the process priorities if their associated counters have reached a trip value plus or minus, is all that is required to accomplish aging of priorities. (The paradigm described is called "exponential aging", if I remember aright.) If the amounts added for cpu starved processes are more than enough to compensate for the bit shifting over time, those processes will age into higher priorities. If processes surrender control with a wait much more often than to the timer, their priorities will rise, if they surrender control much more often to the timer than to i/o waits, their priorities will fall (as is appropriate; processes that are not doing i/o are not real time processes, and so can afford to wait for those that are); if they do a mix of timer and wait surrenders, then with correctly balanced increment quantities, the priority will be stable. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jap@convex.cl.msu.edu (Joe Porkka) (01/17/91)
dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991Jan12.175908.6479@Latour.Sandelman.OCUnix.On.Ca> mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) writes: >> >> Does 2.0 make sending DOS packets, and doing asynch dos I/O any >>easier? Can one abort a DOS request? Thought not... > I do not think it made it, though it is simple to do. The basic > problem is that the multi-packets-pending problem was never fixed. > DOS still expects the packet is sends synchronously to be the FIRST > one returned to the message port. Thus, you cannot have multiple > packets pending because only one of them will be 'first' replying Yes, you can. Sort of. When you send a DosPacket (by hand, not thru dos.library) you can supply a different replyport than your Processid msgport. Then you can mix async and sync with no problem. I dont know how to abort an IO though. Matt do you know?
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/18/91)
>> Couldn't we decide to not use the real-time facilities of AmigaOS, and >> replace the dispatcher with one that "ages" tasks, ala UNIX, like >> ``every multitasking OS [mike has] worked with [now including AmigaOS].'' > > The problem is that aging should be done based on how much CPU a > process has gotten (recently, at that), not how old it is. The Amiga > exec doesn't (to my knowledge) collect stats on this. You'd add one more task structure variable: the Age of the process. AddTask() would be changed to set a new task's initial Age to its Priority. Whenever a task switch takes place, the kernel would first increment all process Ages, and pick by the highest Age. When that process is chosen, its Age is reset to its default Priority. Special wakeup situations might instead choose by Priority (vs Age) to keep a "realtime" reaction. The only difficulty is that the task structure size seems to be hardcoded, so adding a variable might be tough...or does Exec copy the task structure elsewhere on AddTask? kevin <kdarling@catt.ncsu.edu>
peter@sugar.hackercorp.com (Peter da Silva) (01/21/91)
In article <1991Jan17.204425.8037@ncsuvx.ncsu.edu>, kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > Whenever a task switch takes place, the kernel would first increment all > process Ages, and pick by the highest Age. This would add considerably to the cost of a task switch, which right now is pretty close to the ideal of "save registers, queue this task, pull the next task from the ready queue, restore registers". The mechanism Kent Paul Dolan suggested seems better. I'm going to have to think about it a while... there may not be enough hooks to do it efficiently. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
vidynath@function.mps.ohio-state.edu (Vidhyanath K. Rao) (01/23/91)
In article <1991Jan17.204425.8037@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: [deleted material on how to age tasks] >The only difficulty is that the task structure size seems to be hardcoded, >so adding a variable might be tough...or does Exec copy the task structure >elsewhere on AddTask? kevin <kdarling@catt.ncsu.edu> The taks structure size is hardcoded because of the way the AmigaDOS process structure is defined. Otherwise, I don't think that the task structure size is fixed for eternity. Task structure [upto v1.3 at least] has a "free" variable: There is something called UserData. If you just want to experiment, you can make it point at an extension area. But if you want to do this for every one, you will need to make sure that no one else uses it. -- Vidhyanth Rao It is the man, not the method, that solves function.mps.ohio-state.edu the problem. - Henri Poincare (614)-366-9341 [as paraphrased by E. T. Bell]
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/23/91)
<7564@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva): |> Whenever a task switch takes place, the kernel would first increment all |> process Ages, and pick by the highest Age. - me | This would add considerably to the cost of a task switch, [...] Not enough to worry over. I'd say that process selection and switching really doesn't happen very often, cpu-timewise. Hit me up with a good case. Also, the "trick" is to increment just the queue head Age. All others are relative to the head's age diff. <grin - was that murky enough? sorry> I had a much longer explanation, but drat! when I went on vacation last week I shut down the machine which had it on a ramdisk... if I find time again, I'll redo it. Also, on same subject in <1991Jan22.205630.834@zaphod.mps.ohio-state.edu> vidynath@function.mps.ohio-state.edu (Vidhyanath K. Rao) writes: | The task structure size is hardcoded because of the way the AmigaDOS process | structure is defined. Otherwise, I don't think that the task structure size | is fixed for eternity. | Task structure [upto v1.3 at least] has a "free" variable: [...] I think this is one of the things I like better about say, OS9... the fact that system structures are not directly diddled by user processes, and so the task structure can (and does!) grow as needed without messing up previous work. best - kev <kdarling@catt.ncsu.edu>
peter@sugar.hackercorp.com (Peter da Silva) (01/27/91)
In article <1991Jan23.104720.24057@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > Not enough to worry over. I'd say that process selection and switching > really doesn't happen very often, cpu-timewise. Hit me up with a good case. Real-time in general, but if you want a specific case... hmmm... Multi-task MIDI handling. We've had 1200 MIDI messages a second go through a fairly long chain of handlers, which implies lots of context switches. I didn't actually instrument it to determine if context switch time was significant, but in a real-time environment it's generally accepted that you need to have context switches being on the same order of magnitude as subroutine calls. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.