OSDev.org

Hi,
I'm redesigning my taskmanager and I wanted to add a feature that my old manager didn't have: Inter Process Communication. To be honest I haven't read allot of articles on that subject yet, but I've been thinking about simple ways to make it work myself. I came up with the following system of using software interrupts, custom handlers and shared memory:

When a process wishes to pass a message: it puts it's process ID and thread ID in eax and ebx and the physical address of it's message in ecx and preforms a software interrupt.
The handler gets called, reads eax, ebx and ecx (and wakes the waiting thread) and adds those values in the process's message box.
The process or thread maps the physical memory and reads it, unmaps the address, and then it confirms the message by doing another software interrupt.
The original process deletes the message and frees the physical page.

A process can be put to sleep if its waiting for a message a be woken when it arrives, or can constantly check his message box.

=>My question what do you think about my idea?Good?Bad? Or would you like to add something? What are the cons of this idea?


=>I'm also wondering if this would work nicely on SMP architecture, (haven't read allot on that either) or if I should adapt it to make it work.

You don't need the interrupt. You can copy the message in the sender context, then it's put on the receiver queue and if the receiver is receive blocked you resume it. Using interrupts here will not give you any advantage and would probably cause more task switches than necessary. In the SMP case, if the thread is blocked it must go through the scheduler anyway in order to be assigned a CPU which will be done if you resume the thread. The interrupt comes in when you want to notify another CPU regarding scheduler status in an SMP environment.

There is always the question if the copy is supposed to be done in sender or receiver context. I copy it in sender context but receiver isn't wrong either. Each solution can have its advantages.

EDIT: Your solution regarding interrupts when a message arrives isn't completely off. I've seen it being used in some simple real-time systems. When a message arrives the subsystem core gets an interrupt and takes care of the message while the message interrupt is off. This is useful in simple systems where you want a deterministic behaviour, while it is not really appropriate for "rich OSes".