Thinking ahead: Supporting multicore CPUs

any programs that want to talk direct to hardware could be fooled by the HAL into thinking they were talking direct. An application in one thread might think it has exclusive access.

Is this not true of any system that has a possibility of multiple tasks talking to hardware while sharing time/resources with other tasks that might want to do likewise? To give an example, it seems something of a free-for-all with regards the other high resolution timer…

Perhaps the way forward is an extension of the device claim protocol to be able to flag in the HAL (and read in other tasks) whether or not something has been “claimed”? This could even be expanded fairly simply (a few LDRs and a TST) to fault an application trying to use something that it has not first claimed… [it should request the task handle (UID for non Wimp programs) to allow us to tell one app from another]

aaaaa

The thing is that this mean, those task should be user task, and behave as such, and so being prevented access to anything below wimp.

Define “below Wimp”?

RISC OS is not Linux. It isn’t Windows either. The Wimp provides the “framework” for handling task switching and the graphical environment. Nothing else.
If you want to know the time,you ask the kernel (or Territory, who asks the kernel on your behalf).
If you want to redraw a window, you do so using the basic kernel graphics primitives.
If you want to load or save a file to SD card, you’ll be using the filesystem (SDFS, FileSwitch,DeviceFS, SDIO, FileCore…it’s complicated!) which is neither the kernel_nor_ the wimp.

The important thing with the suggestions that I am making is that I am thinking of ways to enhance RISC OS without messing up compatibility. This isn’t Linux where random people can bugger around with the kernel API and just “expect” everything else to lock step. The RISC OS market is small, and perhaps Aemulor is the best testament to the important things that didn’t make the transition to 32 bit (never mind later rotated loads). It is absolutely imperative that further modifications do NOT break correctly written software…

aaaaa

It is absolutely imperative that further modifications do NOT break correctly written software…

Yup, and the difference between an application being presented with full access to the system on a 200MHz clocked processor as a CMT OS application and an application being presented with apparent full access to a system via a thread running on a 2GHz PMT system such that the thread appears to be a 200MHz system is what exactly?
Other than the fact that the CMT app can post messages to a specific area and pick up replies from an adjacent area.
Jaffasoftware had a nascent messaging model to communicate between apps on the same system or different systems by network links. The Jaffasoftware ActiveApps page references another product ZeroMQ
The OS already has a messaging system, add, alter or expand?

aaaaa

aaaaa

aaaaa

aaaaa

You see, my (way simpler) proposal was to add a “preempted behaviour” to the existing Wimp.

+1

I see the wimp PMT (and only in the wimp) as a means to task switch without having an explicit polling loop

+2

It’s just moving the problem of sync away in the user application space, but it’s not really solving much of the issues.

Yes, and? Everything related to multitasking is – in RISC OS – managed in user space by the Wimp. That’s a limit, but also a good thing (you can stop using multitasking at any time), and not so inefficient (a monotasked kernel is really light: try to run dhrystone in supervisor mode VS taskwindow).

And then you could do pretty much anything in any thread

Except from running tasks made for CMT (the 50% one that do not work with Wimp2).

and there is no synchronization primitive in riscos

What for? The kernel is monotask.

The important thing with the suggestions that I am making is that I am thinking of ways to enhance RISC OS without messing up compatibility.

+3

It is absolutely imperative that further modifications do NOT break correctly written software…

+4

One thing to think about also with multicore

IMHO, SMP is a complete non sense for a ‘monotasked’ kernel. AMP + messaging + CLI access would be much more easier to implement, even if more complex to use (the same for PMT VS CMT). That’s the path Amiga users followed some time ago with great success.

SMP is cool, but really too much work and problems. AMP is ‘doable’ today. A few line of codes permit to simulate several ARM systems (with their own memory space) on a multicore processor. ARM says that you can run several sessions of the OS, and if they do not access the same external resources, they will work ‘as is’, without any modification.

Of course, access to all CPU resources in an AMP system is not automatic and transparent, but it’s a good way to use multicore, and a perfect path for clustering (that works exactly the same way).

That’s why I did propose AMP + a set of interaction tools (remote CLI, remote FTP, remote messaging), for multicore systems, but also for mini clusters (for example some Pi configured in USB device mode or present on a network). Then it will be very easy to offlad tasks to other cores or other processors.

Cluster mode (Cores, USB devices, Ethernet devices) would be a great add on to RISC OS, especially with a feature to auto-discover available resources. Of course, interaction tools should be the same in the 3 modes, but with different ways to exchange data (shared memory for cores, usb stack for device mode, ethernet stack for network mode).

That’s a different subject, but more closed to the topic :)

And of course, all of this (AMP mode) not in the kernel, but in modules/user-space. The RISC OS advantage is that all can be unplugged. RISC OS is not here to fix rules, but to provide some services. I see it as a toolbox :)

aaaaa

So just do it. you’re welcome :)

From what i could see, it’s just because the wimp2 author didn’t want to whole job, even saying himself that it would not be a very big thing to make it so, and he does some kind of hack to patch existing application to make them works with his system, and implement his lock primitive etc internally, instead of doing it like it ‘should’ be done, moving those synchronization primitives and the task system one level below, and make in sort bigger part of the system can be preempted, thus allowing regular wimp task to be preempted without having to do all those tricks.

