Cooperative Multitasking

While all want RISC OS to go for Preemptive Multitasking, under Windows / Linux the growing troubles with handling resources, makes programmers want to go for Cooperative Multitasking, by means of callbacks, background workers, cooperative threads, and co-routines:

https://luminousmen.com/post/asynchronous-programming-cooperative-multitasking

Hey Lothar :)

While all want RISC OS to go for Preemptive Multitasking…

Who’s “all”? I am good with RISC OS being Cooperative, the article you’ve shared seems to have reached a similar conclusion I had few years ago, for IoT and embedded applications.

In the past, when RISC OS had a chance to become a popular desktop OS (we are talking 90s/end of 90s) I was one of the people who proposed the transition to pre-emptive multi-tasking, but this was for a number of reasons that were true at that time.

Back at the end of the 90s:

• RISC OS scene still had quite lot of developers who could have changed their apps if needed
• Other OSes were still not as evolved as they are nowadays, they had tons of issues as well
• Preemptive multi-tasking has its strength on the Desktop market more than the cooperative and this because the OS has better control of the user apps. A generic user may run “only god knows” what on his computer. Back then the community wanted RISC OS to be a powerful desktop OS.

However there was also a set of issues to move to pre-emptive:

• Almost no one in the community had RISC OS sources or adequate knowledge on the RISC OS internals
• Acorn was out of business and others were kind of trying to get hold of RISC OS rights so the situation was very confused
• None of the companies who then got RISC OS rights had any idea of how to do the move to pre-emptive (there were many reasons for this)

Fast-forward to today… Right now there are still people who wish to improve RISC OS as a modern Desktop (and there is nothing wrong with that, except now it’s going to be a loooot of work to try to compete with OSes that have evolved for the last 30 years)

Cooperative multi-task still has strength in certain markets like the fore-mentioned embedded software and IoT, but that is not a WIMP-orientated market.

Cooperative multi-tasking can also very efficient for Desktop, don’t get me wrong, but that benefit comes with a price: The user has to be aware of what he/she is doing, the software has to be aware of what it’s doing.

I think a potential good future for a RISC OS Desktop could be in between: User space Tasks scheduling in Cooperative fashion while the OS Kernel gets rewritten to be fully re-entrant and support a pre-emptive kernel threading model, this to allow a more responsive multi-core access as well as more responsive I/O operations.

It could be possible to achieve this also using just cooperative approach, but that could results in an even more complex kernel code…

Anyway thanks for sharing that article! :)

> to allow a more responsive multi-core access

In my understanding, the current SMP module rather implements HMP, but even with this it should be possible, instead of having a WIMP task doing calculations in its main loop, through null reasons, that WIMP task could repeatedly start asynchronous threads on the remaining cores, for doing calculations, and just poll these threads completion flags. Nothing needs to be re-entrant or thread-save. And with 4 cores, should be 300% faster …

But I have to admit, I do not quite yet understand the SMP module sample code enough, to try this, with my WIMP fractal demo.

> A generic user may run “only god knows” what on his computer

I heard a rumor, on the recent MacOS, to start an APP it needs to be signed, and ask for online starting permission from Apple …

the current SMP module rather implements HMP

Or even AMP. AMP is not a bad approach.

CMT is not too, but perhaps it could be enhanced with time limits on tasks.
Or at least a message “[name of application] is blocking the desktop → wait/interrupt/stop”.

A super Wimp2 :)

@ Lothar

to allow a more responsive multi-core access

In my understanding, the current SMP module rather implements HMP, but even with this it should be possible, instead of having a WIMP task doing calculations in its main loop, through null reasons, that WIMP task could repeatedly start asynchronous threads on the remaining cores, for doing calculations, and just poll these threads completion flags. Nothing needs to be re-entrant or thread-save. And with 4 cores, should be 300% faster …

That assumes the only thing the extra cores are running is your calculation routines. While the article you’ve shared implies a scheduler for the extra cores as well.

