Bounty proposal - preemptive multitasking under RISC OS

Another bounty: PMT support for RISC OS (I rely a lot on WIMP2 for this project).

The idea is to get a PMT scheduler working inside RISC OS, in parallel with the normal CMT system. PMT stands for Preemptive Multitasking and CMT for Cooperative Multitasking.

The PMT scheduler will use hardware timers (present in HAL). PMT compliant applications will delegate SWI calls to the PMT system, with specific libraries. The PMT system will then be able to manage all the reentrancy problems. This behaviour should be as transparent as possible, the main objective is to allowed a WIMP application to become a PMT one with a simple recompilation, if possible.

A CMT accelerator should also be provided for old applications. This one will make old applications be preempted by the PMT system (with SWI redirection, if possible). Of course, since a lot of applications will not be compatible with this approach, a whitelist / blacklist of applications will need to be done, based on user’s tests.

A Configure plug-in should be provided for all the is. WIMP2 code must not be used, as the objective is to include the PMT system inside the RISC OS source code. So no GPL code.

Of course, the PMT system will be available from CMT applications, with a light threads library (closed to the one used for AMP mode).

I have also money for this project.

Any ideas?

Arg: wrong title. Should be preemptive multitasking under RISC OS! Sorry for that.

[Fixed by ROOL]

Nota: we could also use the PMT system to implement light threads, available from CMT applications (as we can launch CLI applications in PMT mode with a taskwindow). It would be the same API as the light threads library proposed in this other bounty: https://www.riscosopen.org/forum/forums/8/topics/3079

Some thoughts:

Wasn’t wimp2 written by one guy? If so he would be able and might be persuaded to make it available under a suitable second license.

I’m not convinced about patching existing apps, I seem to recall with properly written or upgraded apps Wimp2 worked fine, the patched things weren’t so good.

In the first stage of development, surely it should be a module to be used on as many versions of RISC OS as possible? So that all new or upgraded software could use it.

I’m not bothered about old apps still using CMT, 1, because I’d prefer them to keep working properly, and 2, old apps generally work fine anyway. (And don’t some people see CMT as an advantage for their homebrew stuff when they want as full control of the processor as possible?)

The PMT scheduler will use hardware timers (present in HAL). PMT compliant applications will delegate SWI calls to the PMT system, with specific libraries. The PMT system will then be able to manage all the reentrancy problems

Can I suggest I slight modification to this approach, which will allow you to implement it without the SWI reentrancy issues:

Install a short piece of code onto the SWI vector that increases a counter when SWI is entered and then call the original SWI vector switching it to return to your code. When the original SWI handler returns, decrease the SWI counter and check if its zero and IRQ enabled in SPSR, if not exit to the original caller. If IRQ are enabled in SPSR and the SWI counter is zero, check if the PMT timer has triggered and exit to the PMT task switcher instead of the caller if so.

For the PMT task switcher timer code, check the SWI counter is zero, if not set a PMT triggered flag and exit. If it’s zero, switch tasks immediately.

EDIT: You’ll also want to check IRQsema in the SWI code so you don’t task switch whilst in an IRQ handler

Wasn’t wimp2 written by one guy?

Yes, it was, and I now believe he works at ARM Holdings doing lots of very clever work for them.

Wasn’t wimp2 written by one guy? If so he would be able and might be persuaded to make it available under a suitable second license.

Yep, good idea.

I’m not convinced about patching existing apps, I seem to recall with properly written or upgraded apps Wimp2 worked fine, the patched things weren’t so good.

Some worked well (around 20%), some not at all. If only a few work it’s better than nothing.

In the first stage of development, surely it should be a module to be used on as many versions of RISC OS as possible? So that all new or upgraded software could use it.

Perhaps, or not. The current module is OK for RISC OS 4. A new one could use HAL timers, and be integrated into the Wimp source code (so no need for hacks). It’ll be much simpler (big part of code is for timer, big other part are hacks to integrate with Wimp).

And don’t some people see CMT as an advantage for their homebrew stuff when they want as full control of the processor as possible?

I do. But I remember also that Filer was more usable with it…

Yes, it was, and I now believe he works at ARM Holdings doing lots of very clever work for them.

I think he’s been there and done that. I’ve just looked at his LinkedIn profile and… I mean… Bloody hell…

A new one could use HAL timers

I’d avoid HAL timers until they’re extended to allow timers to be claimed or shared. TickerV should be more than sufficient for PMT as you’re trying to task swap the process hogs – PMT doesn’t add anything over CMT for well behaved processes.

And don’t some people see CMT as an advantage for their homebrew stuff when they want as full control of the processor as possible?

