Imagining RISC OS and PMT - RISC OS News, Software and Information

Imagining RISC OS and PMT

Published: 26th Jul 2003, 21:10:57GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Wimp2 illustrates what it'd be like [Updated]

Editorial Recent discussion in the drobe.co.uk comments and forums has resulted in recurring calls for RISC OS to gain fundamental operating system features enjoyed by other platforms, notably pre-emptive multitasking (PMT) and full memory protection. Whilst the RISC OS desktop is a cooperative multitasking (CMT) affair, a PMT solution does exist in the form of Niall Douglas' Wimp2 which we'll look at in a moment.

Firstly, we'll briefly explain the differences between PMT and CMT. The RISC OS desktop is a multitasking one as it allows many applications to seemingly run at the same time, from the user's point of view. The computer's processor can execute only one program at a time but the operating system can step in so a given program executes for a while before another program gets time with the processor. This sharing of processor time among programs creates the illusion that multiple programs are running simultaneously.

CMT and PMT are merely different ways of going about and both methods have their advantages and disadvantages. With cooperative multitasking (CMT), individual applications determine how much processor time they receive. Once an application has finished responding to an event, such as a mouse click, or when the application feels it's had its fair share of the processor, the application tells the operating system to move onto the next program waiting for processor time. The OS then pauses that application and tells the processor to resume executing the next application. This passing of control is almost cyclic, as eventually the processor will return to continue executing the original application. The downside to CMT is that if an application crashes or gets greedy and doesn't allow other applications to have time with the processor, the desktop grinds to a halt and multitasking ceases - RISC OS users will be painfully aware of this.

On the other hand, in pre-emptive multitasking (PMT), it's the OS that decides when an application begins and ceases executing. Usually, the OS employs a hardware based timer to measure how much time an application has spent with the processor. When an application has been running for a defined amount of time, the operating system steps in to pause the application and resume the execution of another application. The benefit of PMT is that no application can hog the processor as each application is generally given an equal amount of processor time.

As previously stated, RISC OS uses CMT to acheive multitasking while other operating systems like Microsoft Windows and the Linux kernel use PMT. PMT does indeed appear to be far more beneficial than CMT and if RISC OS adopted a PMT environment, we would see the end to situations like !ChangeFSI hogging the processor whilst processing images.

