Commit graph

3 commits

Author SHA1 Message Date
Anna Lyons
4f00022f7d mcs: Use cancelIPC instead of reply_clear
- reply_clear only does half the job
- remove reply_clear no longer used
2019-08-22 11:22:39 +10:00
Anna Lyons
f103ac223d mcs: Refactor replies to solve revoke problems
Before this change, we set the replyObject in the thread state on recv
with no back pointer such that stray pointers would be left in the
thread state when a reply object was completed.

The new semantics are clearer and fix this problem by doing the
following:

- tcb->tcbReply is removed and the thread state field is always used,
  this was unneccessary duplication previously
- the thread state value is set to the reply object only when the thread
  is in BlockedOnReply or BlockedOnRecv
- the reply contains a back pointer, replyTCB, which points to that
  thread
- if a thread has its reply removed, it must be set to
  ThreadState_Inactive.
- deletion is easy in the blockedOnRecv case, we just unlink the reply
  and the tcb.
- deletion is complicated for blockedOnReply. If we are deleing a tcb,
  we remove the actual reply object and the call chain is broken. If we
  are deleting a reply, we maintain the call chain by moving the tcb to
  the next reply.
- we refactor the reply object interface to solve the above.
    * reply_clear: removes the reply from any connections (tcb, sc)
    * reply_unlink: just unlinks the tcb and reply, and sets the thread
      state to inactive
    * reply_remove: removes the reply from the call chain
    * reply_remove_tcb: removes the exact reply that a tcb is bound to,
      as we are removing that tcb. Breaks the call chain.
2019-08-22 11:22:39 +10:00
Anna Lyons
554f812da3 mcs: scheduling context donation over ipc
After this commit, threads blocked on an endpoint can recieve a
scheduling context from the thread that wakes the blocked thread.
2019-08-22 11:22:37 +10:00