kernel/sched: Clean up docs for _pend_thread(), limit scope

The scheduler has a kernel-internal _pend_thread() utility which
sounds like a function which will add an arbitrary thread to a wait_q.
This is essentially unsupportable in SMP, where that thread might
actually be executing on a different CPU.

Thankfully we never used it like that.  The only spots outside the
scheduler that use the API are in pipes and mailbox, which both just
want to pend a DUMMY thread to track the timeout but will never try to
pend a true foreign thread.

Clarify the comment and add an assertion to make sure this promise
isn't broken in the future.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit is contained in:
Andy Ross 2018-03-09 13:29:00 -08:00 committed by Anas Nashif
parent 345553b19b
commit 81242985c2

View file

@ -189,10 +189,16 @@ s32_t _ms_to_ticks(s32_t ms)
}
#endif
/* pend the specified thread: it must *not* be in the ready queue */
/* must be called with interrupts locked */
/* Pend the specified thread: it must *not* be in the ready queue. It
* must be either _current or a DUMMY thread (i.e. this is NOT an API
* for pending another thread that might be running!). It must be
* called with interrupts locked
*/
void _pend_thread(struct k_thread *thread, _wait_q_t *wait_q, s32_t timeout)
{
__ASSERT(thread == _current || _is_thread_dummy(thread),
"Can only pend _current or DUMMY");
#ifdef CONFIG_MULTITHREADING
sys_dlist_t *wait_q_list = (sys_dlist_t *)wait_q;
struct k_thread *pending;