Welcome, Guest. Please login or register.

Author Topic: Kickstarter for buying and open source Amiga OS  (Read 10031 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline psxphill

Re: Kickstarter for buying and open source Amiga OS
« on: August 22, 2013, 09:15:58 AM »
Quote from: Ezrec;745766
But that '25% of the time' _does_ show that a full SMP system on AROS is possible.
 
Lots of debugging, testing, more experimentation, etc etc. is needed.
 
But it is possible.

Your biggest problem is going to be library reentrancy / atomic data update issues.
 
Some of the solutions, like being in a Forbid/Permit or Disable/Enable are likely to break. If you want those to continue working then Forbid will need to stop being a "don't let a task switch happen" to "stop all other cpu's and don't let a task switch happen", which is going to have a much higher cost.
 
Forbid/Permit was always a bad idea, but it's the bad idea we're stuck with that everyone uses.
 
Cache coherency might also be a problem, although that probably depends on the architecture. So you might find what you're doing works for X86 but you have to go back to the drawing board for ARM/PPC.
 
But you're right, unless you do something then nothing will happen.
 

Offline psxphill

Re: Kickstarter for buying and open source Amiga OS
« Reply #1 on: August 22, 2013, 04:09:32 PM »
Quote from: Ezrec;745818
Yes, that's the mechanism I'm currently experimenting with.
 
Forbid() is now 'stop all other CPUs but this one, and don't let task switch happen'
Disable() is now 'stop all other CPUs but this one, don't let task switches happen, AND stall any interrupts until Enable()'

Do you restart the other CPU if Wait() is called in a Forbid() and then stop it again when the task that called Forbid() is rescheduled?
 

Offline psxphill

Re: Kickstarter for buying and open source Amiga OS
« Reply #2 on: August 22, 2013, 05:52:53 PM »
Quote from: Ezrec;745830
* An implicit Forbid() occurs, and the Disable()ing CPU waits for all other cores' tasks to finish their Quantum, and wait for the Forbid() to release.

Is that how your forbid works? That the other cpu is only stopped when it's quantum expires? That would probably be a mistake, the first cpu might be trying to send a message to port that is on the other cpu (which currently requires a forbid to make sure the port doesn't disappear before you send the message).
 
Quote from: Ezrec;745830
* hardware IRQs are not longer delivered to CPU0 (which is the only core that can get hardware interrupts in this mode)

How is the second cpu task switching if it has no hardware interrupts? Is it controlled by the timer on cpu0?