Why is SMT (multicore) support hard for Amiga OS?

[Fats]

Anyway my last 5 years I did almost nothing but multi-core software design and programming across a diverse array of hardware. I've never written a multi-core OS though. But from my user view, I don't get why multi-core is hard. Threads can run on whatever CPU, synchronization primitives built into the OS need to be updated to do the proper things across cores, and the kernel needs to know how to schedule cores? I must be missing something, obviously.
Thanks

AmigaOS uses a lot of public memory like Execbase. To allow multitasking access to these memory spaces, they are often surrounded by Forbid()/Permit() pairs. This is in system code, libraries and user programs.
Problem is that in a multi-core/multi-CPU occasion also the programs running on the other processor(s) have to be paused when a Forbid() call is made. This will make it very difficult to get any advantage of multiple cores or even may make it run slower due to the overhead.

greets,
Staf.

[Fats]

@Bif

This is just another case of one simple design decision, to share memory pointers for a bit of extra speed, coming back to bite us 25 years later

I disagree, I'm a big fan of message passing by pointer passing; it is one of the reasons I stay with AROS and did not delve into something like DragonFlyBSD.
IMHO, the bad design decision was that user programs were allowed to call a system wide lock. It is like the linux BKL (bug kernel lock) but then an order of magnitude more difficult as it is also used by user programs.

greets,
Staf.

[Fats]

To get things straight; I never wanted to imply that SMP is impossible on amiga-like systems. I just answered the question why I think it is hard.

Lots of interesting stuff here, I am learning a lot just sitting back and watching this for a bit =).
However, how does this even work on a single core system? Isn't access to these resources synchronized across tasks/threads already? Otherwise how do you know if whatever you have written to various memory locations is not in a half baked state when the other thread consuming it or also writing to it wakes up? Does the kernel have some intelligence when swapping tasks to ensure this somehow? I can't imagine that. I'd think this must be what the Forbid()/Permit() type of thing are exactly for if there is no other synchronization mechanism involved in these shared memory locations? I would think the kernel would not allow a task with a Forbid() in place to be swapped for this reason.

Exactly and a program in Forbid() state could rely on the fact that it is the only program in the system that is reading and/or writing to memory. On a SMP system this means that you have to stop all other programs on the other processors/cores.
You could implement this as a start and see what is gives for performance but given that Forbid()/Permit() is used over all the code in the libraries, drivers and user land code I think you will need to invest a lot of time to replace usage of Forbid()/Permit() with semaphores or other synchronization systems to get any benefit of SMP.
But like always I like to be proven wrong.

greets,
Staf.