AROS SMP Research: Technical Discussion

[vidarh]

I don't think anyone has claimed that SMP couldn't be done in a situation where the precondition is that SW base is being built explicitly for that system? Rather the opposite, actually; this is a given! What "people" said is that true SMP can't be done without breaking the Amiga compatibility, which I suppose is a more relevant issue on MorphOS/OS4 than on AROS anyway, since the latter has been CPU/ISA agnostic since pretty much the beginning hence most people are happy to either run AROS builds of whatever SW they use, or run it in an UAE environment.

I think the "breaking Amiga compatibility is a bit too dogmatic. None of the modern alternatives after all run m68 Amiga software directly other than the 68k port of AROS - in all other instances any of the old software that we don't have sources for is run through an emulator/jit. That makes a huge difference, in that it is fully possible to detect attempts at accessing system structures etc., which means careful changes can be made while letting the emulator compensate (e.g. say take up a mutex/semaphore before accessing certain values)

The amount of "native" proprietary software for these new OS's where the author isn't still active is vanishingly small. And the open source software for these OS's can be updated reasonably easily. So if SMP support was added to all of these "tomorrow", how many applications would we realistically "lose"? And if done properly, the "worst case" scenario is to disable SMP while running them.

AROS is in the process of breaking all binary compatibility with past AROS versions anyway, so it's perfect timing for the SMP work as all apps will need to be recompiled, but frankly I just don't believe that it's worth being all that concerned about breaking compatibility over this - the systems where we may want to care about compatibility are the classics, and it's not like they are SMP systems anyway...

[vidarh]

I don't think this should even be considered unless as an absolute last resort. Making that compromise without knowing what the benefits are would be a mistake.

It's not a compromise. It is the clean alternative.

Forbid()/Disable() is the hacky comprise.  In a single CPU system, when done in cases where you're "only" swapping a pointer or two, it can be forgiveable. In pretty much all other instances, it is a big, giant, lazy cop-out that made coding it a tiny bit easier back in the day compared to using semaphores and mutexes to protect the *specific* structures that an application needs to access safely.

Now, I agree that it's not necessary to jump straight into tearing out every Forbid()/Disable() you can find. But we can categorically state that having them there is bad. It's just that for the most part it won't be bad enough to prevent us from seeing some benefit from SMP, and so removing them can wait until there's some SMP support working.

It certainly makes sense to prioritise *where* to clean up Forbid()/Disable() calls first based on profiling which ones actually hurt the most.