Thinking ahead: Supporting multicore CPUs

aaaaa

if you use semaphore, it won’t give any gain on multi core system, if the cores are made to run the same critical section in the same time, only one can be running at once, and so the gain of paralellization is zero.

I suspect you are doing the designers of such a system a disservice. If you think, the two kernels cannot be the same, by necessity.
Imagine – two separate kernels, both having access to a disc drive resource. Both with the drive mapping and structure loaded and used. Independently. If we ignore the difficulties of two cores trying to use the same drive controller at the same time, you run into the higher level problem of the two views of the drive map. I talked about something similar a few months ago when somebody had the idea of making a Pi mimic a generic USB mass storage device, to then interact with the filesystem. It just isn’t possible for two things to both think they have exclusive access to the filesystem.

Work-arounds? Well, I guess you could implement a hardware interrupt controller so a core can freeze out the rest of the system while it does its work by polling the controller (can’t use interrupts, the other core(s) may answer; or start their own disc activity). Oh, and the entire disc structure will need to be reloaded before each write in case something else changed it (plus checking stuff like “was this file deleted?” and “is the one on disc newer?”. Result? Horrible. That sort of idea makes my head hurt.

Alternatively, and more sensibly, we would have a secondary kernel on the secondary core, which looks and feels like the real kernel, but the devices are “virtual” and instead of accessing hardware directly, it just kicks everything over to the primary core, which is the one responsible for doing the actual hardware stuff.
This may be how an early multi-core RISC OS works, and it isn’t so far removed from how the “Tube” interface worked (a mini-MOS that provided basic MOS functions but passed I/O over to the host). http://en.m.wikipedia.org/wiki/Tube_(BBC_Micro)

Two pertinent quotes from the Wiki page (my emphasis):

Numerous coprocessors were developed for the Tube. Most commonly seen was a MOS Technology 6502 processor which allowed unmodified BBC Micro programs to run faster and with more memory, as long as they used the API for all I/O.

Acorn had strongly discouraged BBC Micro programmers from directly accessing system memory and hardware, favouring official API calls. This was ostensibly to ensure applications could be seamlessly moved to the Tube 6502 coprocessor, since direct access from there was impossible. When a program called one of the MOS entry points, a replacement subroutine in the coprocessor’s ROM passed a corresponding message to the host which carried out the operation and passed back the result. In this way an application could run identically on the host or the coprocessor.

This isn’t a new problem. There is a long history of using multiple processors in the same system (and, indeed, Acorn has a somewhat unique history of using multiple alien processors in the same system!), so whether the processors are actual separate devices or cores within the same piece of silicon, that doesn’t make much difference. It isn’t new, it isn’t unknown. There are case studies and use results for a variety of implementations. None of them are absolutely perfect, but then the problem we are facing here is essentially two children with one toy. ;-)

aaaaa

As far as i know, even a sata controller can only handle on request at time

What the hardware can do and what the driver element of the OS can do and what the OS overall can do for an application are very closely linked if your OS stops doing everything else (like talking to your app) because it is waiting for a hardware element to respond.
Think blocking i/o and a slow response to an ethernet packet send and ack.

RISC OS generally sits closer to the hardware, there is a penalty. Great for bare metal style operation, not so good for massively asynchronous like video display changes and a DNS request. Applications have to release control of the CPU or nothing else gets a chance.

aaaaa

aaaaa

aaaaa

hobby1, I don’t think people are as fixed on gaining performance increase with threading as you seem to think they are. Threading can be very useful for the exact opposite, performing background tasks that have a low priority but can be time consuming. Kicking off a thread to do some calculations for example while you continue to do other things in the front end. As such it can help give the illusion of speed and even help return the control to the user much sooner.

aaaaa

It may be easier to implement for the OS developers but how will it be for the average application developer? Sounds to me they would have to start developing for two separate back-ends with two different designs and methodologies? Hardly something to encourage new development.

aaaaa

aaaaa

aaaaa

aaaaa

On Windows, whether you write a console app, a windows application or whatever it’s still a subject to the same underlying PMT kernel.

You seem to be suggesting (I may be misunderstanding you here) keeping a part of RISC OS as CMT and then somehow have a separate PMT exclusively for background tasks. That puts the developer in the situation of possibly having to build an application that runs both on a CMT and a PMT system on the same machine at the same time.

