![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
||||||
![]() |
![]() |
|||||||
![]() |
|
![]() |
Execution contextsAn Execution context is a way of grouping domains with respect to a common thread of execution. A Platform independent model (PIM) can, unchanged, be deployed on a single threaded platform or on a platform using as many threads as there are domains (and everything in between). Thus, execution contexts provide a mechanism for flexible deployment ranging from small, embedded platforms to large, multicore platforms. A restriction is that a domain may only be deployed to a single execution context. Xtu currently provide 2 kinds of execution context:
The process context is where all execution starts, i.e. that is the place where the main() function goes. The process context is also the usual place for setting up and booting any threaded execution contexts. Communication between execution contexts is handled by a multithreaded aware bridge type. To a domain (and a PIM), there is no difference between a single threaded and a multi-threaded bridge. They transfers signals and operations in the same conceptual way. Xtu currently provide the two classes xtu::DefaultProcessContext and xtu::DefaultThreadContext. xtu::DefaultProcessContext supports creation and management of xtu::DefaultThreadContext by the method xtu::DefaultProcessContext::createThreadContext(). The context life cycle provides hooks for booting domains & bridges, running the scheduler, idling where there is nothing to do as well as shutting down the context in a controlled way. |
![]() |
Events
|
![]() |
![]() |
|
©Copyright 2020, Lonfield C&D, Linkoping, Sweden. | ![]() |
|||||||
![]() |
![]() |