Thread context switch

Daniel Waddington d.waddington at ...60...
Fri Mar 25 18:30:18 CET 2011

I'm thinking also that we'd have to change the kernel UTCB mappings?


On 03/25/2011 01:51 AM, Norman Feske wrote:
> Hello Amadeo,
> is your question related to Daniel's posting earlier this month?
>> 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

More information about the users mailing list