The author had one big hurdle that isn’t present now:
The OS source wasn’t available then, it is now.

He did what he could in the limits existing at the time.

aaaaa

aaaaa

Is there a particular reason why some things are broken into several files (like wimp01 wimp02 wimp03 etc) or is it just for readability and could be considered as a single file ?

Think about the time when the Wimp was written. Windows barely existed. Linux didn’t exist. Memory was frightfully expensive, harddiscs too. It may well have been broken into sections so that it could be loaded and assembled in parts rather than clogging up a machine that would be laughably small by today’s standards trying to assemble the entire Wimp in one go.

If I recall, one of the things that happened at the ROLtd camp is to reorganise the Wimp into sections related to what the code was doing (like “icon stuff” and “messaging stuff”) with appropriate names, as opposed to the current mess of numbered files with stuff scattered around. There are rough “themes” to each file, but there are plenty of exceptions, and with no sensible form of function indexing, it is harder than it ought to be to find functions.

I have here a personal copy of the Wimp where I have started to do this, but it’s about a dozen versions out of date. ;-)

aaaaa

aaaaa

aaaaa

aaaaa

What i will try to do is to make ROVIEW be able to load several file,

Could be “doable”. Dupe the file loading stuff into an array and have it select what you wish to look at. It might be worth considering making a “cache file” to save parsing the source every time it is loaded – you can check the file is “the same” (same date and size?) and if so, load a predigested version instead? Just an idea…

and being able to keep in track of things like routine entry points,

It already detects labels in the file you’re looking at. Could do with being refined, but it’s a start.

Note the terms of the licence: You may do what you like with this software provided that you do not remove my credit nor supply this software with a more restrictive licence. If you use this software, or any part of it, to make money, then share… and finally if you fix bugs or extend this software, you must report these changes back to me on the understanding that I may include these changes in the main release of this software; you will be mentioned… If you distribute an executable, you must state somewhere that it is a modified version (not the ‘original’); and you must make your sources available for download according to these terms."

In other words, I expect you to report modifications back to me (and I may extend the original accordingly), you can’t make it GPL, you should mention that your version is not the “original”, and your version should be released with the same licence.

Someone should do an eclipse plugin for this :P

Five or so years ago, I looked at the possibility of doing some stuff with Android. At the time, Orange France offered Usenet and I used to follow comp.sys.acorn using “Groundhog” which was pretty basic but open source. I installed the Android SDK and Eclipse and thought I’d try looking through the Groundhog source to see how it all fit together.
Eclipse must be the biggest, dumbest, slowest, crappiest, horrid, horrider, horridest development environment I have ever had the misfortune to attempt use, and that’s harsh coming from somebody who has a Microsoft VisualC++ v1 CD-ROM kicking around in the back of a cupboard (when the MFC Classes were Hot Poop!).
I dealt with it valiantly for about four hours before giving up, uninstalling it all, and writing the entire basic core of an ARM disassembler in about forty minutes. I never continued with this because… what’s the point? I can just use !Zap.

So i take for principle that all wimp task would be considered as preemptive.

No #1:

You may want to look to see how Printers actually produces output. It’s miraculous and OhMyGod in equal measure. ;-)
[hint: it has a lot in common with Wimp redraw; and it is “blocking” in that… well… go investigate]

No #2:

What happens in a message passing setup if a task is pre-empted before it has had a chance to make its reply? A polling cycle without a reply would be taken as a recorded message failure, would it not?

This would not solve the problem for the system level things, but like this, the whole UI managing code of wimp could remain almost identical and in single task. And only the non UI code that application uses would need to be thread safe.

The ironic thing is that you keep talking about what is and is not thread safe, despite our co-operative task switching working without major incident for over a quarter century and, at one point, a pre-emptive system proving that with some glue and string and gum you can pre-empt quite a few tasks that are “slow”. Indeed, my Wimp pre-emption proposal is no more fancy than “when enabled, the Wimp will swap you out after a delay” (a few centiseconds, perhaps), plus some smoke and mirrors to try to mitigate the problems of zombie windows and such. A task could wrap “lengthy code” in calls to enable/disable PMT; and an evil task could, I supposed, call Wimp_Initialise and then immediately turn on PMT and just run both ways at the same time (yuck)…

The point is, not much consideration is being given to what is and is not “thread safe”, just as not much consideration occurred with this within RISC OS over the last nearly-thirty-years. Hell, even FilerAction sort of works. ;-)

The thing with the Wimp is… programs should not be written to expect exclusive access to anything (other than files that they open). With the exception of specific hardware devices (serial port, for example), there isn’t much in RISC OS to claim exclusivity over. A disc editor has to run knowing that sensitive parts of the disc will need to be re-read before writing to ensure that file operations in another task have not changed things during the editing. Actually, low level stuff is best handled by a “helper module” which can pick up on service calls and events and be notified of activity that way. It is good practice to use helper modules for low level things; application code should not be banging on any sort of hardware. Just because you can doesn’t mean you should!

aaaaa

aaaaa