kernel: Timeslicing and yield to share code

[peter-mitsis]

When timeslicing moves the current thread to the end of the priority queue, it is functionally equivalent to yielding. It makes sense for the two to share common code.

[peter-mitsis]

Updated as per @cfriedt 's comments.

[andyross]

No real complaints here, but just to be That Guy: if this is really removing duplicated code, why is it increasing the line count by 5?

Sometimes refactoring just isn't worth it, IMHO. In this case the API changes needed to effect the unification are larger than the code being duplicated. Not worth it, IMHO.

[peter-mitsis]

@andyross - There is one other thing to consider. We recently did some optimization on k_yield(). By having move_thread_to_end_of_prio_q() / z_yield() use the same logic as k_yield(), we also gain the benefits of those optimizations at ISR level.

Also, FWIW, I think this also cleans up the SMP behavior as well. Without this proposed change, the SMP version of move_thread_to_end_of_prio_q() / z_yield() logically becomes (after realizing that thread is always _current) ...

	thread->base.thread_state |= _THREAD_QUEUED;
	_current_cpu->swap_ok = true;

1. However, the compiler is not clever enough to reach this level of simplification. It will generate a lot of extra overhead that we don't need.
2. Also note the unconditional setting of the _THREAD_QUEUED bit. Please correct me if I am wrong, but I don't think that we want that here. Isn't all that we truly need for SMP is just _current_cpu->swap_ok = true;?

[andyross]

Yes, QUEUED should only be needed when SMP=y because live threads always remain in the queue on UP as an optimization (they have to come out on SMP so that other CPUs don't try to select them, but obviously that isn't a problem when there are no other CPUs). It would be good to clean that logic up for sure, to e.g. unify the list operations with the bit set such that one can be elided in an obvious way. There are gotchas though with the way things interact with other optimizations though, IIRC.