Wimp2
So with that in mind, we gave Wimp2 a shot. Wimp2 is a module that works with RISC OS 2 to RISC OS 4 (it's not 32 bit yet) and it basically enables pre-emptive multitasking on RISC OS. Applications can either talk to Wimp2 to set themselves up to multitask pre-emptively or a supplied patch by Andrew Teirney can be run which transparently converts CMT based software to PMT on the fly. This means software like Oregano and StrongED can be made to multitask pre-emptively without any modifications.

Wimp2 has quite a history, which is worth reading. Its author, Niall Douglas, started development back in 1994 as part of his "regeneration of RISC OS" project called Tornado. Version 0.36, the latest version online, was completed in 1999.

Photodesk running over Wimp2 and multitasking pre-emptively

The good news is that the sources to Wimp2 and the aforementioned patch are available and Wimp2 appears to be released under the GPL, so a 32 bit version is possible and it's also possible for people to improve it and fix it. The source came in handy when I tried running the patch on my RISC OS 4.36 RiscPC as I had to comment out the code that checks for the OS version.

Attempting to run Wimp2 from my boot sequence resulted in multiple aborts and crashes so I decided to play it safe and try it out once the desktop had been fully reached and set up. Once Wimp2 and Andrew's patch are running, CMT based applications can be filtered to be executed as PMT tasks when first run (see screenshot below), and your choices are saved to disc as appropriate if you don't wish to be asked again. Alternatively, application names can be manually added to a textfile to define behaviour like how much processor time each application should ideally be given or to exclude some applications from being run as PMT tasks. This is useful if a CMT based application crashes when forced to run as a PMT application although some applications refuse to be excluded from being run as PMT tasks which leads to problems.

Would you like fries with that?

RISC OS 4 users may wish to exclude !Configure and its 'Generic plug-in' task from being executed as PMT tasks. To be honest, you will need to set aside some time to configure and set up the Wimp2 package to be just right, excluding software that crashes with Wimp2 and finding software that massively benefits from it. Any applications that use the Toolbox run in to problems, which includes OvationPro. It was beautiful, however, to see a ChangeFSI (running as a PMT task) processing a 1600x1200 32k colour spritefile whilst the rest of the desktop continued to multitask smoothly. Another processor hog tamed by PMT, Oregano formatted a huge HTML file whilst the rest of the desktop happily multitasked.

Toolbox issues aside, another problem was redraw. When a window in the RISC OS desktop needs updating or redrawing, the window manager orders the application, to which the window belongs, to find out which areas of its window need redrawing and to do the necessary graphics operations. Under CMT, the application would normally update its window and pass control to the next application. Under PMT with Wimp2, it would appear an application redrawing its window is being forced to multitask every so often when it should be redrawing. This reduces window redraw speed and also causes flickering. Scrolling this StrongED text window or dragging a window over an image being edited in Photodesk is slower than when the applications are running in CMT mode.

Despite these problems, Wimp2 is certainly entertaining to play with if you have the time and the sources are available if you want to improve the modules. The GPL nature of the module rules out any possibility of including the module code in RISC OS but Wimp2 does give a good indication of what RISC OS would be like if the OS were to adopt a PMT environment to replace the CMT system in place at the moment.

Update
Wimp2 author Niall Douglas kindly sent us these comments, regarding this article:

"Actually the redraws are slow because Wimp_UpdateWindow is used instead of Wimp_RedrawWindow plus the Wimp actually makes a special case with window redraw requests (it calls the app directly from the "move window" or "close window" implementation code).

"Wimp2 does nothing for redraw requests, just saves the area into a buffer which it then passes to the app when it's ready for it.

"I should mention that if you write your RO application to natively use Wimp2 then all the problems just go away. Flaky behaviour is 100% caused by the patch which has to do really nasty things under the bonnet. While I never actually wrote a large program using Wimp2, I did port RO2 Maestro to it and it ran very nicely indeed. Things like display redraw speed are much faster if your app is aware it's being preempted and you take the appropriate steps."

Niall also pointed out that only user level code can be pre-empted by Wimp2 and therefore operating system level code can't be. That is, when an application asks RISC OS to perform a lengthy task, like load a file from disc into memory, multitasking ceases until the operating system is done. Wimp2 does make an attempt to at least keep multitasking going when an application uses the OS provided OS_File SWI.

Links
Wimp2

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

nunfetishist 27/7/03 7:20AM	One of the main issues with using PMT under RISC OS is that so many applications assume that they're being co-operatively multitasked, which can screw what they do around message passing. A solution to this might be that you could patch Wimp2 to swap to CMT when using message passing or issuing redraw requests. What also might be interesting is to fiddle with Wimp2 to make it use Simtec's threading module, so you can take advantage of a Hydra if you have one. Don't know if it'd be possible, but it'd be fun.
jess 27/7/03 9:34AM	Why does the GPL rule out the use of the code in RO? - a seperate license could be obtained couldn't it? Or the module could be supplied with it? Was wimp2 designed as an interim stage to a fully PMT RO? Does it in effect make all the PMT apps into one CMT process? With a properly PMT RO would a CMT module running as a single PMT allow non PMT apps to run? -- Jess
imj 27/7/03 10:50AM	If RISC OS applications weren't written by braindead authors in the first place, they'd cooperatively multitask properly and the desktop would never "lock up". It's easy to make CMT work well -- we developed a complete CMT mp4 media system at work with none of these issues that RISC OS desktop has - it just needs authors to stick to the rules. CMT has plenty benefits over PMT, which Chris hasn't mentioned in the article, not least of which is much reduced complexity and no need to guard against threading, mutexes and all the nasty concurrency problems you get with a PMT system. PMT is not the "big thing" that RISC OS lacks. Adding it will not make everything suddenly work better - even if you rewrite every application! All the article here has shown is that it works around a few poorly written programs.
govind 27/7/03 11:06AM	One area where PMT could make a huge improvement is printing. Impression is about the only app I use which makes a half-hearted attempt to stop the desktop grinding to a halt whilst doing so. Chris, did you have any success with Wimp2 when printing from apps? -- Govind Kharbanda, Edinburgh
NeilWB 27/7/03 12:33PM	Good grief! I find myself agreeing with imj - better go and take an angry pill!!! Neil
Plugwash 27/7/03 12:35PM	"just needs authors to stick to the rules" Which is hard when the market relies on conversions from platforms running PMT systems. With a PMT system RISCOS dictates to programs what resouces it can have for a set period of time, not the other way around. It allows the OS to stay in control. I would disagree that PMT is not important, if you've tried rendering big webpages and media, printing and networking under RISCOS it becomes annoying having to wait on applications to gain control of the desktop again. A way forward for PMT with RISCOS would probably be nunf's suggestion of swapping to CMT when needed.
nunfetishist 27/7/03 12:37PM	I'm not sure that using CMT over PMT does reduce complexity at all. In fact, it can increase it. Writing a primitive, but still useful, PMT scheduler is not difficult, and isn't that much code. What it does do though, is make writing multitasking applications much easier - you don't need to think about things. At this point, using Wimp_Poll is just like using select() on a Unix to wait for something to happen that you're interested in. Mutexes, and other forms of syncronisation are easily avoided if you only want one thread per process, and you're not doing memory sharing of any type (and the only memory sharing that RISC OS applications commonly do only happens when doing Drag-n-Drop, and this can be easily guarded against to prevent problems.) CMT is useful occationally - if you spend a lot of time getting everything perfect, you can get better throughput, but at the cost of developer time. Under certian circumstances, it can make creating a highly reliable system very difficult to make. If one of your processes go haywire, another "watchdog" program can't sort things out (for example). Considering the number of OSes that were around at RISC OS' conception, it really should have had PMT from the start. (And they even tried doing it, on top of Mach later on, with the RISC OS Gold project.)
mavhc 27/7/03 12:37PM	Impression is odd because it uses CC's multitasking printing system, not Acorn's. So Impression with Turbo drivers or LaserDirect works much better. Printing has 2 stages, creating the data and sending it to the printer. The sending part multitasks fine now with Print in Background enabled, the creation part reqires the app to call Wimp_Poll if it's taking too long. It's not usually the apps taking ages I mind, it's things like failing to connect to network drives, CD reading etc which stop multitasking until they time out.
AMS 27/7/03 2:01PM	CMT versus PMT that old chestnut.... Oddly I find myself in agreement with imj on this. Good code will work correctly with CMT bad code won't. Perhaps in addition to setting things like a WimpSlot on start up code could indicate a maximum time between poll calls and then if the code doesn't do a poll within that period the OS simply either terminates it (and cleans up) or at least asks the user if it should. What do you think ? -- Annraoi McShane,
epistaxsis_RISC OS 27/7/03 2:29PM	cor another groovy article. Quick illustration of when PMT can go glands up: There is a piece of software we rely on at work which has its roots in Windows 3.1. It uses a SQL4 database. When it is "importing" (actually pkUnzip!) it behaves as if it is single tasking. You cannot use the machine for anything else. If you do and windows (presumably from what i've read above) passes some processor time to something else, you run the risk of data corruption. Nice isn't it? The screen redrw issues that Chris mentions above will also be familiar to windows users - how many times have you seen a window lose its contents while another app is hogging system resources. OK my examples are due to pants (read lazy...) application coding and a pants OS , but, as has been said not every cloud will contain Ag...
Martyn Fox 27/7/03 3:01PM	*In reply to AMS:* Perhaps a default pre-empt time could be defined in Configure which could be over-written by a command in the !Run file as you described (useful for development). A problem might arise when a task is doing something whose timing is outside its control, such as saving a file. Possibly calls to SWIs to do such things could over-ride the pre-emption time and/or the application could call a SWI before doing such things which would temporarily extend the pre-emption time - possibly until the application next called Wimp_Poll. Such a system could reduce instances of the machine totally hanging because an application had crashed. One for Select, perhaps. Martyn
piemmm 27/7/03 4:27PM	*In reply to imj:* I fail to see how CMT can compete in the real world. 1) There will never be a 'perfect' written app. In RISC OS, if an app doesnt yeild and gets stuck in a loop then it will be alt-break, or reboot time. No app is perfect, and will have bugs. This is particularly useless or annoying if you are trying to remotely control a RISC OS box from 50 miles away, and an error dialog pops up on screen causing multitasking to stop. (ignoring the modules around that frig error dialogs to multitask) 2) Every consumer desktop OS (apart from RISC OS) has moved to a PMT model. The most recent case is Apple going from OS 9, to OS X. I fail to see a place for CMT when the rest of the world is using PMT and deals with threading, mutex and other such problems just fine.
Gulli 27/7/03 6:23PM	Thought I'd mention that there was a thread about the CMT/PMT issue on either IconBar or Acorn Arcade a while ago where some programmer (memory error) talked about writing multiplayer network games being "difficult" to say the least on CMT. I agree that CMT has it's uses but there must be a reason why Windows and MacOS have moved to PMT and Linux/UNIX and BeOS were PMT from the start. -- Gunnlaugur Jonsson, Copenhagen, Denmark
NoMercy 27/7/03 7:22PM	I used Wimp2 for years, And I can say for several programs it was very damn useful, but for virtually everything that either didn't use up a lot of processor time or had issues when it was enabled I left it out. Bigest annoyance was Draw, the redraw of the window caused the grid to go haiwire, a few programs didn't like it, but on the whole it was happy there for years until I decided It really wasn't woth the possible problems for the minor improvement. PMT on RISC OS is possible as is memory protection, but boy is it going to break a lot of things along the way, would have been best if RO5 had the features from the start, then authors would have only had to fix once and carry on.
epistaxsis_RISC OS 27/7/03 7:24PM	*In reply to NoMercy:* PMT on RO5 select then?
Gerph 27/7/03 9:25PM	*In reply to Gulli:* Writing multiplayer network games under co-operative versus pre-emptive multitasking is really no difference in complexity - if someone has a good reason to believe that that isn't the case then I'd really like to hear it. Network games have to account for a number of 'features' of the network, one of which is the delay in message delivery. This delay is usually due to the time taken to trasfer the data from one machine to another. Part of that transfer process is that of buffering. The buffering in a CMT system is implicit within the applications being written. Therefore the only difference is that other applications can cause the transfers to take longer. A loaded PMT system can exhibit the same effects. Since you have to take account of the possibility of this delay anyhow because you know for a fact that the network latency is not going to be constant and that there may be issues with certain connections, you're not adding any complexity at all for a CMT system over a PMT system. All this applies to a game which requires messages to be delivered for 'frames' of the game (eg Doom). A game which includes prediction within its networking is explicitly coping with the delay in delivery. A turn-based game should have no issues with the type of environment it is being run under because the messages are (usually) transfered using TCP (rather than the UDP which is assumed in the above comments) and the timing of their delivery is not critical anyhow. I'm pretty sure that CMT introduces precisely zero complexity for a CMT environment over a PMT environment when it comes to network games. Obviously my experience with network games comes to a limited selection - Doom, Heretic, Hexen, 0verkill for frame-based, and NetOXO, NetC4 for turn based. The former 3 are ports from single-tasking environments, 0verkill from a linux application, and the latter 2 are native. I've not written a native multi-player network game which has been seen by the outside world, so if anyone wants to shed any light on why that's any different I'd love to hear from them.
mrchocky 28/7/03 10:03AM	Much as I hate to be a "me too", and much as I'd like to see PMT, I have to say that there is little requirement for it in GUI programs that are ported from other OSes. (I won't mention CLI programs/taskwindows, because that's another issue) X Windows apps, SDL things, even MFC Windows apps (I can't speak for anything else) rely on polling of some kind simply to keep informed about what's going on from the OS. Far more useful (but still an unusual requirement) for these apps is comprehensive threading support. On the other hand, the above Win 3.1 Windows app is not a good example - I understand that there are certain classes of Win 3.1 applications that cannot be properly PMTed. This can be attributed to the design of Windows rather than anything else. -- Peter, drobe.co.uk
jjvdgeer 28/7/03 12:08PM	What exactly is threading support? If I understand correctly, threading means multitasking within one task? I.e. sharing variable/application space? Is it possible to implement that without implementing PMT? -- Jan-Jaap
rob 28/7/03 4:46PM	There are two kinds of threads, kernel level (KLT) and user level (ULT). KLT requires OS support (which almost all do, except RISC OS of course). The big advantages of KLT are: 1) Different threads can execute concurrently on a multi-processor machine. 2) If one thread blocks on a system call it will not block the other threads in the process. ULT's are implemented using a thread library (I think there are/were a few for RISC OS) and don't require any OS support. To answer your question, user level threads do not require the OS to support pre-emptive multitasking.
NoMercy 28/7/03 5:01PM	Threading is on a totally over-simplified level, splitting a program up into several sperate parts which can run at the same time, redrawing a window while sorting out a HTTP request for example, but both parts of the program share the same memory and other resources, Adds a whole new dimension to programming. There's a few Thread-like things you can do under CMT, but to be done well it really needs PMT.
Gulli 28/7/03 7:11PM	*In reply to Gerph:* I don't claim to know the first thing about writing multiplayer network games (other than that it's possible to do so), I was simply mentioning that a programmer had spoken about it being difficult. I think it was one of the VOTI team or developers of TEK (still not sure), the need was at least for a realtime game. If it's as "easy" as you say it makes me wonder why TEK wasn't developed as a multiplayer game or hasn't been since. (easy is within quotes because I doubt that it's in fact EASY to write any sort of a networked multiplayer game - on CMT or PMT) -- Gunnlaugur Jonsson, Copenhagen, Denmark
nunfetishist 28/7/03 10:39PM	I imagine it's a matter of gameplay rather than technical difficulties. It's not the networking code that's tricky - multiplayer versions of normally two-player games are often quite different, either in rules or more fundlementally. Essentially, you often end up having to write two games - just two that share graphics and engine. This is quite a lot of work, and I imagine they skipped it so they could actually get Tek out of the door.
dfeugey (-1.0) 29/7/03 10:29AM	My point is that a lot of people forgot someting important : PMT eats CPU power (and CMT less). About 40% of an Amiga 1200 processing power, up to 100 MHz of CPU power on a real time PMT as the one included inside BeOS. That's a lot. The idea to have PMT is good... Best idea would be to have a !Configure plugin for it, with an option to switch all PMT applications to CMT, when needed. When you use a higly integrated application alone, you'll be able to get the maximum processor power. And RISC OS will keep also something that not a lot of OS have : flexibility (OK, Linux can also change of Scheduling model on the fly).
nunfetishist 29/7/03 12:48PM	PMT eats CPU time? What on earth are you on about? What part of of it eats the CPU time? It can't be the context switching - every multitasking OS does that - including RISC OS, and the overhead of catching a timed interrupt and doing the context switch there can be made very lightweight indeed. In most OSes, PMT increases throughput massively. As for BeOS: 100MHz of what ? Just saying 100MHz is meaningless. And considering I've worked for real-time OS companies (QNX in this case) I can say for definate that real-time PMT schedulers are much easier to write than CMT ones, and are almost always significantly quicker.
Dougal 29/7/03 2:04PM	I second nunfetishist on this one: there's no reason for PMT to make a machine significantly slower. You have to do almost exactly the same amount of work in switching between applicaitons - you have to save the old one, pick the next one, and then load it and run it (the only additional overhead is setting up the timer interrupt really). The only overhead there may be is that you switch applications more often because some application using CMT isn't releasing very often. I.e., PMT has a more regemented set of switching routines. But most modern PMT systems switch in the order of 10 ms intervals (unless some I/O interrupt forces a change). That may seem a short time, but on a 400 MHz processor that's 40,000,000 instructions you get on each shot. Personally I prefer PMT because I'm an OS purist - the only entity in a system that can really make a fair distribution of any resource is the system is the operating system, as only it has the complete picture. Obviously some apps may like more time than the OS gives them, but this is down to how the actual scheduler works rather than it being a PMT versus CMT. The other benefit of PMT is security. "braindead" programmers exist, as do "good old fashion honest mistakes", and under a CMT system you'll get fried. Also PMT means never having to say "yield" Well, unless you really want to -- Dougal
dfeugey 29/7/03 5:05PM	You cannot say that CMT as the same processing power needs as PMT... That's not true. Application switches when it decides to, so when there are less things to save on the stack. Application doesn't have to cope with a possible "unwanted" switch, so less code to implement... With a PMT model, a switch at the wrong time can cost you a lot. If the stacks to save are too big... For example. Sometimes CMT scheduling and interrupts are more efficient than a PMT solution, since you can determinate the exact time needed for a task and the exact processing power available for this task. This model is more "predictive" ; that's why Linux can use this type of scheduling in it's embedding form. So to drop it would be an error... I prefer the "two engine" solution (I have nothing against PMT, but just against things or technologies that you cannot switch off when needed, that's why I love Wimp 2
thegman 29/7/03 5:38PM	Hang onto CMT for backwards compatability by all means, but no /modern/ OS server,desktop or embedded, lacks PMT these days, to the best of my knowledge. Even if PMT were slower, if I can continue to work while my machine is processing stuff the background it has to be a good thing. I find it fustrating at work when I have someone on the phone, and I have to wait for my Mac to load a file or something, it would be downright embarrasing if I had to wait for tasks to complete before I could do anything on my machine.
nunfetishist 29/7/03 8:46PM	*In reply to dfeugey:* You forget that a CMT context-switch still requires stacks to be saved. You also forget that you're moving the complexity by using PMT, not increasing it. While your scheduler has to to more work, your process has to do much less. An application shouldn't ever know, or care when it's been pre-empted. It doesn't need to have to cope with an "unwanted" switch, as you put it. Please state an example of where switching at the wrong point costs you more than having to switch to something that's got a higher priority not happening. If you're playing a movie file, or something, that's the busy process. If something else needs to use the CPU, let it. It nothing needs it, the scheduler returns straight back to the movie player. Linux has many scheduling schemes - the default is a "fairness" scheme, which is perfect for servers, but less so for desktops. But pre-emptable kernel patches, and pluggable schedulers in 2.6 fix all this. The only problem with dropping CMT in RISC OS is so many applications make foolish assumptions, which would break. Please, stop the PMT FUD. For almost all purposes, it's a far superior system, which most RISC OS users don't appear to fully understand. (Example for how PMT can vastly* improve things: Notice how Linux has roughly comparable throughput to RISC OS (in in some cases, more*)? Then note that RISC OS is written in assembler, written by the people who designed the CPU. Linux is mostly C, and was never really designed to leave the world of the 80386. RISC OS is drastically out-dated in many ways these days, compared to even AmigaOS in many ways. Let's not try to come up with silly reasons for not modernising it. Let's come up with real ones. (Like PMT would break too many apps, not because it's slower.
rob 29/7/03 9:52PM	Nice one nunfetishist. I feel it's also worth pointing out that PMT is not some new-fangled technology, it was around a good few years before Acorn was founded.
1 comment(s) are below your moderation threshold. Login to view them.
Use the forum for more comments on this article