alman at mgateinc.com
Tue Sep 24 10:40:28 CEST 2002
From: "Adam Lackorzynski" <adam at os.inf.tu-dresden.de>
> On Mon Sep 23, 2002 at 01:06:56 +0000, Alexey Mandrookin wrote:
> > I found strange behaviour of l4_i386_ipc_wait().
> > In case of interrupt IPC, it return wrong value
> > of the thread id of IPC source.
> You're waiting for a specific interrupt, how useful it is to know the
> "source" if you already have the dest id (this specific interrupt)?
Due to synchronous style of micro kernel, it is very useful to know IPC
Point is that thread wait events from two sources and it need exactly
who is sent event.
Let me explain problem. Thread 5.1 is an interrupt handler. Thread 5.0 is a
By the term, user task cannot wait for key press events, it need only
when no calculations or other work present. The way of hardware interrupt
OS interrupt -> Interrupt handler (5.1) -> User task (5.0)
As you can see, the Task 5.0 must wait for IPC from thread 5.1, otherwise
will locked in l4_i386_ipc_send () function. In that case, next interrupt
can be lost or pended.
Idea is send signal from 5.0 to 5.1, which will inform interrupt thread what
a user task waits
for data. Next, then hardware interrupt coming, it check what user task
ready for receive
(i.e. in IPC wait state). If user task waits, then IPC send from 5.1 to 5.0,
otherwise data puts
Of course, thread 5.1 can try to send IPC to thread 5.0 in any case, and if
return L4_IPC_SETIMEOUT status, put event into buffer. In that case possible
when data present at buffer, user task waits for event and no new interrupts
Another example: COM1 and COM2 generate different interrupt. It is better to
device driver for both ports. It that case also need to know the interrupt
> If you're waiting for an interrupt, use ipc receive, don't care about
> source stuff (also see p. 29 of the L4-V2 ref manual).
Yes, I read in that document, but there some differences with
Anyway, returned values not covers by any L4 documents and look strange.
More information about the l4-hackers