Re: [rtmk-discuss] regarding migrating threads

[Carlos Manuel Duclos Vergara]

> 
> Hi Carlos!
> 

Hello Johan!

> 
> The concept of "processes" does not exist in rtmk.  Instead there's
> threads, tasks and now activations.  The old notion of a "process" is
> in rtmk a task, with one thread populating an activation.
> Regarding resources.  I have not yet figured that out really.  As it
> seems now there's only need for one kernel stack per thread, not
> per activation.  If this is possible (which I think it is), it will
> reduce the number of kernel stacks.
> If you're thinking about "holding resources" as in locking a
> resource (using a mutex or whatever) this will be done by the thread,
> since the thread holds the scheduling state.  Remember that an
> activation is just, in theory, a set of hardware dependent states
> (i.e. hardware registers).
> 

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.

> 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.
However, if this kernel uses the "daemon locker" it won't be a problem.

Bye