So please let me give some considerations here just to make sure we are all on the same page:

• Right now on RISC OS the TaskScheduler is part of the WIMP, which implies that if a task is not WIMP based then it cannot run in multi-tasking (either CMT or PMT or a mixed fashion)
• The above means that RISC OS Kernel for instance is still single task running in a BBC Micro fashion if you want and having no concept of threads and code that could modify its state concurrently
• The WIMP TaskScheduler is CMT which also means that a single task running in the WIMP, if badly designed or coded, can “freeze” the Desktop and the other WIMP tasks (note words being chosen carefully here, so WIMP Task is not the entire OS for example)
• The SMP library right now allows us to run “threads” on a separate CPU core, however such a thread still belongs to a task so is kinda dependent on the above assumptions
• The SMP library right now doesn’t seems to support VFP and NEON extensions, so a math intensive thread scheduled on a separate CPU core may result not as fast as executed on the main CPU via VFP or NEON extension if it would benefits from them

The above are just some considerations/assumptions, there is more, but I am trying not to write an essay lol :D

It is true however that if the Kernel could support thread scheduling on multiple cores allowing them also to compete it would be a big step forward for RISC OS, if nothing else just to interrupt our WIMP Task execution more often so that the WIMP would result more “PMT” like (this assumption comes from the fact that a task could still be running part of itself in a separate core for the code that doesn’t need to access the WIMP API)

@ David

CMT is not too, but perhaps it could be enhanced with time limits on tasks.
Or at least a message “[name of application] is blocking the desktop → wait/interrupt/stop”.

Yup that’s the point of the hybrid approach. However it’s easier said than done lol, let me give some considerations for the case above:

• In CMT the truth is that the entire system is still single task (some may argue that also PMT on a single core is still single task and that would be true), so to have the above we need a mechanism (the simplest of which we already have [ALT] + [F12] to stop a task) using IRQ to start a check for example
• How does that check should work? Accounting used WIMP time? Accounting used Kernel Time? Accounting used extra core time for a single thread? All of the above?
• When we start adding control we kinda get into the same situation as PMT is: What’s the right way to understand what a piece of software is doing in order for the Kernel (in RISC OS the WIMP) to do the right choice?

As an example:

1. User runs a couple of tasks both processing very large JPEGs (for example ChangeFSI, again just an example, please don’t start with “but I use !SuperThis or !SuperThat instead and so I am good” lol)
2. ChangeFSI starts taking a lot of time (but the user really wants those JPEGs converted to Sprites)
3. RISC OS start showing annoying messages that ChangeFSI is using too much time, what the user wants to do?

In my understanding, the mentioned problems need not happen with an AMP approach:

RISC OS and the WIMP will still see only the main core, so nothing changes. But a WIMP task, like ChangeFSI, could claim the additional cores, using the existing SMP_CreateThread. When this is done, nothing changes for the other running WIMP programs. But ChangeFSI will get much faster.

Now lets say, Iris Browser is started, and wants to claim an additional core, for making a Youtube video faster. If all additional cores are already claimed, Iris Browser would run just as expected. If additional core can be claimed, Iris Browser will get faster.

If ChangeFSI makes a mistake, its claimed additional cores will get locked. But ChangeFSI should recognize that additional cores completion flags do not come, and call SMP_DestroyThread for them. If this does not work, RISC OS will crash. But currently, RISC OS crashes anyway, if an error cannot be handled. So nothing changes :-)

There is no need to show messages of taking too much time. Even though there are such annoying messages in Windows. Instead, the Task Manager could show claims on the additional cores. And Task Manager Quit should call SMP_DestroyThread

There may be one problem with the current SMP module. Its threads are not limited to one thread per additional core. Therefore threads must regularly call SMP_Yield. In my view, only one thread per additional core should be allowed. Because with SMP_Yield, two threads could lock each other, and therefore lock the additional core:

