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.
Oops, yes, I did mean to say SMP, duh. SMT presents the same problem though.
Thanks for the insight Fats, that sheds a bit of light on it.
So it seems Forbid()/Permit() is a coarse-grained synchronization mechanism to allow shared access to resources. I'm thinking that shouldn't be a huge obstacle preventing multicore. Indeed while one core has a Forbid() taken out, another thread on another core might have to block/idle, which is not desirable.
However, I think every multicore OS already has this problem and suffers from it. There is not much way around it, access to shared resources requires synchronization. The Win32 API for example may not have equivalent Forbid/Permit, but when you call into the API to allocate memory or access the file system, it is performing it's own synchronization anyway. If two threads are accessing the file system, one will have to wait for the other to exit the critical parts of the API. Probably a key difference here is the granularity, in Win32 the file system may have one or more of its own mutexes, and the memory allocator a different one. So the file system access won't block the memory allocation system, and so on. In other ways the Forbid()/Permit() scheme probably has advantages, because each AmigaOS API call doesn't have to include the synchronization and thus will operate more efficiently. I've designed a number of APIs that work just this way, and execute on multicore just fine. Taking out a lock on each API call can get expensive as locks can get expensive.
The main reason I don't see the AmigaOS calls blocking being a huge issue is because a well written program that is using heaps of CPU probably shouldn't be spending all of it inside AmigaOS calls. You shouldn't have to call into AmigaOS to perform DSP, physics, rendering, or whatever other kind of expensive logic you need to execute that requires all that CPU. Memory allocation may be an issue but it shouldn't be too bad I think, and if you have to, you can create your own private heap to allocate from without the need for synchronization - where I come from you try to simply never reallocate memory so you don't even have to deal with the memory system. I'd think most AmigaOS calls would come down to user interface and IO. I can't see 10 programs all trying to access UI at once and having it stall things out. I think probably only file IO should be a real problem. And every other multicore OS is going to have the same blocking problem here. It's really not much of a problem in practice.
I think for multicore all you can do is try to minimize the time the OS holds locks on shared resources. If programs are written poorly such that they put Forbid() calls around large chunks of code it will prevent good multicore execution. But it would also be forbidding good single core execution as well as other tasks won't be able to get their timeslice if they are blocked out.
Ideally you can create lockless APIs...but realistically that's near impossible, especially for OS functionality I would think.
Anyway I'm just kind of babbling ... still wondering if there is something else big preventing AmigaOS going multi-core.
