They ran on the same CPU, but you still had to use mutexes and atomic operations because it had fully pre-emptive multi-tasking, and so your application had to be ready to lose execution from one instruction to the next. Torn reads/writes definitively were an issue for higher level code (unless you could be guaranteed that your construct would translate to a single m68k instruction), and needed to be kept in mind even in assembler in some situations (see below).
In fact, you'll find lots of Amiga-software being more brutal and enforcing serial-execution for critical section by using Forbid()/Permit() pairs, which will outright disable the scheduler, or even using Disable()/Enable() (disables interrupts too). Of course this is/was very much frowned upon for all but implementing atomic operations, though even this is not guaranteed to be totally atomic in an Amiga system without taking care.
The need to protect against other threads/tasks is/was one of the first things hammered into the heads of Amiga-developers exactly because it was so new to most, who would usually come at it from 8-bit home computers where the standard procedure was that you fully controlled the computer except perhaps for some very trivial interrupt handlers (which most software would take over control of anyway).
And while each of the normal threads would be running on a single CPU in a basic Amiga, any number of devices could DMA - the Amiga depended heavily on this -, and additionally both the Copper (very basic "GPU" of sorts used to set up "display lists" to manipulate various registers etc. though not really limited entirely to graphics) and the Blitter could access memory at any time too, so you very much had to at least in theory be prepared to deal with memory changing during execution of an individual instruction if working in "chip-memory" (the Amiga roughly works with two types of memory: "chip-memory" is memory where auxilliary hardware can steal bus-cycles from the CPU; "fast-memory" is memory that only the CPU can access).
Also note that while unusual, there were true multi-processor Amiga-setups: There were "bridge boards" for the A2000 which effectively were an x86 PC on a card, where the "graphics card" was a buffer in chip memory that would get displayed in a window, and which would receive input from the Amiga keyboard and mouse. There were also PPC accelerator boards (a release of AmigaOS4 for "classic" Amiga hardware with PPC accelerator boards exists; it basically runs everything it can on the PPC, just like for "new" Amiga hardware), though usually these would disable the M68k while the PPC was executing stuff (but I'm not sure if this was enforced by hardware or if it was done by the OS patches for simplicity).
I used to love to tell people of all the different CPUs in my A2000: A 68020 with the 68000 as fallback (if you soft-disabled the 68020 for compatibility) on the motherboard. A 6502-compatible core on the keyboard (the A500 and A2000 keyboards had an embedded SOC chip with a 6502 core + RAM + PROM as the keyboard controller). A Z-80 on my harddisk controller. An 80286 accelerator board + 8086 fallback on my bridge-board... Of course of the 68020/68000 and 80826/8086 pairs only one of each architecture could ever be running at once.
It was a fantastic machine. Unfortunately Commodore all the way through (from long before the Amiga) was an absolute dysfunctional disaster of a company, and it was a miracle they lasted as long as they did (and a testament to the calibre of people that kept saving the company from self-inflicted wounds)
The biggest problem being perpetual under-investment in R&D, and management meddling that systematically whittled away at the lead they once had. E.g. the archetypical example is the Amiga4000. On one hand it is the "flagship"; the biggest, fastest classic m68k Amiga produced.
On the other hand, it arrived late, was ridiculously expensive, and was slow for what was there. The problem? New management wanted to start all projects over from scratch and put their stamp on them.
IDE, for example, was suddenly pushed onto engineering. Without understanding that the Amiga used SCSI for a reason: IDE of the time loaded the CPU too much. Fine on a single-tasking OS, or on machines with more CPU, but the Amiga was built around offloading everything. It was the only thing that kept it competitive in the face of mounting problems for Motorola with upping the speed of the M68k range (work was underway to evaluate alternative CPUs; PA-RISC was the lead contender at the time; in the end Commodore went bankrupt before making a decision, and third parties chose PPC).
The A4000 was the result: IDE dragging down IO performance; a broken memory sub-system due to rushed redesigns; a butt-ugly case compared to the sleek A3000, and trying to compensate for the other problems by going for a 68040, but going "cheap" and picking one of the slower versions and yet stil ending up too expensive.
The truly crazy thing, though, is that as they were doing this, the "A3000+" was pretty much done. It didn't have quite as fast a CPU, but was a step up from the A3000. It had AGA (the last custom chips that the A4000 also got), and a range of other improvements, such as a DSP providing high-end sound (8x CD quality channels), and that could also double as a built in modem. And it kept SCSI...
The best part? It was far cheaper than the A4000, and would've been ready much faster. Of course Commodore had to axe it...
Being a fan of the Amiga at the time was painful...
In fact, you'll find lots of Amiga-software being more brutal and enforcing serial-execution for critical section by using Forbid()/Permit() pairs, which will outright disable the scheduler, or even using Disable()/Enable() (disables interrupts too). Of course this is/was very much frowned upon for all but implementing atomic operations, though even this is not guaranteed to be totally atomic in an Amiga system without taking care.
The need to protect against other threads/tasks is/was one of the first things hammered into the heads of Amiga-developers exactly because it was so new to most, who would usually come at it from 8-bit home computers where the standard procedure was that you fully controlled the computer except perhaps for some very trivial interrupt handlers (which most software would take over control of anyway).
And while each of the normal threads would be running on a single CPU in a basic Amiga, any number of devices could DMA - the Amiga depended heavily on this -, and additionally both the Copper (very basic "GPU" of sorts used to set up "display lists" to manipulate various registers etc. though not really limited entirely to graphics) and the Blitter could access memory at any time too, so you very much had to at least in theory be prepared to deal with memory changing during execution of an individual instruction if working in "chip-memory" (the Amiga roughly works with two types of memory: "chip-memory" is memory where auxilliary hardware can steal bus-cycles from the CPU; "fast-memory" is memory that only the CPU can access).
Also note that while unusual, there were true multi-processor Amiga-setups: There were "bridge boards" for the A2000 which effectively were an x86 PC on a card, where the "graphics card" was a buffer in chip memory that would get displayed in a window, and which would receive input from the Amiga keyboard and mouse. There were also PPC accelerator boards (a release of AmigaOS4 for "classic" Amiga hardware with PPC accelerator boards exists; it basically runs everything it can on the PPC, just like for "new" Amiga hardware), though usually these would disable the M68k while the PPC was executing stuff (but I'm not sure if this was enforced by hardware or if it was done by the OS patches for simplicity).
I used to love to tell people of all the different CPUs in my A2000: A 68020 with the 68000 as fallback (if you soft-disabled the 68020 for compatibility) on the motherboard. A 6502-compatible core on the keyboard (the A500 and A2000 keyboards had an embedded SOC chip with a 6502 core + RAM + PROM as the keyboard controller). A Z-80 on my harddisk controller. An 80286 accelerator board + 8086 fallback on my bridge-board... Of course of the 68020/68000 and 80826/8086 pairs only one of each architecture could ever be running at once.