Hello,
On 2023-12-01 03:23, chenpingyuan--- via Devel wrote:
When the notification status is NtfnState_Active, the kernel will try
to donate the notification's schedule context to the thread by calling
maybeDonateSchedContext.
My confusion point is that: If the thread doesn't have a valid schedule
context, the thread will not be able to execute, then how can this
thread call receiveSignal to receive the signal?
Have a look at maybeReturnSchedContext(), which is called by
receiveSignal().
It will remove the scheduling context from the calling thread if it
equals
the scheduling context bound to the notification.
That means that if a passive thread was running on a borrowed SC, it can
do the receive call and then block there after returning the borrowed
SC.
Your next question will be how to make a thread passive. It used to be
fairly complicated, but since the merging of commit e18e32e28e0, which
allows lazy SC rebinding, it's much easier to create passive tasks:
Just bind the thread's SC to the notification it is going to block on
and the SC will be returned automatically when the thread blocks, just
like when it's running on a borrowed scheduling context.
If the notification is bound to the thread's TCB, it can be a passive
server and block on both an endpoint as well as the notification at the
same time, if a SC is bound to the notification object. When handling
a call, the server runs on the caller's SC, when unblocking because of
a notification, it runs on the notification's bound SC.
Because of this, even if you just want a passive server that doesn't
use notifications, the easiest way to make it passive is by giving it
a bound notification object which is bound to the thread's SC. Then
the passive server will use the notification's SC for startup and be
passive otherwise. The notification itself will be unused then.
Greetings,
Indan
_______________________________________________
Devel mailing list -- devel@sel4.systems
To unsubscribe send an email to devel-leave@sel4.systems
