Hi,
On Tue Aug 05, 2014 at 15:00:02 -0800, Yuxin Ren wrote:
I cannot understand the logic of the IPI interrupt handler very well. I hope someone can help me. Thanks a lot. I am using intel IA32 multi core cpu. My scenario is one client and one server thread on different core. Client sends simple data-only IPC to the server.
- The function Thread::handle_remote_requests_irq is the IPI interrupt
handler, right?
Yes, it is.
So it is running within the interrupt context?
There's no such explicit thing, however, yes in the sense that this function is run due to an IPI/IRQ.
If so, 2. In this function, the variable "c" is set to the current Context. On the server core, when the server is blocked(waiting for IPC), what is current Context? The server thread or the idle thread?
Likely idle.
I have no other threads in the user level, and I assume there are nobackground threads in the kernel or L4Re.
Yes, then idle.
In addition, I guess each thread associates with a Context.
Yes, a Context is a base class of a Thread.
If my assumptions are right and that current Context is idle thread, 3. At the last of this function, it calls c->handle_drq(). But when does the server thread's handle_drq() is called?
There's also a _pending_rqq where the sender CPU puts in requests and the receiver takes them out and processes themesses them.
- In what situation, the variable "resched" will be set to true?
Whenever schedule() must be called because threads changed their state and a reevaluation is needed.
When it is true, 5. c->schedule() will be called, does it mean that we can switch to another thread in the interrupt context? It cannot make sense to me.
Yes, this is done. But do not think of this as an interrupt context (like Linux?), it's much more the same than an entry via a thread's syscall.
Adam