JLF65 wrote:
Quote:

bloodline wrote:
Firstly no AmigaOS message may be over 64k in length, so copyign a message is not going to be an "overhead knightmare".

Secondly, any data which is to be shared should be allocated with the MEMF_PUBLIC flag (RKM:Exec, Chapter 6,Page 67:Paragraph4-verse2). So pointer passing still works, so long as you only share pointers to public memory blocks.

I would also advocate having a locking mechanism for MEMF_PUBLIC blocks, so that the OS knows if the memory block is in use, and by whom. That way the OS can flush unlocked PUBLIC memory blocks (useful if they become orphened).

Just occured to me that, if we had locking on PUBLIC memory bocks, then one could actually use the MMU to protect that memory during the lock, so that only the locking task could actually access that memory... so even PUBLIC memory blocks would be protected

The block size isn't an issue if it is allocated with the MEMF_PUBLIC flag. All such memory would have the same mapping in all spaces, so no context switch would be needed.

If it were necessary to lock the memory, you would do it in the BeginIO() or related functions.

So in the device example, lets say our MP system did this:
- create a pool for exec.library to use for allocations done with the MEMF_PUBLIC flag.
- as part of BeginIO(), check if the IO came from the public pool. If so, it is already globally mapped and needs nothing extra done to it. If not, it's an old(or badly written) program and needs to be "locked". The IO structure is globally mapped, along with any data areas pointed to by the IO.
- after it is finished and about to be replied to the sender, check to see if the memory had been "locked". If so, unlock it.

You can see that the support for older or badly written programs would slow things a bit, but not that much. It's just more work for the system to do.

If you don't want the memory to be truly global, you could make it where memory allocated with MEMF_PUBLIC creates an MMU sub-map that could be quickly merged with other maps when needed. Say you set up a message to send to another program - when the other program tries to access the memory, a page fault occurs. The page fault handler sees the memory is public, so it merges the sub-map and retries the operation. After it's over (ReplyMsg or whatever), the system then resets the map to its original form without the sub-map. It's a little more work than the truly global public memory, but safer.

bloodline wrote:
Firstly no AmigaOS message may be over 64k in length, so copyign a message is not going to be an "overhead knightmare".

Secondly, any data which is to be shared should be allocated with the MEMF_PUBLIC flag (RKM:Exec, Chapter 6,Page 67:Paragraph4-verse2). So pointer passing still works, so long as you only share pointers to public memory blocks.

I would also advocate having a locking mechanism for MEMF_PUBLIC blocks, so that the OS knows if the memory block is in use, and by whom. That way the OS can flush unlocked PUBLIC memory blocks (useful if they become orphened).

Just occured to me that, if we had locking on PUBLIC memory bocks, then one could actually use the MMU to protect that memory during the lock, so that only the locking task could actually access that memory... so even PUBLIC memory blocks would be protected

Kalamatee wrote:

I agree we should implement it now rather than later since at a later date there "may be" third party apps, or the aros code base may become so huge that the task is enourmous.

It would also ensure aros is a more stable OS to develop and to develop for.

A CVS Split would be the best idea, and backport the work once it is at a stable point.

Kalamatee wrote:
Quote:

olivier wrote:
Quote:

Kalamatee wrote:

2> The "performance loss" required by memory protection is minimal at worst.

I am not sure of this: Look at the GNU/Hurd and L4/Pistachio. When leaving a task or passing messages you have to "context switch" more than with the actual A-OS system. To avoid number of those switches, GNU/hurd plays with addressing modes...

im not actually refering to numbers of context switches etc. but the percieved performance difference. I personally dont see it as a problem - and worth while in the end.

Quote:

olivier wrote:
Quote:

Kalamatee wrote:

4> The problem itself is to do with message passing in a protected environment - this is something that can be fixed i believe.

There is no message passing in A-OS, but pointer passing. That make the OS deterministic: You KNOW how much data is passed, 32b of a pointer. But on MP you'd have to pass the real data. As such, you doesn't know anymore how much data is passed: You are loosing speed here too and loose your deterministic OS (real time multitasking).

yes and no.

there _is message_ passing - but it does only pass the pointer to the message. and it is this thats the problem.

passing pointers isnt a problem under MP, they are only "numbers" at the end of the day.

its accessing the data thats the problem.

likewise sharing data between tasks isnt a problem - you just define it as public.

Exec and other system components rely on passing messages for AmigaOS to work, but they share 1 message between many tasks/processes. its this that is the problem.

Since the programs are written to expect it all to work that way they would probably need fixed also.

Each reciever should get its own "copy" of the message.

So what needs to be added to the API then for MP?

Kalamatee wrote:

im not actually refering to numbers of context switches etc. but the percieved performance difference.

Kalamatee wrote:
Quote:

olivier wrote:

There is no message passing in A-OS, but pointer passing.

there _is message_ passing - but it does only pass the pointer to the message.

olivier wrote:
Quote:

Kalamatee wrote:

2> The "performance loss" required by memory protection is minimal at worst.

I am not sure of this: Look at the GNU/Hurd and L4/Pistachio. When leaving a task or passing messages you have to "context switch" more than with the actual A-OS system. To avoid number of those switches, GNU/hurd plays with addressing modes...

olivier wrote:
Quote:

Kalamatee wrote:

4> The problem itself is to do with message passing in a protected environment - this is something that can be fixed i believe.

There is no message passing in A-OS, but pointer passing. That make the OS deterministic: You KNOW how much data is passed, 32b of a pointer. But on MP you'd have to pass the real data. As such, you doesn't know anymore how much data is passed: You are loosing speed here too and loose your deterministic OS (real time multitasking).

Kalamatee wrote:

2> The "performance loss" required by memory protection is minimal at worst.

4> The problem itself is to do with message passing in a protected environment - this is something that can be fixed i believe.

im not aware of any third party software for aros that isnt part of the aros cvs tree so none of the offending programs cant be fixed or at worst diasabled for now.