Re: [rtmk-discuss] regarding migrating threads

[Johan Rydberg]

On 2002.02.11 18:51 Carlos Manuel Duclos Vergara wrote:

: > The concept of "processes" does not exist in rtmk.  Instead there's
: > [...]
: : This weekend i thought  about this and i thought that one way to make
: activations and resources live safely inside this happy new world is thorugh
: a sort of daemon. I mean, it could be possible to start an "activation
: daemon" and this way watch threads and resource locking. It will also be able
: to re-schedule threads, because if you change a thread from one task to
: another... what about its re-scheduling??? somebody needs to take care about
: that.
: Maybe this sounds like a contradiction in a real time kernel, but is only an
: idea.

I might need to clear out the concepts:

In the current (and normal) implementation each thread is bound to its
execution environment, that means the task.  What really binds the thread
to a single environment is the protected virtual address space. The
scheduling parameters each thread holds ain't really bound to an execution
environment.

So we split the concept of "threads" into two parts; threads, and activations.
Where "threads" are just scheduling parameters, and activations is the
execution unit (e.g., hardware registers, ...).

Characteristics of activations:

 * bound to a exeuction environment (i.e. a task),
 * holds machine-dependent states (e.g., hardware registers, ...)
 * can be populated by a thread

Characteristics of threads:

 * not bound to any execution environment,
 * just holds scheduling parameters,
 * can not execute on its own.
 * can populate an activation.

When created, a thread does not belong to any task in the system.  If
a thread wants to execute, it has to "populate" an activation (and an
execution environment).  When initializing thread, you assign a "initial
activation" for the thread -- this is where the thread will start to
execute.

Since a thread no longer belongs to particular execution environment
we can migrate threads between two different environments.  This is
done by attaching a new activation to the thread, suspending the
current activation (this will be implemented as an per-thread
activation-stack).

The thread will live in the current environment until it migrates
into another (normaly the one it last migrated from).

So I do not see any reason for an activation daemon.


: > Sounds great.  I have tried to make the kernel as portable as
: > possible, so I guess there should be no real problem with porting
: > it to the Coldfire architecture.
: : I look the source code and there was really a little assembly code. However
: and as i told you before, Coldfire doesn't have mmu so it will be a little
: tricky.

I have done some thinking as well.  It should be possible to support non-mmu
cpu's, but not without constains.  For example, it will not be able to fork
an address space.  But since CPU's without MMU's are normally only used in
(deeply) embedded environments there's really no need for multiple address
spaces.

regards
johan