Re: transfer of execution with IPC

Joshua Haberman wrote:
> Sorry if any of these questions are already documented somewhere -- if so,
> please refer me to the appropriate documentation.

Here is a recent paper about (among other things) L4 scheduling and IPC:

http://www.ertos.nicta.com.au/publications/papers/Ruocco_06.abstract.pml

Comments and criticisms on the paper are welcome.

> If I do a send+receive IPC and the receiver is already waiting, does the
> receiver immediately run (as opposed to running the scheduler, and picking a
> thread that may or may not be the receiver)?

Depends on which type of send+receive is done. Is it a Call() or a ReplyWait() ?
The policies are different.

On L4::Ka Pistachio 0.4 and NICTA::L4-embedded a Call() will switch directly to
the receiver (timeslice donation); a ReplyWait(to, from) will switch to the
receiver (to) IFF it has a strictly higher priority than the sender (from),
otherwise the sender will run. Check the paper for more details.

> What if it was a send (no receive) IPC?

The receiver runs IFF it has a strictly higher priority than the current thread.

> Assuming neither of these trigger the scheduler, does the scheduler run again
>  at the end of the original thread's timeslice?

On L4::Ka and L4-embedded the scheduler runs at the end of the timertick IFF
what is left of the *current* thread timeslice -(minus) the length of the
timertick is < 0. Again, see the paper for a more detailed discussion.

> Are these behaviors considered part of the L4 API specification, or are they
> implementation details?

They are typically considered implementation details, but since they have
relevant implications for real-time systems, they should not be disregarded.

> Thanks, Josh

Regards,

	Sergio
-- 

--

http://www.cse.unsw.edu.au/~sruocco/
ERTOS Researcher                                              Lecturer
National ICT Australia Ltd.              University of New South Wales

This email and any attachments are confidential. They may contain
legally privileged information or copyright material. You should not
read, copy, use or disclose them without authorisation.  If you are
not an intended recipient, please contact us at once by return email
and then delete both messages.  We do not accept liability in
connection with computer virus, data corruption, delay, interruption,
unauthorised access or unauthorised amendment.  This notice should not
be removed.

begin:vcard
fn:Sergio Ruocco
n:Ruocco;Sergio
email;internet:[email protected]
version:2.1
end:vcard