Could you not scale the amount of time a process gets based on the % of it’s time slot its using. You’ll also want process priorities, such as Realtime, High, Normal, Low etc.

TickerV

It’s for centiseconds needs. I remember that Wimp2 used a millisecond or microsecond timer.

Could you not scale the amount of time a process gets based on the % of it’s time slot its using. You’ll also want process priorities, such as Realtime, High, Normal, Low etc.

On a different, but closed subject, it would be cool to have something more precise than WimpPollIdle. This one guarantee a minimal delay, but not a precise delay (and sometime you wait much much longer than expected). A Wimp event for timers would be much more simpler and logical. Nota: perhaps this feature already exists :)

Some worked well (around 20%), some not at all. If only a few work it’s better than nothing.

That is bad enough that an autopatcher should not be part of the main distribution, and patches (as opposed to properly upgraded apps) should be issued with care.

Perhaps, or not. The current module is OK for RISC OS 4. A new one could use HAL timers, and be integrated into the Wimp source code (so no need for hacks). It’ll be much simpler (big part of code is for timer, big other part are hacks to integrate with Wimp).

Wouldn’t that be phase 2, once you have a range software that can use the module, you move it to the main system (so it works better).

You’ll also want process priorities, such as Realtime, High, Normal, Low etc

What would be ideal would be if current CMT were simply mapped to realtime. Pretty sure it won’t work that way though.

On a different, but closed subject, it would be cool to have something more precise than WimpPollIdle. This one guarantee a minimal delay, but not a precise delay (and sometime you wait much much longer than expected). A Wimp event for timers would be much more simpler and logical. Nota: perhaps this feature already exists :)

I don’t think such a feature can exist already, since the Wimp cannot control whether tasks poll it in a timely manner or not, so it cannot guarantee a precise delay with Wimp_PollIdle. That’s really the point of this whole discussion, isn’t it? Moving to a system where the Wimp /can/ control that; where it can pull back control when it sees fit, not when the currently running task sees fit…

It’s for centiseconds needs. I remember that Wimp2 used a millisecond or microsecond timer.

Giving a task up to 100th or a second as a worst case is acceptable, most tasks will return quicker than this anyhow, allowing the task switcher to switch more than 100 times a second.

On a different, but closed subject, it would be cool to have something more precise than WimpPollIdle. This one guarantee a minimal delay, but not a precise delay (and sometime you wait much much longer than expected). A Wimp event for timers would be much more simpler and logical. Nota: perhaps this feature already exists :)

For precise timing you’d use timers and not rely on the WIMP to poll at a specific time. Wimp_PollIdle is a means to pause an idle task, not call it regularly. Filers tend to use it to hand back for seconds at a time.

This is probably going to seem like a daft question, but why does RISCOS need PMT? What do you want to achieve? A more responsive WIMP or fix poorly written apps?

That is bad enough that an autopatcher should not be part of the main distribution, and patches (as opposed to properly upgraded apps) should be issued with care.

As it was with Wimp2. A tool, and a list of carefully tested applications.

Wouldn’t that be phase 2, once you have a range software that can use the module, you move it to the main system (so it works better).

Yep. Sounds good to me.

This is probably going to seem like a daft question, but why does RISCOS need PMT? What do you want to achieve? A more responsive WIMP or fix poorly written apps?

Three things.
1/ more choices. A PMT system + a CMT one would be cool. And useful to for some porting needs.
2/ some applications will be more responsive. Even if not all, and mainly only applications made for PMT.
3/ a way to provide light threads to other applications (the same way we can launch CLI taks in PMT mode with Taskwindow).

The point 3 is linked to my other proposition of an AMP support. A PMT scheduler for other cores, with light thread support from applications.
Here it’s the same for the main core, via an integrated PMT system.
Nota: the PMT system could also be used for Taskwindow, or the existing Taskwindow code could be used for a more generic PMT system.

The point 2 is interesting for the future. With a PMT system and RISC OS source code available, some system applications could be converted to PMT, with even threads if necessary. Point 1 is for tools as Firefox for example or some SDL games.

Hi all,

Whoever chose to fill that bounty, he can grab what I did in a past life.

All he has to do is to download the archive at the URL below:
http://bgilon.free.fr/RISCOS/preview.tar
Open the TAR archive and looks into the embedded “mthread.zip” zip file.
The testing involves both “classic” (ie. 3.11) and “new” (ie. >= 3.5 but still 26bits) versions of RISC OS.
It is not “preemptive multitasking” but “preemptive multi-threading” per se but this can serve as a basis anyway for those interested.

HopeThisHelpsAsTheySay,
Benoît