torrie@cs.stanford.edu (Evan J Torrie) (01/25/91)
davewt@NCoast.ORG (David Wright) writes: >In article <1991Jan23.213736.28220@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> You say some programs do use input-handlers... does this mean they >>multi-thread themselves, spinning off an input handler task, and then >>communicate between the main program and the input handler task? > If they wish, but that is not normally needed. Most programs on >any machine are waiting for user input, not running in the background. >For instance a paint program would have no need to spawn another task >for input, since it is always waiting. Hey! We can do this on the Mac too by NOT setting the "Can Background" bit!! :-) >> Thus, it seems to be possible to buffer up a whole lot of mousedowns >>on the scroll bar, all received by the input.device task, but the >>actual code to regenerate the window won't be scheduled... thus won't >>you get a jerky, or at least a non-responsive task? > Yes, but the user would expect this, if they had a lot of other >programs running at the same priority. A user accustomed to the Amiga scheduling system would expect this... Does that necessarily mean it is the best thing to do? I would prefer a system which allowed me to work as fast as I can on the program I'm current working on.. i.e. interactive response. >> I'm just wondering if you would get better response by having the OS >>temporarily boosting the priority of an interactive task (e.g. raising >>the word processor priority to 10 while the user is clicking on the >>scroll bar in the WP's window) > Yes, this would work. But is very rude, and not many programs do >this. How do you know that the user WANTS the WP to work smoothly? Why WOULDN'T the user want the WP to work smoothly?? I really can't see that someone would PREFER to have their WP jerking around all over the screen, since it makes the system much more unusable. >Personally, I run a multi-user game on my computer 100% of the time, in >the background. Yes, but this raises another issue. In this case, you are running a task which is servicing other users... effectively, you want your scheduler to give good multiuser response [i.e. no starvation]. For these cases, Unix-like schedulers (which it seems the Amiga scheduler is modeled after, judging by the description so far) are definitely the right choice (after all, a lot of work has been put into researching the best scheduling systems for MULTI-USER OSes) But has anyone considered that practically ALL PCs are single-user machines. I don't run tasks for the benefit of other people. I want what I'm working (in the foreground) to give me the best response possible, even though it may starve some of the tasks in the background [not time-critical ones though such as I/O]. Has anyone investigated alternative schedulers which take the concept of "single user OSes" into account? (Just an idle question directed at the research community). What differences are there (if any) in the "best" type of scheduler for single user vs multiuser systems? Perhaps one valid solution is to multithread your application, and spin off a high priority thread handling user input AND screen regeneration. However, this sort of negates the advantage of preemptive multitasking vs cooperative multitasking, because now you have increased the complexity of your previously simple application. I was involved for a short time with a group writing an OS/2 PM multithreaded application. They spent a large amount of their debugging time trying to remove bugs associated with synchronisation/communication of their threads. Is it any wonder that when Microsoft wrote their version of Excel for OS/2, they wrote it as a single-threaded task, throwing away all those nice capabilities of OS/2?? >rare times it occurs. But technically, yes, you could do what you >want. But why not just run at the same priority all the time? If the >user wants faster response they can up the WP priority. Since most of the >time it will be waiting for user input, the other tasks will get plenty >of time to run in the background, even if the user has the WP running at >a high priority. Time consuming operations though (e.g. importing foreign documents, formatting for printing, searching and replacing) will still run at the upped priority in the background (when you really want them to run at a low priority). Perhaps a better example than a WP would be a spreadsheet or database, which can calculate while you are giving user input. For example, you might have a long search on a database, but you also want to be able to scroll around a list of matching records found so far (while the search is still going on). Or you could go back to my example of a ray tracer where you want to be able to examine parts of the scene rendered so far. In these cases you want the calculation in the background to be at a low priority... but you want the interactive response when you bring it to the foreground to be high. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
swarren@convex.com (Steve Warren) (01/26/91)
In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: [...] > Yes, but this raises another issue. In this case, you are running a >task which is servicing other users... effectively, you want your >scheduler to give good multiuser response [i.e. no starvation]. > For these cases, Unix-like schedulers (which it seems the Amiga >scheduler is modeled after, judging by the description so far) are >definitely the right choice (after all, a lot of work has been put >into researching the best scheduling systems for MULTI-USER OSes) [...] Hmm, I think you are getting an unclear picture of the Amiga multitasking mechanism. My understanding is that Amiga multitasking is different from UNIX precisely in that it was designed to give real-time single-user response. That is one reason there are not multi-user provisions built-in to the OS. One of the first things I noticed when I started using a Sun workstation at work was how poor the user response was when compared to a 68000-based Amiga. I have since learned that this is a function of the way UNIX implements its scheduler vs the way the Amiga does it. The Sun of course is able (with a 68030) to do more things at the same time than the 68000 based Amiga. But sometimes my Amiga seems faster because the OS puts more emphasis on fast user response. I understand that because coprocessors are able to handle much of the user response (through sprite implementation of the mouse cursor, for example), that very little of the total CPU resources are needed to provide snappy response, especially at the workbench level. The CPU does not have to busy-wait for input, of course. Sorry there are not more details here. I am only qualified to discuss this in terms of user-perception, not in terms of low-level OS operations. But I have seen qualified individuals contrast the Unix scheduler with the Amiga scheduler, with the conclusion that the Amiga scheduler is designed to provide real-time single-user response, unlike the Unix scheduler. -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. Warren v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.com
torrie@cs.stanford.edu (Evan J Torrie) (01/26/91)
swarren@convex.com (Steve Warren) writes: >In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > [...] >> Yes, but this raises another issue. In this case, you are running a >>task which is servicing other users... effectively, you want your >>scheduler to give good multiuser response [i.e. no starvation]. >> For these cases, Unix-like schedulers (which it seems the Amiga >>scheduler is modeled after, judging by the description so far) are >>definitely the right choice (after all, a lot of work has been put >>into researching the best scheduling systems for MULTI-USER OSes) > [...] >Hmm, I think you are getting an unclear picture of the Amiga multitasking >mechanism. Yes, quite probably. Can someone with knowledge of both please explain the differences between operation of the Amiga task scheduler, and Unix task scheduler (especially in the areas of adjusting priorities etc). I am reasonably familiar with the Unix scheduler (i.e. I've studied the OS source code), so just differences between the Amiga and Unix would be sufficient for me. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
davewt@NCoast.ORG (David Wright) (01/26/91)
In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > Hey! We can do this on the Mac too by NOT setting the "Can >Background" bit!! :-) But the difference is that on the Amiga programs that don't spawn an input task get along with other programs just fine. It is the exception, not the rule for programs to spawn another input task, and is certainly not required for simple applications. One of the best examples I have seen of the Amiga's superiority (although I am of course biased on two counts) is the graphic front end for Amiga Empire. Here you have a program that: a) Shares the same Empire library as all other clients (when run on the local machine), saving tons of memroy. b) Uses ARexx to extend the Empire game itself by allowing you to write macros for things like navigating a ship around the world automatically. And the ARexx macros are also executed by another task, so you don't have to wait for them to finish. c) Spawns at least one other task which allows the user to move around the map while the Empire game is doing something else, and click on sectors to get a census report on the sectors while Empire is doing something else. d) Spawns even more tasks (at a user defineable "delta" priority) that will tell you the best route between two point on the world, taking into account mobility costs, mined ocean sectors, etc. None of these require the user to wait for any of the other actions to complete before doing something else. > A user accustomed to the Amiga scheduling system would expect >this... Does that necessarily mean it is the best thing to do? I >would prefer a system which allowed me to work as fast as I can on the >program I'm current working on.. i.e. interactive response. The Amiga method WILL give you the best response. If you want the current program to give you the best response, run the others (or change their priority to) a lesser priority than your current program, and it will get all the CPU cycles it requires. > Why WOULDN'T the user want the WP to work smoothly?? I really can't >see that someone would PREFER to have their WP jerking around all over >the screen, since it makes the system much more unusable. You read the rest of my message, you know why. The point is that it is not the OS's [duty|right|job] to determine what the user wants run the fastest. The computers job is to do what the user wants, not the other way around, a point Mac users tend to overlook. > Yes, but this raises another issue. In this case, you are running a >task which is servicing other users... effectively, you want your >scheduler to give good multiuser response [i.e. no starvation]. Not at all. If I decide a user is wasting too much time, I SHOULD be able to cut his CPU cycles to 0 if I choose. Most Unix systems have a much more complicated scheduler which prevents a task from completely going without CPU cycles, which is why Unix is not a real-time OS. You can't be garaunteed a task will execute at an exact time becuase you can't be sure that some other program, even a low-level one, won't become so "old" that the OS decidedes it should run. But remember, just because you run something at a lower level doesn't mean it won't get to run. As we both agree most tasks do a lot of I/O, and are waiting for user or disk interaction. > But has anyone considered that practically ALL PCs are single-user >machines. I don't run tasks for the benefit of other people. I want >what I'm working (in the foreground) to give me the best response >possible, even though it may starve some of the tasks in the >background [not time-critical ones though such as I/O]. The Amiga scheduler provides this, and more. In fact, if you so decided, you could even put the foreground task higher than many OS functions, though you are discouraged from doing so. If you choose this, you could always either run the foreground task higher than normal a point or two, or run your other tasks at a lower priority than normal a point or two, and in both cases the foreground task would get all the CPU cycles it needed, when it needed them most, and would still let everything else run at almost full speed most of the time. > Perhaps one valid solution is to multithread your application, and >spin off a high priority thread handling user input AND screen >regeneration. However, this sort of negates the advantage of >preemptive multitasking vs cooperative multitasking, because now you >have increased the complexity of your previously simple application. Not to mention that the program is now being rude by assuming it knows what the user wants. This is Mac thinking creeping in (the user is too stupid to know what he wants, and me being a smart programmer will force him to live with my "better" method for his own good). > I was involved for a short time with a group writing an OS/2 PM >multithreaded application. They spent a large amount of their >debugging time trying to remove bugs associated with >synchronisation/communication of their threads. This is due to OS/2. On the Amiga it is no more difficult to write multi-threaded code than it is to write seperate programs, and communication is identical for keypresses or task-task communication (at the IDCMP level, which many (most?) applications that support the mouse for more than just menu selections already use). > Is it any wonder that when Microsoft wrote their version of Excel >for OS/2, they wrote it as a single-threaded task, throwing away all >those nice capabilities of OS/2?? Nope. Windows bites, is a huge kludge, and has a rediculously complex, confusing, and contradictory API. > Time consuming operations though (e.g. importing foreign documents, >formatting for printing, searching and replacing) will still run at >the upped priority in the background (when you really want them to run >at a low priority). They don't have to. Each task (even those an application spins off) can run at any priority they choose. Most programmers would probobly run the tasks 1 level below the main program. Dave
torrie@cs.stanford.edu (Evan J Torrie) (01/27/91)
davewt@NCoast.ORG (David Wright) writes:{
>In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:
>> A user accustomed to the Amiga scheduling system would expect
>>this... Does that necessarily mean it is the best thing to do? I
>>would prefer a system which allowed me to work as fast as I can on the
>>program I'm current working on.. i.e. interactive response.
> The Amiga method WILL give you the best response. If you want the
>current program to give you the best response, run the others (or change
>their priority to) a lesser priority than your current program, and it
>will get all the CPU cycles it requires.
It has been pointed out to me (in email) that the Amiga does not age
tasks. This, I guess, can be looked on as either an advantage or a
disadvantage, depending on what sort of workload you have. It
certainly explains why the Amiga is not Unix.
Anyway, my original point was that instead of "running the others"
at a lesser priority (therefore, having to decide BEFORE you start
your tasks), or changing their priorities (probably not a particularly
convenient thing to do everytime you switch programs), why not build
such dynamic priority changing into the OS?
>> Why WOULDN'T the user want the WP to work smoothly?? I really can't
>>see that someone would PREFER to have their WP jerking around all over
>>the screen, since it makes the system much more unusable.
> You read the rest of my message, you know why. The point is that it
>is not the OS's [duty|right|job] to determine what the user wants run
>the fastest. The computers job is to do what the user wants, not the other
>way around, a point Mac users tend to overlook.
But it IS the OS's [duty|right|job] to be as transparent to the user
as possible. If the OS causes my interaction with the computer to be
difficult (because of slow response), then it's interfering with what
I want to do (remember, this is restricted to a single user system)
Perhaps we should take a vote:
How many of you would prefer the application you're interacting with
in the foreground to be jerky, in return for your background ray
tracer or compile getting a few extra timeslices?
How many would prefer the application to be smoother, in return for
stealing some timeslices from your background tasks?
>> Yes, but this raises another issue. In this case, you are running a
>>task which is servicing other users... effectively, you want your
>>scheduler to give good multiuser response [i.e. no starvation].
> Not at all. If I decide a user is wasting too much time, I SHOULD
>be able to cut his CPU cycles to 0 if I choose. Most Unix systems have
>a much more complicated scheduler which prevents a task from completely
>going without CPU cycles, which is why Unix is not a real-time OS.
Yes, but it's also why Unix is a multiuser OS, unlike the Amiga
(virtual memory is also a kicker for real-time systems).
>> But has anyone considered that practically ALL PCs are single-user
>>machines. I don't run tasks for the benefit of other people. I want
>>what I'm working (in the foreground) to give me the best response
>>possible, even though it may starve some of the tasks in the
>>background [not time-critical ones though such as I/O].
> The Amiga scheduler provides this, and more. In fact, if you so
>decided, you could even put the foreground task higher than many OS
>functions, though you are discouraged from doing so.
Doesn't this provide some wonderful opportunities for "nuisance
type" programs, which set themselves up to run at a priority of say
10, and then go into a compute intensive loop?
Even if I run a raytracer at priority -1, and then another compute
bound task, (say calculating Pi at priority 0), then the raytracer
will starve... To a person coming from a Unix background, this is not
attractive (in fact, one might be tempted to not even call it "true"
multitasking [ducking for cover :-)]).
> Not to mention that the program is now being rude by assuming it knows
>what the user wants. This is Mac thinking creeping in (the user is too stupid
>to know what he wants, and me being a smart programmer will force him to live
>with my "better" method for his own good).
This is silly. There is always some point at which the programmer
has to make a decision about how to design the program, and they do
that by [analysing|studing] what users want. And I'd vouch that if
you ask users, they'd want fast response vs slow response.
>> I was involved for a short time with a group writing an OS/2 PM
>>multithreaded application. They spent a large amount of their
>>debugging time trying to remove bugs associated with
>>synchronisation/communication of their threads.
> This is due to OS/2. On the Amiga it is no more difficult to write
>multi-threaded code than it is to write seperate programs.
Yes, but that is the hard part :-). Their problem was not with the
mechanics of syncronisation, it was with the logic. It's a simple
fact of life that multi-threaded applications are harder to
write/debug than single threaded apps.
--
------------------------------------------------------------------------------
Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu
"I didn't get where I am today without knowing a good deal when I see one,
Reggie." "Yes, C.J."dac@prolix.ccadfa.oz.au (Andrew Clayton) (01/27/91)
In article <1991Jan27.014242.2863@Neon.Stanford.EDU>, Evan J Torrie writes: > But it IS the OS's [duty|right|job] to be as transparent to the user > as possible. If the OS causes my interaction with the computer to be > difficult (because of slow response), then it's interfering with what > I want to do (remember, this is restricted to a single user system) Huh? The OS doesn't interfere with your DECISION to run multiple programs at the same time. By default, spawned programs have a priority of zero (0) thus they *share equitably* the CPU resource. > Perhaps we should take a vote: > > How many of you would prefer the application you're interacting with > in the foreground to be jerky, in return for your background ray > tracer or compile getting a few extra timeslices? > How many would prefer the application to be smoother, in return for > stealing some timeslices from your background tasks? Duh! Lets make the OS democratic! :-). *YOU*, all by your lonesome, get to make the decision if you want processes to have priority. Most people don't mess with the scheduler. It's best left alone. > Even if I run a raytracer at priority -1, and then another compute > bound task, (say calculating Pi at priority 0), then the raytracer > will starve... To a person coming from a Unix background, this is not > attractive (in fact, one might be tempted to not even call it "true" > multitasking [ducking for cover :-)]). So, Evan, why do you mess with priority in the first place? Leave the tasks at the default (zero) priority, and they will peacefully coexist and SHARE the resource. If you want to do something that is input sensitive, (like edit a file), then CHANGE the priority of the CPU hog program to -1. A shift of 1 either up or down in priority has a HUGE effect on the other tasks. In other words, if it ain't broke, don't fuck with it. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or receive email. Not to anyone at all. Not even you.
torrie@cs.stanford.edu (Evan J Torrie) (01/28/91)
skank@iastate.edu (Skank George L) writes: >In article <1991Jan27.014242.2863@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> Even if I run a raytracer at priority -1, and then another compute >>bound task, (say calculating Pi at priority 0), then the raytracer >>will starve... To a person coming from a Unix background, this is not >>attractive (in fact, one might be tempted to not even call it "true" >>multitasking [ducking for cover :-)]). > With all due respect the above is a rather silly example. First, I doubt >that you are actually running a ray tracer in the foreground, therefore, if it >is starving you won't notice (same as on Unix so far). Ah, why won't I notice it starving if it is running in the background? It's sitting there in a background window, doing nothing at all on the Amiga, whereas under Unix, the XWindows display is getting updated, albeit slowly, while the Pi generator is still running (at a faster rate). >The fact that you set >the priority of the ray-tracer to -1 and the priority of the program >calculating Pi at 10 says to me that you wanted the program calculating Pi to >a *lot* have more CPU time (same as Unix). On the Amiga, though, this absolute difference in priority makes no difference (does that make sense? :?) Even if I set the difference in priorities to be just 1, the ray tracer will still get ZERO time slices and the PI calculator gets everything. Under Unix, the proportion of timeslices shared between two tasks is proportional to the absolute difference in priorities. > Finally, AmigaDOS is not UNIX (and I think too many Amiga owners forget >this also). Comparing AmigaDOS and Exec to Unix and it's exec is fine but >don't expect them to be the same because they are not. A good point. From what I've read so far, it seems that the Amiga scheduler is a better than Unix for a single user system. But I wonder whether it could be made even better... -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
torrie@cs.stanford.edu (Evan J Torrie) (01/28/91)
dac@prolix.ccadfa.oz.au (Andrew Clayton) writes: >In article <1991Jan27.014242.2863@Neon.Stanford.EDU>, Evan J Torrie writes: >Huh? The OS doesn't interfere with your DECISION to run multiple programs at >the same time. By default, spawned programs have a priority of zero (0) thus >they *share equitably* the CPU resource. It's my contention that the OS should poke its nose into this, though, by PREFERRING interactive tasks over compute intensive. Even Unix does this, by aging tasks based on its recent CPU usage, and I would argue that on a single user OS, this preference for interactive tasks should be even more pronounced. >Duh! Lets make the OS democratic! :-). *YOU*, all by your lonesome, get to >make the decision if you want processes to have priority. Most people don't >mess with the scheduler. It's best left alone. The problem is, though, that the decision to give a process a particular priority is a static decision. What do you do about processes, which spend most of their time being interactive (so you give them a bump up in priority), but then, every now and again go into a compute intensive loop. Sure you can let the user do everything. If the system starts getting slow, the user has to find out which task is causing the slowdown, and then statically change it to a lower priority. Wouldn't a more dynamic scheduler built into the OS be a better solution? >In other words, if it ain't broke, don't fuck with it. I'm not saying it's broken. I'm asking whether it could be improved..., and whether anyone has ever done any comparative studies on the various merits of single user schedulers. (P.S. this thread is rapidly getting stale, so it will probably cease to exist in the near future) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
dac@prolix.ccadfa.oz.au (Andrew Clayton) (01/28/91)
In article <1991Jan27.221142.20062@ncsuvx.ncsu.edu>, John Vestal
And in article <1991Jan27.223145.18292@Neon.Stanford.EDU> (Evan J Torrie)
There were basically the same rebuttals to my rebuttals:
AC> Huh? The OS doesn't interfere with your DECISION to run multiple programs
AC> at the same time. By default, spawned programs have a priority of zero
AC> (0) thus they *share equitably* the CPU resource.
(1)
JV> I think the point here, is that I might want to let one program get a
JV> higher percentage of the CPU. Not share equally, but get, say 65%, and
JV> let the rest of the stuff have the other 35%. But I want to be
JV> garrentteed(sp) that the other processes get the 35%. Currently in
JV> AmigaDOS, you can't do that. Once a process has a higher priority, all
JV> bets are off as to how much CPU other lower tasks get. They get the
JV> "leftovers".
(2)
ET> It's my contention that the OS should poke its nose into this, though, by
ET> PREFERRING interactive tasks over compute intensive. Even Unix does this,
ET> by aging tasks based on its recent CPU usage, and I would argue that on a
ET> single user OS, this preference for interactive tasks should be even more
ET> pronounced.
You both want the operating system to stick it's nose in, or at least do some
cogitation on what SORT of task gets timeslices.
No dice. Going on my knowledge of mainframe schedulers leads me to believe
that task switching based on what the USER want's to achieve is ALWAYS better
than any generalised 'guessing' algorithm in the OS.
You prefer the OS to do some thinking for you, but that algorithm has to be
worked out, and no *generalised* one will meet everyone (or even anyones!)
personal preferences.
Leaving out all the 'guessing', and having the OS work purely on a priority
basis, makes for a more efficient scheduler. If you *want* to you can change
the way your machine reacts to different tasks running.
It's more a religious issue, I guess. Some people say 'don't play with the
scheduler' and others look on aghast stating that they aren't using resources
effectively if they DON'T change scheduler parameters to suit job mix.
The two camps are prolly doomed to eternal bickering. :-). The bottom line is;
AmigaDos is priority based, and I like it like that. I win. :-) :-) :-).
AC> Duh! Lets make the OS democratic! :-). *YOU*, all by your lonesome, get
AC> to make the decision if you want processes to have priority. Most people
AC> don't mess with the scheduler. It's best left alone.
(1)
JV> The best bet, I think, is to have something that says, I will age
JV> processes if you users wants to, but if I need realtime response, then I
JV> won't age other processes. The OS that I use on my computer has two
JV> variables for the democracy.
(2)
ET> The problem is, though, that the decision to give a process a particular
ET> priority is a static decision. What do you do about processes, which
ET> spend most of their time being interactive (so you give them a bump up in
ET> priority), but then, every now and again go into a compute intensive loop.
You are both on the same wavelength -- the decision, however it goes, is
currently a user one. Wasting (and I do mean WASTING) CPU resource by having
the CPU determine odd -airy fairy- parameters (Base Quantums, aging rates,
express priority) is quite obviously resource that is constantly consumed, and
never recovered. Neither your ray tracing program, or your program that asks
users questions and then calculates pi to several billion decimal places will
get the BENEFIT of this once_every_20ms_scheduler code. It's going to reduce
performance, and that, I'm afraid, is *my* criterion for 'badbadbad'.
AC> either up or down in priority has a HUGE effect on the other tasks.
JV> It shouldn't, in my opinion, have that HUGE of a difference in tasks
JV> unless you set the process's priorities so they are a long way apart. I
JV> realy shouldn't be able to tell that much difference between priorities
JV> that differ by one.
I do agree with you, John, that SMALL shifts in the value of priority making
HUGE differences to performance of a given set of tasks, is somewhat clumsy.
Smoothing out the priority takes CPU resource. Bad move. Lets leave it alone,
eh!
ET> (P.S. this thread is rapidly getting stale, so it will probably cease to
ET> exist in the near future)
Ah, the joys of people wanting to complain forever. Where's -MB- when you need
him? [Joke, joke, honest].
Dac
_l _ _ // Andrew Clayton. Canberra, Australia. I Post .
(_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am.
-------- I cannot send or receive email. Not to anyone at all. Not even you.steve@wildcat.UUCP (Steve Holland) (01/29/91)
>In article <1991Jan27.221224.17360@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > On the Amiga, though, this absolute difference in priority makes no >difference (does that make sense? :?) Even if I set the difference in >priorities to be just 1, the ray tracer will still get ZERO time >slices and the PI calculator gets everything. Under Unix, the >proportion of timeslices shared between two tasks is proportional to >the absolute difference in priorities. My source, Abacus' Amiga System Programmers Guide reads slightly differently (on page 259): "Exec starts with...the highest priority. After this, the processor time which it used is subtracted from its relative priority in comparison to the ready tasks. Now it is no longer the task with the highest priority and the processor moves on to the next task. ----------->Steve Holland<----------- Internet: wildcat!steve@alfalfa.com | "To err is human, but to really foul USENET: ..bu!alphalpha!wildcat!steve | things up requires a computer." <if alfalfa doesn't work, try alphalpha>
jbickers@templar.actrix.gen.nz (John Bickers) (01/29/91)
Quoted from <1991Jan25.073516.29644@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > davewt@NCoast.ORG (David Wright) writes: > > Yes, but the user would expect this, if they had a lot of other > >programs running at the same priority. > > A user accustomed to the Amiga scheduling system would expect > this... Does that necessarily mean it is the best thing to do? I Yes it is the best thing to do... look where this discussion is being held... :) > would prefer a system which allowed me to work as fast as I can on the > program I'm current working on.. i.e. interactive response. Seriously, I don't think it is useful to expect the OS to be able to second-guess the user here. > But has anyone considered that practically ALL PCs are single-user > machines. I don't run tasks for the benefit of other people. I want > what I'm working (in the foreground) to give me the best response So, unlike Unix for the average user, you have access to the priorities of every task in the system, to jiggle as you wish. > Perhaps one valid solution is to multithread your application, and > spin off a high priority thread handling user input AND screen > regeneration. However, this sort of negates the advantage of > preemptive multitasking vs cooperative multitasking, because now you > have increased the complexity of your previously simple application. If you wanted to keep things to the simpler level of cooperative multitasking, you could write your program so that it emulated the cooperative scheme - run at a high priority to lock out other things, but every so often did a little pause to see if anyone else wants CPU time. You'd have a limited number of customers, but so it goes... :) > I was involved for a short time with a group writing an OS/2 PM > multithreaded application. They spent a large amount of their > debugging time trying to remove bugs associated with > synchronisation/communication of their threads. Perhaps OS/2 and PM are more complicated than Exec and Intuition. That's certainly the impression I've gotten from various journals. The mechanics of this sort of thing are straightforward on the Amiga. Design problems are a different matter. > Is it any wonder that when Microsoft wrote their version of Excel > for OS/2, they wrote it as a single-threaded task, throwing away all > those nice capabilities of OS/2?? A lot of things that Microsoft do arouse wonder... these are the keen bunch that gave us AmigaBASIC, remember. The one that (for some reason, presumably to keep the program simple) used 24-bit pointers despite the clear guidelines against such things. > database, which can calculate while you are giving user input. For > example, you might have a long search on a database, but you also want > to be able to scroll around a list of matching records found so far This sort of thing would be best done (IMHO) by designing the application to handle it. Suppose that one of the operations the user could begin was to scroll the display down (so the user starts the scroll, but it's supposed to keep going once they release the mouse button - eg: displaying notes as a tune is played, or displaying an animation of tectonic plate movement, etc). > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
mpoutane@niksula.hut.fi (Matti Samuli Poutanen) (01/29/91)
In article <1991Jan25.204236.13509@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> [...] >>> Yes, but this raises another issue. In this case, you are running a >>>task which is servicing other users... effectively, you want your >>>scheduler to give good multiuser response [i.e. no starvation]. >>> For these cases, Unix-like schedulers (which it seems the Amiga >>>scheduler is modeled after, judging by the description so far) are >>>definitely the right choice (after all, a lot of work has been put >>>into researching the best scheduling systems for MULTI-USER OSes) >> [...] >>Hmm, I think you are getting an unclear picture of the Amiga multitasking >>mechanism. > Yes, quite probably. > Can someone with knowledge of both please explain the differences >between operation of the Amiga task scheduler, and Unix task scheduler >(especially in the areas of adjusting priorities etc). > I am reasonably familiar with the Unix scheduler (i.e. I've studied >the OS source code), so just differences between the Amiga and Unix >would be sufficient for me. I'll give it a try. On the Amiga, higher priority tasks can and will get the processor AT ANY TIME they need it. If you have and editor running at a high priority and it Wait():s for a keypress, as soon as the input. device detects a keypress the processor will be 'stolen' from the lower priority task that has it and given to your editor. In UNIX the lower priority task will allways finish its time slice. That's why the Amiga is real-time and UNIX is not. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing Matti Poutanen Helsinki University of Technology Dept. of Physics
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (01/30/91)
dac@prolix.ccadfa.oz.au (Andrew Clayton) writes: >In article <1991Jan27.221142.20062@ncsuvx.ncsu.edu>, John Vestal > >And in article <1991Jan27.223145.18292@Neon.Stanford.EDU> (Evan J Torrie) > > >You both want the operating system to stick it's nose in, or at least do some >cogitation on what SORT of task gets timeslices. > >No dice. Going on my knowledge of mainframe schedulers leads me to believe >that task switching based on what the USER want's to achieve is ALWAYS better >than any generalised 'guessing' algorithm in the OS. > >You prefer the OS to do some thinking for you, but that algorithm has to be >worked out, and no *generalised* one will meet everyone (or even anyones!) >personal preferences. There is a simple solution to this. All it requires is that everything stays the same EXCEPT that everytime a quantum expires then that tasks priority is lowered by 1. Then when all priorities have been lowered to the lowest tasks priority they get re-set to their beginning priorities. this would both Age tasks, allow for higher priorities to get more cpu time, and prevent task starvation while interupts could stay the same simply by raising a tasks priority when it recieves a signal. This way real-time processing would still take place, yet tasks would run much better. just an opinion of course. > _l _ _ // Andrew Clayton. Canberra, Australia. I Post . >(_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. >-------- I cannot send or receive email. Not to anyone at all. Not even you. UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > A user accustomed to the Amiga scheduling system would expect > this... Does that necessarily mean it is the best thing to do? I > would prefer a system which allowed me to work as fast as I can on the > program I'm current working on.. i.e. interactive response. But which program is that? The window you just clicked on last? It might just be a window you moved out of the way to see something better, or maybe it's an I/O handler for another task. For that matter, you can quite easily be using 3 or 4 separate programs "currently", since the context switch on the Amiga is so fast. That's not a work habit you get when it takes 2 or 3 seconds for the Mac to rearrange the windows and play games with desk accessories every time you touch a new window under Multifinder. > Why WOULDN'T the user want the WP to work smoothly?? Because if they did they woudn't have run it at a lower priority than the compute-bound task that's causing the problem. > For these cases, Unix-like schedulers (which it seems the Amiga > scheduler is modeled after, judging by the description so far) No, if you'd been paying attention you would have noticed that the Amiga scheduler is real-time, and not at all like the UNIX one. The UNIX one behaves the way you want, giving interactive tasks higher priority. > Has anyone investigated alternative schedulers which take the > concept of "single user OSes" into account? Yes, the real-time process controls industry. The result is very much like the Amiga scheduler. > (Just an idle question > directed at the research community). What differences are there (if > any) in the "best" type of scheduler for single user vs multiuser > systems? In multiuser systems fairness is very important: no user should be able to use more than a certain amount of any resource to the detriment of other users. VMS, even more than UNIX, takes this point to extremes. In single user systems real-time (predictable, controllable) response is important. > Perhaps one valid solution is to multithread your application, and > spin off a high priority thread handling user input AND screen > regeneration. Yep. > However, this sort of negates the advantage of > preemptive multitasking vs cooperative multitasking, because now you > have increased the complexity of your previously simple application. No, you've reduced it. Instead of having the computation chopped up into little chunks forever falling back to the event loop, you can treat the main part of the application as a simple request/process/respond loop, letting the processing run to completion without breaking it up into a state machine or inserting calls to the scheduler at strategic places. > Is it any wonder that when Microsoft wrote their version of Excel > for OS/2, they wrote it as a single-threaded task, throwing away all > those nice capabilities of OS/2?? Nice capabilities of OS/2? Are there any? Didn't Microsoft just abandon it? One problem with OS/2 is that you can't test your threads as standalone programs with a simple CLI user interface and integrate them after you get them working. In fact, you could simply leave the CLI command driven interface in and use AREXX to communicate between the halves of the program. > Perhaps a better example than a WP would be a spreadsheet or > database, which can calculate while you are giving user input. For > example, you might have a long search on a database, but you also want > to be able to scroll around a list of matching records found so far > (while the search is still going on). Perfect use for a multithreaded application. Like Haicalc. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan27.014242.2863@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > convenient thing to do everytime you switch programs), why not build > such dynamic priority changing into the OS? Because it doesn't do what you think it does. It adds considerably to the complexity of the scheduler, to boot. When I'm running a WP program, there are lots of tasks "currently active": the keyboard handler, the mouse handler, the input handler, Intuition, the disk drivers and the file system if I'm reading or writing files. Which of these should be boosted in priority? > But it IS the OS's [duty|right|job] to be as transparent to the user > as possible. If the OS causes my interaction with the computer to be > difficult (because of slow response), then it's interfering with what > I want to do (remember, this is restricted to a single user system) But it doesn't. In the general case programs just don't interfere with each other to cause slow or jerky response. > How many of you would prefer the application you're interacting with > in the foreground to be jerky, in return for your background ray > tracer or compile getting a few extra timeslices? None, that's why you run your background task at a lower priority. The thing you have to realise is that there isn't any formal "background task". A task is foreground or background purely in the mind of the user. And how long it is since the user touched that tasks window isn't an accurate guide. > Doesn't this provide some wonderful opportunities for "nuisance > type" programs, which set themselves up to run at a priority of say > 10, and then go into a compute intensive loop? Sure. But in a single user system with no protection mechanism there's no way to keep a program from doing bad things. Even systems like OS/2 will freely let any program slip into supervisor state and break stuff. If you want to protect against malicious programmers you need to go all the way to multiuser protection with security and all that stuff. Maybe you want to, but it's sure the Mac doesn't have it. > Even if I run a raytracer at priority -1, and then another compute > bound task, (say calculating Pi at priority 0), then the raytracer > will starve... Don't *do* that then. Really. If you reformat your hard disk while it's in use bad things will happen, too. > Yes, but that is the hard part :-). Their problem was not with the > mechanics of syncronisation, it was with the logic. It's a simple > fact of life that multi-threaded applications are harder to > write/debug than single threaded apps. It is? Why, pray tell? certainly apps that have to emulate multithreading without support are the hardest of all... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan27.221142.20062@ncsuvx.ncsu.edu>, cocoiii@hobbes.ncsu.edu (John Vestal) writes: > The best bet, I think, is to have something that says, I will age > processes if you users wants to, but if I need realtime response, So write a program that runs in the background and shuffles the run-queue based on how long tasks have been in it. Sounds like a weekend hack to me. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
bartonr@eecs.cs.pdx.edu (bartonr) (01/31/91)
In article <7661@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > When I'm running a WP program, there are lots of tasks "currently active": > the keyboard handler, the mouse handler, the input handler, Intuition, These all run as part of the input.device task. ================================================================================