I'm thinking also that we'd have to change the kernel UTCB mappings?
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%24a69...
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