https://gitlab.riscosopen.org/jlee/SMP/-/blob/master/docs/SMP

@ Lothar

Interesting thoughts, thanks for sharing.

About your concerns with the current SMP module, yup the README reports that. A bit more details below.

The actually thread_yeld function calls spinrw_write_lock to set up a write spinlock, now that function is from SyncLib and will wait forever if it can’t set the write spinlock (is designed to do so).

Such function also disables IRQs and has to be executed in privileged mode, hence there is also a context switching involved to call thread_yeld (if the thread is in user-space).

However spinrw_write_lock should sleep the thread that is waiting to get the write lock, hence it’s possible that, with IRQs still disabled, and other threads trying to join there might be situations where that core could be made unaccessible and if this happens and the thread is not asynchronous with the main thread on WIMP Core then the WIMP Task may stuck and freeze the Desktop. But if the WIMP Task is asynchronous with such thread then the WIMP Task may just wait for a signal back and so keep working regularly without completing its job (which would be more like nobody knows what’s happening) which is a different outcome than the crash scenario and not what we want in both cases.

Using a single thread per core is surely safer, but will make a user confused on the performance, because there will be big bumps: when a core is available then performance could increase a lot and when it’s not available then performance may not increase at all and the software in execution may result much slower and for no apparent reasons…

So as you can see here comes the famous “price to pay” for these approaches. The user is required to know what he/she is doing and so does the software. The big rise of PMT simply solved all the issues from the user perspective and the generic developer perspective hence convenience at the price of optimisation and latency, but for years CPUs and computers got faster and faster and so this was not a concern.

Just my 0.5c

> but will make a user confused on the performance, because there will be big bumps

It will then just feel like Windows, when “Windows Modules Installer Worker” or “Defender” pop up and take near 100% load on all cores :-)

It will then just feel like Windows, when “Windows Modules Installer Worker” or “Defender” pop up and take near 100% load on all cores :-)

loooool :D

So as you can see here comes the famous “price to pay” for these approaches. The user is required to know what he/she is doing and so does the software. The big rise of PMT simply solved all the issues from the user perspective and the generic developer perspective hence convenience at the price of optimisation and latency, but for years CPUs and computers got faster and faster and so this was not a concern.

This a good point. You still are not going to be able to port large applications such as web browsers and have them work at a reasonable speed even on high end hardware, unless they can do proper PMT and SMT. Even for the trivial stuff that I write, I’m not going to re-structure code which works everywhere else just for RISC OS if it uses some neither fish nor fowl scheme of CMT on the primary core and yielding threads on other cores.

Though in 90% of such cases you find the programmer was lazy about something important.

Everybody is lazy, programmers habitually so, that’s why they create libraries instead of recoding and testing each time.

I think what you meant was “sloppy in what they did in the code and equally sloppy in their testing.”

@ Druck

You still are not going to be able to port large applications such as web browsers and have them work at a reasonable speed even on high end hardware, unless they can do proper PMT and SMT.

Absolutely correct, which is why for the Cloverleaf project and the RISC OS Direct that seems to want to push RISC OS Desktop to the masses I am not so sure it’s being done the right way.

I repeat my self (sorry for being pedantic), right now RISC OS has potentials for embedded applications and IoT with the smallest number of changes.

While, for an effective modern Desktop experience, it probably needs some re-thinking, where probably means I am trying to be well mannered and not aggressive, but with the complexity that CMT + AMP will introduce on both the average Jo user and the general developer, I think RISC OS may not have a huge success as a modern Desktop, I hope I am wrong.

On top of that we have the security issues, so really not sure what to say guys, however I hope for the best as always.

Fast-forward to today… Right now there are still people who wish to improve RISC OS as a modern Desktop (and there is nothing wrong with that, except now it’s going to be a loooot of work to try to compete with OSes that have evolved for the last 30 years)

