Talk:Preemptive multitasking

A very interesting article. I have used Wimp2 on my RiscPC for quite some time now. You are right that it is not a complete solution, but I do think it works well in some cases - specifically when unzipping a large archive with sparkplug comes to mind. The patch which has been released allows you to select which applications should be used with Wimp2, so by some trial and error it is possible to get the "most" out of it. I suppose a "fix" should be transparent to the end user, but hey ROS users are used to tinkering with the system ;) Polas

• Personally, I suspect a properly designed PMT environment running either on top of, or as part of the WIMP is the answer for now. Properly designed so that in the future, we could move to a pure PMT OS, with the CMT environment running as a process in the PMT environment, ala Windows NT's NTVDM. This would enable faster development of an improved system (for all of Windows 95's drawbacks, it was better than Windows 3.1. Now think of that much of an improvement to RISC OS,) with the ability to go back and do it right later. Oh, and patching applications ala WimpPatch is necessarily hackish, and probably isn't the best answer - I think the best answer is to properly modify applications for a PMT environment. That said, buzzwords can be thrown around all we like, that doesn't actually get the code written. Unfortunately, I don't have enough knowledge to spec out an API or the design of the system, so I can't be of much help here. --Bhtooefr 12:14, 9 October 2009 (UTC)

A long time ago back in the days when I had a Archimedes 410, I wrote a program that just did wimp_polls and counted them. Results were singularly unimpressive. The maximum number of wimp_polls per second was pretty dire, made one think that the cost of a context switch for a wimp application would be very high. Much higher than a context switch for a typical PMT system KeithSloan

Context Switch cost

That's probably true, but there are many substantial changes since RO2/3 ARM2/3 days. Lazy task switching is but one, and of course substantial changes in the wimp and processor speed. Besides, you have to do context switch in PMT or CMT, so that's not a factor either way. --Pnaulls 19:05, 9 October 2009 (UTC)

Windows 9x

I've removed Windows 95, 98 and ME from the section about running a PMT OS on top of a CMT one. The Windows 9x family of operating systems have a real pre-emptive multitasking design, which isn't running "on top of" anything else. Although it appears to DOS programs that DOS is still present, what they get is merely an emulation environment. It's an ugly mess, but it's not PMT on top of CMT. Wimp2 appears to be the only example. --Tialaramex 22:15, 1 November 2009 (UTC)

• Explain how Win16 apps can take down a Win9x system, then. Please note that I linked a Microsoft knowledge base article about how Win9x handles multitasking. The article is vague, but note how the 32-bit code is definitely an extension on the 16-bit code. Also, note this: "Because of this dependency on cooperation to switch between applications, if a 16-bit application stops responding (hangs) before it has yielded to another application, it may cause Windows to hang as well." I'm reverting the edit. --Bhtooefr 04:10, 2 November 2009 (UTC)

Sure, all Windows applications, including Win16 apps, can take down a Win9x system in a number of ways. For example the OS makes no effort to prevent most kinds of direct hardware access. This gives a malicious or just badly written program countless opportunities to hang the system directly.

But to address the example you gave, I agree the KB article doesn't spell out what's happening in this scenario very well. As with RISC OS, Win 3.x was co-operative and so Win16 application programmers could assume that any system context stayed the same while their code was running - like the Wimp_OpenTemplate example in RISC OS. In Windows 9x in many cases the thunking layer achieves this by having 32-bit code with a context parameter, and the 16-bit code is thunked by always using the same context. For those cases Win32 and Win16 programs can run in parallel. If the Win16 program hangs up somehow, Win32 programs don't care. But in some cases (to save RAM footprint or developer effort) the opposite is done, the 32-bit code is thunked to share some 16-bit code which may have a single context. Some type of mutual exclusion (I don't know the icky details, but let's say a lock) is used to keep this code from being used simultaneously. Of course if a Win16 program goes into an infinite loop no Win32 programs can successfully take the lock to use this legacy 16-bit code.

You might say "Aha, the smoking gun - see, he admits the Win32 program can hang" but having programs blocked by mutual exclusion, perhaps forever, can happen on any PMT system. For example, the GNU C library on Linux uses a futex to ensure only one thread is allocating or freeing memory. Due to a bug it is possible for the library to get into a state where while trying to free memory, it calls another library routine which, in turn, tries to allocate memory - but the allocator futex is already taken. The program will block, waiting for its own futex, forever. This is a programming mistake called a "deadlock".

However, because Windows 9x is a real pre-emptively multitasked system, the fact that one program is hung up waiting for a lock is not fatal. Other programs can still run and they can even kill the offending 16-bit program to free things up. Of course like any non-trivial software, Win9x has bugs, some of which can still cause the entire environment to hang or crash.

I leave it to you to put my edit back, or not. --Tialaramex 11:02, 2 November 2009 (UTC)

• Putting your edit back, per this MS knowledge base article saying that "Win32 threads are preemptively scheduled and may even preempt Win16 processes." (My emphasis.) That said, it looks like they've run into some interesting issues with legacy code in the OS that are still of interest to RISC OS. (And, I was aware that DOS apps were preemptively multitasked, although they were PMTed back in Windows 3.0, too, IIRC - the discussion was about Win16 apps, which I had previously understood were treated differently under Win9x than under, say, WinNT.) --Bhtooefr 13:23, 2 November 2009 (UTC)