Sending events to RCV end-point and not immediately switching to RCV thread

[phanikishoreg]

With Tcaps, there is a possibility that a ASnd to a RCV end-point may not always switch to it, which depends whether Sender wants to YIELD to it or If the Recving tcap has higher priority over the sender to be able to switch to it.

This possibility of not switching to the rcving thread has other side-effects, especially if the last state of the rcving thread is THD_STATE_RCVING. If this is the case, then the scheduler thread of the rcving thread would always be notified of the current thread state(i.e, RCVING) with no indication of whether there were Sends to it (whether there are events pending in rcving thread's queue).

The proper design level solution would be to introduce additional thread states, that indicates if the thread is blocked and has no events pending, etc. Basically thread states need to be more elaborate. And changing the thread state to reflect pending events whenever there is a ASND to it.

At this point though, I'm aiming at a low-impact quick-change solution and not expose kernel level to bugs because of the deadline constraints. And that would be, to return a boolean with a sched event to the scheduler which indicates whether the thread has "pending" events, so that a scheduler thread can decide to schedule its rcving thread for it to process it's pending events.

[Others]

Closed by #200 (@phanikishoreg can you confirm?)

[phanikishoreg]

At the kernel level, the thread states are only tracking for return to user-level semantics for preemption/non-preemption register restore and return convention for a thread suspended on cos_rcv.

Having thread states for blocked/unblocked are a user-level scheduling responsibility and not the kernel.
So PR #200 is the fix for this issue, yes.