Ironically, technological “progress” may be pushing things in a favourable direction, thanks to the recent trend of doing f*****g everything with f*****g web applications. If the Iris project delivers a browser capable of both running all the usual “productivity” stuff, and facilitating all modern ways of picking fights with complete strangers, then RISC OS as a whole would be far more usable. To this end, a good multitasking model (albeit as a sticking-plaster rather than a long term solution) might be “Iris, when running, gets to do whatever the hell it likes”.

Iris, when running, gets to do whatever the hell it likes

Soon we will have Irisc OS.

“Iris, when running, gets to do whatever the hell it likes”

What could possibly go wrong?

How does that check should work?

If forcing preemption, every X centiseconds since the last poll unless the program says otherwise.
If reporting an app blocked, then X seconds since the last Wimp poll unless the program says otherwise.

If you’re wondering about the “unless the program says otherwise”, think how printing works…

Everyone is leaving out Zombie tasks in PMT systems.

Yeah, I’ve come across that. Not often, but it can happen on XP. Trying anything with the program gets the “bong!” error sound and redraws go to hell with bits of stuff splattered all over.

The user is required to know what he/she is doing

I disagree. How and why the multitasking works is not a user problem (unless said user is a programmer). I run apps on my phone. What goes on inside? NMFP, I just want the app to work.

In my view, only one thread per additional core should be allowed.

Surely this is just an implementation problem? Threads, when created, ought to be shared out as necessary with no requirement of the program to know what core it is running on. Why? Think what ought to logically happen on a single core machine.
If a program doesn’t yield correctly to work on single core, it won’t work correctly coexisting with other threads on other cores.

Ironically, technological “progress” may be pushing things in a favourable direction…

I agree with your point, but I also have to mention that thanks to the continuous changing I have a job! Otherwise we would still be using Dec vt100 terminals ;)

How does that check should work?

If forcing preemption, every X centiseconds since the last poll unless the program says otherwise.
If reporting an app blocked, then X seconds since the last Wimp poll unless the program says otherwise.

Rick I wish it was that simple, here is a real life example for you then:

1. Process 1 requires resource X, to get it P1 requests a mutex for X
2. X is already owned by Process 2, so process 1 has to wait
3. Process 2 to complete its job requires resource Y, to get it P2 requests a mutex for Y
4. Y is already owned by P1, so process 2 has to wait
5. the rest is history of every day :D (for the non techy users, this is the point where things can go very badly on a PC)

(hint they are both working fine, just waiting for the OS to give them their mutex back…)

In another thread you’ve mentioned Tannembaum, the example above is THE example of how PMT can gets complicated.

The solution in this case is to use graph theory and map all the resources on a system and blah blah blah, tons of literature on the matter

Now this means that on RISC OS not only we need to add the PMT, but also the above and believe me when I say to get that stuff right is a job on its own, you guys have mentioned zombie processes… let’s think about it for a moment, grab your mug of tea, have a sip, think about it… and yes coffee for me!!!! :D

@ Stuart

Soon we will have Irisc OS.

loooool true! :D

@ Rick

The user is required to know what he/she is doing

I disagree. How and why the multitasking works is not a user problem (unless said user is a programmer). I run apps on my phone. What goes on inside? NMFP, I just want the app to work.

In a CMT that means no help/support from the OS itself on a number of things:

• When an application go unresponsive the user needs to know what to do, on a PMT the process will get zombie and the rest of the OS and other apps will keep working just fine (unless the OS is Windows lol)
• Some application in CMT may take some time to process data and in such time they may not release control back to the OS, so if a user is running such apps on a CMT he/she needs to know that is not wise to try send an email at the same time (the email client may timeout due lack of time-slices to keep processing data from the sockets). This is even more true when a network connection is UDP based…
• Some application may take a lot of time to complete some jobs without releasing control to the OS, in these situations the system will appear very unresponsive, however the user needs to know that everything is ok and he/she doesn’t need to reboot the computer

