Thread context switch

[Daniel Waddington]

Norman,
When we first tried this we used getcontext/makecontext/setcontext like 
implementations.  Basically these APIs allow us to construct a stack and 
register state (context) to switch to.  I thread is switched by loading 
the registers and changing the ip/sp.   I think the main issue is that 
in our first attempt we did not copy the "additional context members" 
and "UTCB" to the new stack frame.  The thread switching works until you 
try to access the utcb.

Do you see any issue in simply copying these extra bits?

Daniel



On 03/25/2011 01:51 AM, Norman Feske wrote:
> Hello Amadeo,
>
> is your question related to Daniel's posting earlier this month?
>
>
> http://genode.org/community/viewml?thread_name=008f01cbddc7%248cdc9d90%24a695d8b0%24%25waddington%40samsung.com&forum_name=genode-main
>
>> Is there any mechanism to switch contexts in Genode threads? What I want
>> to do is, whenever some condition is satisfied, to save the current
>> thread context, create a new context (new stack, update sp and ip) to
>> substitute the thread’s old context, and restore the old context when
>> another condition is satisfied.
> In short, there is currently no way in asynchronously changing the
> context of a Genode thread via the Genode API.
>
> Your question leaves open whether or not the original threads gets
> preempted (similar to receiving an interrupt) at any time during its
> execution, or if the thread explicitly yields control (e.g., by trying
> to get a lock, or by invoking a system call). The former case is similar
> to a VCPU execution model, which must be supported by the underlying
> kernel. Of Genode's current base platforms, only Fiasco.OC provides such
> a feature. Hence, Genode does not expose a VCPU-like abstraction at its
> API level. The latter case is much easier because your problem can be
> modelled with using multiple threads and locking, or by employing a
> user-level threading library (using setjmp/longjmp).
>
>> I have looked into the implementation of the Thread class and, even
>> though the thread context is public, the context allocation APIs seem to
>> be private. Is there some other public API that I can use for this
>> purpose? What would be the most reasonable way to tackle this?
> The 'Thread_base::Context' does not contain any CPU registers. It hosts
> only the meta data Genode needs to manage and use the thread. For
> example, the pointer to the Thread's UTCB, the thread name, and the top
> of the stack. Therefore, this API is private to Genode.
>
> To provide you with a sensible approach, I'd appreciate more specific
> information about your actual problem. In particular, the above question
> (VCPU semantics or synchronous flow of control) is important.
>
> Regards
> Norman
>