[NTLK] Geek Question: TTask and TUTask

Matthias Melcher mm at matthiasm.com
Fri Feb 20 04:28:30 EST 2015


Great help. Thank you, Simon. I will limit myself to TTask and TSCheduler and see what happens. The code that glues everything together is the context switching at the end of all SWIs. I will try to implement my own context switching. After that, I can "weave in" the native code on a task-by-task basis.

If that works, we can combine any native code that exists with emulation for the parts that have not been rewritten.

> On Feb 19, 2015, at 2:06 PM, Simon Bell <simonbell at me.com> wrote:
> 
> Paul will have a better understanding of this. But here is my take on it.
> 
>> On 18 Feb 2015, at 22:53, Matthias Melcher <mm at matthiasm.com> wrote:
>> 
>> Why did the engineers create TTask and TUTask?
> 
> To protect the OS kernel from user access. The same pattern is used for monitors, ports, shared memory: all objects.
> 
> A TUTaskWorld encapsulates the ports and shared memory a TUTask needs to communicate with other tasks; it is the world in which the task lives.
> A TUTask creates a kernel TTask to run the task code, but the only (very limited!) access to that TTask is through the TUTask. The two are not related in any class hierarchy.
> 
> The task queue managed by TScheduler holds only TTask instances. If you are replacing the task switching mechanism I don’t think you need be concerned with CUTask at all. But depending on how deep your replacement goes, you may need to consider that the SWI handler twiddles processor registers stored in the TTask for copying shared memory as well as task switching.
> 
> Simon
> 
> ----------------------------------------------------------------------
> 
> http://newtontalk.net/



More information about the NewtonTalk mailing list