Are the above enough or do you need more? (not trying to change your opinion, just providing more details to explain mine)

Just my 0.5c

And as for porting a browser, the problem is that no one wants to actually port it (too much work), they want to write pseudo compatibility layers instead (Unix Lib, SharedLibs, etc). If they were to take the time to actually port the applications (use the OS native API’s directly, not some compatibility layer) including reworking execution paths to support CMT correctly then the prograams would run correctly without the issues we see.

What you are describing isn’t porting, it’s re-writing from scratch for an OS which works in a completely different way to anything else. That was tried and failed when browsers were 1/1000th of the complexity they are now.

The only way to port something is to produce compatible versions of the support libraries it uses, and to have an OS which doesn’t lack fundamental features or needs a completely different way of working. Specifically we are lacking SMT i.e. threads which can use all OS APIs, and all the side effects of PMT such as blocking IO which RISC OS can’t do only having CMT.

I agree with your point, but I also have to mention that thanks to the continuous changing I have a job! Otherwise we would still be using Dec vt100 terminals ;)

It’s almost paid for this place, probably a “snap” at Chez Ruck and a number of others round ‘here’

That was tried and failed when browsers were 1/1000th of the complexity they are now.

True and not so true. For Firefox, for example, there is one codebase that could be easier to adapt than the others: the Android version.

What could possibly go wrong?

Quite a lot of things, I readily concede.

Process 1 requires resource X, to get it P1 requests a mutex for X

Well, there’s your first problem. RISC OS is basically a one-thing-at-a-time OS. How we multitask is a matter of smoke and mirrors and not making assumptions (like expecting font, colour, or OS_GBPB position ¹) to be the same between polls. Hell, one cannot reliably assume file handles are constant across polling (especially if something naughty did a *Close and a bunch of handles were reopened with one of them using the same handle you’re using).

How will it work in practice? Well, there’s the question. That process will probably stop pending something somewhere servicing what it is asking for.

Y is already owned by P1, so process 2 has to wait

Yeah, a resource deadlock. A possible way around that is not to have processes that require resources from other processes that require resources from it. After all, this isn’t exactly a Unix system. ;-)

the example above is THE example of how PMT can gets complicated.

Yup. Read that. Didn’t he call it the Diner’s Problem or something?

When an application go unresponsive the user needs to know what to do

You don’t really “get” zombie processes on RISC OS. The application will either crash (and the OS usually takes care of error message and recovery, even these days trying to gloss over the backtrace gibberish) or it will appear to freeze. At which point the user can press Alt-Break to try to kill the app.
It’s actually simpler than Ctrl-Alt-Del to call up the process manager in Windows (I’m referring to XP as I’ve not used anything later) when a zombie app happens. Because, trust me, the fact that the multitasking continues is little consolation when there’s a big window covering most of the screen that won’t go away and trying to do anything with it (including minimise) is “BONG!” time.
It also isn’t helped in that there appears to be a subtle difference in how the process manager works. Trying to kill the application might fail. The way to nuke it is to switch to the process list and pick the appropriate process and kill that. Which means the user, potentially, needs to understand that there’s a difference between applications and processes and able to find and terminate the correct thing. Or, you know, reboot the piece of crap ’cos that works too.

[ personally, I don’t bother with the process manager, I fire up ProcessExplorer and do it directly ]

So, you were saying what about CMT requiring more user knowledge?

It’s not an issue of what type of multitasking is in use, it’s an issue of how the system is designed. For example, RISC OS can (usually) survive power cuts or pulling the plug, so long as this doesn’t happen at the exact instant of a disc write. XP, on the other hand, needs to be shut down gracefully. I made a fair bit of tea-and-biscuits money back 15-odd years ago dealing with XP bluescreening to UNMOUNTABLE_BOOT_VOLUME because some twit yanked the plug rather than waiting a minute or two to shut down properly (of course, trying to get proper clueless users to understand that “Shutdown” is behind the “Start” button is a battle in itself).