That’s what Wimp2 applications did. Some were compliant, and preempted. The other run in CMT mode. Best of two worlds (3, as you can go to monotask with CMT, if you keep all the CPU time for you).

Wimp2 was mainly a set of tricks. With timers in HAL and source code available, it would be much easier to implement it today. The idea is very simple: if my task is compliant, I’ll stop it after xxx cs. Else I will not.

aaaaa

OK, so you’re basically suggesting a similar route as others have suggested here – I guess I was misunderstanding you there!

aaaaa

Well on windows when you look at it […]

Kindly look at the .Net runtime. I have deleted all but v1 from my system as the C: drive is a 4GiB SSD that Windows and its associated rubbish filled up. I would love to drop in .Net 3.5 (or whatever the latest is) but no, it doesn’t work like that. In order to be compatible with all the various versions of .Net, I need to have all the various versions of .Net.
To put this into context, it is like every C program built with a different CLib requiring that version to be present on the machine. How stupid it would be to have half a dozen CLibs installed at the same time.
Point is – with “backwards compatibility” like that, please don’t hold up Windows as being any sort of sensible API.

You never saw an application being frozzen on a pmt system maybe ?

Yes. Even to the point of rendering the system near unusable.

or even the whole system going down ?

Depends. I have had Windows crash on a BSOD, but these days those tend to be “important” hardware problems that the only thing the OS can reasonably do is report it and die disgracefully. The last BSOD that I remember XP throwing was when the graphics card fan stopped on the NAS box and it all went wrong. Can’t get the fan to go, but the machine runs ‘stable’ so long as I stick to 640×480. Any more than that, the GPU overheats and the machine crashes. Wheee!

I have had Linux suffer a peculiar error where the login process (I think?) died, so I couldn’t log in from keyboard nor could I telnet in nor did it respond to serial logins. The machine was still up, pinging it gave a response, but it was just dead to the user.
This is probably like RISC OS when you crash the kernel but the Caps Lock key and the pointer still work. How dead is dead? ;-)
For me, I’d say “Linux died on me”. At the time, Linux advocates were very specific to point out that the kernel was still running, blah blah. But it isn’t a hell of a lot of use if my only option is to hit the big red button…

There are number of things you can perfectly do under unix that will put the system on its knee with very simple C programs, like recursive forks for ex.

Sounds like the process handler sucks. Can’t it detect and throttle this sort of behaviour? Can a five line C program really bring a Linux system on its knees…in 2015?

Normally, you could use ‘volatile’ variable, but the volatile keywords normally doesn’t garantee anything regarding ordering of instruction that the compiler or cpu can think as being independent from each other because they only see one part of what will really be going on on the cpu during the execution.

It means “don’t cache”, in other words, always read the variable “live” from memory. The problem is, as you suggest, that a task can be switched out between reading the variable and making use of it. This isn’t a multi-core issue, it affects single core threads too.

their whole multi threading engine revolve around this,

From the kernel up is aware of this behaviour. Frankly, I think with RISC OS we would be better looking for a simple and compatible way to implement PMT-like behaviour within the Wimp. Something like the proposal I made a few days ago may be “doable” in a few weeks of part time coding by somebody knowledgeable of the Wimp’s internals.
To do proper PMT in the command line? You’re possibly looking at rewriting the entire kernel and then breaking it to remain compatible… Any sensible timescale on that? ;-)

Maybe at a certain level they all rely on a same kernel, but does that make all the different kind of runtime on which all application are built identical , not really,

No, the runtimes are not identical. But if the underlying kernel doesn’t support what is being asked, the only option is something like the RISC OS Wimp – which provides support for multiple tasks.
Think about it – you mention all these different runtimes, but you forget the extremely important point – that you can run them at the same time. VC, MFC, COM, ActiveX – all of this stuff can run at the same time so it should be clear that the common factor in the PMT behaviour isn’t the runtime at all. The runtimes just offer different ways of exposing the underlying task switching.

The thing i was suggesting is more that the os would be fully pmt, but keep the whole current cmt layer as a single task of this pmt system,

That’s more or less how Win32/NT deals with Windows 3.1x tasks.

