Thanks Gernot !<br>That did make it clear. <br><br>suresh<br><br><br><div class="gmail_quote">On Fri, Apr 17, 2009 at 1:40 AM, Gernot Heiser <span dir="ltr"><<a href="mailto:gernot@nicta.com.au">gernot@nicta.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Suresh,<br>
<br>
If you think about it, you'll realise that it doesn't matter from the<br>
PoV of semantics. The reason is that an IPC only happens if both the<br>
sender and receiver are ready (by definition of synchronous IPC).<br>
<br>
The implementation scheme used in L4-embedded (and, to my knowledge,<br>
all previous L4 versions -- I should actually check what OKL4 does ;-)<br>
is to simplify implementation: the message is always transferred while<br>
the kernel is in the sender's context. In the case where the receiver<br>
is waiting for the IPC, this means that the data is never touched, it<br>
is simply left in the registers while a context switch is performed to<br>
the receiver. (Ok, memory-backed message registers are touched, but<br>
that's unavoidable.)<br>
<br>
In the case where the sender is blocked when the receiver initiates the<br>
IPC, you don't lose anything, as you'd still have to restore the<br>
register message from the sender's TCB, and that's easier to do in the<br>
sender's context.<br>
<br>
And for virtual registers that aren't mapped to physical registers it<br>
doesn't matter.<br>
<font color="#888888"><br>
Gernot<br>
</font></blockquote></div><br>