When using a computer, the user needs to have some idea of how to do certain tasks. Things can (and will) go wrong, and each problem at user level (in other words not BSOD stuff) will have a solution that should work. How to get rid of unwanted/errant tasks. You know, swipe-up on iOS or swipe-sideways on Android (though I think they’ve changed it again) once you’ve brought up the list of active applications. And yeah, that’s something else useful to know.

Whether it is CMT or PMT is really not relevant in the discussion.

(unless the OS is Windows lol)

My XP is really quite stable, and only dies horribly if I use USB serial and USB networking at the same time. One or other of them is a lame-ass driver that is broken.

On the other hand, I got a LiveCD version of Ubuntu to kernel panic simply by trying it out and running a few apps. (…LOL)

Some application in CMT may take some time to process data and in such time they may not release control back to the OS

Which is why the OS helpfully provides an hourglass. It’s smart enough that it won’t turn on for a third of a second, so you can drop it into your program as necessary, and it will only appear when the activity is slow enough to be noticed.
There’s a percentage – very useful to use if you’re taking time. There are even little coloured bands (LEDs) above and below the hourglass… for some reason.

But most of all, it’s probably worth looking at the algorithm to work out if there are places where one can drop in a few calls to Wimp_Poll, set to return immediately on a NULL event (see, it does have a use). This means the app can do it’s stuff and the desktop keeps on chugging. That’s how Manga parses its big list ’o stuff.

so if a user is running such apps on a CMT he/she needs to know that is not wise to try send an email at the same time

There’s such a thing as buffering and flow control. I never had a problem sending and receiving emails while intensive operations were ongoing, like debatching news or processing fido packets. The machine (an A5000, 25MHz ARM3) would stutter as the job was done, but by and large everything kept on going.

An email client probably shouldn’t make silly assumptions regarding the ‘speed’ of the data link, the user might be using a 14k4 modem, for example. As for the internal time out of a socket, I think it’s a good long time. Not long enough to support carrier pigeon packets, but long enough to deal with hiccups and glitches. I’ll let Authentic Steve chime in here, he probably knows this.

This is even more true when a network connection is UDP based…

UDP doesn’t give the guarantees of TCP. Anything using it ought to be either managing itself, or able to cope with missing packets.

however the user needs to know that everything is ok

Copy-paste the above paragraph regarding the hourglass. :-)

just providing more details to explain mine

I am looking at this specifically from the point of view of RISC OS. There will soon be a method to allow software to reside on other cores. It should also involve task switching (so that it can correctly run on n cores, where n is >=1, spreading out the workload as necessary).
However, underpinning all of that… is RISC OS. The same one we know and love right now. The same one that needs a nappy and a bottle of Rhum if you dare try to print something to the VDU in a service call handler. The same one that runs every task at &8000 ². The same one where all I/O is blocking (you can’t dump a megabyte to a file and let everything else carry on while you busy-wait it being done; everything will stop for the duration of the write).

That’s where I’m approaching this from. So, yeah, if we’re going to add any sort of PMT to RISC OS, it’s going to be PMT in the very loosest definition possible. Basically enforced time slicing, akin to how Wimp2 did things. And, note, that ran into a number of difficulties regarding message/event queueing and needed to do some hacky patching to handle interrupting something reading from file. More details elsewhere, suffice to say, “it’s not going to be easy”. ³

¹ Special exception for FilerAction, because that’s far from the only dumb assumption it makes…

² Not strictly true, some module tasks can run in place, modules themselves, and utilities (that load into the RMA). But anything with filetype Absolute (&FF8) expects to start at &8000, and BASIC programs start up “sort of there” (usually ~&8F00 after some workspace for BASIC to use).

³ Defining “not easy” as “a ground up rewrite with an entirely different API that can actually do this stuff in the sort of way that a preempted system needs in order to function”. That kind of not easy.