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