Personally, I would try to implement a “the Wimp can run this as a PMT task” for three reasons:

• It will take a lot less time than rewriting the Wimp.
• We can’t afford to create a Wimp that isn’t entirely compatible with the current API – we’ve already lost too much to unavoidable hardware changes.
• From this, we can be better placed to see how PMT’d code behaves and look to ways to refine the system without dealing with the massive upheaval of having first recreated everything else.

It’s a question of economics…

And again, on something like the pi where most UI application are supposed to be driven by event coming from a busy usb bus that already have the ethernet card on his arm, the risk of seing the window manager on the main cpu overflown by events is very low, so the interest of really having ui capable preemptive task is really moot.

Code of that nature (USB, ethernet) should be working off interrupts from the respective hardware and be completely disassociated from the task switching stuff.

If the back end raises an event to a UI-level process (an app), it is up to the UI handler (Wimp) to store the state for the application, and the application to request the data from the back end as and when it can, and for the back end to sensibly manage the data.
For example, if a serial port is a simple Rx/Tx style, it is possible that an application slow to respond may result in data loss. A better serial port could have the back end detect buffer filling up and automatically deal with flow control (CTS/RTS) to tell the transmitter device to hold off.
The Internet stack is similar, so a program that works well on a 1.xGHz Panda will also work, albeit slower, on a 33MHz ARM6 RiscPC. The difference between 33MHz and over a gigahertz is massive; but it works because everything behaves in a sensible manner. Oh, and it all works in a CMT environment too. ;-)

PMT is ubiquitous because the two major OSs use it. But it isn’t the only game in town…

aaaaa

aaaaa

aaaaa

I can see the wimp_poll routine listed in os.c from OSLIB but i can’t find the code source for it, how do i find the code source for a given ‘routine number’ ?

I’m not familiar with OSLib. Could it be written in assembler? A fair few parts of DeskLib are – you just shuffle the registers around then call the SWI…

but from i can see it’s exactly how i expected, and he’s not even bothering with much.

I think it is “sufficient to do the job without reinventing the wheel”.

He say that apparently even lot of lower level calls are already thread safe as RO3.0 was already meant to be preemptive,

? That’s news to me. From what I recall, Niall was extremely fond of RISC OS 2 and somewhat hated RISC OS 3 (with all that nasty C code leaking in). This, perhaps, shows most clearly with this piece of code:

\ Kick into USR
MOV R9,PC
BIC R8,R9,#3
TEQP R8,#0
MOV R0,R0
\ Apologies to RO3 owners, but the message list was always
\ pointless.
MOV R0,#200
LDR R1,finalisetask
SWI "XWimp_Initialise"
MOV R3,R1

Gee. Thanks. [re. R3]

But already, he gets into a bother to get millisec timer,

Because on the older machines, you had to bash the hardware directly if you wanted a fast timer. And hope that nothing else was doing likewise.

From what i understand, OSLib is what is used to deal with lower level part of event system, messages, and in fact is the lower level routines behind wimp is that it ?

OSLib (like DeskLib, etc) is a library that makes it “nicer” to do stuff from C.

The topology is roughly this:

• Squishy wet thing with eyeballs attached
• Application
• Library
• Wimp
• OS/kernel
• Hardware

The ones in italics are part of the firmware. The HAL ought to sit between the OS/kernel and the hardware, but it seems to me that a fair few things still talk directly to hardware. Not anything like as much as before, but some…

Them wimp is a sort of frontend that manage anything that is UI specific ? (windows, menus, UI events, task abstraction etc), and OSLib is what take care of all filesystem, system events, networking, etc, and wimp is built on top of this to implement a multi task windows system ?

No. The Wimp is the UI and the back end for task swapping and the UI specific stuff. OSLib is… just a library. That translates higher level C constructs into something applicable for the OS.

If you call a function with a name like wimp_poll and pass it a few pointers to data structures, the library will issue the SWI “Wimp_Poll” and mess with the registers either side of the call to get the right data in the right places. It’s easier than inlining __asm and trying to do it all yourself.

I think I’ve mentioned this to you before. RISC OS is not Linux. The Wimp isn’t built from a pile of interacting libraries. It just “is”. And it is here, if you’re interested: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/s/