Multitasking on the Amiga: Can I Create a Better Exec Kernel for Workbench 2.1? 

A priority of only 1 difference ought not to freeze a system. That write-up could just as well be for QDOS and you saw how that works (if you watched it until the end). If you lookup non-preemptive (or real-time) priority definitions, that's how the Exec kernel is behaving. I'll do a deeper dive during May for #AMayGA.

Hi Dave, thank you for that input...that's very interesting. It's not been my experience with priorities from what I recall, but I haven't used them on UNIX/Linux in a long time since machines are so fast now that it seems pointless...so I will take a closer look using my spare Ubuntu server to refresh how it behaves...maybe I'm conflating various operating systems that I've used. As I understand UNIX/Linux nice values, they are 40 priorities above the possible max of 100 that the system gives a job (i.e. if the priority is 100 then you start at 120 and you can give -20 to +19 to adjust from that)...that's what I recall it being at least. So from the way it works of what you are describing, the 255 values are just an absolute rank where a higher process can get as much CPU time as it wants (perhaps all of it), which seems inefficient that anyone higher up in the rank (even barely) gets absolute control over the CPU above the others. Even in a ranking system, I would expect priorities in rank just one apart to allow each other some processor time so the system doesn't hang.

As a follow up, Windows only gives you 6 levels or priority. Setting Firefox either above normal or to low really has little impact (i.e. no system freezing or application stalling). So not a good way to test in Windows, though the system or app doesn't freeze up at least.

@@8BitRetroJournal I just mean its like the real-time priorities I have experienced in my work, and a feature I would expect any multitasking kernel to have, even if not exposed directly to the user. There is not a common/portable direct way to set priorities in most Unix/Linux, e.g., no such POSIX command. It could only be done on systems with real-time extensions to support realtime programming/systems (rather than common timesharing). In Unix/Linux, we just use [re]nice and it participates in the scheduling in a way that is sufficient for most purposes, and prevents you from completely starving other processes. When Linux first got SMP support, perhaps LInux 2.2 (?), there was a patch I used that gave it SGI Irix like realtime commands, so that you could reserve a processor and pin a process to that processor (if you like) and nothing else could run there. These are not typically commands though, presumably because it's too easy to make the system unusable, such that you'd have to reboot if you don't set the priorities right (as you can lose control of all command shells). Anyway, just sharing my experience learning this stuff 30 years ago. The way Amiga's command work is consistent with other systems back in the day.

@@DrDavesDiversions oh interesting, real-time priorities are a different beast I see. since they will take all available resources: google's AI says "real-time priority means that a process will execute without giving the CPU to any other processes, not even the task manager" which is exactly what the Exec kernel does. In another post they describe the difference between preemptive and non-preemptive priority scheduling as follows: non-preemptive priority says "once the process gets scheduled, it will run till its completion." So a real-time preemptive kernel is then not preemptive?!?!? Boy that's confusing...but interesting. Definitely digging deeper into this now. Love when my hobble bring up more questions that I can explore elsewhere.

@@8BitRetroJournal Cool, ya I was similarly fascinated by this stuff when I needed it to solve performance problems in the '90s in my work. It's not "that they will take all available resources," but probably more correct to say that the schedule will always choose a higher priority process that is ready to run, i.e., wants the CPU. If the high priority process does some thing that blocks (not needing the CPU), like waiting on I/O, another (lower priority) process can run; so this priority scheme is still quite useful since most well-behaved processes (and kernel task) are this way: they are not always CPU bound. (A busy/polling "wait" though will keep the CPU.) You are using some "weird" examples, "Lines" and "AmigaBASIC" that seem CPU bound doing calculations (as you are running them) so the scheduler will preempt them only for equally (or higher) ranked processes. Aside: "real-time" priorities are just examples of strict priorities in scheduling. I mentioned them because other OS, that are real-time OS, definitely expose this strict priority system directly to the user. That said, AFAIK, Amiga exec makes no real-time guarantees, but its priorities are the "simple" strict priorities of the type that an OS implements to do internal OS things. (The "real-time" part of a scheduler, if an OS has it, absolutely guarantees that a thread/process will run within a given time interval; for things like machine control, medical equipment, etc. HP-UX, QNX, and many others are examples of real-time OS.) Perhaps the best way to teach this is to say this more strict/"primitive" kind of priority is a great OS building block on which one *might* build other sorts of [proportional] priority mechanisms or scheduling, but those are typically not been found necessary for commercial OS. At least that's my current best understanding. :)

I just tried it and indeed, it works nicely...and agree that Exec is not so good. Executive is basically needed to make a real scheduler and I like the way it's done. Executive gives itself almost the highest priority (126, one shy of the max, so it utilizes the "real-priority" scheduler that Exec is to its advantage) and then toggles priorities based on initial values and "nice" adjustments. It has similar behavior to my 90s Mac OS hack (CPU Doubler) in that it seems processes run in spurts as opposed to more interlaced...but both programs had to modify the behavior from outside of the kernel. The way I got into the Mac scheduler was through intercepting a system call (waitnextevent / getnextevent) so it was even a bit less granular than Executive. Still, love to see a neat application like that. I really wonder how many actually appreciated what it does (was it a popular piece of software?). It was a fun quest to better understand how both worked (and how Linux does its scheduling as well). Kudos to QDOS for making me ask those questions.

I will dig into it. I don't actually think that the Exec kernel is broken, and likely Paul's explanation might be exactly what I experienced. That being said, it's not necessarily a good thing if that's the case...i.e. to basically only allow for what are termed "real-time" priorities where a task with higher priority takes over the machine and only if a task has equal priority to another task will they work together. I don't believe that's how Linux/UNIX works (and definitely not the way QDOS works which was modeled after UNIX). From my understanding, Linux has a priority range of 0 to 140, with lower values given more access to the CPU. The 101 to 140 range is for nice values that a user can control: a nice of 0 being normal (equal to 120 priority), and -19 to 20 choosing how "nice" the process behaves with others (reducing and increasing the overall priority). So those values are (as I interpret that) being added to the system priority (to give a total range up to 140) to determine the final task priority. But that isn't to say Linux only uses what are called "real_time" priorities where the task takes over the system. That's the issue I'm having with the Exec kernel...at least the little that I played with it. Now if I did something wrong, and Paul's book can help me understand that...then lovely). I will definitely dig deeper into that since I find it really interesting to see how that works. Now it turns out the Executive program seems to modify that and as I'm thinking about this now in context of the Exec Kernel, if all the Exec kernel does is give "real-time" priorities, perhaps the Executive task acts as its own kernel substitute, monitoring all other processes and changing priorities on the fly to give it a more UNIX/Linux control and to prevent system freezes. That would be cool and in many ways would mimic the hack I did on the Mac OS kernel back in the mid 90s. We will see but I'm looking forward to better understanding it.

I'll be doing a comparison between the two. The QL version is ok to play but the Amiga (and Atari) is insane. Also very difficult to play and its controls are a bit funky in that the accelerator has to be lifted up, it doesn't seem to just go up by itself if you let go of joystick forward.

@@8BitRetroJournalThe data bus bandwidth restriction in the QL is what really did for it and why graphics performance was so poor, if only it had a "proper" 68K CPU and a floppy disk drive - the QL could and should have been a world beater.

@@LondonSteveLee Yup, so true. The cost cutting hurt it on the performance side. I think the disk choice was based on them wanting to go to the wafer drive model (precursor to SSD cards) but that was just too ahead of its time to make it workable.

@@8BitRetroJournal Sinclair was good at picking the wrong horse or using technology simply because it was cheapest/theirs despite market realities.