Re: [atomthreads] A qustion about atomThreadSwitch

[Kelvin Lawson]

Hi Elvin,

It might be a bit easier to understand with the comments left in:

if (old_tcb != new_tcb)
{
/* Set the new currently-running thread pointer */
curr_tcb = new_tcb;

/* Call the architecture-specific context switch */
archContextSwitch (old_tcb, new_tcb);
}

/**
 * The context switch shifted execution to a different thread. By the time
 * we get back here, we are running in old_tcb context again. Clear its
 * suspend status now that we're back.
 */
old_tcb-suspended = FALSE;

The suspended flag is set to TRUE when a thread is being suspended,
and is set to FALSE when it runs again. This is used as housekeeping,
to keep a track of what suspension state a thread is in.

For any thread that calls into this function, the calling thread
(itself) is old_tcb and the new thread being switched in is new_tcb.
When you return from archContextSwitch() *in the context of the
original calling thread* then the running thread is back to the
original thread (old_tcb), so it needs to mark itself as not suspended
any more, by setting its flag to FALSE again.

Thanks,
Kelvin.

On 11 September 2012 12:29, elvinwds elvin...@gmail.com wrote:
 Hi All:

 I am a new to RTOS and  have been studying the source code of atomthreads
 for a while,  and now I have question about the atomThreadSwitch function in
 atomkernel.c.

 The source code without comments of atomThreadSwitch is :
 static void atomThreadSwitch(ATOM_TCB *old_tcb, ATOM_TCB *new_tcb)
 {
if (old_tcb != new_tcb)
 {
 /* Set the new currently-running thread pointer */
 curr_tcb = new_tcb;

 /* Call the architecture-specific context switch */
 archContextSwitch (old_tcb, new_tcb);
 }

  old_tcb-suspended = FALSE;

}

 My question is about the last line :   old_tcb-suspended = FALSE. Only
 when the old thread been scheduled back in, the RTOS can run to here. This
 means that when the RTOS runs to here , the old thread has been scheduled
 out, so the state of the old thread can not be suspended, And why have to
 set the state of suspended false here?


 With Regards,
 Elvin

Re: [atomthreads] Thread entry parameter

[Kelvin Lawson]

Hi Holger,

I was just wondering how you got on with Venray and Atomthreads in the
end? Did the processor hit the road?

Best regards,
Kelvin.

On 2 November 2012 08:12, Holger Teutsch holger.a.teut...@gmail.com wrote:
 Kelvin,


 On Fri, Nov 2, 2012 at 12:51 AM, Kelvin Lawson i...@atomthreads.com wrote:


 The target processor is 64bit and unfortunately the entry_param is
 hardwired to 32bit. So it's not possible to pass a pointer in a clean way.


 Wouldn't it be better to define a port specific ENTRY_PARAM_TYPE like
 POINTER ?


 Yes, this makes sense. I've added an issue on Github and will try to get
 this into the next release.

 Great !


 Does the full test suite pass? Are you interested in submitting your port
 to the project? Don't feel like you have to of course, but new architectures
 are always interesting so I thought I'd ask :-)


 Yes, the full test suite passes.
 The most complicated task in porting was to adjust the stack sizes of the
 test suite so the stack wasn't overrun *before* stack checking could detect
 it 8-) .

 Another idea came to my mind then:
 What about

 add a field POINTER stack_limit to the TCB. E.g. for an architecture with
 stack grows downwards that describes the bottom of the stack.
 the architecture dependent task switcher could do a rather *cheap* overrun
 check when switching stacks on *each* switch
 the port can put a magic word there or just compare pointers on its own
 discretion
 that is much less overhead (and of course a much less rigorous checking)
 than full stack checking but it's frequent
 these extra fields could be added by a preprocessor macro e.g.
 PORT_TCB_EXTRA_FIELDS. That would avoid permanent overhead for all ports.


 Right now the processor is for demonstrating Venray's IP and currently it's
 all simulated (cgen, gdb's sim, sid  friends). When the processor hits the
 road will submit the port for sure.

 Thank you for creating and sharing atomthreads.

 Regards
 Holger